Status
Not open for further replies.

Roguedeus

It's never too late to procrastinate...
Veteran
Joined
Mar 19, 2013
Messages
542
Reaction score
111
First Language
English
Primarily Uses
N/A
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

Eorzean
Veteran
Joined
Oct 25, 2015
Messages
266
Reaction score
84
First Language
English
Primarily Uses
RMMV
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

It's never too late to procrastinate...
Veteran
Joined
Mar 19, 2013
Messages
542
Reaction score
111
First Language
English
Primarily Uses
N/A
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%.

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.
 
Last edited by a moderator:

Riff

Eorzean
Veteran
Joined
Oct 25, 2015
Messages
266
Reaction score
84
First Language
English
Primarily Uses
RMMV
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?
 

Vegnarus

Veteran
Veteran
Joined
Jan 15, 2015
Messages
103
Reaction score
23
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]
 
Last edited by a moderator:

Portkey89

Veteran
Veteran
Joined
Apr 4, 2012
Messages
78
Reaction score
16
First Language
English
Primarily Uses
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!!!   :)
 
Last edited by a moderator:

Ghost of Christmas Kloe

The Icecream Princess
Veteran
Joined
Nov 15, 2015
Messages
1,548
Reaction score
957
First Language
English
Primarily Uses
RMMZ
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...  :distrust: ;)   :D
 
Last edited by a moderator:

Yanfly

Veteran
Joined
Mar 15, 2012
Messages
1,738
Reaction score
2,622
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:

  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. :D

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.

[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.

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. :)

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.
 
Last edited by a moderator:

Cinnamon

Veteran
Veteran
Joined
Jun 20, 2014
Messages
605
Reaction score
209
First Language
English
Primarily Uses
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).
 
Last edited by a moderator:

Roguedeus

It's never too late to procrastinate...
Veteran
Joined
Mar 19, 2013
Messages
542
Reaction score
111
First Language
English
Primarily Uses
N/A
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

The Icecream Princess
Veteran
Joined
Nov 15, 2015
Messages
1,548
Reaction score
957
First Language
English
Primarily Uses
RMMZ
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

Veteran
Veteran
Joined
Jun 20, 2014
Messages
605
Reaction score
209
First Language
English
Primarily Uses
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

The Icecream Princess
Veteran
Joined
Nov 15, 2015
Messages
1,548
Reaction score
957
First Language
English
Primarily Uses
RMMZ
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

Veteran
Veteran
Joined
Jun 20, 2014
Messages
605
Reaction score
209
First Language
English
Primarily Uses
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

Veteran
Joined
Mar 15, 2012
Messages
1,738
Reaction score
2,622
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

Veteran
Veteran
Joined
Apr 4, 2012
Messages
78
Reaction score
16
First Language
English
Primarily Uses
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...  :distrust: ;)   :D
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.
 
Last edited by a moderator:

Yanfly

Veteran
Joined
Mar 15, 2012
Messages
1,738
Reaction score
2,622
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

Veteran
Veteran
Joined
Jun 20, 2014
Messages
605
Reaction score
209
First Language
English
Primarily Uses
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?
 
Last edited by a moderator:

Vegnarus

Veteran
Veteran
Joined
Jan 15, 2015
Messages
103
Reaction score
23
@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.
 
Status
Not open for further replies.

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Latest Threads

Latest Posts

Latest Profile Posts

I'm really tempting to pre order cyberpunk 2077... should I do it or not :/ I really want to play the game but don't want to take a big hit to my saving because of it
So I need to come up with quite a few action sequences.
Was stressing about this plugin earlier, but pretty happy with how its looking now! Purple makes it pop more too!! :)
A friend requested me to do a pfp for his twitch channel, so far he approved one of my sketches, so going to digital now. The style he's looking for is quite different from my usual, hopefully I can get it right... :kaoback:

Forum statistics

Threads
105,484
Messages
1,014,067
Members
137,130
Latest member
LitoBooni
Top