Light Weight - Battle Order - Script Plugin, Idea

[Roguedeus]

I am thinking of writing a plugin for Yanfly's FTB Battle Option that utilizes its AP model but maintains the speed/initiative of the default system, with a twist.

Like FTB, actors will be able to take multiple actions in a turn, dependent on the AP used in the action. But unlike FTB, each potential action point has its own initiative and actions that require multiple action points must WAIT until the total points needed reach their initiative order.

The catch, of course, is that the player will need a visual indicator so they are aware when their potential actions will fall within the order. I figure I could use Yami's - Order Gauge for this somehow.

Thoughts? Critiques? Potential issues?

[Roguedeus]

Ao no Kiseki CBS - The battle system I linked right above that post. Does he specify terms for each individual script?

On that note. Someone at rpgmakerweb says the terms are free to use, even commercial.

[Roguedeus]

The authors blog has this... http://kaisou-ryouiki.sakura.ne.jp/

(Google Translate)

Material of the Terms of Use

    RGSS3: that this is a regular user of RPG Maker VX Ace
    Photos and sound: it can be used without restriction
    Remodeling is free
    Material as it is in reprint is prohibited (OK if was modified)
    We do not take any responsibility even if some kind of failure occurs due to the use of the material
    Please be sure to back up before use
    Description Please read properly
    It is OK to be employed in the Toka commercial
    Such as the use of reporting and described to the ReadMe is not particularly necessary
    Support and request is not accepted
    Use within the range of common sense

If I assume what the translation says is accurate, its saying that Commercial use is fine, and editing the code for personal use is fine, as long as you credit the author.

Am I wrong?

[Roguedeus]

On that note, I have no idea if or when my work will be sold someday, I just want to make sure that when the determination is made, I haven't used anything I shouldn't.

[HimeWorks]

Seems to be OK. There's a topic on the forums about translated tou On Jun 2, 2015 2:37 PM, "Roguedeus" notifications@github.com wrote:

The authors blog has this... http://kaisou-ryouiki.sakura.ne.jp/

Material of the Terms of Use

RGSS3: that this is a regular user of RPG Maker VX Ace
Photos and sound: it can be used without restriction
Remodeling is free
Material as it is in reprint is prohibited (OK if was modified)
We do not take any responsibility even if some kind of failure occurs due to the use of the material
Please be sure to back up before use
Description Please read properly
It is OK to be employed in the Toka commercial
Such as the use of reporting and described to the ReadMe is not particularly necessary
Support and request is not accepted
Use within the range of common sense

If I assume what the translation says is accurate, its saying that Commercial use is fine, and editing the code for personal use is fine, as long as you credit the author.

Am I wrong?

— Reply to this email directly or view it on GitHub https://github.com/Hime-Works/Requests/issues/246#issuecomment-108047937 .

[Roguedeus]

If you are talking about rpgmakerweb then I am at a loss as to where the topic is. It doesn't jump out at me.

edit: Found it... Not in a very intuitive place IMO... But maybe I am just impatient. ;)

[Roguedeus]

Finely... http://forums.rpgmakerweb.com/index.php?/topic/27527-translated-terms-of-usage-of-japanese-blogs/page-5#entry334453

[Roguedeus]

That battle system is really quite slick. I have not had a chance to get into the nuts and bolts yet, but a quick look at the demo and I am excited.

I am pretty sure I will have to write a plugin in order to make it play nice with my new state mechanic. At the very least.

[Roguedeus]

No dice...

I couldn't preserve my state mechanic AND allow actors to jump each other in action queue without completely destroying the continuity of turns.

The fundamental change that battle system does is make every action its own turn. So if an actor acts twice before any enemies act, two turns have passed for the actor, while only one turn passed for the enemies.

I figured that could simply be the issue with having greater speed, is that your turn limited defenses and buffs lasted a shorter duration... But then it hit me. Every action, every battler processed regeneration. As already pointed out, if you act twice, you regenerate twice. Which of itself isn't all that bad, except I have at least three entire scripts already built on timing using regenerate_all as some kind of reference point to 'count' towards duration. Talk about FUBAR.

Id have to rewrite and re-balance my armor mechanic, my item restrictions, my state mechanic, and all items using my state effects over time script... (advanced damage and healing over time)

I was really hoping I might use that system too. Its really slick and polished. /sigh

[Roguedeus]

Iterate, Iterate, iterate...

Come full circle. Looks like all the time I've spent re-engineering Yanfly's FTB into a weird hybrid was for naught. It just doesn't feel right. I may mess with it some more a bit, but not to the point of rewriting it almost completely.

edit: On that note... I may end up using the Ao no Kiseki CBS. I'll just have to disable a few things. Another iteration to check. ;)

[HimeWorks]

Consider writing from scratch. FTB itself can be implemented in a hundred linE's or two. On Jun 4, 2015 12:09 AM, "Roguedeus" notifications@github.com wrote:

Iterate, Iterate, iterate...

Come full circle. Looks like all the time I've spent re-engineering Yanfly's FTB into a weird hybrid was for naught. It just doesn't feel right. I may mess with it some more a bit, but not to the point of rewriting it almost completely.

— Reply to this email directly or view it on GitHub https://github.com/Hime-Works/Requests/issues/246#issuecomment-108713186 .

[Roguedeus]

I'd like to write my own combat mechanic but I am reminded how I thought it would be simple changing his script the first time, and that turned into a week long ordeal where I simply gave up and cut out some parts I was attempting to add.

It would seem I am still in the habit of biting off more than I can chew.

I am still stunned that my state mechanic has managed to work so well. Though Its only a base script atm with almost no options. Then again states are rather straight forward compared to combat. Or at least easier for me to wrap my head around the data flow.

I don't mean to be defeatist or anything, its just that I am working alone and its really easy for me to get side tracked or thrown completely off by something I want, but can't solve. Then I have to pester you, or try to find someone else that's willing to assist me.

[Roguedeus]

Could you analyze Yanfly's FTB mechanic and tell me what I would need to do to make it 'fixed' turn rather than 'free' turn, where all acting battlers (including enemies) order of action are queued by a formula result.

Or would you be willing to take a script request?!?

I could suggest a few specific changes if you are willing.

edit: (In the mean time, I am going to see if I can't get it... Its been a while since I tried last time. Maybe my brain can handle it now.)

[HimeWorks]

Open a new issue with a description of what you would like in your battle system.

[Roguedeus]

Thanks!

If I find myself unable to manage, I'll make the request. :)

[Roguedeus]

I just spent a few hours doing my best to unwrap the default battle mechanic. I'm not finished, but I seem to be missing something between Scene_Battle.battle_start and Scene_Battle.turn_end. Especially, where and how Scene_Battle.process_action resolves.

  def update
    super
    if BattleManager.in_turn?
      process_event
      process_action
    end
    BattleManager.judge_win_loss
  end

  def process_action
    return if scene_changing?
    if !@subject || !@subject.current_action
      @subject = BattleManager.next_subject
    end
    return turn_end unless @subject
    if @subject.current_action
      @subject.current_action.prepare
      if @subject.current_action.valid?
        @status_window.open
        execute_action
      end
      @subject.remove_current_action
    end
    process_action_end unless @subject.current_action
  end

  def process_event
    while !scene_changing?
      $game_troop.interpreter.update
      $game_troop.setup_battle_event
      wait_for_message
      wait_for_effect if $game_troop.all_dead?
      process_forced_action
      BattleManager.judge_win_loss
      break unless $game_troop.interpreter.running?
      update_for_wait
    end
  end

I see where in_turn? determines if the BattleManager @phase is :turn and then calls the method, and this occurs in a constant loop regardless of the current turns resolution. But I am failing to see how it all fits together somehow.

I see all these disparate parts and I don't see where they become the battle mechanic. As such, its exceptionally difficult for me to follow the data flow, and why it would be in one place rather than another.

edit: recursion used to turn my head into knots... but now, for some reason, its moved on to complex loops like Scene_Battle.update and how it plays with BattleManager so well.

[Roguedeus]

I am not sure if this is accurate. But this is what I have noted from what I can understand.

Default Battle Flow:

 *) - Battle Start Prep: 
      (+)Process Event (if event triggers on turn ZERO)

#------------------------------------------------
 1) - (Scene_Battle) *PARTY* Command Selection
      (+)Refresh Status Windows
      (+)(BattleManager) *ACTOR* Input Start (#2)

      (-)(Scene_Battle) Next Command, if FIGHT (#3)
      (-)*TURN* Start (If no Actors can act) (#5)

#------------------------------------------------
 2) - (BattleManager) *ACTOR* Input Start
      (+)*PARTY* Make Actions
      (+)*TROOP* Make Actions
        Note: Enemy actions are PREDETERMINED here. Before actor selection.

      (-)Returns TRUE if Not Surprised, and Actors can act. (#1)

#------------------------------------------------
 3) - (Scene_Battle) Next Command
      (+)(BattleManager) Next Command (Can Actors act?)
        (+)Actor index set. (Current Selecting Actor)
        Note: Actor skipped if battler.next_command is FALSE. (no more actions)    

      (-)*ACTOR* Command Selection (#4)
      (-)*TURN* Start (If no Actors can act) (#5)

#------------------------------------------------
 4) - (Scene_Battle) Command Selection
      (+)Selection Made.

      (-)(Scene_Battle) Next Command (Repeats until no more actors can act) (#3)

#------------------------------------------------
 5) - (Scene_Battle) *TURN* Start
      (+)Windows Closed

      (-)(BattleManager) *TURN* Start (#6)

#------------------------------------------------
 6) - (BattleManager) *TURN* Start
      (+)Actor index CLEARED
      (+)*TROOP* Current Turn iterated.
      (+)(BattleManager) Make Action Orders. (Order of actions determined)
        Note: 'action_battlers' array is created & sorted here.

      (-)(BattleManager) *TURN* Start (update)

#------------------------------------------------
 Update) - Process Event

 Update) - Process Action
      (+)In 'action_battlers' order, each battlers actions are performed.
        Note: Array is shifted, until empty.

      (-)*TURN* End (If no more battlers in array) 

[phase]

@phase

that notified me :P

[Roguedeus]

Perhaps I am getting stuck on how the update -> process_action loop, and thus the process_action method itself, knows when...

Wait... In the default mechanic, @phase remains :turn until all @subject (actors) have performed all their actions... And this only changes when turn_end changes @phase... Which itself only happens if there are no longer any valid @subject... And there are only valid @subject if BattleManager.make_action_orders has been called and @action_battlers has been filled.

So...

Why doesn't process_action simply return turn_end unless @subject all the time?!?

[Roguedeus]

Do I need to ask a more specific question?

[HimeWorks]

Didnt see the notification.

Doesn't it return turn end unless subject all the time? On Jun 20, 2015 11:44 PM, "Roguedeus" notifications@github.com wrote:

Do I need to ask a more specific question?

— Reply to this email directly or view it on GitHub https://github.com/Hime-Works/Requests/issues/246#issuecomment-113861367 .

[Roguedeus]

I'll try to make since of the code again tonight, and ask any questions I can more constructively.

The above is generally a pile of confusion as to how the general flow of data in the scene is handled. I can't follow it from beginning to end. :) I was wondering if you might shed some light on it.

[Roguedeus]

I made three posts about the confusion.

[Roguedeus]

Or I could just play Chris Sawyers Locomotion all night... :p Talk about getting distracted.

edit (FML: The last thing I need right now is a decade old game I loved, but could rarely play at the time, to suddenly be completely available and calling to me like a sirens song)

[Roguedeus]

Well, that didn't take long. I'm not sure why it didn't click way back when I first played the game, but Its pretty obvious now. There is a major, and fatal, flaw in its basic design. Much the same as with a few other really good games that are nothing more than a practice in repetition. Many people don't have a problem with that, but I do. Once I find that point in a game where the basic mechanic is laid bare and the select few 'I WIN' buttons are made obvious, I can rarely bring myself to keep playing. At least, as long as there are alternatives that fill the same basic role.

Locomotion is now in the same league as Creeper World III and Heroes of Might and Magic III... I'll play it when I need something to occupy my attention for an hour or so, but devoid of any real sense of challenge. :)

Now to see if I can get my ass back into something productive.

[Roguedeus]

Alright, I have traced every step of the scenes execution and I am still left with the same question.

How can this method be called every update (every frame) and NOT automatically end the turn, because BattleManager.make_action_orders hasn't been called yet to create the array from which @subject is assigned?

  #--------------------------------------------------------------------------
  # * Battle Action Processing
  #--------------------------------------------------------------------------
  def process_action
    return if scene_changing?
    if !@subject || !@subject.current_action
      @subject = BattleManager.next_subject
    end
    return turn_end unless @subject
    if @subject.current_action
      @subject.current_action.prepare
      if @subject.current_action.valid?
        @status_window.open
        execute_action
      end
      @subject.remove_current_action
    end
    process_action_end unless @subject.current_action
  end

BattleManager.next_subject would be returning nil every frame... Making return turn_end unless @subject TRUE. Thus turn_end should be getting called every frame that a @subject has not been assigned. Thus the scene should be ending the moment it begins, before any actions can be assigned.

I simply can not find the point in the code where this should be getting prevented. Yet its NOT happening, so it must be there. I just CANT SEE IT.

Help? :)

[HimeWorks]

Are you sure that method is called every frame? For example print out what subject is. On Jun 23, 2015 4:32 AM, "Roguedeus" notifications@github.com wrote:

Alright, I have traced every step of the scenes execution and I am still left with the same question.

How can this method be called every update (every frame) and NOT automatically end the turn, because BattleManager.make_action_orders hasn't been called yet to create the array from which @subject is assigned?

--------------------------------------------------------------------------

* Battle Action Processing

--------------------------------------------------------------------------

def process_action return if scene_changing? if !@subject || !@subject.current_action @subject = BattleManager.next_subject end return turn_end unless @subject if @subject.current_action @subject.current_action.prepare if @subject.current_action.valid? @status_window.open execute_action end @subject.remove_current_action end process_action_end unless @subject.current_action end

BattleManager.next_subject would be returning nil every frame... Making return turn_end unless @subject TRUE. Thus turn_end should be getting called every frame that a @subject has not been assigned. Thus the scene should be ending the moment it begins, before any actions can be assigned.

I simply can not find the point in the code where this should be getting prevented. Yet its NOT happening, so it must be there. I just CAN SEE IT.

Help? :)

— Reply to this email directly or view it on GitHub https://github.com/Hime-Works/Requests/issues/246#issuecomment-114406044 .

[Roguedeus]

I had been trying not to poke the code, and visualize it completely in my head... I have not yet.

I see now why what I asked isn't happening. @phase doesn't equal :turn until turn_start is run. So update won't execute process_action until ability selection is completed.

Is it just me, or is that entire process REALLY convoluted?

[Roguedeus]

BTW, I can trace the flow from start to finish now... Oddly, I don't know why it was so difficult for me to see it from the beginning.

I can't explain it.

[Roguedeus]

Essentially the flow of battle revolves around a hand full of methods. (In order of execution)

battle_start (Which kicks off the order with the initial BattleManager.input_start conditional)

BattleManager.input_start (which creates each battlers default actions)

next_command (which repeats until ALL action selection completes)

turn_start (which merely signals to process_action its OK to do its thing)

process_action (watching from inside an update loop for some odd reason, along with BattleManager.judge_win_loss)

turn_end (Which re-starts the order with BattleManager.input_start)

[HimeWorks]

Let's break down the battle logic. This is how the scene sees it

1. Battle Start - start
2. Battle Processing - update
3. Battle End - terminate

Start and end are pretty simple. Breaking down battle processing

Input Start
Enter Input - next_command until all battlers have inputed
Input End
Turn Start
Process Turn
Turn End

The default system doesn't use Input End and instead simply begins the turn when all inputs have been entered.

Now we're processing turns for every battler

Process Action
Process Action End

So putting it together we have

Battle Start
Loop
   Input Start
      Process Input
   Input End
   Turn Start
      Process Action
      Process Action End
   Turn End
End Loop
Battle End

Doesn't seem that convoluted.

[Roguedeus]

Thanks. That is pretty much what I tried to say. :)

Glad I wasn't mistaken.

At first, I couldn't see the point of the update method constantly watching the state of @phase and then resolving pending actions... But since, I've realized that is a good way to make sure that you don't have to ensure every possible action during a turn checks for an end to the battle. Instead the BattleManager is watching for battle ending conditions at all times.

[Roguedeus]

Currently, I am trying to hack a very primitive, execute actions in battler order, into Yanfly's battle system.

At the moment I am trying to determine make_action_orders during input_start and then shifting through them in next_command (much like 'Free Turn Battles' already does), but including enemies.

If I do everything correctly, process_action will instantly turn_end as all the battlers will have performed their actions.

[Roguedeus]

Holy shit... It works.

/boggle

[HimeWorks]

Boom, there it is.

Figured out how battle logic works and then it just works.

[HimeWorks]

Now, if your action orders automatically re-order themselves whenever a battler makes a move (eg: I slow you down, or I choose to wait), now you have a working action gauge.

Though since you mentioned turns, now you have to make a decision: how long is a turn? When all battlers have made one action?

eg: Actor and Slime are in battle. Actor has a speed of 200, slime has a speed of 100. This means that the actor is twice as fast as the slime and theoretically can make twice as many actions for every action the slime makes.

Assuming "attack" takes 0 time to cast, then here is a possible sequence of events:

Assuming everyone can act immediately when battle begins

1. Actor attacks
2. Slime attacks
-----------------------------
3. Actor attacks
4. Actor attacks
5. Slime Attacks
------------------------------

Now, when does a turn end? When both battlers have made an action? In this case, this means that a single battler could move a lot of times before the turn is over.

[Roguedeus]

I am going to hit this will all the combinations of actions I can (repeats, multiple actions per battler, etc) and see if what I did isn't flawed.

Once thats done. I am going to hack in Yanfly's (FTB) action points guage windows.

Once thats done, and working, I am going to make the order of action, count remaining AP's... With a 'Pass' and 'delay' option. Delay will cause the current battlers position to shift behind the next battler in line. Pass, will end that battlers selection while saving some of its AP to carry over to the next round.

Its not as dynamic as a full on action guage, but it should simulate casting time well enough. As in, actions requiring more AP than you have, you need to PASS your turn to have enough in the next turn to use that action. And it will allow actors to 'hold' their actions until others have acted first. With the risk of not knowing whos the next in order of action.

Personally, I don't think that visible orders of action are conducive to real strategy. The fear of not knowing exactly when your party can act is partially why you act one way vs. another when fighting really dangerous enemies.

Or I could hate it... And reiterate AGAIN... ;)

[HimeWorks]

There are definitely a lot of ways to implement action order.

To avoid too much work in case of iteration it would be useful to find a way to separate the order logic from the battle system On Jun 25, 2015 4:47 PM, "Roguedeus" notifications@github.com wrote:

I am going to hit this will all the combinations of actions I can (repeats, multiple actions per battler, etc) and see if what I did isn't flawed.

Once thats done. I am going to hack in Yanfly's (FTB) action points guage windows.

Once thats done, and working, I am going to make the order of action, count remaining AP's... With a 'Pass' and 'delay' option. Delay will cause the current battlers position to shift behind the next battler in line. Pass, will end that battlers selection while saving some of its AP to carry over to the next round.

Its not as dynamic as a full on action guage, but it should simulate casting time well enough. As in, actions requiring more AP than you have, you need to PASS your turn to have enough in the next turn to use that action. And it will allow actors to 'hold' their actions until others have acted first. With the risk of not knowing whos the next in order of action.

Personally, I don't think that visible orders of action are conducive to real strategy. The fear of not knowing exactly when your party can act is partially why you act one way vs. another when fighting really dangerous enemies.

Or I could hate it... And reiterate AGAIN... ;)

— Reply to this email directly or view it on GitHub https://github.com/Hime-Works/Requests/issues/246#issuecomment-115392350.

[Roguedeus]

I figure I'll shoot for the way that requires the least amount of on screen doodads. :)

Also... I'm afraid I was to quick to claim victory. I am missing something obvious and now its broken. The order of action, and resolution is functioning for enemies, but actors aren't shifting.

Somehow the actors @actions are getting reset... It would be funny if it wasn't so difficult for me to find.

[Roguedeus]

Oh boy... I am working really hard NOT to lose my cool. But I am having one helluva time finding where the hell this is happening.

Enemies process perfectly. Actors selections execute, but then the same actor is selected over and over again, because their action array is not staying empty. But according to my output, it is getting emptied exactly the way it should. Only between @subject.remove_current_action and the next BattleManager.next_command the array is getting refilled with a blank action waiting for its item to be assigned.

edit: At least, thats my best guess at the moment.

[Roguedeus]

I'll note that it works fine in a clean project with just Yanflys scripts.

Ugh...

[Roguedeus]

I found the offending script and I have been staring at it for the last 20 minutes or so with no luck as to figuring out how the hell it actually did.

Yanfly's Instant Cast...

The only time it touches @subject.make_actions is during perform_instant_action and that is only called if instant_action? is TRUE... Which I just verified its NOT. There is an alias of execute_action that calls enemy_add_actions but that particular method has return if @subject.actor? as a conditional. And I verified that isn't getting through.

I really want to understand HOW this is happening. But I really don't need to. I had planned on pulling Instant Cast anyway, as my new mechanic effectively does the same thing once I consider AP's as a limiting factor to actions and ZERO AP actions will essentially be instant actions.

It just really bothers me that this happens. The best thing seems to be to walk away for the rest of the day, and look at it again the next.

[HimeWorks]

At least the problem was caused by others' code! On Jun 26, 2015 6:53 PM, "Roguedeus" notifications@github.com wrote:

I'll note that it works fine in a clean project with just Yanflys scripts.

Ugh...

— Reply to this email directly or view it on GitHub https://github.com/Hime-Works/Requests/issues/246#issuecomment-115911629 .

[Roguedeus]

Yeah. I am actually kind of excited that it wasn't my mistake this time... lol

I actually got this right, pretty much right out of the box. Once I took the time to understand the flow of the data anyway.

Of course, it helps when I know that if I had a problem I simply can't get, that someone is willing to answer a question for me. I am glad you put up with me.

[Roguedeus]

HAH! I just spent the last 3 hours tweaking how battler speed is factored...

I am obsessive... Its a flaw.

[Roguedeus]

I've gone with a dual parameter speed determination. One primary and one secondary, where the primary parameter is the leading determination (independently), and the second is an 'adjustment' based on the avg of that parameter between all battlers in the scene (dependently). (The parameters are Finesse and Ingenuity, aka: AGI and LUK)

Thus its possible for a battler that is weak in the primary determiner to occasionally get the jump on their target due to the fact that they are above the battlefield average in the secondary determiner. However, the primary determiner is ALWAYS the most important.

Being below average in the secondary can also cause slight penalties. Thus a battler with superior primary AND secondary determiners will almost always lead each turn.

Its a little complex for something as simple as a battle order, but easy to understand and open to min/max game play, with some planning.

It just took me three hours to get the math right. :)

[Roguedeus]

Just completed the AP conditions in action selection. Works great.

Next up... Visuals.

[Roguedeus]

I'm adding the custom commands to the actors and having some unexpected trouble...

Is there any reason why this works:

  #-----------------------------------------------------------------------------
  # new: 
  #-----------------------------------------------------------------------------
  def add_command_delay(args)
    cmd = Command_Item.new("Delay", :delay)
    add_command(cmd)
  end
  CommandManager.register(:delay, :actor)

and this does not work:

  #-----------------------------------------------------------------------------
  # new: 
  #-----------------------------------------------------------------------------
  def add_command_pass_turn(args)
    cmd = Command_Item.new("Pass", :pass_turn)
    add_command(cmd)
  end
  CommandManager.register(:pass_turn, :actor)

All else being equal that is... <cmd: delay> & <cmd: pass>, both on the same actor. The code is nearly identical. But only Delay is showing up on the command list.

Here are the command call methods.

  #-----------------------------------------------------------------------------
  # new: 
  #-----------------------------------------------------------------------------
  def command_delay
    puts("DELAY HERE")
    next_command
  end

  #-----------------------------------------------------------------------------
  # new: 
  #-----------------------------------------------------------------------------
  def command_pass_turn
    puts("PASS TURN HERE")
    next_command
  end

If its something obvious... I blame my fatigue.

[HimeWorks]

Try Game_Command instead of instantiating an item command On Jun 28, 2015 9:55 PM, "Roguedeus" notifications@github.com wrote:

I'm adding the custom commands to the actors and having some unexpected trouble...

Is there any reason why this works:

-----------------------------------------------------------------------------

new:

-----------------------------------------------------------------------------

def add_command_delay(args) cmd = Command_Item.new("Delay", :delay) add_command(cmd) end CommandManager.register(:delay, :actor)

and this does not work:

-----------------------------------------------------------------------------

new:

-----------------------------------------------------------------------------

def add_command_pass_turn(args) cmd = Command_Item.new("Pass", :pass_turn) add_command(cmd) end CommandManager.register(:pass_turn, :actor)

All else being equal that is... & , both on the same actor. The code is nearly identical. But only Delay is showing up on the command list.

If its something obvious... I blame my fatigue.

— Reply to this email directly or view it on GitHub https://github.com/Hime-Works/Requests/issues/246#issuecomment-116364918 .

[Roguedeus]

I am getting a no method error (here) when I do that.

  #-----------------------------------------------------------------------------
  # Define built-in command methods according to the API specs
  #-----------------------------------------------------------------------------
  def add_command(cmd)
    cmd.battler = self   #<---
    @base_commands.push(cmd)
  end

So I used Game_BattlerCommand instead. :) It didn't help.

<cmd: guard>
<cmd: item>
<cmd: potions>
<cmd: delay>
<cmd: pass>  #<--- Invisible

[Roguedeus]

Pass must be duplicating some other method in the ruby library... Because a totally random alternative works just fine.

edit: Nope. It was the symbol... dunno why but it just didn't like :pass_turn changed it to :pass and it works fine.