Spring RTS Engine

Posted: **28 Mar 2015, 21:46**

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

Posted: **28 Mar 2015, 23:25**

you have badtargetcategory, that's a blacklist.

Posted: **28 Mar 2015, 23:30**

no, badtargetcategory is just categories that are prioritised lower.

Posted: **29 Mar 2015, 04:05**

hokomoko wrote:no, badtargetcategory is just categories that are prioritized lower.

THIS^^

Posted: **29 Mar 2015, 15:52**

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

Posted: **29 Mar 2015, 16:42**

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

Posted: **29 Mar 2015, 17:16**

yeah, 32. Why is that?

Posted: **29 Mar 2015, 17:48**

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

Posted: **30 Mar 2015, 02:20**

hokomoko wrote: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.

Posted: **30 Mar 2015, 12:23**

White list is ideal for s44.

Posted: **30 Mar 2015, 12:24**

That doesn't invalidate the need for a blacklist.

Posted: **31 Mar 2015, 17:09**

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.

Posted: **31 Mar 2015, 18:45**

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.

Posted: **31 Mar 2015, 22:10**

Google_Frog wrote: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.

Posted: **01 Apr 2015, 01:01**

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)

Posted: **01 Apr 2015, 02:34**

Forboding Angel wrote: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).

Posted: **01 Apr 2015, 18:57**

Forboding Angel wrote: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.

Posted: **01 Apr 2015, 19:31**

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

Posted: **01 Apr 2015, 19:34**

Google_Frog wrote:
Forboding Angel wrote: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?

Posted: **02 Apr 2015, 00:06**

Forboding Angel wrote: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).

Spring RTS Engine

Blacklist target category

Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category

Re: Blacklist target category