Why would you have left FAF?
-
yeah it all basic lockstep, but it uses some proxy like host-server (that doesn't run it's own simulation), that decides how fast the simulation runs, who is out of sync and it can somehow reorder the clients inputs.
Also apparently the lag just increases for slower cpus over the whole game timeplayers with slower-than-average CPU's will fall further and further behind the reference time but can stay ingame with increasing order latency
I don't know how long bar games can last, but a lot of supcom games are played on minus-speed for extended periods of time, so this approach also might break the game for a lot of people
-
yeah if I understand this correctly it essentially means that people will fall behind further and further until they are several minutes behind. So this doesn't sound like a feasible solution at all.
-
@blackyps said in Why would you have left FAF?:
yeah if I understand this correctly it essentially means that people will fall behind further and further until they are several minutes behind. So this doesn't sound like a feasible solution at all.
But this does mean that game only lags for a lager instead of lagging for everyone and game does not freeze when someone has lost connection.
it also may be considered to not be feasible that everyone lags when 1 of the 16 players lags.
it also allows players to spectate the game without lagging it to much
in Beyond all Reason i have seen as much as 50 spectators in 16 vs 16 game, or about 60-70 in 8v8 game
yes it does mean that you can fall behind by any number of seconds or minutes
but it does sound fine to me for casual games
in comparison for game being unplayablealso in BAR 8v8 someone can crash for example on minute 30
and players can decide to wait for him to launch the game again and catch up or just take his units and keep playing and if he will logs in again and load the game again and catch up to other players they can give him his base back.in tourneys i see this fall behind feature be less desirable... but can probably make game pause automatically if players fall behind more than by 2 sec or something like that.
in case of sim lag i think in BAR it works that game does slow down to wait slow PC players but not always... it depends and idk how exactly it works there
Tho idk why were are discussing this here... don't think we can add this functionality to FAF
TA4Life: "At the very least we are not slaves to the UI" | http://www.youtube.com/user/dimatularus | http://www.twitch.tv/zlo_rd
-
@zlo said in Why would you have left FAF?:
it also allows players to spectate the game without lagging it to much
That's basically how FAF Live replays currently work.
You have some server that gets all the info from the players saves that and then distributes it to all spectators at a slower rate.@zlo said in Why would you have left FAF?:
also in BAR 8v8 someone can crash for example on minute 30
and players can decide to wait for him to launch the game again and catch up or just take his units and keep playing and if he will logs in again and load the game again and catch up to other players they can give him his base back.Yeah a reconnect mechanic would be cool, but I don't think you can somehow get the game to load a replay, then after some time swap from watching replay into one of the players positions and then somehow make the game believe you are actually connected to an online lobby playing this game, without a lot of work on the engine side.
@zlo said in Why would you have left FAF?:
in case of sim lag i think in BAR it works that game does slow down to wait slow PC players but not always... it depends and idk how exactly it works there
From the link above it seems like it balances the speed around the average cpu rating of all players and people slower than this might fall behind.
@zlo said in Why would you have left FAF?:
Tho idk why were are discussing this here... don't think we can add this functionality to FAF
Well lag and desyncs are something that make people quit the game, but yeah fixing it is probably out of scope of FAF (for now).
But discussing the solutions other projects use is kinda fine here I think. Better than just telling people that make those suggestions "it won't work." without any explanation. -
@nex said in Why would you have left FAF?:
@blodir the current tick rate is 100ms tho, so doubling(halving) that to 50ms will only give you a marginal increase in responsiveness compared to the current 150(?) ms of input lag
Current inputlag is 500 ms
(BAR players say that they don't like that aspect of FAF)
-
@zlo said in Why would you have left FAF?:
Current inputlag is 500 ms
huh interesting
my brain somehow had this number 150 saved for some reason.
Well with 500ms input lag assuming the sim tick "lag" comes on top that is currently 50ms on average (100 max) so you could reduce the input lag by 5-10%, by doubling the sim tick rate.
Doesn't sound like a good trade tbh. -
@nex said in Why would you have left FAF?:
@zlo said in Why would you have left FAF?:
Current inputlag is 500 ms
huh interesting
my brain somehow had this number 150 saved for some reason.
Well with 500ms input lag assuming the sim tick "lag" comes on top that is currently 50ms on average (100 max) so you could reduce the input lag by 5-10%, by doubling the sim tick rate.
Doesn't sound like a good trade tbh.i think the inputlag is mostly defined by the ping that users usually get.
i am not sure but it is just if ping is higher than inputlag then the game will start to feel laggy, choppy and stuff like that. -
I mostly skimmed through the most recent messages but two things - I think Blodir said this but networking code is separate, so that would be much easier to fix if we had source code access and wouldn’t take a full game engine rework iirc.
A rather important detail that I haven’t seen mentioned though: even if, and that’s a very big, expensive, and unlikely if, we got the rights to SC:FA that doesn’t mean we get the source code. Afaik our current understanding is that the original source code is lost. Meaning we’d still be stuck with assembly patches and reverse engineering which does us little good and makes getting the rights to SC a moot point in terms of making game engine/networking related improvements.
-
@nex said in Why would you have left FAF?:
@zlo said in Why would you have left FAF?:
Current inputlag is 500 ms
huh interesting
my brain somehow had this number 150 saved for some reason.
Well with 500ms input lag assuming the sim tick "lag" comes on top that is currently 50ms on average (100 max) so you could reduce the input lag by 5-10%, by doubling the sim tick rate.
Doesn't sound like a good trade tbh.This is not correct. Here's some approximations for magnitudes of different latencies:
- Sim/physics update/input sampling. Note, as I said earlier, that the worst case scenario is that the length is doubled for an input! So if supcom runs at 10hz (which idk if it does) that would be worst case of 200ms delay! (or more, if the inputs are scheduled to be processed at an even later tick)
- Framerate, monitor offsync with framebuffer and vsync. This on the scale of <16ms for 60fps.
- Display lag, input devices, drivers, and so on. <5ms
Network latency between two players with reasonable ping is not at all relevant, because the sim tick rate dominates!
Like say you are playing an 1v1 game with someone with a direct connection (without proxy). You can tell from experience that you still experience a comparable amount of input lag. Keep in mind that ping refers to round-trip-time. So if you have 40ms ping between two players, that would amount ot only 20ms one-way latency. So when you are sending an input packet at tick
nthat is destined for tickn+1, the other player will receive it 20ms later - even though, assuming 10hz tickrate, there's still 80ms of the tick left! So we can easily expect that at low ping and slow sim rate contexts network latency is practically irrelevant.Also note that if someone is late, the time window might be extended multiple ticks in the future so eg. inputs collected at tick
nwould be processed at tickn+2instead ofn+1. A higher sim tick rate gives more flexibility in this sense, where a slower one introduces a large additional delay in the worst case. -
Unless we plan on re enginein faf into spring I'm not sure how this benefits us at all or the topic of players leaving
-
@ZLO @Blodir @Nex @BlackYps We're completely lost in our dreams XD. We have not yet found a HERO who will negotiate on behalf of FAF. Legal and diplomatic challenges seem more difficult.
We need a hero)
But there's no harm in dreaming, so let's continue)
@zlo said in Why would you have left FAF?:
yes it does mean that you can fall behind by any number of seconds or minutes
but it does sound fine to me for casual games
in comparison for game being unplayableI note that it is assumed that all players will play through the coturn server and there will be no peer-to-peer connection. Therefore, at the stage of connecting to FAF, we can detect the loss of packets when connecting to the coturn server. I think this solution will already weed out 90% of lagers whose pockets are lost. And the SpringRTS network system that we are discussing will eliminate micro-lags.
As I understand it, if you experience a lag, this does not mean that you will lag behind the entire game; if you have new hardware, for example i3-12100 (good single-threaded performance), then in theory you will catch up with the rest very quickly.
-
@nflanders said in Why would you have left FAF?:
@ZLO @Blodir @Nex @BlackYps We're completely lost in our dreams XD. We have not yet found a HERO who will negotiate on behalf of FAF. Legal and diplomatic challenges seem more difficult.
We need a hero)
But there's no harm in dreaming, so let's continue)
@zlo said in Why would you have left FAF?:
yes it does mean that you can fall behind by any number of seconds or minutes
but it does sound fine to me for casual games
in comparison for game being unplayableI note that it is assumed that all players will play through the coturn server and there will be no peer-to-peer connection. Therefore, at the stage of connecting to FAF, we can detect the loss of packets when connecting to the coturn server. I think this solution will already weed out 90% of lagers whose pockets are lost. And the SpringRTS network system that we are discussing will eliminate micro-lags.
As I understand it, if you experience a lag, this does not mean that you will lag behind the entire game; if you have new hardware, for example i3-12100 (good single-threaded performance), then in theory you will catch up with the rest very quickly.
I will do it, what's the budget?
-
@nflanders I like how you just ignore when I say we've already tried this. We've already had a very well off person who had connections that tried this. It didn't work. Even if it did, the source code is lost as far we know and that was from years ago. Meaning it's even less likely to be around now. Unless we've got someone willing to cough up millions and has some good lawyers what you're saying just simply isn't going to happen. Even if you've got that, it's still highly unlikely as it has already not worked once.
Even if you somehow managed to make this happen, this being getting the full rights to the supcom name, the only thing that would really make sense at this point is a Supcom 3 game that's closer to SC:FA than SC2. And if in this hypothetical you make it a subscription based platform as you seem to be suggesting for FAF then, well, I have no words for how much I'd hate that for a game like Supcom. No words that won't get me banned at least.
-
@exselsior said in Why would you have left FAF?:
the source code is lost
I guess the forever part of the project can be laid to rest with this.
-
@melanol said in Why would you have left FAF?:
@exselsior said in Why would you have left FAF?:
the source code is lost
I guess the forever part of the project can be laid to rest with this.
FAF is still going even without the original source code, or rights to the supcom IP for that matter, so not sure why that would be the case.
-
@exselsior It can be called life support without source code.
It's really hard for me to explain that you need source code to properly do things in programming.
-
@melanol I'm a software engineer, I'm well aware of how this works. FAF is intended to keep SC:FA alive. It's doing exactly that. Not sure what your point is. Sure some things are harder/basically impossible due to no source code access, but that hasn't kept FAF from succeeded at keeping a community alive for years. It won't be a lack of access to source code that eventually kills FAF.
-
Supcom has an inbuilt input latency, which is independent from both the sim latency(which comes on top, if at all) and network latency(which the input latency is meant to compensate for).
so no matter how good your ping is you will have those 500ms of input lag. this could in theory be a variable lag, but from what I can remember it's fixed (and apparently to 500ms), to make every game feel consistent.
so every tick (or possibly every frame) the game collects your inputs for tick n+5 and sends them to all other players.
At tick n+5 the game checks if it received inputs from all players and if not pauses.
So these 500 ms are currently fix. assuming the game might take about 100ms to send your inputs(if it gathers them all over the course of a tick and then sends them once) then you get up to 100 ms of extra lag (if you press right before it's send you get 0ms, if you press right after a send you get 100 ms extra lag), so on average that is 50 ms lag, which you could halve by doubling the sim rate, so you'd gain 25ms on average but the 500ms (which is chosen so that players with a ping of up to 250ms to each other can play together) will always come on top of that, so the net gain is between 5-10%so tl;dr there is a 500ms inbuilt lag to compensate for any network lag, which overshadows any amount of lag introduced by the sim tick rate.
-
Without the source code I'm sure you would have to re engine supcom, which would only cost.....a lot
-
@nex said in Why would you have left FAF?:
Supcom has an inbuilt input latency, which is independent from both the sim latency(which comes on top, if at all) and network latency(which the input latency is meant to compensate for).
so no matter how good your ping is you will have those 500ms of input lag. this could in theory be a variable lag, but from what I can remember it's fixed (and apparently to 500ms), to make every game feel consistent.
so every tick (or possibly every frame) the game collects your inputs for tick n+5 and sends them to all other players.
At tick n+5 the game checks if it received inputs from all players and if not pauses.
So these 500 ms are currently fix. assuming the game might take about 100ms to send your inputs(if it gathers them all over the course of a tick and then sends them once) then you get up to 100 ms of extra lag (if you press right before it's send you get 0ms, if you press right after a send you get 100 ms extra lag), so on average that is 50 ms lag, which you could halve by doubling the sim rate, so you'd gain 25ms on average but the 500ms (which is chosen so that players with a ping of up to 250ms to each other can play together) will always come on top of that, so the net gain is between 5-10%so tl;dr there is a 500ms inbuilt lag to compensate for any network lag, which overshadows any amount of lag introduced by the sim tick rate.
Yes, I talked with Jip yesterday and he confirmed that inputs are scheduled for 5 ticks in the future. It's possible to (almost) completely eliminate this by scheduling the inputs at a proxy server like sc2 (or seemingly BAR). Basically they asymmetrically schedule inputs based on latency, such that people with high ping to the server have higher input lag than those with low ping to the server. So in those cases input lag is totally dominated by sim tick length.
I get what you are saying now though, I thought you were saying that there's some nebulous other source of input lag or that network latency dominates, which is not true. It's just a somewhat arbitrary value of 5 ticks chosen to be acceptable by gpg in order to avoid writing dynamic scheduling logic x) Even in pure p2p it should be easily possible to communicate input scheduling changes based on latency (though then the scheduling has to be synchronous).
