[ACE] Encounter Rate on Yanfly's System Options

[dinhbat3]

So I have successfully and quite easily (thanks to Yanfly's script design) added a variable controlling bar that the player can set in Yanfly's System Options script.

I have altered the calculation of the number of steps until the next encounter as well.

My question is whether it is possible for the alteration of the variable to cause a change immediately.

To explain what I mean:

Let's say my equation to calculate encounter is: n + $game_variables[x]

n = the default average set up on the map

x = the variable that is being controlled in Yanfly's System Options.

Once the player enters a map or finishes a battle. n is established.

By default the value of variable x = 0.

Let's say the map rolls n = 5.

5 steps later a battle will occur and n will be rerolled. Let's say to 7 this time.

If the player thinks that is too frequent they can go to the system options and change variable x.

Let's say the player sets the value of x to 20.

The problem is that n has already been rolled to be 7 and the count has already been set.

The changes applied in the menu will not take effect until there is another rolling of n.

The reroll won't happen again until a battle or a new screen, then the variable will be considered.

Is there any way to have it so that the encounter rate is rerolled when the setting for variable x is changed in the System Options Screen and it take effect immediately.

In the above example, I would want the 7 that rolled after the encounter to be rerolled and recalculated to something around 26. (reroll n = 6 + x value = 20).

Sorry for the long and probably over elaborate explanation. I hope someone has some ideas. Maybe a parallel process? But even then I wouldn't know how best to approach it. Thanks in advance for any ideas.

~ Dinhbat

 

[Kes]

I wonder if there might be an easier way of doing this, which would (I think) also solve your problem.

To prevent the 3-steps-and-it's-a-battle(even when you've set e.g. 30 steps on the map) problem with the way that Ace handles the calculation of random battles I alter the default script from this:

class Game_Player < Game_Character #-------------------------------------------------------------------------- # * Create Encounter Count #-------------------------------------------------------------------------- def make_encounter_count n = $game_map.encounter_step @encounter_count = rand(n) + rand(n) + 1 endendto this:

@encounter_count = rand(n) + rand(n) + 1 + $game_variables[5]This would simply add the amount in variable 5 to the encounter count. This would increase the average by that amount and ensure that many steps have been taken before a battle.

What I then do is set that variable at the very beginning of the game.

What might work for you is setting it at some reasonable average at the beginning of the game and then link the variable to whatever you have set up in the Systems Option Menu.

btw, how exactly did you set that up?  That might make a difference, but I'd be interested to see how you've done it anyway.

EDIT

I didn't actually say that the function in the code above is in Game_Player

 

[dinhbat3]

I basically already did the same things as you have mentioned.

I set a variable equal to 100 at the start of my game. 100 because it works on percentage.

In Yanfly's System you can set a gauge that allows manipulation of variables. The player can change the variable from 0-300. (None to 3x rate)

I have already calculated a reasonable means to achieve an accurate @encounter_count based on the variable.

My question is not a problem of encounter rates. I have already found a calculation that solves that using the variable.

What I am asking for is a way so that the effects are enacted immediately after the gauge is altered.

Currently what happens is that the @encounter_count will not take into effect the updated variable until another encounter has occurred or until a new map is loaded (basically any time when the n value is re-established). So if a very low percentage was used, then half way thru the map you wanted to change that... you are likely not to get a reroll to update according to your change of heart until you get to a new screen or until you happen to get into the encounter from that low % encounter rate.

~ Dinhbat

 

[Yato]

Basically, I would insert a check when exiting Scene_Options and call $game_player.make_encounter_rate if the variable has changed.

Actually, upon looking at the system options script, I might even just place the call right in the variable change method. Something along the lines of

def change_custom_variables(direction)#original method$game_player.make_encounter_rate if var == 4end

Changing the 4 with your variable id. This would recalculate the encounter rate every time you chance the variable, even by one. Since the make_encounter_rate method is so simple, this shouldn't be an issue.

 

[dinhbat3]

Thanks so much Yato!

I worked great. Only edit is that the the method is make_encounter_count. (Just in case anyone else needed to use the above)

I really appreciate the help. <3

Final tweek: How can I add a % sign to the variable I am manipulating on the bar? As you can see in this picture. The volume functions have the default % sign. Is there a way I can add a % sign to the Encounter rate bar I created?

Spoiler

~ Dinhbat

**Edit: Added Pic**

 

[Yato]

Haha, I really shouldn't try and answer script questions before my morning coffee. I make stupid mistakes like that.


As for adding the percent sign, that's pretty simple. In the draw_custom_variable method, near the end, just before draw_gauge and draw_text, you want to add the following:

value = sprintf("%d%%", value) if YEA::SYSTEM::CUSTOM_VARIABLES[ext][0] == 4

Again changing the 4 to your variable number. In the screenshot you provided, you only had the one variable in use. If that is the case, you don't need the if YEA:: etc part of the line. That just makes it so the % sign only shows for that one variable.

 

[dinhbat3]

Thanks again Yato!

I was very close to solving it but my guess and check method isn't the most precise. hehe.

I really appreciate all the help.

One problem solved... Many new script issues to post next. =D

This thread can be closed.

~ Dinhbat

 

[Mithran]

This thread is being closed, due to being solved. If for some reason you would like this thread re-opened, please report this post and leave a message why. Thank you.