Ff you could have one thing in the next update it would be…
-
Client 2 is airborne and doesnt need to have smooth movements of guys still on the carrier. Client 1 still is on the deck and would like it, but doesnt need such DR code for stuff off the carrier while he is taxiing.
I believe the system I described is used by several unity games for a different reason, so I dont think its impossible - though whether its feasible or would even help I have no idea.
-
Do you know how DCS solved that matter (if they did solve it, that is) ?
-
Client 2 is airborne and doesnt need to have smooth movements of guys still on the carrier. Client 1 still is on the deck and would like it, but doesnt need such DR code for stuff off the carrier while he is taxiing.
I believe the system I described is used by several unity games for a different reason, so I dont think its impossible - though whether its feasible or would even help I have no idea.
Science fiction
-
Do you know how DCS solved that matter (if they did solve it, that is) ?
no i dont and i wondered of course…. …
the best way would be to have a “local” carrier for every client, and to make the local entities use the local speed of the local carrier rather than the networkd inherited speed…that would mean a transmission on the network of the relative speed rather than absolute speed …
so from the local carrier speed, we would add the relative speed from network which should be OK then (at least myuch better)
but that suppose some kind of possible discontinuity at take off / landing (may not visible).
and that supposed that the same object could be drawn on every local machine with its own speeds and angles …which is something totally in contradiction form the way Falcon4 heart is managed, I.E the same objects should be computed on every local machine …without network transmission…
all of this means => Total HACK / fake things locally…
=> Totally out of our scope at that point…but i wonder if i could do some voodoo magic like that
-
To make you understand better :
Take the AAR / Tanker as an example …
TO be able to refuel in MP , the tanker entity is controled via the one refueling, so the control is transfered from client to client… which is fine since only 1 client is refueling at a time…
The parallel with the carrier is that we have several clients on the same objects in the same time…
imagine a 3 basket refueling on the same tanker, clearly, the 2 others that dont “own” the tanker would suffer the Lag from the network …
-
then it has to pass to the server and not to the client…
-
then it has to pass to the server and not to the client…
you missed the point…host or client is the same problem…
As long as the object is controled by someone else that YOU, you will see it lagging … think about AAR with 3 aircraft trying to refuel on the same tanker…
-
I miss something : other humans (i.e not controlled by me) are smooth enough in multi to fly in close formation with them, with no lag or aberration in position, etc. Why is it different with the tanker ?
-
I miss something : other humans (i.e not controlled by me) are smooth enough in multi to fly in close formation with them, with no lag or aberration in position, etc. Why is it different with the tanker ?
Even if this is smooth from a user POV, the reality is that there is a Lag between aircraft, but nobody see it since all of this is dynamic and nobody flies next to the other physically.
BUT when you need extra precision for AAR you may see some problem… a small lag and you would be disconnected immediatly
Of course the Tanker beeing computed with DR code, it MAY be possible that in stable situation with very very small lantecy on the network you could refuel on a remote Tanker…but a single lag would result in a disconnect
But as i said, ground objects are not DR computed, and even if it was the case, there would be some small shaking …which i think would be very very ugly on a carrier deck…
-
In next update all i want for christmas is fps optimization :).
Mostly when i turn on that danm TGP lol
-
In next update all i want for christmas is fps optimization :).
Mostly when i turn on that danm TGP lol
you got the point : for christmas, get a nice new CPU and GPU and you will get your fps optimzation
-
I have top chime in on this and give my 2 cents for what it’s worth.
I get it Mav,
The carrier is moving, the player (host) is turning up his/her jet. The jet is static, but the carrier is moving. Hit box (or object) is moving with the carrier, but the jet is static because it is not moving on the deck. The MP players (clients) are turning up there jets. The carrier is moving from the hosts perspective. The carrier is static from the clients perspective because there would be an enormous amount of “hand shaking” between host and client for a moving carrier. NOW, you start to taxi. The host taxi’s on a moving carrier. The host is moving on a moving carrier. The MP’s (clients) are now taxing on a moving carrier. The “hand shaking” connection gets loaded up and you get lag. Like you said Mav, that kind of lag gets real messed up because of all the positional information that has to be exchanged (i.e. hand shaking between computers). I am wondering if you still have any hair left???
:fart:
1 possible solution I thought of that might help (or not) would be to have the host and clients on a static carrier with the world moving around it (like previously mentioned) much like the airbase structure. Once a jet is launched from the carrier, the jet that is now airborne, would see a moving carrier that is animated. It looks like the deck of the carrier he/she just launched from but it is a simple “in game” animation. It does not show any other client’s actual positions. Instead, it shows a jet on the CAT ready for launch (as well as other static deck objects). Once another client launches, the animation shows a jet being shot off the deck. Once that jet is airborne, the clients position is updated as usual. All MP’s in flight see each other when airborne. Think of the carrier as a small bubble. Outside the bubble, you see an animated representation of what you just launched from. For those still on the deck, the see the airborne jet with no problems (as I get this). Once inside the bubble, you see all the MP’s together taxing on the deck (a static deck with the world in motion around them). But once airborne, you see an animated representation of what you were launched from.
NOW, trapping! I envision the same, but in reverse. The MP flight is marshaled. When each jet enters into the pipe (LSO approach G/S @ 1/4 mile), the approach is in real time for each jet, but the MP’s (marshaled) see an animation of a jet approaching and trapping. Bolters would have to be yet another animation they would see when that event happens, as well as a crash or barricade type landing.
The carrier would need it’s own bubble so to speak. I don’t know if that could be done, but it is something I thought about after reading all of this. This same technique could be used for other things. It would significantly reduce the hand shaking between computers in MP. Just my 2 cents here. Any thoughts???
-
Lol i have a decent pc
would be cool if it was possible to increase fps though.
I haventryed every thing all the tips suggested etc yes i gain some fps but if i put the tgp on then forget it lol.I get decent fps any other time eg 50-60 etc
-
So the code must be forgiving on small lag frames. If the lag is higher than a limit then disconnect him.
-
So the code must be forgiving on small lag frames. If the lag is higher than a limit then disconnect him.
I think Mav kinda said that already. After a certain point, lag will drop you. When playing games online, it is like taking a dump. Try to put too much TP in the toilet, and the toilet will overflow kicking out all the crap!
-
I have top chime in on this and give my 2 cents for what it’s worth.
I get it Mav,
The carrier is moving, the player (host) is turning up his/her jet. The jet is static, but the carrier is moving. Hit box (or object) is moving with the carrier, but the jet is static because it is not moving on the deck. The MP players (clients) are turning up there jets. The carrier is moving from the hosts perspective. The carrier is static from the clients perspective because there would be an enormous amount of “hand shaking” between host and client for a moving carrier. NOW, you start to taxi. The host taxi’s on a moving carrier. The host is moving on a moving carrier. The MP’s (clients) are now taxing on a moving carrier. The “hand shaking” connection gets loaded up and you get lag. Like you said Mav, that kind of lag gets real messed up because of all the positional information that has to be exchanged (i.e. hand shaking between computers). I am wondering if you still have any hair left???
:fart:
1 possible solution I thought of that might help (or not) would be to have the host and clients on a static carrier with the world moving around it (like previously mentioned) much like the airbase structure. Once a jet is launched from the carrier, the jet that is now airborne, would see a moving carrier that is animated. It looks like the deck of the carrier he/she just launched from but it is a simple “in game” animation. It does not show any other client’s actual positions. Instead, it shows a jet on the CAT ready for launch (as well as other static deck objects). Once another client launches, the animation shows a jet being shot off the deck. Once that jet is airborne, the clients position is updated as usual. All MP’s in flight see each other when airborne. Think of the carrier as a small bubble. Outside the bubble, you see an animated representation of what you just launched from. For those still on the deck, the see the airborne jet with no problems (as I get this). Once inside the bubble, you see all the MP’s together taxing on the deck (a static deck with the world in motion around them). But once airborne, you see an animated representation of what you were launched from.
NOW, trapping! I envision the same, but in reverse. The MP flight is marshaled. When each jet enters into the pipe (LSO approach G/S @ 1/4 mile), the approach is in real time for each jet, but the MP’s (marshaled) see an animation of a jet approaching and trapping. Bolters would have to be yet another animation they would see when that event happens, as well as a crash or barricade type landing.
The carrier would need it’s own bubble so to speak. I don’t know if that could be done, but it is something I thought about after reading all of this. This same technique could be used for other things. It would significantly reduce the hand shaking between computers in MP. Just my 2 cents here. Any thoughts???
any thoughts ? yes… totally unrealistic method
anyway enough of talk here this is 'not a dev forum sorry for thread hijack
-
Hi
I don’t know if my wish was already mentioned: a working “rate of turn indicator” on the ADI would be pretty awesome for IFR flying, especially approaches and departures
Is it hard to “activate” it? -
how about SAMs like the SA15 or some ships being able to intercept bombs too?
-
Hi
I don’t know if my wish was already mentioned: a working “rate of turn indicator” on the ADI would be pretty awesome for IFR flying, especially approaches and departures
Is it hard to “activate” it?I thought this was already working - the ball is your slip indication, and the bars beneath are your rate of turn, right?
-
Huh. I havent even looked at the turn and slip indicator for BMS. Just relied on the ADI. Didnt think it worked for some reason, but I dont think Ive ever checked, either.