Spring RTS Engine

Well, that sounds good, but the problem there is that then they'd have to be globals. So we'd be paying for access to a global every time we wanted that array.

IOW, 300ms at start, before gameframes run, is just one of the many things we have to pay for at start for faster operation during the entire game.

yeah 300ms for one widget, what if theres 10 widgets... 3 seconds...

also, isnt there some timeout for widgets...? in metal maps people drop because their metal patch finder or something freezes because of too much metal D:

There are no fixed timeouts, so far as I know. And if a Widget gets locked in a loop, then yeah, it'll cause serious problems, just like a Gadget can. Unsynced stuff is downright evil, if it gets locked in a loop or triggers really nasty issues due to iterations growing exponentially.

That's a problem with the Widget, though, not necessarily with Spring itself. If a "metal finder" is written so poorly that it can't handle a metal map, then it's a badly-written piece of software, basically.

It's pretty easy to avoid that kind of lock state- for example, it could do this, at start:

Check X,Z-->X2,Z2. Check only 60 elmos away. Do that 16 times, for a square 240X240 elmos on a side. If all or most of the squares report high metal values... voila, we have a metal map, do not perform further operations.

See? Not rocket science. Just some common sense.

300ms to initialize the table sounded ridiculously high. So I went and tested it. Building the table takes ~0.0002 seconds.

Niobium wrote:300ms to initialize the table sounded ridiculously high. So I went and tested it. Building the table takes ~0.0002 seconds.

Its because your version is 300% faster.

If you are not able to reproduce, just ask...

If it manages to take that long, congrats, you've hit a horrible bug. First, actually check if it's that part of the widget, then report it.

Argh, you can't mention optimization and table.insert/delete in the same sentence. But I think you're missing what I meant. Telling lua to make a table of size 3-10 is reasonable. Initiating a *large* table is an extremely rare case and that's not even the right way to go about it.

Localizing an upvalue is going to have a small impact when you get and set it about 3-5 times.

Localizing an upvalue is going to have a small impact when you get and set it about 3-5 times.

But how long until it's actually slower than using those two additional instructions?

I meant a small positive impact. It'll be slower and uglier with 1-4 uses of the var. And what do you mean 'than', localizing IS the two additional instructions.

lurker wrote:If it manages to take that long, congrats, you've hit a horrible bug. First, actually check if it's that part of the widget, then report it.

This is how it happens for me:
1. Start spring.exe and deactivate Argh's widget.
2. Quit spring
3. Again start spring.exe
4. When ingame, F11->Enable arghs widget
5. Short Freeze.

It does not happen if you disable and reenable it again ingame. And its clearly the function widget:Initialize(). When wiping that function it does not happen anymore.

Maybe when iterating UnitDefs for the very first time it gets (expensively) generated. And when using it later again its fetched fast from some cache?

It makes those at game start.

Try leaving that in but removing the opengl calls.

Ok, I did. It still happens. This is how Initialize looks:

*sigh*
What this means: caching the radius value in the radiusDefs table on Initialize causes all not-yet loaded models to be parsed first. Therefore the reported 300ms delay is normal, and a claim of 0.0002s startup time *highly* dubious for any widget performing the same computation unless said computation is 1) also done by another widget that comes earlier in the alphabetical ordering or 2) preceded by a /give all command.

Right, I'd forgotten that one out of ten files is delay-loaded for some strange reason.

I actually like delay-loading, but what is and what isn't is a mess.

Kloot wrote:Therefore the reported 300ms delay is normal, and a claim of 0.0002s startup time *highly* dubious for any widget performing the same computation unless said computation is 1) also done by another widget that comes earlier in the alphabetical ordering or 2) preceded by a /give all command.

When I tested it yes, other widgets had done the exact same computation, maybe half a dozen of them even, it's quite common.

Yeah, testing that in isolation gives the wrong impression about what it does and how big of an issue it really is. Doing stuff like unitDef / weaponDef / featureDef table iterations... meh, I probably do that 3-4 dozen times as P.U.R.E. starts up, tbh, to speed various things up. I guess that's why I didn't observe the lag.

Could somebody build in support for different enemy colors for different ally's?


As a spec 4v4v4v4 games arent followable due to this.

Use Team Platter for that? For me its exactly the point of this widget to not try to use different colors.

this is a 4 year old thread, much of what was discussed may not be a limitation any more. It is probably better to to do a new discussion.

You are probably right Smoth, but we re here now... And this way all related info about this widget is bundled in one thread.


Why are people referring to teamplatter while teamplatter isnt 'allyplatter'. I am using enemyspotter for a reason, teamplatter doesnt give me clarity who is my teammate or enemy. Also, I prefer the more subtle gfx of enemyspotter. Teamplatter isnt relevant to me since the units are already teamcolored.

Allyspotter/platter is what it needs to be for me.

What Sring function gives back the ally id number given the teamID

is it this?

Spring.GetReadAllyTeam(teamID) ?