Ignoring Categories

[Evil4Zerggin]

Pruning script for mods (requires Python 3.x): http://springrts.com/phpbb/download/file.php?id=1945

Currently there is code for ignoring categories in CCategoryHandler:

Code: Select all

		if (name.find("ctrl") != std::string::npos
		 || name.find("arm") != std::string::npos
		 || name.find("core") != std::string::npos
		 || name.find("level") != std::string::npos
		 || name.find("energy") != std::string::npos
		 || name.find("storage") != std::string::npos
		 || name.find("defensive") != std::string::npos
		 || name.find("extractor") != std::string::npos
		 || name.find("metal") != std::string::npos
		 || name.find("torp") != std::string::npos)
			return 0;

I suppose it's too much to ask to remove this completely due to *A mod compatibility (although I am willing to provide a Python script to perform such removal for mods that require it), but this prunes many more categories than necessary. There are a lot of words that contain the sequence "arm" for example (e.g., "armoured"), wheras AFAIK only the whole word "ARM" need be pruned.

[Tobi]

It could be fixed mod side indeed; I wouldn't oppose removing it from engine.

[Tobi]

Removed this sillyness from engine.

To make a mod/game behave exactly identical to how it is behaving now, in next version, remove any categories from the mod/game with any of the following strings in the name:

ctrl, arm, core, level, energy, storage, defensive, extractor, metal, torp

Also moving thread to development.

[KDR_11k]

I guess that explains the WTF I got with my armored/unarmored bad target categories...

[FLOZi]

Removed this sillyness from engine.

To make a mod/game behave exactly identical to how it is behaving now, in next version, remove any categories from the mod/game with any of the following strings in the name:

ctrl, arm, core, level, energy, storage, defensive, extractor, metal, torp

Also moving thread to development.

Excellent! I was talking about this in #sy just the other day, the engine shouldn't fix bad mods.

[Evil4Zerggin]

Sweet, thanks! Although this probably means I should speed up deployment of pytdf...

[Evil4Zerggin]

Pruning script for mods. Readme included. Requires Python 3.x. .fbi only.

[TheFatController]

Excellent! I was talking about this in #sy just the other day, the engine shouldn't fix bad mods.

How exactly is this the mods fault , the engine was originally designed for 3d TA and this feature was added created by the engine developers.

[Neddie]

This is just one more case of unnecessary and unproductive backwards compatibility, and now it has been removed. I don't see how any argument against the change could be made, and I don't see any further need for discussion.

[TheFatController]

Not sure how you interpreted that as an argument against the change, I was simply commenting on the 'bad mods' remark which makes no sense.

[FLOZi]

It makes perfect sense when you know the code was added fairly recently (compared to the history of spring); Some mods were running into problems because they had too many categories, so this code was inserted to cut out some of the old TA ones which tend to litter fbi's.

What should have happened is the mod maintainers removing the unneeded catergories instead of the engine messing with them.

So yes, the mods were broken and the engine was fixing them.

Perhaps if i point out that S44 was at one point broken in this sense, you won't get so butthurt. Point is, we fixed it.

[Pxtl]

Removed this sillyness from engine.

To make a mod/game behave exactly identical to how it is behaving now, in next version, remove any categories from the mod/game with any of the following strings in the name:

ctrl, arm, core, level, energy, storage, defensive, extractor, metal, torp

Also moving thread to development.

What problem does unused categories cause anyways? What's actually wrong with having these extra categories? A slight performance fail?

[jK]

you are limited to 32

[imbaczek]

btw how hard would it be to move to uint64_t? or perhaps to a vector<bool> or a bitset?

[jK]

uint64_t would reduce the performance, std::vector<bool> would need more space and even more performance.
std::bitset is okay.

[Tobi]

If doing such thing make a proper type for category set IMO so you don't have to guess based on the name of the variable, and so it can be changed to something else easier.