Closed Roguedeus closed 10 years ago
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.
Hah! I wish I could do that as easily as you do!
So cool!
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>
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
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/
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.
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.
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
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.
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.
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.
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.
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...
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.
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.
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. :)