Blacklist target category

[Forboding Angel]

string onlyTargetCategory Default: ""
A string of unit category entries which this weapon can target. i.e. any unit whose category does not match any entry in this tag, cannot be targeted by this weapon. (See #Categories)

Having only a whitelist for targeting makes things MUCH harder. I would like to have a blacklist as well.

noTargetCategory

[Jools]

you have badtargetcategory, that's a blacklist.

[hokomoko]

no, badtargetcategory is just categories that are prioritised lower.

[Forboding Angel]

no, badtargetcategory is just categories that are prioritized lower.

THIS^^

[hokomoko]

Forb, you can implement this yourself in unitdefs_post.
Keep a string with all categories.
if no "onlytargetcategory" is given, make an onlytargetcategory that holds that string while replacing (:gsub?) all targets in that unit's blacklistCategory

[Silentwings]

That works, but the trouble with it is you can only have so many target cats.

[Jools]

yeah, 32. Why is that?

[8611]

32 cattoys because https://github.com/spring/spring/blob/9 ... yHandler.h

Code: Select all

static inline unsigned int GetMaxCategories() {
// categories work as bitfields, so
// we can not support more than this
return (sizeof(unsigned int) * 8);
}

badtargetcagecattoy:
viewtopic.php?f=21&t=29769&p=536476#p536553

BLACKLIST = EVERYTHING excluding WHITELIST
viewtopic.php?f=21&t=29769&p=536476&hil ... ry#p536476

[Forboding Angel]

Forb, you can implement this yourself in unitdefs_post.
Keep a string with all categories.
if no "onlytargetcategory" is given, make an onlytargetcategory that holds that string while replacing (:gsub?) all targets in that unit's blacklistCategory

I don't want to do it in unitdefs post. It is something that should be available directly via the unitdef. That's not to say I wouldn't use post as a workaround for now, but having to do so is ridiculous. It should have never been a whitelist in the first place.

[FLOZi]

White list is ideal for s44.

[Forboding Angel]

That doesn't invalidate the need for a blacklist.

[Google_Frog]

If implementing a blacklist in _posts is a hack then what is _posts for? I think that this is exactly the sort of thing that _posts is meant to do. It seems like a pointless request for the engine.

[Forboding Angel]

Just because something can be done in lua doesn't mean it should be. Knorke's workaround is a kludgy hack and is extremely inflexible at best.

A blacklist should have been the default in the engine, not a whitelist, but realistically, there should be both a blacklist and a whitelist.

[8611]

If implementing a blacklist in _posts is a hack then what is _posts for? I think that this is exactly the sort of thing that _posts is meant to do. It seems like a pointless request for the engine.

I agree, because behaviour-wise nothing in the engine changes. It is all about how some unit-properties get feed into the unit-reader-thing. Perfect example for _post imo.

---

Such thing does not even have to be in _post, that is just one way.
One should remember what a unitDef file actually is:
It is a .lua script that creats a table with the properties of the units and returns it.
*How* that table is created is up to modder and what the script does is up to the modder.
Common is something like:

Code: Select all

unitDef = {
  unitname = "tank",
  name = "Tiger Tonk", 
  maxDamage = 1000,
  ...  
  ...
  weapons = {
    def = "Cannon",
    onlyTargetCategory = "TANK TRUCK INFANTRY",
    badTargetCategory  = "BUILDING",
  },
}
return lowerkeys({ tank = unitDef })

That is not just a dumb list of "key=value" : It just looks like one because it mimics the .fbi files from Total Anthillnation. Often that is okay. Yet even in that simplest example the use of lowerkeys() is a hint that .lua files can do more.
(compare to .fbi files which were limited to "key=value" listings.)

So going with that idea it could also look like:

Code: Select all

unitDef = {
  unitname = "tank",
  name = "Tiger Tonk", 
  maxDamage = 1000,
  ...
  ...  
  weapons = {
    def = "Cannon",
    targeting = {
    prefered = "TANK TRUCK INFANTRY",
    lessPrefered = "BUILDING",
    neverTarget = "AIRCRAFT",
    }
},
return makeMyDef (lowerkeys({ tank = unitDef }))

In above example the function makeMyDef () would take the targeting-preference table in a format the modder likes and turn it into a format that the engine likes.

Another possiblity:

Code: Select all

weapons = {
    makeMyWeapon (
		{weaponName="Cannon",
		prefered = "TANK TRUCK INFANTRY",
		lessPrefered = "BUILDING",
		neverTarget = "AIRCRAFT",})    
    },

The possibilities are endless, the main problem is to decide on a way that fits personal preferences.

[Forboding Angel]

It still boils down to the fact that you are advocating using a whitelist to make a blacklist. That is silly. Didn't I have you foe'd?

Please be polite (Misdemeanor 9). (Silentwings)

[Google_Frog]

Just because something can be done in lua doesn't mean it should be. Knorke's workaround is a kludgy hack and is extremely inflexible at best.

A blacklist should have been the default in the engine, not a whitelist, but realistically, there should be both a blacklist and a whitelist.

Correct, not everything should be done in lua. But now look at this case. Implementing this in _posts (or somewhere similar):

• Has no performance impact.
• Adds some code complexity but saves the engine internals from that complexity (which is better imo because the engine seems more fragile to me).
• Allows you to quickly change your mind and use different types of lists.

So the benefits of lua (saving the engine from complexity, implementation flexibility) are there without the common drawbacks (performance).

[FLOZi]

That doesn't invalidate the need for a blacklist.

No, it invalidates

A blacklist should have been the default in the engine, not a whitelist

instead.

[Forboding Angel]

I was talking to 8611, not Google_frog? Wtf gajop?

[Forboding Angel]

Just because something can be done in lua doesn't mean it should be. Knorke's workaround is a kludgy hack and is extremely inflexible at best.

A blacklist should have been the default in the engine, not a whitelist, but realistically, there should be both a blacklist and a whitelist.

Correct, not everything should be done in lua. But now look at this case. Implementing this in _posts (or somewhere similar):

• Has no performance impact.
• Adds some code complexity but saves the engine internals from that complexity (which is better imo because the engine seems more fragile to me).
• Allows you to quickly change your mind and use different types of lists.

So the benefits of lua (saving the engine from complexity, implementation flexibility) are there without the common drawbacks (performance).

You're still advocating a blacklist derived from a whitelist. Honestly am I the only one who sees the issues with that and the added needless complexity?

[hokomoko]

You're still advocating a blacklist derived from a whitelist. Honestly am I the only one who sees the issues with that and the added needless complexity?

It is needless in your opinion, because this complexity lies in your domain rather than in someone else's.

I (and others posting in this thread) see the actually see the complexity needed in the engine to support this feature as needless.
There's nearly no advantage to the engine solution other than saving you (and maybe some random other game in the future) <10 lines of code, that you can immediately forget about (the future dev may even copy paste your solution, and not think about it at all).