Quote from: WALKEN on April 07, 2016, 07:47:40 PMI believe if you want a true simulation you also need a real bike as the controller.
In my opinion, a dual-axis force feedback handlebar controller + foot controls + sensor seat pad (+ Oculus :D) would be sufficient to be counted a "true simulation".
@PiBoSo
Obviously nobody at the moment is even close to GPB and seeing how many betas and test riders it took to get to the current stage, it might take a while until there is something close.
Still, I feel like communication could be better sometimes :P For example, my simple question on why the Varese's crankshaft(s) is set to counter-rotating or how long it took you to join the discussion on the lowside bug.
BTW, in comparison to other games, GP Bikes uses very high bandwidth and the replay size (and the lags when viewing other players) makes me wonder what data is actually being transmitted.
Would you care to elaborate on that?
The only problem I have with the replays is that the wheels lift way off the ground when bikes flip from left to right or vice versa.... otherwise I have no issues with lag or stutters.
Hawk.
Quote from: vin97 on April 08, 2016, 12:37:41 AM
BTW, in comparison to other games, GP Bikes uses very high bandwidth and the replay size (and the lags when viewing other players) makes me wonder what data is actually being transmitted.
Would you care to elaborate on that?
Interesting!
What games are you comparing GPB to?
On the client or on the server side? Or both?
Could you please provide some numbers?
With or without the dynamic track surface?
Quote from: HornetMaX on April 08, 2016, 08:18:42 AMbut what's the big deal with the varese crankshaft ?
It's no big deal but one short response to acknowledge it would be enough.
Quote from: HornetMaX on April 08, 2016, 08:18:42 AMWhy would you want to know that ? I doubt that you (or me), once we have the answer, will be able to suggest something smart to him on that matter.
Don't know. The fact that the game is not able to render the bikes of other players correctly makes me think that there is something that is not optimized. Of course I am only speculating, so don't take this as an insult to your coding skills, PiBoSo ;)
Quote from: HornetMaX on April 08, 2016, 08:18:42 AMMost likely, the high bandwidth comes from the fact the GPB struggles to do the thing properly
What do you mean?
@PiBoSo: Haven't done any proper measurements but I came to the conclusion based on how large the replays are and how much the connection influences the game.
Quote from: PiBoSo on April 08, 2016, 05:31:43 PMSounds great :)
I'll do my best to improve the modding tools.
I have a few suggestions for TrackED, will post them in the suggestions section...
Quote from: vin97 on April 08, 2016, 06:33:28 PM
Don't know. The fact that the game is not able to render the bikes of other players correctly makes me think that there is something that is not optimized. Of course I am only speculating, so don't take this as an insult to your coding skills, PiBoSo ;)
What do you mean with "not able to render the bikes of other players correctly" ?
I haven't seen any problem with that.
Quote from: vin97 on April 08, 2016, 06:33:28 PM
Quote from: HornetMaX on April 08, 2016, 08:18:42 AMMost likely, the high bandwidth comes from the fact the GPB struggles to do the thing properly
What do you mean?
I mean that other games may limit bandwidth and replay size by sending over minimal information that is not enough to properly reconstruct the true status of the bikes. This may not be noticeable all the time, but there's no magic recipe to send a bunch of float in half their proper size.
Quote from: HornetMaX on April 08, 2016, 07:46:09 PMWhat do you mean with "not able to render the bikes of other players correctly" ?
The front wheel / handlebar of other players is always very laggy no matter how low the ping is.
Quote from: vin97 on April 08, 2016, 08:15:11 PM
Quote from: HornetMaX on April 08, 2016, 07:46:09 PMWhat do you mean with "not able to render the bikes of other players correctly" ?
The front wheel / handlebar of other players is always very laggy no matter how low the ping is.
Because it depends on 2 pings: the ping player A --> server and the ping server --> player B. Were they both low ? Were both players having the bandwidth setting to the appropriate level ?
I just checked my replay of the Mugello race again and yes the onboard cameras are basically unusable for race footage because of the laggyness.
...I was spectating Nick who ran the server and my ping never exceeds 30ms on his server.
I should add that this laggyness only occurs when the suspension is working (accelerating, changing direction, etc.).
If the bike is just rolling at a fixed lean angle, the replay is usually smooth. Of course this is a purely theoretical scenario.
Who recoded the replay ? You or the server ?
I recorded the replay.
I have tested all combinations and the replay is only not laggy when viewing the person who recorded the replay.
Try the server's replay, it should be the best one.
Same result. Other bikes are always laggy, I'm not making this stuff up ::)
Quote from: vin97 on April 10, 2016, 01:02:05 AM
Same result. Other bikes are always laggy, I'm not making this stuff up ::)
What's "other bikes" on a replay taken from the server ? ::)
I hosted a session yesterday and did a few laps with Kerazo. Kerazo was the other bike and he had low ping all the time.
Quote from: vin97 on April 10, 2016, 03:16:26 PM
I hosted a session yesterday and did a few laps with Kerazo. Kerazo was the other bike and he had low ping all the time.
The ping is not all that matters. What is your upload speed ?
Local hosting on an ADLS line could be problematic. Better do the test on a real server with good upload speed (like dibu's).
12 Mbps
Look, I can do these tests but it doesn't change the fact that no matter how good your connection is (as a client), bikes of other players will be laggy.
This is not acceptable for an online multiplayer game IMO.
Gotta agree with Vin, the other players bikes lag so badly it can cause crashes at times and is confusing too. In replays it can look so bad its a joke!!!
I have 50MB/s internet going to 70MB soon, still dont matter if another has a bad ping.
DD
Quote from: vin97 on April 10, 2016, 04:02:02 PM
12 Mbps
Just to be sure, that's the upload speed (and not the download one) ?
Quote from: vin97 on April 10, 2016, 04:02:02 PM
Look, I can do these tests but it doesn't change the fact that no matter how good your connection is (as a client), bikes of other players will be laggy.
They will be laggy if their own connection (othe rplayers) is poor and/or if the server's connection is inadequate.
Some lag is inevitable due to the network: that's why you have lan parties :)
In online FPS it's way less visible because the objects moves slower than our bikes and hence the client side prediction can work better.
But if there's something to improve about that I'd be happy if it could be done. I just can't be as sure as you seem to be that there's is definitely something to do better.
It is upload.
But lag at 25ms ping?
I will definitely test it with a LAN, if it's still laggy I think you would agree with me that something is wrong/unoptimized.
Quote from: vin97 on April 10, 2016, 04:37:44 PM
It is upload.
But lag at 25ms ping?
Player A to server = 25ms
Server to player B = 25 ms
So we have 50ms of ping only: you should sum the time it takes to actually send the data and the time the server takes to process data (and the time the clients eats up in generating / processing the data).
But let's keep it at 50ms. Now try to do the math: if a bike is travelling at 360Kmh, how far will it travel in 50ms ?
Now you see it's not only a matter of "how much data GPB sends out".
Quote from: vin97 on April 10, 2016, 04:37:44 PM
I will definitely test it with a LAN, if it's still laggy I think you would agree with me that something is wrong/unoptimized.
It would surely be a stringer argument.
Quote from: vin97 on April 10, 2016, 04:37:44 PM
It is upload.
But lag at 25ms ping?
I will definitely test it with a LAN, if it's still laggy I think you would agree with me that something is wrong/unoptimized.
Raced with my brother a few beta's ago via LAN and had the same bouncing tire issues. I'll try to dig up the replay in a second here.... doesn't seem to show it as much as I remember it, I think it's due to discarding all the footage that looked super messed up due to it, but there is a few instances where my brother (bike behind me in all the vids) didn't have anything odd on his end of things (with his bike, on his end mine was doing the bouncing thing in replays).
(I don't feel like screwing around with trying to embed this video, just click the link if you care to see the example.)
https://www.youtube.com/watch?v=tZHP3JEFc7w
I was the host, so only 25ms from Kerazo to me.
Thanks, grimm. The suspension lag is definitely there (most visible in the last clip) although it would be much easier to see from onboard view.
Quote from: HornetMaX on April 10, 2016, 04:52:20 PMBut let's keep it at 50ms. Now try to do the math: if a bike is travelling at 360Kmh, how far will it travel in 50ms ?
Now you see it's not only a matter of "how much data GPB sends out".
Of course there has to be a short delay (resulting in a small offset of the bike position) but there shouldn't be gaps where the game is completely ignoring the actual user input (and physics engine output) and instead keeps the suspension and handlebar at a fixed position until it decides to abruptly move it.
Quote from: vin97 on April 10, 2016, 05:31:39 PM
Of course there has to be a short delay (resulting in a small offset of the bike position) but there shouldn't be gaps where the game is completely ignoring the actual user input (and physics engine output) and instead keeps the suspension and handlebar at a fixed position until it decides to abruptly move it.
These are typical of network instability.
Ping is one thing, but then you also have jitter: if the data from a client (or from the server) doesn't come in very regularly, then the client will have to predict (more than the usual) where the bike will be (in absence of new data from the server). On fast movements this can be a problem.
But I see what you're saying, I'm not saying the problem is not there. I'm just saying that it may not be something you can solve easily: to properly describe the status of a bike you need a bunch of float. When you have N bikes, you multiply by N. You can hit network issues pretty quickly and prediction can work only up to a point.