please increase packet limit

[jamerlan]

Could you please adjust packet limit?
like: currentLimit = currentLimit * 1.5;

I got "Waiting packet limit was reached" errors on FFA games (at the end) and can't give orders to units.

Also all people get this error when playing vs AI. And AI(E323AI 3.25.0) stopping to build units when messages appears. AI builds units and atacks a lot and then he did nothing like a zombie.

I see this thread ofc, but editting config is not what players really want. Especially newbies that want to train playing vs AI: http://springrts.com/phpbb/viewtopic.php?f=11&t=27284

[Forboding Angel]

Dude, can you not read? The AI is spamming a gazillion commands a second. It's an AI issue. Allowing that to go on without dropping them would cause your cpu to die in agony.

Use properly maintained AIs.

[jamerlan]

Forboding Angel, you should read better too)))

I propose just to increase limit a little.

I have this bug on FFA too without any AI.

[gajop]

to me it's just silly that there's the limit for single player games

[jamerlan]

to me it's just silly that there's the limit for single player games

Agree. If singleplayer game with bot was started via springlobby - packet limit messaged are already waiting for you behind the scenes :-D

[Forboding Angel]

Ok, let me put it another way. Do you like getting 30+ fps or do you prefer getting 1fps?

A "little" won't do any good. You are not keeping in mind the sheer assload of commands that AIs send every frame (32 game frames happen every second (wait, that's every half second) - 64 gameframes per second)!

[jamerlan]

So it's better to see zombie-bot in the middle of the game? And when only 2-3 people left in FFA it's better to loose because you can't give orders to units?

[hoijui]

The solution is, for AIs to restrict themselfs internally.
If we turn off that limit for singleplayer... have a guess how AI devs are testing their creations.
So the real problem is, that none of hte native AIs (except Shard) is actively maintained. You are free to take over that task for any of them!
tell me which one you are most interested in, and we can make it a git submodule if it is not yet one, and you are free to go. i would be very happy to see that!
if you are unsure, we can also make all of them git submodules, and you can start doing small stuff for all of them, and decide later which one to work on more, or keep going on on all of them.

[gajop]

Ok, let me put it another way. Do you like getting 30+ fps or do you prefer getting 1fps?

A "little" won't do any good. You are not keeping in mind the sheer assload of commands that AIs send every frame (32 game frames happen every second (wait, that's every half second) - 64 gameframes per second)!

Not a FPS thing. It causes a lot of bandwidth and makes your replay files bigger, that's it. The same applies to widget->gadget communication. Correct me if wrong, but if you were to encapsulate a multiple messages into a single bigger one, it would stop causing the problem?

Unless the AI is doing calculations on a remote PC, I don't think it will ever be the case that sending commands is more CPU expensive than planning & scheduling them.

If we turn off that limit for singleplayer... have a guess how AI devs are testing their creations.

Yep, my AI was spamming those messages quite a lot. But there are cases when it's a valid reason, for me those are:
1) Testing an early prototype of an AI, mostly meant to be played 1v1. I've actually had my spamming AI play against someone over a network (with me spectating), and there were no obvious problems (perhaps a large bandwidth usage for the host).
2) Working on this scenario/mission editor. That will most definitely be used in "singleplayer" mode most of the time. I simply don't care much to optimize that (yet I must). An example of the limit being hit is when I drag multiple units with a mouse and simultaneously update their position, lots of updates going.

If we could, I'd have the default limited, and allow the user (host) to set a different (or no) limit himself, consciously (meaning they'll hopefully be aware of the problem).

[hoijui]

gajop, giving a move command casues all PCs that run the simulation to do expensive pathing calculations. in general this is much more expensive hten the AI planning the move (which also happened on a single machine only).
we did not invent this limit out of the blue. it is actually very reasonable, and born out of real experience of actual games beeing played, not few test games or theoretical thoughs or whatever.
It is not about the network bandwidth, but about the CPU load the commands in those messages cause in the simulation.

1) That is a special case, so handling that specially and the normal case by default is the right way to go (and it is what is the case now)

allowing the user or host to change the limit manually is not a good solution, as that will be used too often and eliminate the intended benefit of the limit (all AI devs would use it all the time, and tell AI players to use it too).

if players manage to reach the limit without any AI being present, and without buggy widgets that could be improved to not cause it, then the limit has to be increased, else not

[klapmongool]

Could you please adjust packet limit?
like: currentLimit = currentLimit * 1.5;

I got "Waiting packet limit was reached" errors on FFA games (at the end) and can't give orders to units.

[jamerlan]

Maybe I use some "bad" widgets. But I have no idea: which widgets are bad.

[zwzsg]

Correct me if wrong, but if you were to encapsulate a multiple messages into a single bigger one, it would stop causing the problem?

I don't think so. I had a widget that caused me to reach the packet limit thing. I decreased the message size without changing the message frequency, and then the problem was gone.

[zerver]

There are two limits. One for packets/second and one for bytes/second. If either limit is exceeded packets may be dropped. The system allows the limits to be temporarily exceeded by a fairly large amount though.

[Pako]

Players are right. There was no problem with bandwidth nor CPU lags when thousand units got issued a custom formation command.

There were even some very evil Lua picture drawing widgets which draw thousand lines in a half second. The unoptimized GL line drawing lagged many times more than the bandwidth lag or creating those lines.

[jK]

Engine devs know more than you.
Also these limits don't just limit the bytes per second, they also limit the packets per second, so the cmds per second and so indirectly the cpu workload per second.

[zerver]

The reason for these limits is that a malicious widget otherwise could perform something similar to a DDoS attack, which would essentially make the whole game unplayable.

No matter how we set these limits, someone will complain that they are too low. So please try to live with it and adapt your code. 64 packets per second is plenty.

Besides, you are free to configure these limits as you like, but then you also need to host the game...

[jK]

No matter how we set these limits, someone will complain that they are too low. So please try to live with it and adapt your code. 64 packets per second is plenty.

64 aren't plenty ... ways too low to give 50 flashes multiple move cmds via custom formations ... esp. cause these limits don't delay the cmds instead they drop them ...

[jamerlan]

Besides, you are free to configure these limits as you like, but then you also need to host the game...

Currently if we start singleplayer game with AI (E323AI) - it will become zombie after about 10 - 15 minutes with dropped packets. So this bug should be created for springlobby?

[hoijui]

E323AI should be modified.
as i alreayd said elsewhere, it is currently unmaintianed (like all native AIs except Shard, and KAIK is.. half maintained by Kloot). so .. if you want to fix E323AI, just fork the repo on github, and start coding!
as soon as it shows any improvements, tell us, and it can be put in main E323AI repo, or if you want to go on developping it, we can link to your repo on github instead, and thus make that the official one.