Add Self State - Eval Condition

[Roguedeus]

Would you be willing to add an Eval condition to the Add Self State?

That way its not only a % probability, but can be based on whatever we can imagine? :)

I am thinking that my primary use will be to see if a state already exists, and then allow a chance of a new state to either stack with the old, or replace it with something worse.

That would be feasible wouldn't it?

Example:

• Use a spell, 50% chance of self poison.
• Use spell again, see poison, now 50% chance of death.
• Etc...

[Roguedeus]

Just to make sure, the Eval only needs to return true/false, and can run any code before hand?

Ex:

<eff: add_self_state 2 eval>

if a.state?(1)
    a.remove_state(1)
    return true
else
    return false
end

</eff: add_self_state 1 eval>

[HimeWorks]

The existing design first checks whether it can be added, and then proceeds to add it.

if rand < prob
  user.add_state(state_id)
end

So it would not have any compatibility issues with anyone already using the script.

However, the problem with my effect manager is that the note-tag format is hardcoded. The framework supports this extended note-tag

<eff: add_self_state-triggers>
  {plugin will parse this}
</eff>

But then that wouldn't be very suitable either, since the only way I know how to parse the stuff is like

option1: value1
option2: value2

It would require some thought how to actually implement it. Perhaps if I extended the note-tag to further support things like

<eff: add_self_state-triggers arg1 arg2  ... >
   {extended data}
</eff>

Then that would allow you to write arbitrary scripts in the extended data, while making it clear what the ID and condition type is.

[Roguedeus]

Last night I wrote a Blink script. Shockingly, it only took about three hours for me to find the data, manipulate it, and complete it.

I think that's a record! I may actually get to where I won't have to request you to do all the work, and just ask whenever I can't get something specific to work out. :)

Right now I think my primary focus should be to figure out RegExp's and Eval functionality. I would be better able to hold these sorts of conversations with you, and add my suggestions. Right now I kind of feel like a half-wit whenever you get to saying something like the above.

I know enough to understand what you are explaining, but not enough to work it out in my head and suggest solutions, or volunteer help.

[HimeWorks]

Most of the problems is currently a usability thing.

The note-tag structure I have proposed above is something I can do without much trouble since I've done it in other scripts before, but the question is whether it would be something that would be easy to use.

The example note-tag you suggested for specifying a scripted condition seems to be a suitable way to tag your skill/items.

[Roguedeus]

So to do this you'll have to expand the Effects Manager script I take it?

Would that mean that it could apply to all the plugins you've written for the manager?

[HimeWorks]

There are two ways I could go about doing this (possibly doing both in the end):

1. modify the framework so that each plugin can override the note-tag parsing for themselves. Then you're not stuck with having to choose one of the note-tag formats I provide
2. provide additional note-tag formats, and then allowing you to choose which one you want to parse (possibly many, if necessary)

[Roguedeus]

If you are looking to preserve your original vision, and ease of use, you may just add an optional format for advanced use. I know a little bit about scripting, but I still get intimidated by custom note tag'ing and parsing. I can only imagine how other people look at it. Expecting the user to create their own individual tags may just get the option ignored.

[HimeWorks]

Going the extended note-tag would look something like this

def add_effect_IDSTRING_ext(code, data_id, args, ext)
    # type cast your args here

    # now add the effect to the object
    add_effect(code, data_id, args)
end

Which is basically the same as the regular add_effect_IDSTRING method except you get your ext data as well

Note that the original RPG::UsableItem::Effect does not support the use of extended arguments, so you're basically parsing the extra stuff into maybe a regular array and then adding it to your skill/item.

[Roguedeus]

I know I may seem a bit slow, but I have no experience using unknown-arg parameters, and wouldn't know what to do.

I'm sure I could figure it out quickly. I have read that this particular feature is one of Ruby's strengths.

[Roguedeus]

I have an idea about making magic get harder and harder to use, the more its used. The penalties get easier to resist as your caster class level increases, and you obtain optional passives. Its a way to try and counter balance the possibility of mana potion abuse and just to throw in a small level of challenge to bigger fights.

Currently, the way states work, I can only rely on the spell used to dictate the state applied to the caster. But with the ability to change the state applied based on the current condition of the target, I can ratchet up the state effect as often as new spells are cast, if cast too often.

Not to mention a system like this, might be applied to normal skills as a Conditional States option rather than a flat 'State Chance' that currently exists. It allows for a whole lot more variation in how one skill can have multiple consequences for the target, based on whatever is happening to the target at the time.

Right now in your scripts, and the community, I can find these state based functions.

• Passive States (Permanent states)
• Param Value States
• TP Value States
• Progressive States
• Yanfly's Lunatic States (Which has a ton of customizability)
• Temp Stats (Execution States)
• Water Walk State
• Toggling States
• State Action (Very similar to what I am describing, but causes a new skill to fire rather than a new state)
• Add Self-State (on action)
• Double Cast (on state)
• Morphing and Shapeshifting states
• Aura States
• Infective States
• Active Cost States
• Auto States (as begin of battle)
• Field States
• State Groups
• Terrain States
• Action States (Re-Action States, set per battler)
• Stealable States
• Transfer States
• Retain States (Permanent States)
• Untargetable State etc... I a sure I'd find more

Point is, that while I can find a script that allows for conditional skills... Your Action Skill Change script will fire a different skill when conditional is true, even multiple skills.

But nowhere is there a conditional state script. :)

[HimeWorks]

How about tagging a state with

<conditional state>
   if cond_1
      apply state 5
   else if cond_2
      apply state 7
   end
</conditional state>

So the whole purpose of that state is to act as a placeholder to apply a different state.

[Roguedeus]

That would accomplish the same thing, pretty much.

You have a knack for finding the most efficient way of doing things. :)

[Roguedeus]

Just to be sure... The condition can be a code like

if rand(100) <= 50 for chances, or anything else that returns true?

Also, can the current conditions be removed/replaced?

I realize that states can resist other states, but that seems limiting. There may be times where stacking states is desired, and others where its not. Building in an auto-resist to a state makes that more complicated to accomplish.

[HimeWorks]

75 for conditional state discussion.

I imagine most of that would apply to the new script.