Spring RTS Engine

moveinfo.tdf wrote:[CLASS0]
{
name=KBOT1;
footprintx=1;
footprintz=1;
maxwaterdepth=5;
maxslope=36;
crushstrength=5;
}

[CLASS1]
{
name=KBOT2;
footprintx=2;
footprintz=2;
maxwaterdepth=22;
maxslope=36;
crushstrength=10;
}

[CLASS2]
{
name=AKBOT2;
footprintx=2;
footprintz=2;
maxwaterdepth=5000;
maxwaterslope=50;
maxslope=36;
crushstrength=50;
depthmod=0;
}

[CLASS9]
{
name=TANK3;
footprintx=3;
footprintz=3;
maxwaterdepth=22;
maxslope=18;
crushstrength=30;
}

This code wont work, you cant build the units that uses class TANK3, because the key name is CLASS9 instead of CLASS3

on older spring version this wasnt a problem.

i noticed this bug when i was unable to even build the units that didnt have movementclass detected by spring because of this bug.

use lua -_-

erm? how exactly lua fixes this?

That means that the engine got broken but it won't get fixed since anyway you can easily Lua it. Pretty soon other TDF and FBI will stop working too, and you'll be told to use Lua. Then s3do won't be loaded anymore, but not a big deal as you can Lua your own graphic now. After that, the rest of the engine will crumble apart, but that won't be fixed since it can so easily be worked around with a few dozen thousands lines of Lua.

yeah... lets fix every bug in engine with lua crap...

TradeMark wrote: on older spring version this wasnt a problem.

Stop spreading bullshit ktxbye. The move-classes have been expected to be numbered consecutively FOR AT LEAST THREE YEARS, EVEN AFTER THE SWITCH TO THE LUA-BASED FBI PARSER. Just because your total lack of common sense made you encounter this for the first time NOW doesn't mean the engine "got broken", no matter what zwzsg's cute little stock response says.

erm, my map is less than 3 years old, besides i played it less than year ago last time, and at this year i noticed i couldnt build those units anymore... i tested with older BA versions, no difference. so i suppose its engine changes.

Yes, there was an engine change. The change being that units with invalid or missing move-definitions (making them *useless*) are now removed from the game instead of leaving it in a logically inconsistent state as older versions did (but doubtlessly zwzsg will still think of said change as "breaking"). Combine that fact with the prior assumption of contiguity you didn't know was there all along which causes your CLASS9 block to be ignored so "movementclass=TANK3;" is an invalid reference and what do you get?

TradeMark wrote:erm? how exactly lua fixes this?

use a lua def, not a tdf.

(Or just fix your tdf lolol)

Spring's (lua) tdf parser is much stricter than OTA, and so it should be.

Stop spreading bullshit ktxbye. The move-classes have been expected to be numbered consecutively FOR AT LEAST THREE YEARS, EVEN AFTER THE SWITCH TO THE LUA-BASED FBI PARSER.

This.

Kloot wrote:Yes, there was an engine change. The change being that units with invalid or missing move-definitions (making them *useless*) are now removed from the game instead of leaving it in a logically inconsistent state as older versions did (but doubtlessly zwzsg will still think of said change as "breaking"). Combine that fact with the prior assumption of contiguity you didn't know was there all along which causes your CLASS9 block to be ignored so "movementclass=TANK3;" is an invalid reference and what do you get?

so after all this raging there was an engine change after all...

its not nice to just disable the units (took long to find out wtf was going on). it was better back then, when they got some default movementclass, and you were still able to build them.

better solution would be to move the name variable as the array key, then there would be no problems and reading/modifying the files would be easier too. (for example if you want to remove a moveclass).

Like this:

[KBOT1]
{
footprintx=1;
footprintz=1;
maxwaterdepth=5;
maxslope=36;
crushstrength=5;
}

[KBOT2]
{
footprintx=2;
footprintz=2;
maxwaterdepth=22;
maxslope=36;
crushstrength=10;
}

[AKBOT2]
{
footprintx=2;
footprintz=2;
maxwaterdepth=5000;
maxwaterslope=50;
maxslope=36;
crushstrength=50;
depthmod=0;
}

[TANK3]
{
footprintx=3;
footprintz=3;
maxwaterdepth=22;
maxslope=18;
crushstrength=30;
}

This could be changed without breaking every mod: if the array has name variable in it, then the name would be taken from it, if it doesnt, then name would be taken from the array key name.