Jump to content
kal

Ruby/RGSS3 questions that don't deserve their own thread

Recommended Posts

So, this would work for eight directions:
 

x = $game_player.x
y = $game_player.y
[region_id(x+1,y), region_id(x-1,y), region_id(x,y+1), region_id(x,y-1), region_id(x+1,y-1), region_id(x+1,y+1), region_id(x-1,y-1), region_id(x-1,y+1)]

@Kayzee I have an equipment specific skill system (talked about this with Fazune and assigning skills based on equipment-using the same system), and specifically, for spellcraft weapons, if one has two spellcraft weapons, the Dual Hand skill will be in place, but that is replaced by the weapon using a note-tag. However, I only have note-tags for dual-wielding the same spellcraft weapon, not for two differing spellcraft weapons. That's why I'm checking this, and yeah, it should be like...
$game_party.leader.weapons ...... (and so on for other party members)

 

Share this post


Link to post
Share on other sites

No silly, why did you change the numbers? Did you think they were the index of the party member or something?

$game_party.leader.weapons[1] && ($game_party.leader.weapons[0] == $game_party.leader.weapons[1])

For the party leader at least.

 

Edited by Kayzee

Share this post


Link to post
Share on other sites

Actually, no... I think the weapons array only returns weapons, so 0 will be the first weapon no matter where it's slot is. But you may have to try it and see!

Share this post


Link to post
Share on other sites

OK, phew, this might be a long post.

 

I am trying to change how the Feature for increasing or decreasing a parameter works. The feature being the one found in actors, classes, states, etc.

 

I simply want it to only multiply the value by the BASE PARAMETER. Parameters increased from equipping gear (like a sword with +60 ATK) should not be considered in the equation.

 

  #--------------------------------------------------------------------------
  # * Get Parameter
  #--------------------------------------------------------------------------
  def param(param_id)
   value = param_base(param_id) + param_plus(param_id)
   value *= param_rate(param_id) * param_buff_rate(param_id)
    [[value, param_max(param_id)].min, param_min(param_id)].max.to_i
  end

Here, in Game_BattlerBase, we see that is giving us the sum of the base parameter and the "param_plus." However, simply commenting out the param_plus part makes equipped gear no longer give any flat stats whatsoever. So I did this instead.

 

  #--------------------------------------------------------------------------
  # * Get Parameter
  #--------------------------------------------------------------------------
  def param(param_id)
   value = param_base(param_id)
   value *= param_rate(param_id)
   value += param_plus(param_id)
     [[value, param_max(param_id)].min, param_min(param_id)].max.to_i
  end

I had no need of "buff rate" so that was also removed. OK, so now gear still gives the stats they are supposed to and the parameters should only be multiplying by the base parameter. Problem solved? I wish.

 

OK, so I have an item that increases ATK by 3% (103% in the features tab). A character can equip four of these at the same time. Each one they equip, though, is giving slightly more ATK than the last one equipped (i.e. first one equipped is raising ATK by 3% of base value, let's say that equals 12. The next one equipped is increasing ATK by 13, then the next by 14, when all of them should be 12), even when the param formula is telling it to simply set the increase in ATK based only on the base parameter. This is what I cannot figure out. Why does it do this?

Share this post


Link to post
Share on other sites

I have a minor question of my own, that I'm not sure warrants a whole separate thread.

 

Is there a way to rotate a selected tile set in drawing maps?  For instance, the tile sets for steps in building interiors can only face left or right.  Is there a way to rotate them so they can face up, or down?

Share this post


Link to post
Share on other sites
1 hour ago, WCouillard said:

OK, so I have an item that increases ATK by 3% (103% in the features tab). A character can equip four of these at the same time. Each one they equip, though, is giving slightly more ATK than the last one equipped (i.e. first one equipped is raising ATK by 3% of base value, let's say that equals 12. The next one equipped is increasing ATK by 13, then the next by 14, when all of them should be 12), even when the param formula is telling it to simply set the increase in ATK based only on the base parameter. This is what I cannot figure out. Why does it do this?

 

Because param rates don't give an item a stat bonus based on the rate, rather all the param rates from multiple items are multiplied together into one rate for the stat.

 

Let's look through how this would work for multiple items with a 103% feature rate:

 

Okay first off, as you probobly know, all percentages are really just a multiplier times 100. Internally, 103% is really stored as a floating point value of 1.03 instead.

 

So let's look at what happens when there are four items with a rate of 1.03:

 

Starting with a rate of 1, it multiplies the value by 1.03 which is obviously 1.03.

Next item, multiplies 1.03 by 1.03 which according to windows calc program is 1.0609.

Next item multiples 1.0609 by 1.03 which gives us 1.092727.

Next item multiplies 1.092727 by 1.03 which gets us 1.12550881.

 

Floating point math on computers is always a little wonky, so if this seems incorrect that's probobly why. But correct or incorrect, the final result would be multiplying the stat by 1.12550881, and with rounding it means that every item seems to give you a little more.

 

For what you are looking for, I recommend you take a look at this script. It lets you give an item a plus bonus equal to the percentage of a base stat.

 

1 hour ago, Phantom77 said:

I have a minor question of my own, that I'm not sure warrants a whole separate thread.

 

Is there a way to rotate a selected tile set in drawing maps?  For instance, the tile sets for steps in building interiors can only face left or right.  Is there a way to rotate them so they can face up, or down?

 

This isn't a Ruby/RGSS3 question and is therefore INVALID! ... But I will give you an answer anyway! :3

 

And the answer is:

 

Not in the map editor I don't think. Pretty sure you can draw your own tiles or manipulate the tileset images to make up/down steps though. Besides, wouldn't just rotating the tiles make the perspective kinda wonky sometimes?

 

 

 

 

Edited by Kayzee

Share this post


Link to post
Share on other sites
1 minute ago, Kayzee said:

This isn't a Ruby question and is therefore INVALID! ... But I will give you an answer anyway! :3 And the answer is: Not in the map editor I don't think. Pretty sure you can draw your own tiles or manipulate the tileset images to make up/down steps though.

 

 

 

 

Ah.  Sorry, then.
But thank you for your information.

Share this post


Link to post
Share on other sites
1 minute ago, Phantom77 said:

Ah.  Sorry, then.
But thank you for your information.

 

Hehe, it's fine. I can see how you might mistake this for a thread about general questions that don't deserve their own thread if you are new to all of this. Honestly, I am not sure if there is a thread about general questions that don't deserve their own thread! Maybe there should be? In any case... *sprinkles some fairy dust on you* Hehehe...

Share this post


Link to post
Share on other sites
2 hours ago, Kayzee said:

Internally, 103% is really stored as a floating point value of 1.03 instead.

 

Is there a way for me to simply change this to not work this way, rather than use that other script? I have a lot of percentage stat increases locked behind character level (using Hime's Feature Conditions), so that script would likely create a bigger problem by not being able to control WHEN those stat increases would take effect (looks like the notetag will take effect upon equip with no other conditions allowed).

Share this post


Link to post
Share on other sites

Might as well post here for another question...

I have a fog script that must be summoned by an event and then go to another event page as to not keep calling the activation (which makes it so that the fog refuses to move because it keeps getting called over and over again back into its starting postion).

So I use a switch and another event page will open as a result of that switch turning on. Moving to another map will turn that switch off, so that when returning to the map the fog activates again.

But if you save the game and then load the save file, the switch is still on, and the fog therefore does not get called.

 

So now that the introduction to the problem is out of the way: what I need to do is have it so that when a save file is selected to load, switch 138 will turn off. How would I do that?

Share this post


Link to post
Share on other sites
#==============================================================================
# ** Scene_Load
#------------------------------------------------------------------------------
#  This class performs load screen processing. 
#==============================================================================

class Scene_Load < Scene_File
  #--------------------------------------------------------------------------
  # * Processing When Load Is Successful
  #--------------------------------------------------------------------------
  alias coolie_on_load_success on_load_success
  def on_load_success
    coolie_on_load_success
    $game_switches[186] = false
  end
end

Paste this as a new script under Scene_Load and you should be A-OK. Just change the "186" I put in there to "138" or whatever switch you want to turn off/on.

Share this post


Link to post
Share on other sites
2 hours ago, WCouillard said:

 

Is there a way for me to simply change this to not work this way, rather than use that other script? I have a lot of percentage stat increases locked behind character level (using Hime's Feature Conditions), so that script would likely create a bigger problem by not being able to control WHEN those stat increases would take effect (looks like the notetag will take effect upon equip with no other conditions allowed).

 

Well... yes? I mean you can rewrite it to work any way you want. I can probobly show you where to begin too! If you look at the param_rate method in Game_BattlerBase it looks like this:

  #--------------------------------------------------------------------------
  # * Get Rate of Parameter Change
  #--------------------------------------------------------------------------
  def param_rate(param_id)
    features_pi(FEATURE_PARAM, param_id)
  end

 

So that calls another method called features_pi which looks like this:

 

  #--------------------------------------------------------------------------
  # * Calculate Complement of Feature Values
  #--------------------------------------------------------------------------
  def features_pi(code, id)
    features_with_id(code, id).inject(1.0) {|r, ft| r *= ft.value }
  end

You could follow the rabbithole down more looking up what features_with_id does, but just for the sake of not being here all day, I will tell you. It gives you an array of features with a matching code and id. Now inject and stuff... Well that basically does what I said in my last post. It's basically 'for every member of this, start with (value) and run {code} with the arguments | lastvalue, member | ' and... ... I am not explaining this very well am I? Maybe this will do a better job? Yes? No?

 

Annnnyway... The question is... How exactly should it work? Because it seems to me like what you really want is not to have it multiply the param by 1.03, but to make each item add bonus of .03 times the base param. And, okay you can do that, but... well it's getting kinda complicated isn't it?

 

Alternatively you could also rewrite the other script to use it's own form of conditionals too. I have no idea which one would be easier to do, but either way you are bound to do a lot of grunt work messing around with the database right? Unless you used the value minus 1 maybe? Phew...

 

 

Edited by Kayzee

Share this post


Link to post
Share on other sites
2 hours ago, WCouillard said:

#==============================================================================
# ** Scene_Load
#------------------------------------------------------------------------------
#  This class performs load screen processing. 
#==============================================================================

class Scene_Load < Scene_File
  #--------------------------------------------------------------------------
  # * Processing When Load Is Successful
  #--------------------------------------------------------------------------
  alias coolie_on_load_success on_load_success
  def on_load_success
    coolie_on_load_success
    $game_switches[186] = false
  end
end

Paste this as a new script under Scene_Load and you should be A-OK. Just change the "186" I put in there to "138" or whatever switch you want to turn off/on.

 

Awesome, thanks! I totally missed Scene_Load, seems pretty obvious now haha

Share this post


Link to post
Share on other sites
9 hours ago, Kayzee said:

Because it seems to me like what you really want is not to have it multiply the param by 1.03, but to make each item add bonus of .03 times the base param

This is exactly what I want to do when it concerns param increases only. The EX and SP parameters can be left alone. I am terrible with math-y things, it's confusing me more each time I mess with it. Anyone want to be a gem and help me achieve this?

 

Param features (such as ATK * 180%) should increase the BASE param only by 80% of the base value (so really, it should be more like ATK + 80%). If TWO things are equipped that use this feature, it should add the bonuses together, not multiply them in order (as in ATK +80%, then NEW ATK VALUE + ATK +80%).

 

  def features_pi(code, id)
    features_with_id(code, id).inject(1.0) {|r, ft| r += ft.value } #WC
  end

So when I change features_pi to do addition rather than multiplication... it is now giving +33 to a stat that has a base value of 30 when a 10% increase is applied. So it looks like it's giving it the 10% bonus (+3) as well as doubling the stat's base value (+30) for a total of +33.

 

I thought maybe the 1.0 in the inject there was to blame, but changing it to 0.0 just made everyone's max stats a value of 1. *sigh*

Edited by WCouillard

Share this post


Link to post
Share on other sites

I wouldn't really change features_pi if I were you, it's used for a bunch of other features. I think it would be better to copy the code into param_rate an just change that.

 

And remember, the value for a 10% increase would be 110% or 1.10 to be exact. If you add the multipliers, well the 1.0 in the inject is the normal 100%. Add 1.10 and you have 2.10 or 210%!

 

You could try this maybe:

def param_rate(param_id)
    features_with_id(FEATURE_PARAM, param_id).inject(1.0) {|r, ft| r += (ft.value - 1)}
end

Hmmm... I thought this approach might have problems with values less then 100% but thinking about it I don't think it will! :O

 

So yeah, I think this would sum up the values for each item the way you want. :3

Edited by Kayzee

Share this post


Link to post
Share on other sites
1 hour ago, Kayzee said:

features_with_id(FEATURE_PARAM, param_id).inject(1.0) {|r, ft| r += (ft.value - 1)}

LOL, I had this exact line hours ago but it was "ft.value - 100" godddddddddddd I'm a fool. Thank you! :D

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×