Spring RTS Engine

Pretty common small supreme battlefield game:
http://replays.springrts.com/replay/fe4 ... 879b8f899/

This went a lot better in 94.1.

There was a giant freeze somewhere at 35 mins when a hundred hovers or so attacked and got bombed by over a 100 sea bombers.

Any tips on how to get better fps are greatly appreciated. I´m especially curious how to disable smoke effects.

That map has some fairly serious issues and really needs to be repackaged. I may do it a bit later for the hell of it.

That'd be really appreciated!

Cool, that would be great. Any idea why the lagging got so bad at the time it did?

klapmongool wrote:Any idea why the lagging got so bad at the time it did?

Running the demo reveals Lua memory usage suddenly jumps up to ~2GB (after remaining below 20MB the whole game) around time index 35:09, then it gets freed all at once which triggers a CPU spike.

This happens consistently (even after /luaui disable) so the only valid explanation is that it originates in synced BA luarules code, and you can confirm for yourself the spike disappears by issuing /cheat /luarules disable just prior to 35:09.

Kloot wrote:

klapmongool wrote:Any idea why the lagging got so bad at the time it did?

Running the demo reveals Lua memory usage suddenly jumps up to ~2GB (after remaining below 20MB the whole game) around time index 35:09, then it gets freed all at once which triggers a CPU spike.

This happens consistently (even after /luaui disable) so the only valid explanation is that it originates in synced BA luarules code, and you can confirm for yourself the spike disappears by issuing /cheat /luarules disable just prior to 35:09.

Ok, what conclusions can we draw from this?

klapmongool wrote:Ok, what conclusions can we draw from this?

That there is a bug in Spring 95 or in BA 7.84.

I mean a bit more specific. And please don't turn this thread into a MT war. I'm trying to find out why there was such a sudden spike. Maybe devs or game devs can find out what causes it.

You can reduce the number of smoke effects by reducing the maxparticles.

Beherith wrote:You can reduce the number of smoke effects by reducing the maxparticles.

Thx, that is what nixtux said as well when I spoke him earlier. The downside to that is that it would limit the nanospray as well (right?) and I like to have that on so i know if stuff is building or not (or reclaiming).

klapmongool wrote:

Beherith wrote:You can reduce the number of smoke effects by reducing the maxparticles.

Thx, that is what nixtux said as well when I spoke him earlier. The downside to that is that it would limit the nanospray as well (right?) and I like to have that on so i know if stuff is building or not (or reclaiming).

No, nano particles are done seperately. (MaxNanoParticles instead of MaxParticles)

I'm trying to find out why there was such a sudden spike. Maybe devs or game devs can find out what causes it.

The attacking player who sent the wave of 100+ hovers gave an area-attack order while all of them were selected, with a radius large enough to include 100+ targets within the command's area.

As a result each of the 100+ units received a queue with 100+ attack commands in it, and because at least one* of BA's gadgets requests the entire command queue of every unit within gadget:AllowCommand which is called for each individual queue command, those commands need to be copied over into Lua memory 100*100*100 = ONE MILLION times.

Spring can handle that up to a point, but the Lua allocater can not. Even worse, the gadget doesn't actually care about the commands, just the size of the queues, so copying them is a complete waste of time and memory.

* unit_target_on_the_move.lua

And just to kill any discussion pre-emptively: no, this did not "go a lot better in 94.1" (you can reproduce it as easily there as in 95.0), and no, MT would not have mattered either.

Yes, this was entirely the fault of target_on_the_move - ticketed http://imolarpg.dyndns.org/trac/balatest/ticket/508

Kloot wrote:

I'm trying to find out why there was such a sudden spike. Maybe devs or game devs can find out what causes it.

The attacking player who sent the wave of 100+ hovers gave an area-attack order while all of them were selected, with a radius large enough to include 100+ targets within the command's area.

As a result each of the 100+ units received a queue with 100+ attack commands in it, and because at least one* of BA's gadgets requests the entire command queue of every unit within gadget:AllowCommand which is called for each individual queue command, those commands need to be copied over into Lua memory 100*100*100 = ONE MILLION times.

Spring can handle that up to a point, but the Lua allocater can not. Even worse, the gadget doesn't actually care about the commands, just the size of the queues, so copying them is a complete waste of time and memory.

* unit_target_on_the_move.lua

And just to kill any discussion pre-emptively: no, this did not "go a lot better in 94.1" (you can reproduce it as easily there as in 95.0), and no, MT would not have mattered either.

Thanks for analyzing this!

Silentwings wrote:Yes, this was entirely the fault of target_on_the_move - ticketed http://imolarpg.dyndns.org/trac/balatest/ticket/508

Thanks!

how to disable it ?

Not possible to disable - wait for update, sorry!