• Add Review
  • Subscribe
  • Nominate
  • Submit Media
  • RSS

Beta Patch C

  • DJC
  • 01/21/2017 08:10 PM
  • 1090 views
Update with latest round of bug fixes available for download here.

Everlong v3.30c (2017.01.21):

*Monster AP no longer increased in Hard Mode, not scaled in Auto Balance Mode, cannot scale up for bosses in Custom Mode; prevents variable overflow error
*Story Mode correctly skips boss battles when chosen
*Power creep for Auto Balance Mode now working correctly; total levels can now reduce balance amount to 25% of averages
*Fixed bug where Boss HP not calculating correctly in Default and Hard Modes
*Custom Monster Balance settings restore correctly after boss battle adjustments
*Enemy Skills influenced by party maximum HP, such as Uber Daemon's Doomsday, now function correctly
*Boss Altair in Atlantis had incorrect HP and monster scaling data
*Inserted workaround for Seraphia war charge crash; Impatient Mode skips problematic code execution

This patch mostly corrects bugs with the monster balancing options. Custom settings are adjusted for boss battles to guarantee a minimum HP. This prevents automatic victories at battle start that could result in some necessary code never executing. After a boss battle, custom settings made by the player reset to chosen values. Previously, a logic code error set HP to zero instead of reverting to the memorized value.

Boss AP is also now restricted to 100% in all balance modes. Increasing the AP value for bosses caused variable overflow, since these enemies already have the maximum value. This resulted in bosses with zero AP. Some regular enemies that also have maximum AP can still be affected by this issue. When I find the time, I'll implement a fix for them.

Story Mode was presenting the option to skip boss battles as intended, but regardless of player choice, battles were always fought. This was due to the control switch always being reset by the battle preparation event run before bosses. The control switch is now reset in the cleanup event run after bosses.

The power creep added in the last patch was not functioning correctly due to a flaw in the database. I had to transfer data from an old install of the game project to get files updating in Windows correctly. I forgot to increase the current variable matrix to the new size the changes in the old install required. Code was trying to execute that referenced non-existent variables. This should have crashed the program when using Auto Balance Mode, but apparently RM2K3 doesn't care about code with undefined variables, which is insane. Also, power creep used to only allow a 50% reduction in using hero stats to balance monsters against the player. Now it can go all the way down to 25% of averages.

Anything relying on calculating the party's average maximum HP was probably not functioning correctly due to a logic error. The code was not resetting the storage variable before doing the math. This resulted in too high a number. For example, enemy skills that deal damage based on maximum HP dealt excess, a particular problem for Uber Daemon's Doomsday, which inflicts one less than the party maximum. Maybe an errant delete keystroke when this event was selected in the editor removed the necessary first line that either was or should have existed.

In testing the bug fixes, I also realized the Altair battle in Atlantis was different than a normal boss. HP was increased in the last patch and a minimum value being calculated when that's actually unnecessary, since this boss does not use the death threshold to trigger the custom death animation and code. Altair had 200k HP more than intended.

Players have infrequently experienced crashes during the Seraphia War charge, probably due to the large number of map events that begin moving simultaneously. In an older version I removed some arrow picture animations, thinking those draw functions the culprit. As a player recently received this crash again, I have added a new workaround that entirely bypasses the problem code. Players only need to select Impatient Mode in options before the event sequence. This can be reverted, without missing any content, shortly after at the conclusion of the bunker scene.

I'm also aware other crash bugs plague the project. Luckily they are rare. I believe I am unable to address them, since they are caused by faults in the engine itself or DynRPG. I did have an idea to address this by forcing the game to save in the background after x amount of time or certain triggers, preferably when the teleport function is executed or after the battle scene, but I don't have the expertise or time to use DynRPG to create the necessary plugin. If there are any active DynRPG plugin coders still out there, I could use your help.

Posts

Pages: 1
PepsiOtaku, who is on this site is an active DynRPG coder I believe; Maybe you can PM him for some assistance.
Pages: 1