SHOOBINATOR'S PROFILE

author=bugmenot
I am not a programmer (getting only parts of strings is... something). How about a single attribute_ID?


RPSAttribute=4B9A6F,04,4B9A70,%1

So anything that has at least that specific attribute_ID checked gets the row bonus. % means it has to be somewhere within 1..127

Actually, I think attribute ID should work just as well in this case. Thank you! I will have to look into this soon.

author=bugmenot
So... magic Skills that can still hit regardless of the caster being blind?

It sure would be possible to split up the accuracy calculation between two types of skills. Needs some time, though.

Yeah, something like this. Except right now, conditions do not affect the success rate of skills, and it seems that the success rate of a skill is entirely determined by the success rate that you set for it in the "Skills" tab in the database.

author=bugmenot
SkillAccuracy=
Failure% = { 100% - (SkillHit% x Hit%(u)**) } x (Agi(t) / 2x Agi(u)) +25%(IncreaseEvasionArmor)

This formula cannot be right because even while inflicted with a condition that gives a 0% hit rate, the skill still hits. After some tests, I would also surmise that the target evasion, (Agi(t) / 2x Agi(u)), part is also not really included in the calculation.

If possible though, the following formula is the one that I would want for skills that have the "WNonElem" attribute (again, if you can compare exact strings):

author=bugmenot
PhysicalAccuracy =
Failure% = { 100% - (WeaponHit%* x Hit%(u)**) } x (Agi(t) / 2x Agi(u)) +25%(IncreaseEvasionArmor) +25%(if target in BackRow)

This way I can make a skill that is truly equivalent to a regular attack for enemy regular attacks while still retaining physical skills for enemies and heroes that are not affected by condition hit rates (such as the hit rate for a Blind condition).

Ah, thank you. I think I understand the physical attack variance patch. I will probably keep in a little bit of variance, but 20% was way too much especially with other multipliers increasing the damage range further.

I will have to look more into that RPS patch for sure.

EDIT: Oh btw, did you just make that RPS patch? Thanks a lot! So the RPS patch is not compatible with your NoRowBonus quick patch? Just realized that the whole point of your RPS patch is that you are assuming that there is still the back/front row bonus for damage. However, are these "physical" skills affected by factors such as accuracy (and conditions like Blind that may affect accuracy) and odds of hitting someone in the front row versus the back row?

Okay, thanks. I don't think showing pictures is the problem. In fact, I already reduced some lag that was present before using Move picture (although your way of just leaving the picture in the right place but at 100% transparency and then setting it to 0% transparency later sounds better/simpler than doing show picture and placing it outside the borders of the game display at first (which is what I did)).

I'm doing a pretty good job of keeping parallel/autorun events off when they are not currently in use.

Has anyone experienced exceptional lag on their maps by using DynRPG and/or any of these plug-ins?

This is currently my issue. It might have to do with having a few too many parallel process events functioning at once somewhere on one of my maps (a larger map, at least in event count, that I've been using to prototype puzzle elements). However, this particular map worked 100% bug-free and without lag before I patched my RPG_RT.exe file using Cherry's DynRPG v0.20. So I then added several plug-ins/patches as follows that PepsiOtaku (or Cherry) has released:

RPG_RT_noautobattle.ips
battle_mpstat_display.dll
faster_atb_advanced.dll
game_clock.dll

I have tried removing the patches and plug-ins and re-testing my game, but I am still getting the same lag. Therefore, I think it has something to do with how DynRPG is making its function calls during runtime. However, what kind of things would cause lag outside of the default battle system?

I kept the previous version of RPG_RT and I can easily switch back to the old one by renaming them and the older one still works fine. But the plug-in functionalities are just too good to pass up! :)

Besides this lag on this one map, these plug-ins have been working great! One small gripe though is that if a hero battler has HP AND MP restored from the same spell/item, there isn't much time between showing the HP and showing the MP that you sorta lose sight of what the number for HP was. Could you possibly add a (larger) wait time of some sort to space these out a little better? Thanks.