[YEP] Yanfly Engine Plugins

[Roguedeus]

I spent some time verifying some ATB details when I discovered that I seem to be misunderstanding the way that the rubberband parameter functions.

It seems that setting the Minimum Speed parameter at all, results in the Highest Speed parameter being meaningless.

Example #1:

//Default ATB RubberbandLowest Speed = 0.5 * BattleManager.highestBaseAgi()Highest Speed = 1.5 * BattleManager.highestBaseAgi()Highest Battle AGI = 100

Lowest Battle AGI = 10

Results in a Lowest battlefield Speed of 50 (50% of the highest) thus all battlers with an AGI lower than 50, are treated as though they have an AGI of 50.

(Which is everyone but the 100 AGI Enemy)

Now:

Highest Battle AGI = 100

Lowest Battle AGI = 50

The 'Highest' Speed parameter has never been factored in. One enemy attacks twice for every attack of all other battlers.

Example #2:

Lowest Speed = 0.2 * BattleManager.highestBaseAgi() //<- New lowest rubberband settingHighest Speed = 1.5 * BattleManager.highestBaseAgi()Highest Battle AGI = 100

Lowest Battle AGI = 10

Results in a Lowest battlefield Speed of 20 (20% of the highest) thus all battlers with an AGI lower than 20, are treated as though they have an AGI of 20.

(Which is everyone but the 100 AGI Enemy)

Now:

Highest Battle AGI = 100

Lowest Battle AGI = 20

The 'Highest' Speed parameter has never been factored in. One enemy attacks five times for every attack of all other battlers.

(Because the highest speed cap is based on the highest base AGI... Never considering the lowest)

I am thinking I must be misunderstanding this...

If I am can someone please explain it? Possibly explain how, in any scenario where the Lowest Speed is defined, that the Highest speed is ever factored in?

Thanks!

 

[Riff]

I spent some time verifying some ATB details when I discovered that I seem to be misunderstanding the way that the rubberband parameter functions.

It seems that setting the Minimum Speed parameter at all, results in the Highest Speed parameter being meaningless.

Example #1:

//Default ATB RubberbandLowest Speed = 0.5 * BattleManager.highestBaseAgi()Highest Speed = 1.5 * BattleManager.highestBaseAgi()Highest Battle AGI = 100Lowest Battle AGI = 10

Results in a Lowest battlefield Speed of 50 (50% of the highest) thus all battlers with an AGI lower than 50, are treated as though they have an AGI of 50.

(Which is everyone but the 100 AGI Enemy)

Now:

Highest Battle AGI = 100

Lowest Battle AGI = 50

The 'Highest' Speed parameter has never been factored in. One enemy attacks twice for every attack of all other battlers.

Example #2:

Lowest Speed = 0.2 * BattleManager.highestBaseAgi() //<- New lowest rubberband settingHighest Speed = 1.5 * BattleManager.highestBaseAgi()Highest Battle AGI = 100Lowest Battle AGI = 10

Results in a Lowest battlefield Speed of 20 (20% of the highest) thus all battlers with an AGI lower than 20, are treated as though they have an AGI of 20.

(Which is everyone but the 100 AGI Enemy)

Now:

Highest Battle AGI = 100

Lowest Battle AGI = 20

The 'Highest' Speed parameter has never been factored in. One enemy attacks five times for every attack of all other battlers.

(Because the highest speed cap is based on the highest base AGI... Never considering the lowest)

I am thinking I must be misunderstanding this...

If I am can someone please explain it? Possibly explain how, in any scenario where the Lowest Speed is defined, that the Highest speed is ever factored in?

Thanks!

Let's use your second scenario as an example.

Battler A: 100 AGI

Battler B: 10 AGI

Lowerband: 0.2 of highest base AGI

Upperband: 1.5 of highest base AGI

To my understanding, so far what you have said are correct. Just to add to what you said, while answering your question of how the upperband is being used, one word - buffs.

If you have a buff that doubles AGI, Battler A will cap at 150 while Battler B will be at 20. If you decided to triple, Battler A stays at 150 AGI while Battler B's AGI will be boosted to 30.

So increasing the Upperband value will allow the highest AGI battler to cap further.

Hope that answers your question. I feel like I might have missed your point. Haha.

 

[Roguedeus]

Let's use your second scenario as an example.

Battler A: 100 AGI

Battler B: 10 AGI

Lowerband: 0.2 of highest base AGI

Upperband: 1.5 of highest base AGI

To my understanding, so far what you have said are correct. Just to add to what you said, while answering your question of how the upperband is being used, one word - buffs.

If you have a buff that doubles AGI, Battler A will cap at 150 while Battler B will be at 20. If you decided to triple, Battler A stays at 150 AGI while Battler B's AGI will be boosted to 30.

So increasing the Upperband value will allow the highest AGI battler to cap further.

Hope that answers your question. I feel like I might have missed your point. Haha.

Thanks for the reply.

You're right. Buffs should function that way.  However, they don't seem to in practice.

The above scenario I explained is straight out of a troop test I made for verifying rubberbanding. Only my Highest Speed cap is 400% not 150%.



I applied a passive state to the enemy that doubled their AGI (making it 200 vs. 50) which should have resulted in the Enemy attacking around 4 times as fast (right?).



However, they didn't get any faster than twice the slowest battler in actions... Everything still stayed two attacks from the enemy to one attack from everyone else.

it is why I made the post to make sure I wasn't misunderstanding how it should be functioning, compared to how its actually functioning. It seems as though the Lowest Speed is factoring the total AGI of the highest AGI battler, rather than the base AGI.

 

[Riff]

Thanks for the reply.

You're right. Buffs should function that way. However, they don't seem to in practice.

The above scenario I explained is straight out of a troop test I made for verifying rubberbanding. Only my Highest Speed cap is 400% not 150%.

15_1218a.PNG

I applied a passive state to the enemy that doubled their AGI (making it 200 vs. 50) which should have resulted in the Enemy attacking around 4 times as fast (right?).

15_1218b.PNG

However, they didn't get any faster than twice the slowest battler in actions... Everything still stayed two attacks from the enemy to one attack from everyone else.

it is why I made the post to make sure I wasn't misunderstanding how it should be functioning, compared to how its actually functioning. It seems as though the Lowest Speed is factoring the total AGI of the highest AGI battler, rather than the base AGI.

It does seem like lower rubberbanding did take effect on your lower speed battlers (50 -> 100). Does that mean BattleManager.highestBaseAgi updates as highest Agi?

 

[Cinnamon]

Yanfly, could you look at my error, please?

http://forums.rpgmakerweb.com/index.php?/topic/53099-multiple-hit-drain-hpmp-amount-incorrectly-displayed/

I have incorrect damage display for drain. :/

 

[Vegnarus]

Since I cannot reproduce the error, I'm going to ask you to do the following.

 

1. Download all the newest updates of the plugin.

2. Create a new project.

3. Install -only- the affected plugins.

4. Recreate the error.

5. Upload the project online (do -not- deploy it).

6. Post the link here and I'll take a look at it.

 

Thanks for helping!

[SIZE=10.5pt]Hmm... I played with it for a little longer and I narrowed it down even more. Have 3+ Actors in the party and play with the troops while all of your members are Level 1 and then while they are about Level 30+. This was also tested on a fresh project with just CoreEngine, BattleEngineCore, PartySystem and the CTB add-on using the versions from the latest update. [/SIZE]

[SIZE=10.5pt] [/SIZE]

[SIZE=10.5pt]Use low level troops and cancel in and out of the Formation command while CTB is on and you should be able to reproduce it. At Level 1 it remains white and usable no matter what, and at higher levels it's grayed out. It might have something to do with the AGI of the enemy party compared to your own. That might explain why the bug is so elusive. So if you can't get it work, widen and narrow down the two parties' AGI gap and you should get it at some point. [/SIZE]

 

[Portkey89]

Sorry for putting you through a headache!  It apparently was a conflict with a months-outdated version of HIME's Disabled Choice Conditions.  I re-downloaded that, and the problem went away.  Your patience is so appreciated! My enemies are attacking me again - and for once - that's a great thing!!!  

 

[Ghost of Christmas Kloe]

Sorry for putting you through a headache!  It apparently was a conflict with a months-outdated version of HIME's Disabled Choice Conditions.  I re-downloaded that, and the problem went away.  Your patience is so appreciated! My enemies are attacking me again - and for once - that's a great thing!!!  

Although I will mention that the fact that a choice conditions plugin conflicts with battles is slighty odd, if I do say so myself... Oh well... Whatever works I guess...   

 

[Yanfly]

Spoiler

can i request a change in your Message Core plugin?

this

Window_Message.prototype.convertEscapeCharacters = function(text) {    text = Window_Base.prototype.convertEscapeCharacters.call(this, text);        text = this.convertNameBox(text);        text = this.convertMessageCharacters(text);    return text;};Window_Message.prototype.convertNameBox = function(text) {        text = text.replace(/\x1bN\<(.*?)\>/gi, function() {                return Yanfly.nameWindow.refresh(arguments[1], 1);        }, this);        text = text.replace(/\x1bN1\<(.*?)\>/gi, function() {                return Yanfly.nameWindow.refresh(arguments[1], 1);        }, this);        text = text.replace(/\x1bN2\<(.*?)\>/gi, function() {                return Yanfly.nameWindow.refresh(arguments[1], 2);        }, this);        text = text.replace(/\x1bN3\<(.*?)\>/gi, function() {                return Yanfly.nameWindow.refresh(arguments[1], 3);        }, this);        text = text.replace(/\x1bNC\<(.*?)\>/gi, function() {                return Yanfly.nameWindow.refresh(arguments[1], 3);        }, this);        text = text.replace(/\x1bN4\<(.*?)\>/gi, function() {                return Yanfly.nameWindow.refresh(arguments[1], 4);        }, this);        text = text.replace(/\x1bN5\<(.*?)\>/gi, function() {                return Yanfly.nameWindow.refresh(arguments[1], 5);        }, this);        text = text.replace(/\x1bNR\<(.*?)\>/gi, function() {                return Yanfly.nameWindow.refresh(arguments[1], 5);        }, this);    return text;};

to this:

Spoiler

  Window_Message.prototype.convertEscapeCharacters = function(text) {    text = this.convertNameBox(text);    text = Window_Base.prototype.convertEscapeCharacters.call(this, text);    text = this.convertMessageCharacters(text);    return text;  };  Window_Message.prototype.convertNameBox = function(text) {    text = text.replace(/\\N\<(.*?)\>/gi, function() {        return Yanfly.nameWindow.refresh(arguments[1], 1);    }, this);    text = text.replace(/\\N1\<(.*?)\>/gi, function() {        return Yanfly.nameWindow.refresh(arguments[1], 1);    }, this);    text = text.replace(/\\N2\<(.*?)\>/gi, function() {        return Yanfly.nameWindow.refresh(arguments[1], 2);    }, this);    text = text.replace(/\\N3\<(.*?)\>/gi, function() {        return Yanfly.nameWindow.refresh(arguments[1], 3);    }, this);    text = text.replace(/\\NC\<(.*?)\>/gi, function() {        return Yanfly.nameWindow.refresh(arguments[1], 3);    }, this);    text = text.replace(/\\N4\<(.*?)\>/gi, function() {        return Yanfly.nameWindow.refresh(arguments[1], 4);    }, this);    text = text.replace(/\\N5\<(.*?)\>/gi, function() {        return Yanfly.nameWindow.refresh(arguments[1], 5);    }, this);    text = text.replace(/\\NR\<(.*?)\>/gi, function() {        return Yanfly.nameWindow.refresh(arguments[1], 5);    }, this);    return text; };

basically make the name box text to be updated 'before' window base convert escape character executed...

to maintain the original text when passed to name box (since name box is executing convert escape character too)

i ask this because i made auto color plugin here:

http://forums.rpgmakerweb.com/index.php?/topic/49350-est-auto-text-color-plus/

it can color certain text... or certain escape code... to certain color.

the text you pass to Window_NameBox is already convert all \n[x] to actor x name...

so when i have this:

color actor 1 (\n[3]) to color 3

color text "Doraemon" to color 4

actor 1 name is Doraemon Zero

when using:

\n<\n[3]>

it will be auto colored only the doraemon part with color 4.

because it will become like this:

\c[3]\c[4]Doraemon\c[0] Zero\c[0]

the step why it become like that is like this

because by window base convert escape character... it transform:

\n<\n[3]>

to:

\n<\c[3]Doraemon Zero\c[0]>

then that text passed to name box and because it contain Doraemon Text... it transform to:

\n<\c[3]\c[4]Doraemon\c[0] Zero\c[0]>

this is not happening in message box... just in name box...

with above changes... it fix that behaviour. i could add that code as patch in my plugin... but since it's overwritting... it mean that when there's a change in your plugin... i will have to redo the patch... if it's ok for you... could you implement those change.

sorry if above is not clear enough >.<. it's quite hard to explain this.

edit: for now i updated my plugin to include those overwrite code as patch but with plugin parameter to turn it on/off.

Just make the overwrite change to your plugin. There was a specific reason I made mine in the order I had it set in.

Spoiler

[SIZE=10.5pt]Hmm... I played with it for a little longer and I narrowed it down even more. Have 3+ Actors in the party and play with the troops while all of your members are Level 1 and then while they are about Level 30+. This was also tested on a fresh project with just CoreEngine, BattleEngineCore, PartySystem and the CTB add-on using the versions from the latest update. [/SIZE]

[SIZE=10.5pt] [/SIZE]

[SIZE=10.5pt]Use low level troops and cancel in and out of the Formation command while CTB is on and you should be able to reproduce it. At Level 1 it remains white and usable no matter what, and at higher levels it's grayed out. It might have something to do with the AGI of the enemy party compared to your own. That might explain why the bug is so elusive. So if you can't get it work, widen and narrow down the two parties' AGI gap and you should get it at some point. [/SIZE]

Once again, can you create an empty project for this and upload it online? Considering it's so elusive, chances are, my time is going to be spent blindly hunting a bug that might not even appear. My time's as scarce as is. When my time's wasted, I won't be able to provide new content for others and that's just unfair to both me and my other users. So, if you want me to fix the bug, I'm going to have to ask you for your help. If you can't provide the sample project, I can't provide a fix.

Spoiler

I spent some time verifying some ATB details when I discovered that I seem to be misunderstanding the way that the rubberband parameter functions.

It seems that setting the Minimum Speed parameter at all, results in the Highest Speed parameter being meaningless.

Example #1:

//Default ATB RubberbandLowest Speed = 0.5 * BattleManager.highestBaseAgi()Highest Speed = 1.5 * BattleManager.highestBaseAgi()Highest Battle AGI = 100

Lowest Battle AGI = 10

Results in a Lowest battlefield Speed of 50 (50% of the highest) thus all battlers with an AGI lower than 50, are treated as though they have an AGI of 50.

(Which is everyone but the 100 AGI Enemy)

Now:

Highest Battle AGI = 100

Lowest Battle AGI = 50

The 'Highest' Speed parameter has never been factored in. One enemy attacks twice for every attack of all other battlers.

Example #2:

Lowest Speed = 0.2 * BattleManager.highestBaseAgi() //<- New lowest rubberband settingHighest Speed = 1.5 * BattleManager.highestBaseAgi()Highest Battle AGI = 100

Lowest Battle AGI = 10

Results in a Lowest battlefield Speed of 20 (20% of the highest) thus all battlers with an AGI lower than 20, are treated as though they have an AGI of 20.

(Which is everyone but the 100 AGI Enemy)

Now:

Highest Battle AGI = 100

Lowest Battle AGI = 20

The 'Highest' Speed parameter has never been factored in. One enemy attacks five times for every attack of all other battlers.

(Because the highest speed cap is based on the highest base AGI... Never considering the lowest)

I am thinking I must be misunderstanding this...

If I am can someone please explain it? Possibly explain how, in any scenario where the Lowest Speed is defined, that the Highest speed is ever factored in?

Thanks!

You're right about what you think the rubberband setting does. Only thing is, their AGI will still remain at the their current AGI. However, the speed they have will be the speed calculated by the rubberband.

Yanfly, could you look at my error, please?

http://forums.rpgmakerweb.com/index.php?/topic/53099-multiple-hit-drain-hpmp-amount-incorrectly-displayed/

Spoiler

Spoiler

I have incorrect damage display for drain. :/

I'm sorry, but due the limited amount of time I have, I can only provide support for my own plugins.

 

[Cinnamon]

Yanfly, the error IS from your plug-in? Why else would I post here. xD

If I remove your Battle Core, it works fine.

To quickly recap:

MP Drain 56 damage

Enemy 1: 100 MP

Enemy 2: 5 MP

DISPLAYED DRAIN: 56 56

ACTUAL Drain: 56 + 5 (61)

The individual drain amounts are being overwritten by the last (or first?) amount.

If I have 5 enemies, and the first (or last) has a different amount of MP, all the drain amounts will be that different amount.

e.g. 5 5 5 5 5 instead of 90 90 90 90 5 (or whatever).

 

[Roguedeus]

You're right about what you think the rubberband setting does. Only thing is, their AGI will still remain at the their current AGI. However, the speed they have will be the speed calculated by the rubberband.

Then I seem to be having a very unusual situation as the speed doesn't seem to accurately reflect the rubberbanding. (I posted above in reply to someone else about it)

It doesn't seem to matter how high one battlers effective AGI gets when buffed (in calculating speed via rebberbanding) that battlers number of actions stays constant with their AGI before being buffed.

Its as if the 'Maximum Speed' parameter in the rubberbanding is never factored, and the 'Minimum Speed' parameter is factoring current agility, not base agility when determining the speed cap.

I'll make a demo soon, so its clearer.

 

[Ghost of Christmas Kloe]

Yanfly, I don't understand, the error IS from your plug-in? Why else would I post here. XD

If I remove your Battle Core, it works fine.

Well, its more Plugin X doesn't like Battle Core so if you take either out, it works... So what he means is its not his plugin but an other one...

 

[Cinnamon]

Well, its more Plugin X doesn't like Battle Core so if you take either out, it works... So what he means is its not his plugin but an other one...

No, because if I deactivate every other plug-in except his, I still have this issue.

 

[Ghost of Christmas Kloe]

No, because if I deactivate every other plug-in except his, I still have this issue.

That is very odd, since theoretically that is impossible. Update Battle Core to the newest update but other than that, I cannot help...

 

[Cinnamon]

That is very odd, since theoretically that is impossible. Update Battle Core to the newest update but other than that, I cannot help...

How is it theoretically impossible though?

 

[Yanfly]

Yanfly, the error IS from your plug-in? Why else would I post here. xD

If I remove your Battle Core, it works fine.

To quickly recap:

MP Drain 56 damage

Enemy 1: 100 MP

Enemy 2: 5 MP

DISPLAYED DRAIN: 56 56

ACTUAL Drain: 56 + 5 (61)

The individual drain amounts are being overwritten by the last (or first?) amount.

If I have 5 enemies, and the first (or last) has a different amount of MP, all the drain amounts will be that different amount.

e.g. 5 5 5 5 5 instead of 90 90 90 90 5 (or whatever).

I'm having no issues at all. Please follow these instructions:

1. Download all the newest updates of the plugin.

2. Create a new project.

3. Install -only- the affected plugins.

4. Recreate the error.

5. Upload the project online (do -not- deploy it).

6. Post the link here and I'll take a look at it.

Then I seem to be having a very unusual situation as the speed doesn't seem to accurately reflect the rubberbanding. (I posted above in reply to someone else about it)

It doesn't seem to matter how high one battlers effective AGI gets when buffed (in calculating speed via rebberbanding) that battlers number of actions stays constant with their AGI before being buffed.

Its as if the 'Maximum Speed' parameter in the rubberbanding is never factored, and the 'Minimum Speed' parameter is factoring current agility, not base agility when determining the speed cap.

I'll make a demo soon, so its clearer.

The rubberband limits are calculated at the start of battle. Any AGI buffs made mid-battle do not affect the speed of the lower AGI units.

 

[Portkey89]

Although I will mention that the fact that a choice conditions plugin conflicts with battles is slighty odd, if I do say so myself... Oh well... Whatever works I guess...   

Right?  BIZARRE.

The first zillion rounds of testing, I didn't bother disabling that.  I could've SWORN that at some point I removed it, but maybe that was before Yanfly updated his script?  I was running my battle tests through the Troop Test Battle in the database editor, so I figured how could Choice Conditions POSSIBLY come into effect?  In-Game, still unlikely, sure, but I figured ZILCH chance in the editor.  Disabling it fixed the problem, and re-downloading it fixed the problem.  So odd.

 

[Yanfly]

The reason why Hime's Choice Conditions had a compatibility issue with mine was because he overwrote the "Imported" variable and erased its contents.

The "Imported" variable is the variable I use to store compatibility checks with all my plugins. -_- Though, I think Hime fixed this later.

 

[Cinnamon]

Thanks Yanfly. Turns out it was a bug in one of the previous versions. I guess I was using a pre-RMMV release version because it added about 300 lines of code. Had to go and merge it manually with the one in the project to avoid losing my settings. Quite a hassle but at least it's fixed!

One problem, though: now enemies that take damage move up diagonally instead of just backwards. How can I turn that back to normal?

 

[Vegnarus]

@Yanfly: The tests I ran were from a fresh project so you should easily be able to reproduce them. That's why I made that post anyway. But I have the data and js folders here if you want them: http://www.mediafire.com/download/7i5kud547a0d3m4/Test+Project.rar

To reproduce the bug, fight a troop and set all 4 members to level 1. Use the Formation command, exit and then try to use it again. It should still be usable regardless of what you did.

Then set everyone's level to 30 and fight the same troop. If you use the command, then this time it will be grayed out.

All 4 plugins were active during testing.