Spring RTS Engine

I would like to change it so that (by default) the game speed will not be throttled based on spectators.
Please tell me what you think by voting...

Thanks

I agree, spectators should not slow the game. If they are struggling to keep up, let them lag out.

Hmm...

Any word on the possible issues this may cause?

I think this limitation should be at the discretion of the host and not decided by the engine itself.

Peet wrote:I think this limitation should be at the discretion of the host and not decided by the engine itself.

+1

Umbra wrote:

Peet wrote:I think this limitation should be at the discretion of the host and not decided by the engine itself.

+1

+1

MidKnight wrote:

Umbra wrote:

Peet wrote:I think this limitation should be at the discretion of the host and not decided by the engine itself.

+1

+1

+1

OK JUST STOP

the OP obviously doesnt understand how spring works. The reduced game speed is necessary to maintain sync. It is the host's responsibility to kick specs who are lagging or slowing down the game. Its not that hard just /kick. Or on autohosts use the !kick or !votekick command. This thread is pointless.

d_b wrote:the OP obviously doesnt understand how spring works. The reduced game speed is necessary to maintain sync. It is the host's responsibility to kick specs who are lagging or slowing down the game. Its not that hard just /kick. Or on autohosts use the !kick or !votekick command. This thread is pointless.

Congratulations, all wrong.

Regret wrote:

d_b wrote:the OP obviously doesnt understand how spring works. The reduced game speed is necessary to maintain sync. It is the host's responsibility to kick specs who are lagging or slowing down the game. Its not that hard just /kick. Or on autohosts use the !kick or !votekick command. This thread is pointless.

Congratulations, all wrong.

really? how so? I am rather convinced otherwise so please teach me the one true path!

I think the funny thing is that everyone is agreeing with me and voting 'no' which is the opposite.

I think allowing the player to have control is a good thing however there are already many things a host must calibrate...
We cant just endlessly add things in...
It''s just be a huge mess that takes months for a new user to sort through and understand.

IMO:

By default enable slowing down for players,
by default disable slowing down for specs.

And put both in config var, possibly a single one with 3 choices: never slow down, slow down for players only, slow down for both players and specs.

If a spectator cant render speedmetal games fast enough they should never have joined.

If a spectator CAN render speed metal games fast enough they should never have joined.

How about we make specs who can't run the game fast enough run at their own speed? The host will send all the commands etc to the spectator, but won't care about him and will just run the game further with the proper speed, while the spectator will just basically watch a replay. He will not watch it in real time so he shouldn't be allowed to send any commands, but specs dont send many anyway (only chat, map points etc and stuff like cpu usage). There could be even a host command similar to !kick that would remove a player / spectator from the game and switch him into read-only replay watching mode.

Just some ideas I got. I know noone will implement them anyway ;]

AFAIK that is exactly what would happen if Spring didn't slow down for them.

Tobi wrote:AFAIK that is exactly what would happen if Spring didn't slow down for them.

Right now, it seems that connection is lost if ping is more than ~1 minute.

We need some changes so that specs only lose the connection if they completely stop to send sync responses. Also, the annoying repeated "no sync response for spectator" must be removed ofc.

Thanks for your votes, I will look into this...

zerver wrote:Also, the annoying repeated "no sync response for spectator" must be removed ofc.

This info can be parsed in a console widget if desired, I don't think it should be removed.

But it's clearly a bug. As far as I can tell the code checks when it's last received any data, but I've heard people say they time out when it gets high enough and there are no other issues.