MV - Chrono Engine Bug/Softlock on Victory

TL;DR: There's a bug in Mog's Chrono Engine (Chrono Mode) when a battle is won and there is a Ally or User scoped skill "charging" or "casting" (whatever you want to call it), the victory screen will hang up/freeze. It will no longer accept input to proceed to the "Results" screen. The game is still running and no errors are present in the console, so it basically just soft locks itself. Turning off all plugins except Mog_ChronoEngine still produces same problem. Help please.

I don't know if finding the error/bug in the code would be easier or just adding some kind of additional check during the Victory phase that forces it into the results screen. I don't know enough programming or JavaScript to do either.

Mog Plugins

The Long of it:

Since early development of my game, I've had a seemingly random bug/glitch, where sometimes upon winning a battle the game would soft lock on the victory screen. I say soft lock because the battle sprites will loop in their victory poses and any map effects like mog's weather, will continue to play but it won't proceed to the Results screen that displays exp and gold. I know nothing with computers is truly random so I assumed it's a very specific set of circumstances that trigger this bug but I was unable to reliably produce it. I thought, incorrectly, that is was a plugin incompatibility, but this can be reproduced in Mog's Demo for Chrono Engine with all the plugins turned off except for Chrono Engine. After a long time and thorough testing I can now reproduce this error every time, narrowed it down to the Chrono Engine plugin itself and this is beyond my feeble JavaScript knowledge.

To reproduce the error: This can be done in Chrono Engine Demo using Chrono Mode.

Set an Ally or User scoped skill to have a speed that is not zero. I used Cure, a healing spell from the demo. For ease of testing, I set this to a high number, 300 (Figure1). This puts the user of that skill into "charging" or "casting" state until there ATB bar fills. I also gave slime like 10 HP so they are easier to kill. If all the enemies are slain before the skill goes off, the victory screen will play as normal but get stuck and not go to the result screen. It's also worth noting that the damage combo counter and the enemy hp HUD elements do not get cleared as well (Figure2). Start a battle and kill everything except for one enemy. Cast cure to the user or an ally. Kill the remaining enemy before Cure has had a chance to cast. Get stuck on Victory screen.




At first I thought this was a me problem and had something to do with a plugin incompatibility but I finally found myself with some time to investigate this further and used Mog's demo to track this down as best as I could. I tried Google thinking surely I can't be the only one to have had this problem. No luck, but Google isn't what it used to be.

Anyway, deleted all the plugins in the demo except for Mog_ChronoEngine (Figure3) and using the above method, still got the same freeze (Figure4) just without the stuck Combo Counter and EnemyHP.



I tried to make all User/Ally scoped skills to be a speed of 0 so they would just immediately be cast (this screwed with some balancing and they way I had some skills planned but it's easy enough to adjust for) but there are still instances where the player can select a skill while another one is firing off leading to the soft lock freeze.

This is particularly annoying when it happens after a tough battle like a boss battle because hitting F5 means the player has to start from the last save and all that hard work and progress is lost.

I lack the programming/JavaScript skills to solve this problem and am welcoming any solutions to this as I'm kind of far into development and this is just crushing my motivation to continue.:LZSsad:

This might be of interest to @kalian19 since he also uses Chrono mode and has some scripting skill. I'll take a look at it today, although most of my knowledge is with ABS mode.

Thanks, @AquaEcho . I was hoping you or @kalian19 would reply since you two are also fellow ChronoEngine enthusiasts. Your last couple of threads about using chrono engine inspired me to finally reach out for help with this. I was kind of naively hoping the solution would just jump out of the ether.

I'm very surprised chrono engine has been out so long and I can't find a single instance of someone else reporting this. A few people that played my x-mas jam game got this bug.

You've done a lot of work yourself narrowing down the issue and giving instructions to replicate it. I think most people use ABS mode though I've seen a couple people around like I think @SundialShark who do use Chrono Mode

Check out your preEndChronoSystem function around line 4036. Underneath the battler.atbClearCN(), put this line of code to clear your casting:
I believe this should work in theory. If not, I'll have to run some tests when I have free time.

Thanks for helping, sadly no change. No errors or anything and battles seem to function normally and victory is processed normally unless your charging the ally/ user skill. It still freezes.

Can you use the console log and type in:
And see if it is still true?

If it is, use this in the console to turn it off:
at least to see if you can move.

Also, check your battler's ras cast and ras charge:
with index 0 being the first ally battler. Check other battlers and see if there is info there at the end of a normal battle and at the end of a mid-cast battle that freezes the game.

If the info persists on the battler when it is midcast/charge and it freezes, then this may be the culprit.

For the charge, you can do You can do it for every battler or find the one that is frozen that still has info in the charge property.

If this doesn't do anything, either, I'll try to check it out later when I can.

$gameSystem.isChronoMode() is true when checking during the hang up freeze.

setting $gameSystem._chronoMode.enabled = false made the actors move for a few frames and then they stopped. The "Victory" message never left the screen and neither did the EnemyHP gauge. Actors are still looping in their Victory poses. Subsequent applications of $gameSystem._chronoMode.enabled = false yielded nothing. Which is weird.

I don't understand what everything means with the battler info but here's the console:

My mistake - you need .battler() after $gameMap.players()[0], etc. for the ras.charge.

I'll give it a shot later with a vanilla chrono project and retrace the steps you took. I am certain preEndChrono or EndChrono is held up with something, but I'll look elsewhere in case.

correcting the syntax to $gameMap.players()[0].battler()._ras.charge = {}; just gives {} in the console. Just wanted to say thanks again for helping.

Yeah, all that does is empty out the property charge so it shouldn't give you anything in the console. I have a small window of time before my concert so I'm going to check it out right now and see if I can do anything really quick.

Hey, apologies, I just got around today to checking the forums. I may not get to take a stab at it today but I'll look into it and see what I can dig up. I've encountered soft locking sometimes when a tool's duration and its pose duration is set extremely high (e.g. 9999) but I haven't ran into this quite yet. I'll try and reproduce it and see what's going on as well. Just to clarify it needs to be user targeted, has a cast time greater than 0 and must be 'charging' when the last enemy is defeated and chrono engine moves to victory phase?

Yes, Seems to be any ally scoped skill. It starts to go into victory phase but never plays the victory ME or goes to results page. It does show the Victory graphic and the battlers go into their looping victory poses as seen in the OG post under Figure2. Also enemyHP and damage combo counters are Not removed. All player input is halted but you can still press F4 or F5 etc. It just literally gets stuck looking like the screenshot in Figure2.

It's a very specific set of circumstances that makes this happen. I only got it intermittently during testing so it was tricky to figure out what series of events causes it. I thought just setting these types of skills to have a speed of zero would solve this but there are times when say a combo skill is executed and a battler is already ready to act with a charged atb bar, that the player can select say a healing skill but the enemy is killed during that combo skill leading to the soft lock / freeze. Also setting atb to wait mode helps reduce the risk of this happening but it is still possible.

Currently, my findings are that the updateVictory, preEndChronoSystem, and endChronoSystem are hung up due to the casting (not finishing the technique even if the ras cast is cleared). If you run each line separately in the console log:

You will return to normal, with the exception being the results graphic stays due to the fact that the Input.isTriggered('ok') did not occur during the loop check.
Again, this only gets you out of the lock. I'll find the culprit soon... haha. Alas, the testing ends here for now because I need to get to the concert now.

Whatever it is, it has to occur before the last enemy is defeated, and it is more than just "clearing" the current bars/statuses. I believe it is because it never gets to execute the tool event of your technique, so it locks (sort of like a movement route that never gets to move so it locks the game as well).

Basically, we need a "skip/cancel skill if battle system is ending".

Started checking through victory phase myself as it indeed exists within the versions modified by flintx as well though about to have to leave to go eat with some friends. If ya haven't beat it into submission by the time I get home bass I'll relieve you and get my turn in XD

@bass2yang it is weird because a skill that say damages an enemy will cleared at the start of victory but like a buff or heal won't.

Have a good concert!

@kalian19 no rush! I'm going to eat soon too.

I think it is because the tool event itself was either cut short, looking for a target still, or has no way of ending itself. This is also partly because the updateVictory(), preEndChronoSystem(), and endChronoSystem() works when that screen occurs (minus the results screen which is dependent upon player input).

Here's what is needed to clear those tools. I tried it manually before defeating the last enemy and it didn't lock.
Since the 3rd person is the healer in the vanilla project, this is what I am currently using the completely cancel the technique.

What needs to happen now is that before the enemy even collapses, the cancel needs to be done. I haven't found it yet so the game still locks. This code is only the cancel the technique. It doesn't prevent the soft lock yet since it runs right when all enemies are dead instead of the action prior to defeating all enemies.

That means going into the applyCN() and getting a result that you know will ensure defeat and also making sure that the enemy is the last one alive. Or something like this.

Cheers!

Edit: I actually use this as my "cancel Masamune's wind storing technique with Slash attack" event function.

If we're looking at applyCN we might can use Game_Chrono.prototype.isAllEnemiesDead = function() {
return this.getAliveEnemies().length === 0; and see if is = to 1. If that is the case we also need to be able to tell if the attack will kill the target at that time. we'll need a function to accomplish this or call the correct function to do so. If both are deemed to 1 and true then we can then try to go wherever we need to from there. Game_Chrono.prototype.forceClearBaseParameters and then Game_Chrono.prototype.executeVictory probably. I haven't documented much on this side of the engine yet, mostly been getting camera functions and the engine to play nice in battle lately and started working on a parent child system for multiple target cursors for when an attack can reach out and touch a target from the parent target but havent got to far with it due to time. I won't be back until late into the night but once I get home if I can manage to keep my eyes open I'll see what we can do and if this approach is possible.

Edit: I am curious if there is a distinction between something that targets allys at the level this seems be an issue versus an enemy battler and exactly what the distinction is in the engine.

@bass2yang can you test with any other ally spell to see if it does the same thing? A buff in particular that doesnt account for any sort of damage calc.

I tested it earlier with .isAllEnemiesDead() and it is too late to check at that time - it will still soft lock - the cancel will need to occur before that. I even made it check before the var dead = true and it still locked.

I threw the cancel functions in the console and the moment the player starts walking toward the enemy for an attack, I executed the commands and the cancel was cleared - no soft lock issues. At least if we were doing it this way, of course. Edit: I tested this many times and I was 100% successful when I cancelled the technique before the attack lands. This means that when the enemy is declared dead and the phase has completed, there is an issue if the skill still needs to complete.

The alive members will be important so I definitely will be incorporating that.

Let me know what you come up with - I'll try it out again with the applyCN() and related functions when I get the chance tonight.

I had a skill that buffs attack and def that had speed set to a hundred and it would soft lock. My healer is usually in party member 4 slot but almost all my party members have some sort of self buff or apply state to ally skill and this happens.