UnitRestricted Test

[Argh]

First test with new Spring build.

UnitRestricted has several bugs:

1. The Wolf in NanoBlobs is restricted to 0, no matter what I set it to. Please tell me that is the result of some testing code and not some bizarre bug

2. It should be documented that you need to set the value to 0 in order to limit it to 1. Not exactly intuitive, but meh.

3. I could queue multiples of a given unit, even after it was restricted. I should note that I couldn't build the unit- that part works just fine. But AIs will probably go bonkers, sending out commands to build things they are no longer allowed to. Perhaps the smarter AI designers will search for these values themselves.

Overall, this is an absolutely awesome feature, and I'm very excited about it. It may seem like a fairly lame thing, but it's not- it'll make game-balancing the most powerful things a lot easier, and give game designers a good tool for keeping certain things from getting out've hand, both on offense and defense. Great stuff.

[Fanger]

Somewhere.. Smoth just became very happy.. but he doesnt know why yet...

Unit limits are indeed for the win..!


Now what we need is also for a unitrestricted group function where several units can be limited to the same pool.. Ie, unit A, unit B, and unit C, can all be built but the total restriction on them is 10 so at any given time the total number of A, B and C cannot exceed 10, so you could have 8 C, 1 A, and 1 B.. or any other combination that added up to 10..

This would alow you to make a unit where if you build that unit/building, you cannot build this other unit/building because the total limit for them is 1, or that you can only build 5 of a certain tech level of unit.. or so forth...

[rattle]

Actually the way armor is handled now could be used for unitlimits as well, only that we assign the group a unit pool number (-1 for infinite perhaps) and units get an individual number as well (-1 means they can reach the group limit, while limiting them limits them to the amount unless the pool is full).

Also counting should begin at 1 instead to reduce confusion and 0 should be used for... no build option at all (even thought that does make no sense to me).

About the GUI, that's unlucky I guess.

[Yeha]

The counting does begin at 1, UnitRestricted=0 mean that you cannot build any of that unit. Sounds like there could be some bug with it do you have any datafile i could test with to reproduce the problem?

You can queue units even if the max number of unit is met. This can be usefull with factories for an example where you can queue up units and set it on repeat, it will skip any units it cannot build, but still hold them in queue untill they actually can be built. Some feedback from the gui that no more unit can be built at the moment would probably be good though.

[AF]

I take it that the n# of a unit built and the max is accessible now via the AI interface and not via kludges such as trying to parse the units fbi from the VFS?

[Argh]

I'll send you the latest build of NanoBlobs, and you can verify that it works for the Demon, but not for the Wolf. Maybe because it flies? I haven't read the code yet.

[Argh]

It's definitely because it flies. Non-flying units work perfectly. Neither factories nor mobile Builders can build the Wolf, or any other unit that flies. Weird bug.

[Snipawolf]

God bless Argh for testing Spring so much, I wouldn't have an idea what the hell was going on if he didn't >.>

[Yeha]

Think i found the bug with the Wolf, should be fixed in svn now.

[Argh]

Very cool. I shall test.

[Argh]

Works! GJ Yeha