Moving CV in MP
-
This post is deleted! -
The carrier trajectory - route can be sent to clients by intervals of x time or x distance. It will be a host created vector route with points from a to z. Those points could be auto created or drawn in MC.
Before it reaches z the server will share the next set of points. Why not the whole route? Maybe it’s threatened and has to change course.
And super sexy to abort or go around cause a tanker ship would refuel it. Do they do it or nukes cover it all these days?Στάλθηκε από το MI 5 μου χρησιμοποιώντας Tapatalk
-
@MortelSil In the example you gave about pedestrians this would typically be done with deterministic existence / movements of NPCs… it only needs to be synced if more than one player interacts with it.
If not no need to sync it all. This would be game dependent of course how vital it is to be synced etc…@Arty this would work if the MP implentation has a concept of frames. Otherwise just sending that information would not be enough it would need to be sent along with what frame since 3d world start to put it at X.
And all clients could than insure that happens at time Y. Deterministic. You could also as you said send course changes so long as all the changes were sent with frame information.Its subject to the butterfly effect cause basically your dealing with a time machine .
One small mistep and over time the divergance becomes greater and greater.
So yes its doable depending on the FALCON MP implementation.
But even with the proper implementation would still be tricky dicky. -
I confirm that after several years of attention, moving carrier in MP is a no go
This is simply impossible without seeing clients sliding between each other because of network inherent lag
To be clear
Carrier movement is feedert into the local aircraft FM
If carrier movement is not EXACTLY the same for each client , then each aircraft will compute locally the FM windifferent values
It is impossible (with my knowledge) on a network to anticipate the lag perfectly , DR code is only evaluating it, so even with the best DR code and very smooth and slow carrier movement , the network lag will provoke “shaking” on the deck between the aircrafts that are on the deck
What I did though is that carrier are in MOVEMENT now as long as A player is not on top of it
That means the first player to land has the chance to land on a moving carrier , even in MP
If he leaves the Game before the second client lands, the second client will see carrier moving as well
Believe me I lost many brain cells on that one
I think this is doable though like in arma when players enter in the same moving vehicle , I don’t know how they do though , I believe the computation of the soldier movement is more simple than a FM
-
Shit I may have an idea
Maybe the idea would be to make every FM calculation for players on the deck ON THE HOST and ship the result with standard aircraft DR code which is very good in BMS
Mmmmmmmmmmhhhhh……(BRAIN) cells frying again)
-
Shit I may have an idea
Maybe the idea would be to make every FM calculation for players on the deck ON THE HOST and ship the result with standard aircraft DR code which is very good in BMS
Mmmmmmmmmmhhhhh……(BRAIN) cells frying again)
Shit no
In that case the clients will se OK between each other but they might see the carrier shaking then
Enough ! I don’t want to talk about this anymore for now !!!
-
I wonder how VRS got it to work in FSX with the TACPACK. Before that, moving carriers in MP were a no go in FSX…
-
-
I wonder how Apache longbow did it some xx years back when we didn’t even had ADSL but dial up lines.
@MortelSil In the example you gave about pedestrians this would typically be done with deterministic existence / movements of NPCs… it only needs to be synced if more than one player interacts with it.
If not no need to sync it all. This would be game dependent of course how vital it is to be synced etc…@Arty this would work if the MP implentation has a concept of frames. Otherwise just sending that information would not be enough it would need to be sent along with what frame since 3d world start to put it at X.
And all clients could than insure that happens at time Y. Deterministic. You could also as you said send course changes so long as all the changes were sent with frame information.Its subject to the butterfly effect cause basically your dealing with a time machine .
One small mistep and over time the divergance becomes greater and greater.
So yes its doable depending on the FALCON MP implementation.
But even with the proper implementation would still be tricky dicky.we all synch with the Falcon clock. No need to know the exact frame. I understand what u say but I think of it that way:
Let’s say a gap is created for whatever reason.
Waiting to get the new data continue as the trajectory was, u have all the data.
New data comes but the carrier must warp or jump from one point to the other. No use an algorithm (they exist) to soften the transfer, (like weather now is not on off but transitions from one state to the other) taking in account to have the carrier at the point it should be at the end of the received trajectory, so some speed or a more tight turn…
Now u will say but for one client the carrier will be at point A and for the rest at point B so what? in my world we all are at the same. yeap a compromise to have mp carriers. -
If everyone host his own carrier and from certain moment -the ABEAM call f.e- the aircrafts positions are transmited not in relation to the world but in relation to the carrier and placed in your own sesion in relation to YOUR carrier. Carrier may not be perfectly sincronyzed for the different players, but aircrafts will show properly in “your carrier”.
-
Impossible unless you have an instantaneous (0ms) ping.
?? No such animal exists!!
0ms ping = no ping which is impossible!!
C9
-
ON THE HOST
Don’t know the validity behind my thoughts, but my first call would be something like sync data to the “cloud”, aka server hosting the mission.
Another path might be a simple “Have-Quick logic”, where code pre-calculates behavior of the carrier and what to expect for next 2-3sec (max lag scenario per end-user machine and network) and follow/spread this logic to underneath players.
-
Pretty much we all say - suggest the same thing.
The dev’s have the code and know it’s limitations.
The way to implement and optimize such a thing if you don’t have the experience is another story.It’s not just all to related to the carrier but among other clients also.
Having 2 in the same vehicle is easier I believe, Here u have 3+ The carrier and 2+ humans on different vehicles.
One is on final the other is taxing to clear the way and park and at the same time the carrier is moving, all must see the same thing and interact on the same thing, Something like the clouds and all see the cloud and interact the same way with it. I hide in the cloud the other must see that I entered the cloud and at the same time the cloud travels.So it all must be relational and not actual movements.
For A the carrier is at X,Y 10,10 for B it’s at 11,10 for C is at 10,11
A is on final B is behind C is taxing to park.In that case in a radius around the carrier, maybe triggered by a takeoff or land command by human, all position calculations must be calculated in relation and not actual. The problem is the transition from actual to relational.
Meaning before going relational and while in the air u are at xyz in relational u must be in xyz plus or minus something. How to get from one to the other so it will not warp?
Same could happen while just taxing, 1 on catapult waiting for the other to taxi and take position on the catapult and one passes above to go around, while one comes to go guns on the carrier or Kamikaze…Now on the same time in inclement weather if u want the carrier to go up and down cause of the waves… :lol:
-
The problem is the transition from actual to relational.
Meaning before going relational and while in the air u are at xyz in relational u must be in xyz plus or minus something. How to get from one to the other so it will not warp?The transition when inbound could be done when on the abeam position, maybe with a radio call. You will be alone and away from others players and a bit of warp will not affect much. A fixed radius will affect the possibility of executing initial and breaks in formation.
On the other hand, when being launched the transition should happend pretty fast not to affect the rejoin. Here a pretty small radius could work, the warp would be noticiable for those on the deck, but it would’t have any other effect than visual…
-
If everyone host his own carrier and from certain moment -the ABEAM call f.e- the aircrafts positions are transmited not in relation to the world but in relation to the carrier and placed in your own sesion in relation to YOUR carrier. Carrier may not be perfectly sincronyzed for the different players, but aircrafts will show properly in “your carrier”.
Exactly, same way formation flying is handled…
-
I wonder how VRS got it to work in FSX with the TACPACK. Before that, moving carriers in MP were a no go in FSX…
Moving carriers were never a no-go in FSX, the required APIs have always been there, just nobody released a tool prior to TP (I did have one that worked quite well in our tests but never finished all the features I wanted for a public release [i.e. proper pitching/rolling deck, adjustable FLOLS, manual wave-off lights and MOVLAS for Team SDB carrier, etc]). But in FSX the carrier is just a local object roaming around the scenery, and it is quite simple to just compare its position with the host’s one and apply required corrections. The whole TP is just built on top of that assumption. Also, peer planes already float quite a lot in normal FSX MP, so if such a tool produces any floating/jumping of other airplanes around you it is impossible to discern if it is caused by the tool’s lag or the crappy FSX multiplayer synchronization.
So probably not a useful way for BMS devs to solve the problem here.
-
What if you where to give the carrier a pre-determined path to follow during the mp session? Give it two specific coordinates to travel between at a specific speed that way every system connected to the session will know exactly where the carrier should be at any given moment.
-
This post is deleted! -
If everyone host his own carrier and from certain moment -the ABEAM call f.e- the aircrafts positions are transmited not in relation to the world but in relation to the carrier and placed in your own sesion in relation to YOUR carrier. Carrier may not be perfectly sincronyzed for the different players, but aircrafts will show properly in “your carrier”.
And how do you ensure that each owned carrier has the exact same positioning , speed and rotation speed ?
They need to be synchronized , and synchronized perfectly else you will se some shaking between aircrafts
Look at tanker , the tanker is owned locally when on the boom , and ownership is transferred from client to client
Did you see how the tanker slides sometimes at ownership transfer ?
That would be continuously the case in that case and all aircraft would shake. Relatively to each other
Actually I tested this solution already
-
What if you where to give the carrier a pre-determined path to follow during the mp session? Give it two specific coordinates to travel between at a specific speed that way every system connected to the session will know exactly where the carrier should be at any given moment.
Impossible , because the carrier is rotating into the wind to catapult and recover aircrafts then turn back on its original course
Therefore there is speed and course changing. And that would require perfect synchro on all clients which is impossible due to lantecy => that would shake
Believe me , its better to have a static carrier when several players on it rather than a shaking that ruins the experience