Encounter Surprsie Conditon (Re-Visited)

[Roguedeus]

Is it possible to add a note tag to a troop the same way you do with 'Troop Escape Ratio', but have it dictate the chances that the battle is a surprise for the party?

At current moment this is the #1 request I can make. I am finding my current encounter system is lacking that single balancing component, and I can't find any surprise dictating scripts anywhere. Lots of escapes, and encounter rates, but no surprsies! :p

Thanks for your consideration!!

Note: I know I have gone a little crazy with my requesting. But I figure its better to share. It may give you an idea, and you may just say yes. :)

[HimeWorks]

http://himeworks.wordpress.com/2013/10/10/troop-surprise-condition/

Ratio only involves numbers. Condition works with any formula.

Might as well throw in a pre-emptive script out there while I'm at it. I guess I could always combine them together, but then I don't know what to call the script.

[Roguedeus]

Hah! I wish I could do that as easily as you do!

So cool!

[Roguedeus]

I am reviving this with a question (now appears to be a bug).

How would I make this apply to all encounters regardless if they are random/planned?
Never mind, I found the commented section. Un-commenting made it work.

However, it doesn't seem to like me using the ' s ' or ' v ' options in formulas...
(Tested in clean project)

Works
<surprise condition: p.agi < t.agi>
Works
<surprise condition: true>
Errors
<surprise condition: v.10 > 10>
Errors
<surprise condition: s.51 == true>

Errors
<surprise condition: v10 > 10>
Errors
<surprise condition: s51 == true>

[Roguedeus]

While figuring this out I also realized why I have not noticed any surprise/preemptive battles in my testing of late...

I just wasn't noticing them, as the Ace Battle Engine seems to be breaking the notifications. Go figure.

I have often wondered why I sometimes thought I passed a round without enemy activity. The few times it happened when I was paying close attention to the beginning of the battles (and not just pounding keys to get through to what I wanted to find) they where genuine issues with something I did wrong. But now I realize not all of them where me. :p

[HimeWorks]

v and s are arrays so you would use

<surprise condition: v[10] > 10>
<surprise condition: s[51] == true>

I designed it the same way as the default damage formulas.

I should probably provide a link to this post somewhere
http://himeworks.wordpress.com/2013/06/04/rgss-formula-variables/

[Roguedeus]

Ah, I tried v.[x] and s.[x], not without the dot...

The one way I didn't try ends up being the right way. Go figure!
Thanks. I will check it out when I get a chance.

[Roguedeus]

I wanted to share this, for anyone else that might use it.

Its Hime's script with the planned events enabled, as well as a new option to use switches to guarantee either a preemptive strike or a surprise. Ignoring the switches (or setting them to 0) will enable Hime's script to run without adulteration.

SNIP

Link in next comment.

[Roguedeus]

Now that I am not a complete noob, I have gone ahead and made a simple plugin for Hime's script.

No need to altar anything. Just place it underneath.

http://www.roguedeus.com/Stuff/RDeus%20-%20Suprise%20or%20Preempt%20Switches.rb

[HimeWorks]

The on_encounter code would be executed twice, which may or may not be desirable. That is likely the reason why I commented it out.

[Roguedeus]

I can't think of a situation where it would cause a problem. Can you?
I am on the verge of passing out at my desk atm, so I might be missing something.

I just finished a plugin for Bubbles State Descriptions...

http://www.roguedeus.com/Stuff/RDeus%20-%20Object%20Descriptions.rb

Note:
Its primary function is to support more database info in *.txt files. Via Bubble's txt file notes script.

[HimeWorks]

Whether it's a problem is debatable, but think of the following situation

module BattleManager

  def self.on_encounter
     $game_parrty.total_random_encounters += 1 
     < other code >
  end
end

This is when someone decided that everytime they "encounter" something (ie: not an evented battle), they want to increment a variable by 1. Now, everytime they encounter an enemy, the counter gets incremented twice.

This is a silly example because there are MANY ways to write the code in such a way that you avoid such a problem, but usually, I don't like to call a method multiple times if it would compromise data integrity.

I believe a more "proper" approach is to do this in Game_Interpreter

def command_301
    return if $game_party.in_battle
    if @params[0] == 0                      # Direct designation
      troop_id = @params[1]
    elsif @params[0] == 1                   # Designation with variables
      troop_id = $game_variables[@params[1]]
    else                                    # Map-designated troop
      troop_id = $game_player.make_encounter_troop_id
    end
    if $data_troops[troop_id]
      # on_encounter here!
      BattleManager.setup(troop_id, @params[2], @params[3])
      BattleManager.event_proc = Proc.new {|n| @branch[@indent] = n }
      $game_player.make_encounter_count
      SceneManager.call(Scene_Battle)
    end
    Fiber.yield
  end

Which requires you to overwrite code, but overwriting code is only a problem if someone wants to use two scripts that overwrote the same method.

But it all really depends on how you see things. Some people don't see the example I presented as a problem at all.

[Roguedeus]

That's a good idea. There isn't a single script I am using that overwrites command_301, so it shouldn't be much trouble.

[Roguedeus]

Question:
Is the reason you want to use command_301 rather than just stick it into the battle_start alias, due to the tendency of people to overwrite certain methods over others?

battle_start is touched by a TON of scripts...

[HimeWorks]

Mainly because I don't want to call on_encounter again for the reason above.
However, because that's the only reason, it is easily fixed.

I've updated the encounter surprise script with a new "encountered_checked" flag to avoid this double checking.

[Roguedeus]

After fixing (I hope) the Element-Ex script rewrite, I feel like my brain is on fire... I am gonna have to update the plugin later. :p

Thanks for tackling that btw.