"Type" value range in State file

[GoogleCodeExporter]

What feature would enhance usability or efficiency?
Having the possibility to enter range of values in the State file ; or maybe 
pre-existing families?

What steps would demonstrate the improvement granted by the recommended
feature?
1. It would make the State file way more readable AND more easily 
maintainable/changeable (by not having dozens of copy/paste'd lines of options)
2.
3.

What is the current behavior in the above situation?
Possibly very big number of exactly similar "behaviour description" lines

What revision of the product are you using?
172

What type of homunculus/mercenary are you using?
Vanilmirth

Please provide any additional information below.
So basically no real new functionality, just making use of the State file more 
easy. I actually came upon the idea by wanting my homonculus not to attack 
players, homonculi and mercenaries: I had to have "Type" lines for type 0 to 
25, and then 6001 to 6046 (or something along those lines). Unless I completely 
missed some already existing range functionality (in which case you can nuke 
this request right now), I had to add it one by one, with exactly the same 
settings. And then I thought later that I would rather have the homonculus be 
in DefendOnly mode, with no casting delay (I have some delay in my Default 
case) --> I needed to add/modify lines exactly the same way on EVERY of the ~65 
lines (which I didn't gather the courage to do :D)

You got the idea.

Might be some families instead (e.g. 'Player' = 0 to 25) to keep it simple, as 
I think players, homonculi and mercenaries are the most susceptible to share 
options for their Types, while monsters in general most likely don't get too 
much common options (and do not come in nice Type order).
I just like tidy effortless config files, that's all :P

Original issue reported on code.google.com by talimek...@hotmail.com on 22 Aug 2010 at 7:49

[GoogleCodeExporter]

Okay. I've been thinking about this for a while, and I agree: It is very 
necessary. Thanks for the suggestion! Now, I have a question of opinion.

The way that I'm planning to implement this is in an extension to the existing 
ActorOptions setup. I'll add a table of "ActorOptionSets" (or similar name) 
that would have the following options: "BaseActorForm" ("Type" or "ID"), 
"BaseActorIdentifier" (TypeID, actor ID, or unused for default), 
"ActorGroupForm" ("Type" or "ID"), "ActorGroupStart", "ActorGroupEnd"... That's 
kind of hard to see, so I'll give an example

rail_state["ActorOptionSets"] = {}
rail_state["ActorOptionSets"]["Players"] = {}
rail_state["ActorOptionSets"]["Players"]["BaseActorForm"] = "Type"
rail_state["ActorOptionSets"]["Players"]["BaseActorIdentifier"] = 0
rail_state["ActorOptionSets"]["Players"]["ActorGroupForm"] = "Type"
rail_state["ActorOptionSets"]["Players"]["ActorGroupStart"] = 1
rail_state["ActorOptionSets"]["Players"]["ActorGroupEnd"] = 25

This example would cause all types between 1 and 25 to imitate type 0. You 
would still have to specify a "ByType"][0] = {} block.

Would that be sufficient to solve this problem in your situation?

Original comment by faithful...@gmail.com on 2 Sep 2010 at 3:48

• Changed state: Pending

[GoogleCodeExporter]

Yes, that would solve my little "problems" :)

That's a nice solution. And although I have to admit that I needed your example 
and its description to understand the idea, I have nothing more simple in mind 
right now, and this solution is actually quite straightforward once you get how 
it works (using an existing ActorOptionSets as a "model"/behavior pattern for 
others).

Still, I have a question: what would the "Players" label be used for?
Nothing? (just a label to distinguish 'families' and help remember what we were 
describing)
or used somewhere else as a shortcut to this 'family'? in which case it might 
get messy: is the model (here '0') excluded from the definition of the family? 
what about cascaded, interwoven or clustered families? (like a single "swordman 
class" family can not be made without defining behavior for Swordman, then 
making a family for Knight based on it, then Crusader (as the Type are not 
contiguous), etc... point being that there wouldn't be a nice swordmanClass 
label to used as shortcut -if that's indeed the idea- but some 
swordmanClassPart1, swordmanClassPart2, and so on, instead)

I'm not trying to be annoying here. Just trying get your idea (/be sure about 
it), and maybe help you check that there is no blind spot in it.

Original comment by talimek...@hotmail.com on 8 Sep 2010 at 12:47

[GoogleCodeExporter]

I've been thinking on this. The "players" label would simply be a unique 
identifier for that group. It would not be used by the AI other than to 
reference the unique settings.

I don't think that nested/cascaded families would be of a great benefit. It'd 
make the configuration even more difficult to understand for what seems to be 
minimal gain. To take your swordsman hierarchy as an example, would defining 
actions to take against a crusader be anything similar to swordman? I'm not 
convinced that it would be. Setting up a hierarchy in a configuration like 
RAIL_State would be more difficult than simply making new groups for each, and 
there would be nothing stopping multiple groups from modeling off of the same 
base actor.

What do you think?

Original comment by faithful...@gmail.com on 17 Sep 2010 at 5:08

[GoogleCodeExporter]

If the "players" label is just something for us, then it's perfectly fine to 
make multiple groups. I don't think that we need anything more complicated

Original comment by talimek...@hotmail.com on 22 Sep 2010 at 9:41

[GoogleCodeExporter]

I've been thinking a little about this, i don't know too much about LUA 
programming, but there must be a way to accomplish this, how about an 
intelligent way to write the config for families? i.e:

rail_state["ActorsGroup"] = {}
rail_state["ActorsGroup"]["Players"] = {}
rail_state["ActorsGroup"]["Players"]["BaseActorForm"] = "ByType"

Here's when it can start to get tricky:
rail_state["ActorsGroup"]["Players"]["GroupValues"] = 0.25,27,30.40

Now in this string we find the values separated by dots (.) or by comas (,).
Anything between dots means it's a range, in the previous example we have 
"0.25", meaning a range from 0 to 25 and later we have coma separated values, 
which mean included in the group one by one "27,30" meaning the value 25 and 30 
are part of the group as well.
I find this very convenient not only for PvP WoE but also for friending.
I know it can increase the complexity of configuration writing at a point, but 
that's what the wiki is for isn't it?

Then we just add the normal configuration for any actor (these are just random 
values):
rail_state["ActorsGroup"]["Players"]["MaxCastsAgainst"] = 3
rail_state["ActorsGroup"]["Players"]["FreeForAll"] = false
rail_state["ActorsGroup"]["Players"]["AttackAllowed"] = true
rail_state["ActorsGroup"]["Players"]["SkillsAllowed"] = true
rail_state["ActorsGroup"]["Players"]["TicksBetweenSkills"] = 0
rail_state["ActorsGroup"]["Players"]["Priority"] = 3
rail_state["ActorsGroup"]["Players"]["MaxSkillLevel"] = 5
rail_state["ActorsGroup"]["Players"]["DefendOnly"] = false

Original comment by Kusanag...@gmail.com on 22 Sep 2010 at 2:09

[GoogleCodeExporter]

Yeah it shouldn't be THAT hard to do.

http://lua-users.org/wiki/SplitJoin

Original comment by Kusanag...@gmail.com on 22 Sep 2010 at 6:06

[GoogleCodeExporter]

That would be even neater indeed, if it's not too much of a hassle/too 
time-consuming to implement properly

Original comment by talimek...@hotmail.com on 25 Sep 2010 at 8:55

[GoogleCodeExporter]

If I was going to implement a range as described by Kusanagi, I would use the 
more standard hyphens and periods: 0-25,27,30-40. This is easier to 
distinguish. Also, the table 

I'm still deciding the best way to implement ranges. I'm thinking that it 
should be split apart when loaded because splitting it on every access would 
cause the script to slow to a crawl if there were many different groups.

Original comment by faithful...@gmail.com on 5 Dec 2010 at 2:57

• Changed state: Accepted