Blacklist target category - Page 2

Blacklist target category

Requests for features in the spring code.

Moderator: Moderators

User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Blacklist target category

Post by Forboding Angel »

Arugh, are you so oblivious?

This would mean that you would have to keep a master list of all categories used in _post and if you did not keep this list up to date, bad (or interesting, depending on your point of view) things would happen. It's kludgy and messy. Moreover it is not consistent with the whitelist behavior, and as a result is quite ugly.
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Blacklist target category

Post by FLOZi »

No you wouldn't.
hokomoko
Spring Developer
Posts: 593
Joined: 02 Jun 2014, 00:46

Re: Blacklist target category

Post by hokomoko »

FLOZi wrote:No you wouldn't.
You can construct the category list in a quick pass over all units. No need to write it explicitly.

Code: Select all

categories = {}
for _, unitDef in pairs(UnitDefs) do
    categories[unitDef.category] = true
Google_Frog
Moderator
Posts: 2464
Joined: 12 Oct 2007, 09:24

Re: Blacklist target category

Post by Google_Frog »

Forboding Angel wrote:
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?
Yes.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: Blacklist target category

Post by PicassoCT »

Yes.

But you are free to fork the engine. and push and pull
https://github.com/spring/spring

It seems you used up all your knorkes for today. You must construct additional knorkes. ;)
User avatar
Silentwings
Posts: 3720
Joined: 25 Oct 2008, 00:23

Re: Blacklist target category

Post by Silentwings »

To me also the suggested unitdefs/_post implementation seems natural. Although it is a bit annoying only having 32 categories.

If it was possible to both blacklist and whitelist in the unitdef, then since a single unitdef belongs to multiple categories, it doesn't look fun to try and decide the "expected behavior" or suitable error msg for cases which did both at the same time in a logically inconsistent way.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Blacklist target category

Post by Forboding Angel »

hokomoko wrote:
FLOZi wrote:No you wouldn't.
You can construct the category list in a quick pass over all units. No need to write it explicitly.

Code: Select all

categories = {}
for _, unitDef in pairs(UnitDefs) do
    categories[unitDef.category] = true
Ok, that's all fine and good, but in the end, you are using a whitelist to create a blacklist and in turn output a whitelist. :|
hokomoko
Spring Developer
Posts: 593
Joined: 02 Jun 2014, 00:46

Re: Blacklist target category

Post by hokomoko »

Ok, that's all fine and good
I'm glad we agree.
User avatar
Jools
XTA Developer
Posts: 2816
Joined: 23 Feb 2009, 16:29

Re: Blacklist target category

Post by Jools »

How about we agree to call it greylist and move on to wish each other a happy easter?
Post Reply

Return to “Feature Requests”