@nflanders
They bought this game for their portfolio.
They may not even know that the game has an audience 
.
Why would you have left FAF?
@exselsior said in Why would you have left FAF?:
You can technically use the client without having supreme commander installed.
That's a big 'technically', given that you CAN'T use the client without having paid for supreme commander on GoG or steam.
(And like nflander's friend, it was really frustrating for me who bought the game decades ago - and I also have friends who bought the game decades ago, but can't play FaF because they didn't buy it again on GoG/steam)
If I'm honest, I bought it really cheap on GoG - about Ā£3... And I honestly like the fact that accounts are linked to purchases, since it stops smurfing on the ladder VERY effectively. But it is a real shame that so many people who bought supreme commander are probably in the position of being unable to play FaF; particularly given that FaF devs don't get paid for supreme commander purchases!
If you bought the game before steam you can get it through steam by sending them you CD key. I bought it when it came out in 2007 and still have the box and CD, still play "through" steam.
If $10 is stopping you from play though idk what to tell ya.
Fetch your CD key, use it to activate it as a game code in Steam, boom valid license.
"Nerds have a really complicated relationship with change: Change is awesome when WE'RE the ones doing it. As soon as change is coming from outside of us it becomes untrustworthy and it threatens what we think of is the familiar."
ā Benno Rice
@redx said in [Why would you have left FAF?]
I'm so confused. What problem are you trying to solve here? You keep making suggestions that seem aimed at bringing in money, but to what end?
Can I solve the problem? Of course not. If there was a person who would try to negotiate cooperation with Nordic Games.
Success largely depends on the character of the negotiator.
This can help solve a very wide range of problems.
Here is the maximum program:
-
Completely solve the problem of lags and disconnections during the game. Ideally, a system like in Beyond All Reason RTS, where only those with a poor connection to the server lag, everyone else enjoys the game. (more details: https://springrts.com/phpbb/viewtopic.php?t=37637)
-
The game can become free on Steam. Will solve the problem with "funnel".
@ftxcommando said in Why would you have left FAF?:
the problems FAF has always had with regards for players isn't retention related, it's funnel related.
Does the negotiator achieve success or not, if someone wants to try why not? The main thing is that the person is competent.
@nflanders said in Why would you have left FAF?:
@redx said in [Why would you have left FAF?]
I'm so confused. What problem are you trying to solve here? You keep making suggestions that seem aimed at bringing in money, but to what end?
Can I solve the problem? Of course not. If there was a person who would try to negotiate cooperation with Nordic Games.
Success largely depends on the character of the negotiator.
This can help solve a very wide range of problems.Here is the maximum program:
Completely solve the problem of lags and disconnections during the game. Ideally, a system like in Beyond All Reason RTS, where only those with a poor connection to the server lag, everyone else enjoys the game. (more details: https://springrts.com/phpbb/viewtopic.php?t=37637)
The game can become free on Steam. Will solve the problem with "funnel".
@ftxcommando said in Why would you have left FAF?:
the problems FAF has always had with regards for players isn't retention related, it's funnel related.
Does the negotiator achieve success or not, if someone wants to try why not? The main thing is that the person is competent.
Lol, I give 100% success here
@nflanders said in Why would you have left FAF?:
@redx said in [Why would you have left FAF?]
I'm so confused. What problem are you trying to solve here? You keep making suggestions that seem aimed at bringing in money, but to what end?
Can I solve the problem? Of course not. If there was a person who would try to negotiate cooperation with Nordic Games.
Success largely depends on the character of the negotiator.
This can help solve a very wide range of problems.Here is the maximum program:
Completely solve the problem of lags and disconnections during the game. Ideally, a system like in Beyond All Reason RTS, where only those with a poor connection to the server lag, everyone else enjoys the game. (more details: https://springrts.com/phpbb/viewtopic.php?t=37637)
The game can become free on Steam. Will solve the problem with "funnel".
@ftxcommando said in Why would you have left FAF?:
the problems FAF has always had with regards for players isn't retention related, it's funnel related.
Does the negotiator achieve success or not, if someone wants to try why not? The main thing is that the person is competent.
Even if you could somehow convince Nordic to care about FAF, you would have to completely rewrite the game to completely solve lag and connection issues. The reason the game is so susceptible to connection issues is literally the very core of how the game's simulation engine works. You'd literally be better off porting all of the game mechanics and units to Spring or something than trying to change SC:FA into a client/server game.
To be frank, none of the problems you are trying to solve are problems that are a fundamental barrier to playing FAF for pretty much anyone. The only people for whom SC:FA not being free is a real barrier to entry is people who are blocked from Steam because of political reasons. Can people in that country even download free games from Steam? Even if you got your pipe dream, it wouldn't affect player retention. You're pushing super hard for something that is irrelevant to everyone except you.
@redx said in Why would you have left FAF?:
Even if you could somehow convince Nordic to care about FAF, you would have to completely rewrite the game to completely solve lag and connection issues. The reason the game is so susceptible to connection issues is literally the very core of how the game's simulation engine works. You'd literally be better off porting all of the game mechanics and units to Spring or something than trying to change SC:FA into a client/server game.
Spring uses deterministic lockstep like supcom, besides you don't want an authoritative server RTS regardless.
Connection issues are in no way 'core' to how the game works. You wouldn't need to rewrite the game to solve network lag.
You'd most likely have to make significant changes to increase the sim tickrate (source of most of what appears as input lag) gracefully though.
@blodir Isn't the input lag something that's deliberate (and not related to the sim)?
Because you need the input lag, to compensate for potential network lag.
That's why the game has a standard input lag of X ms, so people that have X ping to each other can still play together without stuttering.
That is because the engine expects input from every player on every tick, so if you have a higher ping than the input lag, the game micro freezes till all inputs arrive.
Changing the simulation tick rate shouldn't matter, but you'd need to rewrite how the engine works to be able to solve this lag problem. You'd need to introduce some kind of rollback code, that when there is no input from a player continues the simulation, but once the input for an earlier frame arrives, you'd need to roll back to that state and recompute up to the current tick (that's how most fighting games work), but that's a pretty heavy workload for a complex simulation like supcom (that doesn't even manage to run in real time sometimes).
As far as I understand springRTS, it handles it by having a server-client architecture, with the server as the single source of truth, so when someone lags behind they'll just get updated to the state of the server.
@nex said in Why would you have left FAF?:
@blodir Isn't the input lag something that's deliberate (and not related to the sim)?
Because you need the input lag, to compensate for potential network lag.
That's why the game has a standard input lag of X ms, so people that have X ping to each other can still play together without stuttering.
That is because the engine expects input from every player on every tick, so if you have a higher ping than the input lag, the game micro freezes till all inputs arrive.
Changing the simulation tick rate shouldn't matter, but you'd need to rewrite how the engine works to be able to solve this lag problem. You'd need to introduce some kind of rollback code, that when there is no input from a player continues the simulation, but once the input for an earlier frame arrives, you'd need to roll back to that state and recompute up to the current tick (that's how most fighting games work), but that's a pretty heavy workload for a complex simulation like supcom (that doesn't even manage to run in real time sometimes).As far as I understand springRTS, it handles it by having a server-client architecture, with the server as the single source of truth, so when someone lags behind they'll just get updated to the state of the server.
Tick n:
- collect pooled inputs during the time between tick n-1 and now and send to other players. Mark these inputs as destined for tick n+1
- run simulation with inputs destined for tick n (if inputs for tick n have not been received from all players, then pause)
So with 500ms sim tick length if you enter input (eg. give a move command to a unit) 10ms into tick n-1, then the input will be sent at 500ms, and executed at 1000ms. That is a 990ms input delay, which is tied to the sim tick rate.
@nex said in Why would you have left FAF?:
As far as I understand springRTS, it handles it by having a server-client architecture, with the server as the single source of truth, so when someone lags behind they'll just get updated to the state of the server.
I don't know much about springRTS, but based on quick googling this is incorrect and it works the same as supcom and just about every other RTS. Note that the client-server network topology is not mutually exclusive with deterministic lockstep. When people refer to a server in the context of games like eg. sc2 they are referring to a proxy server that facilitates connections between the players (just like what we have in faf!) (though it is possible to have some extra functionality too, just not the kind that you are describing)
@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
@blodir said in Why would you have left FAF?:
@nex said in Why would you have left FAF?:
As far as I understand springRTS, it handles it by having a server-client architecture, with the server as the single source of truth, so when someone lags behind they'll just get updated to the state of the server.
I don't know much about springRTS, but based on quick googling this is incorrect and it works the same as supcom and just about every other RTS. Note that the client-server network topology is not mutually exclusive with deterministic lockstep. When people refer to a server in the context of games like eg. sc2 they are referring to a proxy server that facilitates connections between the players (just like what we have in faf!) (though it is possible to have some extra functionality too, just not the kind that you are describing)
Might entirely be I just looked at what was posted above
https://springrts.com/phpbb/viewtopic.php?t=37637
and how the syncing works:
https://springrts.com/wiki/Syncing_System
these all mention a server/host, which must not necessarily be a dedicated server, but there is still a host and clients in the architecture
@nex said in Why would you have left FAF?:
@blodir said in Why would you have left FAF?:
@nex said in Why would you have left FAF?:
As far as I understand springRTS, it handles it by having a server-client architecture, with the server as the single source of truth, so when someone lags behind they'll just get updated to the state of the server.
I don't know much about springRTS, but based on quick googling this is incorrect and it works the same as supcom and just about every other RTS. Note that the client-server network topology is not mutually exclusive with deterministic lockstep. When people refer to a server in the context of games like eg. sc2 they are referring to a proxy server that facilitates connections between the players (just like what we have in faf!) (though it is possible to have some extra functionality too, just not the kind that you are describing)
Might entirely be I just looked at what was posted above
https://springrts.com/phpbb/viewtopic.php?t=37637
and how the syncing works:
https://springrts.com/wiki/Syncing_System
these all mention a server/host, which must not necessarily be a dedicated server, but there is still a host and clients in the architecture
First link the first reply clarifies that it's regular ol' deterministic lockstep. However, the second link appears to describe a re-syncing feature. Yea, this is a hybrid approach where the system falls back on authoritative server approach if the parallel simulations get out of sync. As a downside whoever is selected as the authority gets to cheat to their heart's content 
@blodir said in Why would you have left FAF?:
@nex said in Why would you have left FAF?:
@blodir said in Why would you have left FAF?:
@nex said in Why would you have left FAF?:
As far as I understand springRTS, it handles it by having a server-client architecture, with the server as the single source of truth, so when someone lags behind they'll just get updated to the state of the server.
I don't know much about springRTS, but based on quick googling this is incorrect and it works the same as supcom and just about every other RTS. Note that the client-server network topology is not mutually exclusive with deterministic lockstep. When people refer to a server in the context of games like eg. sc2 they are referring to a proxy server that facilitates connections between the players (just like what we have in faf!) (though it is possible to have some extra functionality too, just not the kind that you are describing)
Might entirely be I just looked at what was posted above
https://springrts.com/phpbb/viewtopic.php?t=37637
and how the syncing works:
https://springrts.com/wiki/Syncing_System
these all mention a server/host, which must not necessarily be a dedicated server, but there is still a host and clients in the architectureFirst link the first reply clarifies that it's regular ol' deterministic lockstep. However, the second link appears to describe a re-syncing feature. Yea, this is a hybrid approach where the system falls back on authoritative server approach if the parallel simulations get out of sync. As a downside whoever is selected as the authority gets to cheat to their heart's content
From the first link it does sound like they have an ad-hoc server implementation that gets to determine the destination tick of each input packet so the high ping players experience more input delay. Unfortunately this would require supcom source code and a new proxy server implementation (but it is still the same network model and only a minor optimization). Again didn't look too closely tho just skimmed...
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 time
players 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
