Unit limits

[smoth]

now that the request spam has died down.

I seriously know several mods can utilize a unit limit. I have put a lot of thought into what would be the most usefull way to implement this. Also, before anyone freaks this does not mean that suddenly spring will have this for AA.

Initialy I thought a FBI tag would be a good idea but upon further reflection that requires a huge amount of work on the moders part. So a unitlimit.tdf would be better.

It would work like this(I am using my mod as an example:

Code: Select all

[1]
{
rx78;
alex;
guncannon;
}

[4]
{
Xamel;
gallop;
corebooster;
sniperII;
Medea;
}

[group=60]
{
rx79rl,rx79zook,rx79plus;
Powered,poweredrl;
}

All other units would not have a limit.

Individual limits:
Anything under '1' will be limited to 1, anything under 4 will be limited to 4.

Group limits:
Group=60 means that the units rx79rl, rx79zook and rx79plus as a group are limited to 60, this means for example if I have 30 rx79zook and 30 rx79rl then I have reach my limit of 60. However, I can still build powered gms as I do not have 60 of them.

This will allow moders to quickly set unit limits on our units where needed.

In game:
How would it handle a repeat order?
It skips the unit and builds the next(if then next can be built).

What if I want to que several up?
You can but if you reach the limit it simply will stop or move to the next unit if appropriate.

When does a unit count towards a limit?
When it starts to build it will check count, this will prevent people from using several factories to produce one unit to escape the unit limit.

Is the limit global?
No, it would be on a per player basis.


So, yeah there it is. This would be a great help to us modders, allowing for a sort of hero or singular unit that will stand out on the battlefield. Please consider adding this.

[AF]

That might be awkward internally as it means that the engine has to look at each and every section, iterate through all the tags and find one that matches the unitname, just so it can make a string like "LIMITS\\4\\Xamel"

I believe the 2 other ways of doing ti would be much much better

add a unitlimit=; in the unit fbi or do it this way:

Code: Select all

[UNIT_LIMITS]
{

rx78=1;
Xamel=4;
// etc...

}

also:

[1]
{
rx78;
alex;
guncannon;
}

those tags have to equal something and have a value, otherwise you'll get boost::spirit parser error during loading and spring will crash.

[Guessmyname]

Just plop =99 on the end, like with the armour thing

[AF]

but its still a much more cpu intensive way of doing it


I would rather:

Code: Select all

int limit;
GetDef(limit,string("LIMIT\\")+ud->name, "32000");

which is much simpler than

int limit=32000;
// get the list of categories for "LIMIT"

iterate through that list of categories{
if item == ud->name{
limit = atoi(catgeoryname)
}
}

also the suggestion smoth amde brigns with it deadweight values, whcih will be parsed, processed and stored regardless of the fact they'll never be used. They also serve to confuse newcomers who will end up asking, "what does the 99 value mean?"

[SinbadEV]

While we are on the subject, how would you suggest we impliment supply based limmiting?

[smoth]

@sinbad
Please do not derail this thread with that. Talk about it in another thread. I am trying to get this done and derailing this thread will not get it done.

[smoth]

but its still a much more cpu intensive way of doing it

It is still only run once, and it is not ever going to be run for more then 100,000 different units, which in modern processors as a single run is quite negligible.

also the suggestion smoth made brigns with it deadweight values, whcih will be parsed, processed and stored regardless of the fact they'll never be used.

What do you mean deadweight values? What is bad about them?

They also serve to confuse newcomers who will end up asking, "what does the 99 value mean?"

We have it in armor.txt so we can have it in the limits.

[AF]

In thatc ase I'm going to have a look at armour.txt and think about changing that too.

It's just your method requires an explanation and a bit of thought, when there's a method which doesnt require any of that.

[smoth]

which is?

[FizWizz]

It's just your method requires an explanation and a bit of thought, when there's a method which doesnt require any of that.

I found the 'explanation and bit of thought' to be straight-forward:

Code: Select all

[1]
{
rx78;
alex;
guncannon;
}

[4]
{
Xamel;
gallop;
corebooster;
sniperII;
Medea;
}

[group=60]
{
rx79rl,rx79zook,rx79plus;
Powered,poweredrl;
}

All other units would not have a limit.

Individual limits:
Anything under '1' will be limited to 1, anything under 4 will be limited to 4.

Group limits:
Group=60 means that the units rx79rl, rx79zook and rx79plus as a group are limited to 60, this means for example if I have 30 rx79zook and 30 rx79rl then I have reach my limit of 60. However, I can still build powered gms as I do not have 60 of them.

I give this a +1.

[AF]

That syntax is impossible, and whatsmore its distorting opinions. This is the nearest thign to what smoth suggested that would not give a boost::spritit parser error that crashes spring on startup:

Code: Select all

UNIT_LIMITS]
{
    [1]
    {
        rx78=99;
        alex=99;
        guncannon=99;
    }

    [4]
    {
        Xamel=99;
        gallop=99;
        corebooster=99;
        sniperII=99;
        Medea=99;
    }

    [group=60]
    {
        rx79rl=99;
        rx79zook=99;
        rx79plus=99;
        Powered=99;
        poweredrl=99;
    }
}

Which sorta messes up the last bit. To get smoths ideal way of doing it would require a new parser setup, with new parsing rules for boost::spirit


This is what i suggested:

Code: Select all

[UNIT_LIMITS]
{
    rx78=1;
    alex=1;
    guncannon=1;

    Xamel=4;
    gallop=4;
    corebooster=4;
    sniperII=4;
    Medea=4;

    rx79rl=60;
    rx79zook=60;
    rx79plus=60;
    Powered=60;
    poweredrl=60;
}

And as a sidenote for groups possibly this:

Code: Select all

[UNIT_LIMITS]
{
    rx78=1;
    alex=1;
    guncannon=1;

    Xamel=4;
    gallop=4;
    corebooster=4;
    sniperII=4;
    Medea=4;

    60=rx79rl, rx79zook, rx79plus, Powered, poweredrl;
}

[smoth]

Ok, you missed the point of the group limit... what you are suggesting will not work.

The rx79rl,rx79plus and rx79zook are in essence the same mech... hence why I am asking for the group.

The poweredgm is it's own mech and it's variants need to be in it it's own group

so in total there would be 120 of them 60 being powereds and 60 being rc79s


as far as an impossible parser .. no,dude. You can write a parser for this half awake.

psuedo code

Code: Select all

It would just read the textfile

look for '['

read the next char, is is a numeric? then it is a limit handle from there..
go to lookforbraket
else,is it not a numeric? the is it the word "group"?
treat as a group. look for number after = set as group limit.

lookforbraket
found it
am I group or limit?
if limit read line to get unit names sepperated by collon till next bracket.

if group
read unit name, look for comma, read unit name stop on simicolon.till nex bracket
loop

While we could possibly make the parser simpler by doing this:

Code: Select all

[Unit limit]
{
unitnameZ=value;
unitnameX=value;
unitnameY=value;
}

[group limit]
{
unitnameC,unitnameB,unitnameD=value;
}

That would still allow for some organization but odds are many unit lists will be out of order.

[AF]

That latter pseudocode would be unlikely to make it in as the devs will want a cleaner more reliable setup using existign code, aka TDFParser. Also TDFParser brings with it extra benefits such as making it easier to handle the data, and comments (multiline + singleline).

Your syntax also deviates from the TDF standard in a way that seems hackish.

Code: Select all

[UNIT_LIMITS] 
{ 
    rx78=1; 
    alex=1; 
    guncannon=1;

    Xamel=4; 
    gallop=4; 
    corebooster=4; 
    sniperII=4; 
    Medea=4;

    [GROUPS]
    {
         groups = powered, rx;
         [powered]
         {
             num = 60;
             units =Powered, poweredrl;
         }
         [rx]
         {
             num = 60;
             units = rx79rl, rx79zook, rx79plus;
         }
     }
}

better? That method allows extra properties to be added to the groups...


e.g.

Code: Select all

    [GROUPS]
    {
         groups = powered, rx;
         [powered]
         {
             num = 60;
             units =Powered, poweredrl;
         }
         [rx]
         {
             num = 60;
             units = rx79rl, rx79zook, rx79plus;
             rx79rl=2;
         }
     }

rxr79l is now worth 2 whereas the rest are worth 1.. Meaning you can ahve 30 rx97l's or 15 rx97l's and 30 rx79zook's, of course you wouldnt use that in this case as you've said they're all just variations of the same unit.....

[smoth]

That looks good to me but then would they implement that AF?

[AF]

The parsing for that is already available as TDFParser, and it could be moved to another format (such as xml), once the TDFParser class is bound to an IParser interface.

That and it's a lot easier to parseand maintain.

[smoth]

Don't get me wrong, I understand and agrea with what you are saying here but I am curious whether or not someone will actually do it.

I am cool with this:

Code: Select all

[UNIT_LIMITS] 
{ 
    rx78=1; 
    alex=1; 
    guncannon=1; 

    Xamel=4; 
    gallop=4; 
    corebooster=4; 
    sniperII=4; 
    Medea=4; 

    [GROUPS] 
    { 
         groups = powered, rx; 
         [powered] 
         { 
             num = 60; 
             units =Powered, poweredrl; 
         } 
         [rx] 
         { 
             num = 60; 
             units = rx79rl, rx79zook, rx79plus; 
         } 
     } 
} 

I just wonder if it will get done.

[AF]

The main issue here is that the flow of control for building units is obscure and awkward to follow in spring......

[esteroth12]

as the current versio doesn't have support for global caps, how about...

Code: Select all

[UNIT_LIMITS] 
{ 
  [PLIMIT]
  {
    rx78=1; 
    alex=1; 
    guncannon=1; 

    Xamel=4; 
    gallop=4; 
    corebooster=4; 
    sniperII=4; 
    Medea=4; 

    [GROUPS] 
    { 
       groups = powered, rx; 
       [powered] 
       { 
         num = 60; 
         units =Powered, poweredrl; 
       } 
       [rx] 
       { 
         num = 60; 
         units = rx79rl, rx79zook, rx79plus; 
       } 
     }
   }

  [GLIMIT]
  {
    rx78=1;
  }
} 

where PLIMIT means Player Limit and GLIMIT is Global Limit

this would have the same limits as Smoth's post, except the RX-78 can only have 1 instance on the entire map

GLIMIT can have anything that PLIMIT has, such as groups

[AF]

Code: Select all

[UNIT_LIMITS] 
{
    [GLOBAL]
    {
        rx78=2;
        alex=3;
        guncannon=3;

        Xamel=4;
        gallop=4;
        corebooster=4;
        sniperII=4;
        Medea=4;
    }
    [PLAYER]
    {
        rx78=1;
        alex=1;
        guncannon=1;

        Xamel=4;
        gallop=4;
        corebooster=4;
        sniperII=4;
        Medea=4;
    }
    [GROUPS] 
    { 
         groups = powered, rx; 
         [powered] 
         {
             player_num = 60;
             global_num = 60;
             units =Powered, poweredrl;
         } 
         [rx] 
         {
             player_num = 60;
             global_num = 60;
             units = rx79rl, rx79zook, rx79plus; 
         } 
     } 
}

How about that?

[esteroth12]

it wouldn't be able to can't tell the difference between a group limit for 1 player and a group limit for everybody...