Moving CV in MP
-
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
-
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
No, that’s not what I meant. Not like the tanker where ownership is passed from one to another.
I meant each one has his carrier ALL THE TIME. They may not be prefectly synchronized but while in carrier ops (start and end of that to be defined) the position of every aircraft is transmited with a coord system based on the carrier, not the world.
For example, I am at 1,5NM bearing 090 from my carrier. My position is transmited to another player and my aircraft is placed at 1,5NM, 090 of his carrier. Our respective carriers may not be on the same spot, but we will see the other planes correctly placed around my carrier as long as de carrier ops last (from abeam to launch for example).
Not even know if it is possible or if it makes any sense from a coding point of view, but that’s what I meant…
-
No, that’s not what I meant. Not like the tanker where ownership is passed from one to another.
I meant each one has his carrier ALL THE TIME. They may not be prefectly synchronized but while in carrier ops (start and end of that to be defined) the position of every aircraft is transmited with a coord system based on the carrier, not the world.
For example, I am at 1,5NM bearing 090 from my carrier. My position is transmited to another player and my aircraft is placed at 1,5NM, 090 of his carrier. Our respective carriers may not be on the same spot, but we will see the other planes correctly placed around my carrier as long as de carrier ops last (from abeam to launch for example).
Not even know if it is possible or if it makes any sense from a coding point of view, but that’s what I meant…
when you will be flying close by and this transition will take place crash boom the one to the other.
This is why I said transfer the carrier in the first place. The carrier is the point where the center of the world should be. And the issue is the carrier movement not the planes movement in the air. Now for AI on the carrier a strong magnet is needed. and the relevant position calculation for the humans.
Z axis is flat on USA ones the problem might be with USSR that have the curve at the front of the ship. This is also constant. Get the path and glide from the 3d model like declare the polygon vector xy margins and the z, exactly the same as the terrain in Falcon, that way the moving aircraft will respect and glue on this carrier terrain, If out side the margins ooops drop to sea.
Their speed must be their speed minus (or plus) the carrier speed with respect to angle differentiation. example the airplane taxis vertical to the carrier path then u must not subtract the speed, if the plane taxi the opposite way to carrier path and if the plane taxis the same as the carrier, those for display purposes.Objects on the carrier are child’s of the carrier, carrier is the parent. child’s travel on the carrier as in ground terrain, the parent is traveling with vector and speed. For all aircraft on the carrier the carrier is not actually moving they all have a common ground which is that polygon with the margins. Outside those oooopps.
-
when you will be flying close by and this transition will take place crash boom the one to the other.
Yes, that’s why I said that the transition should happend on the abeam position and right after launching, you will never be close to any other plane on those moments
-
…because the carrier is rotating into the wind to catapult and recover aircrafts…
So don’t allow the carrier to change course, either just set the winds to match the carrier or set the carrier course to match the wind. Or just land in a cross wind like a man.
-
So don’t allow the carrier to change course, either just set the winds to match the carrier or set the carrier course to match the wind. Or just land in a cross wind like a man.
…
It’s a joke I guess right (?)
-
Well, when the carrier doesn’t move, we may have crosswind too
Which most navy pilots aren’t accustomed to -
@Red:
Well, when the carrier doesn’t move, we may have crosswind too
Which most navy pilots aren’t accustomed toNope
Most of the time there is no player on the deck
When the first player to come back ask for carrier recovery the carrier turns into wind
When the first player lands , the carrier freezes which means it will stay in the wind for the others anyway
-
And that’s where you’ll find TE builder like me who will induce a windshift in the TE just as that perfect moment, like in real life
-
@Red:
And that’s where you’ll find TE builder like me who will induce a windshift in the TE just as that perfect moment, like in real life
That is not a problem , the carrier adjust real time as long as no player
Most of the cases case1 recovery means less than 1.30 minute between aircrafts , you will need to be extra precise
Besides you have no idea when the first player will land
-
Yes, that’s why I said that the transition should happend on the abeam position and right after launching, you will never be close to any other plane on those moments
And how that solves the problem?
U r 100ft to the right and the transition puts u 100ft left. What will happen?Στάλθηκε από το MI 5 μου χρησιμοποιώντας Tapatalk
-
Judging from the BMS devs posts guys…
Its really a matter of the fact that Carrier movement is non deterministic.
It HAS to be deterministic on all clients.
It means that the EXACT position down to probably at least 4 decimal points of accuracy I assume depending on how many points of float accuracy the FM uses.Getting deterministic behavior of non playable entities is not easy and if it is not implemented from the beggining may take a considerable reworking of the code.
The reason why just setting points is not enough is because not only does it need to go to the other point but at every physics step all clients have to be at the exact same point at every physics time step.
Floating Points calculations are not deterministic by default and being off by .00005 on one calc on that machine very quickly starts to create divergence.
This has to be taken into account in order to get deterministic behavior.
Furthermore I am going to go out on a limb and say that BMS does not have a synced physics timestep? This would be required to get networked deterministic behavior when two clients are interacting with host entities.Given that the implementation of this would be something like…
1. Host sets initial conditions for carrier with no one on the carrier prior to Host allowing players to spawn. (if you can acheive determistic behavior by implementing fixed framerate physics)
2. Player spawns
3. Deactive the suspension of aircraft… simplified FM while on carrier (use some simple movement style)(Also recommended is to not use dead reckoning while on carrier just sync position and rotation relative to carrier as origin similar to FPS)
4 Player can move to the catapault
5. Players can takeoff.
6. Once gear has left carrier return to Dead Reckoning and advanced FM
7. When return for Landing
8. Player one calls for landing
9. Host now sets carrier to deterministic direction of wind and locksteps the carrier position with all clients
10. Player one lands
11. Player one after caught by wired is acheived now back to simple FM
12 Player one switched fro Dead reckoning to positional updates from origin of carrier.
13. Player two … repeat 10 - 12There is a lot of steps there and a lot of hoops to be jumped… a lot of code probably would have to be re written.
Maybe now is not the time to rework the entirety of the MP code because the pay off is too small.
If there becomes more and more reason to do it might be worth it.Personally before this I would choose alot of other things first. As nice as it would be.
Id rather see more detailed ECM warfare better that also works in MP and other things.
Probably for now its better to just live with it? I dont know the implementation of BMS MP code so just what it seems to me.