Question about Ex-Paramenters

[JamesRyan]

Hi guys,

I'm just wondering about how the Ex-Parameters are calculated. For example, i got 100% TGR by default, then i add a state which raises this by 800% and followed by another state raises it by 200%. So is it calculated as 100 * 8 then * 2 more = 1600 or is it only calculated with the last state (100 * 2 = 200) and forget about the first state (100 * 8)?

Sorry for the complicated explaination (I'm not too good at English).

Looking forward to your answers. Thanks a lot!

 

[Trihan]

ex-parameters are cumulatively calculated, but TGR is actually an s-parameter, which is calculated as a complement rather than directly adding them together:

def sparam(sparam_id)

  features_pi(FEATURE_SPARAM, sparam_id)

end

 

def features_pi(code, id)

  features_with_id(code, id).inject(1.0) {|r, ft| r *= ft.value }

end


To take your example, the inject method will start with a value of 1.0. In the first iteration, we multiply our current value (1.0) by the value of the feature being considered, in this case the default 100% TGR. So our first iteration is 1.0 * 1.0 which is 1.0.

In the second iteration, we have our current value (1.0) multiplied by the value of the feature, 8.0 (800%). 1.0 * 8.0 is 8.0, so that's our new value.

In the third iteration, we have our current value (8.0) multiplied by the value of the feature, 2.0 (200%). So our final TGR is 1600% (16.0).

 

[JamesRyan]

Now i clearly understand how it works. Thank you very much for your help, Trihan!

 

[Trihan]

Note that the target selection method doesn't work exactly as you might expect:

def random_target

  tgr_rand = rand * tgr_sum

  alive_members.each do |member|

    tgr_rand -= member.tgr

    return member if tgr_rand < 0

  end

  alive_members[0]

end


tgr_sum is the cumulative total of every member's TGR value, So if you have one character with this set of features and the other three with a default 100% TGR, the sum will be 16.0 + 1.0 + 1.0 + 1.0 = 19.0. tgr_rand is set to a random number between 0 and 1, multiplied by the sum. So let's say (for the sake of rand choosing a nice round decimal, which it actually won't but it will work for illustrative purposes) that the number chosen was 0.4, our random number will be 19.0 * 0.4 = 7.6.

We then iterate through each living member of the party, subtracting the current member's TGR value from tgr_rand. We return that member if tgr_rand is now less than 0.

In our example case, if the 1600% TGR member is in the first slot they'll be chosen immediately, as 7.6 - 16 is obviously less than 0. However, if the random number generated had been, say, 0.9, the resulting value would be 17.1. In this case the first iteration would take 16 away from 17.1, leaving 1.1. The next iteration would take away 1.0, leaving 0.1. The third iteration would take away 1.0 and the value would end up less than 0, so the third member would be chosen.

In short, it's also important to have tank characters in a higher party slot, and even a ridiculously high TGR still has a chance of not being targeted.

Edit: I screwed up and had the tank's TGR multiplied by 10, which screwed up my values. Fixed the equations.

 

[JamesRyan]

So the party slots are really important for checking target selection. I have never thought of this before. Thank you once more time for the detailed information.

 

[Trihan]

I actually screwed up a bit there with the values, but I've fixed them now.

I'm actually considering changing the way targeting works in my game, and having the enemies consider each party member in order of highest TGR rather than going through each party slot in order. I think it'll make more sense that way, what do you think?

 

[Kes]

Yes!

One of the reasons I decided not to implement targeting at all in any of my games is the near impossibility of fine tuning it so that the correct party member is always picked (I didn't know about the slot thing) so anything that makes it more accurate has to be a good thing.  And even if I had known, because the player can choose the party, there is then no control over who is in which slot. This would be true for many (most?) games.

 

[JamesRyan]

So are there any ways to change how the target selection is decided totally based on the value of TGR?

 

[Andar]

That is how the target selection is decided totally based on TGR - the mathematics of frequency distribution can only work that way.

What do you believe how the target selection should be? If you tell us that we might be able to point you to a solution

 

[Trihan]

This will do the same thing but in order of TGR rather than party position, meaning the slot isn't important any more:

def random_target

  tgr_rand = rand * tgr_sum

  alive_members.sort_by { |member| member.tgr }.each do |member|

    tgr_rand -= member.tgr

    return member if tgr_rand < 0

  end

  alive_members[0]

end

 

I'm still working on perfecting an algorithm that takes into account the differences between TGR ratios.

 

[JamesRyan]

This will do the same thing but in order of TGR rather than party position, meaning the slot isn't important any more:

def random_target

  tgr_rand = rand * tgr_sum

  alive_members.sort_by { |member| member.tgr }.each do |member|

    tgr_rand -= member.tgr

    return member if tgr_rand < 0

  end

  alive_members[0]

end

So is this method can be used while waiting for a perfect solution from you?

 

[Trihan]

You can use it if you like, I don't mind. ^_^

 

[JamesRyan]

Thank you for that 

 

[Murd]

The party slot is important like DQ series. The first position will have the highest posibility being targeted than the last one. So, it makes sense that you put your tank character in the first position and the fragile one in the last. I'm not sure that DQ series have hidden trg for each character or not but this is how targeting works.