Consistent crash

[Vertu]

The title says it all. In a map ready for the playtest to make it public, there is a very consistent crash at exactly the time 00:58:00 while not in editor mode. Upon reaching this game update count the game will freeze completely and become unresponsive. The only way out of this is by manually closing it using the popup from windows detecting it being unresponsive.
I have no made extreme changes to anything from my last map. Nothing crazy. I also looked at the only source of (known) stutter, the Summoner, which there where two of but after they completed there was no stutter (which already happened upon the summoner being loaded on Gameload just like any already pre-gameload existing unit on the map but this was to be safe). I let the game run after they built, disabled edit mode and the crash still happened. While in edit mode, the crash does not happen.

I have no idea what could be causing the crash. I also can't find any output_log.txt or player.log, I can only provide a save to be looked at. I also don't know what could be happening at specifically 00:58:00. I have never specified that GameUpdateCount so it has to be coincidence from another script(s) and like I said before, I have not made a change so massive it could have any hope of causing a crash. It also doesn't help with how it only happens during edit mode and very few things have that specification outside of :Once and :Gameload.

I would be very happy if the source of the crash can be found. I have no clue where to look and what could POSSIBLY be doing this.

Edit: Forgot to mention this was encountered on the "Hardcore" difficulty, I have not tested if it does not happen on the other difficulties but it shouldn't matter. The changes caused by the selection of difficulty should not be involved in the issue. The closest being the removal of ERNs that are predetermined to go into the ERN Port.

[GoodMorning]

(There's a 99% chance you're about to be asked to post the game log file. If you'd like to do that proactively, see here: https://knucklecracker.com/forums/index.php?topic=34722.0 )

[Karsten75]

(There's a 99% chance you're about to be asked to post the game log file. If you'd like to do that proactively, see here: https://knucklecracker.com/forums/index.php?topic=34722.0 )

Make that 100%

However, I'd like to draw your attention to this article. https://github.com/KnuckleCracker/CW4-bug-tracker/discussions/579

The TL;DR is that if the game locks up like that, it's not the game that causes it, but something else.  The entire game is user mode and can be killed by closing the app. Anything more severe than that and it's in a driver or other system code.  Which also makes it very unlikely that the issue will be found in the player.log file, but we will still look. It' smore likly that Windows Event Manager might point to a cause. But that's for a different support group.

[Vertu]

Maybe "Crash" is the wrong word, I am unfamiliar with the actual terminology so based on the reactions, "Soft lock" is probably a far better designation.
I did want to provide the log files but I couldn't recognize them or find them via the paths provided in the forum post "Creeper World 4 File Locations" by Knuckle Cracker which worked in the past but not this time for what ever reason and the output.log was absent.

After looking more specifically based on the persistence of the request, I have identified them so here they are:
I included older logs manually copied to be saved in suspect they where the actual logs and the original logs I was looking for where simply changed or what ever but without the confirmation at the time, I didn't include them upon post creation.
So here are my most recent logs and the older ones manually copied and saved after first experiencing the soft lock.

[Karsten75]

Nevermind, I tested it and it had no effect.

[Karsten75]

So, Vertu, we have identified the issue. 

Hours of work. Work that could have gone into development of the next game. Long  amounts of time staring at a game running at 9 UPS. Even lower under the debugger.

And the root cause? Well, a typo of yours in one of your many scripts. You forgot that you're writing in RPL and didn't have variables in the correct stack order.  As a result, some 4RPL call has to iterate over a range of 3,000,000. You mistakenly multiplied a value of 1,.000.000 by 3.  You issue this call twice in succession.

Hopefully that gives you a clue and you can fix it from there. Good luck.

In 72 hours I will update this post with the source file name and the line numbers of the calls. That way you get a chance to figure it out if you are so inclined.

Just kidding:

Lines 219 and 220 in "Vertu Advanced Fighter.4rpl".

Code: [Select]

ApplyToDamageMap(<-shotLaser1 <-target.x <-target.z <-DAMAGE_DIST 1000000 * <-DAMAGE_DEPTH true)
ApplyToDamageMap(<-shotLaser2 <-target.x <-target.z <-DAMAGE_DIST 1000000 * <-DAMAGE_DEPTH true)

The distance is being multiplied by 1000000 rather than the depth.

Correct code, depending on stylistic choices would be:

Code: [Select]

ApplyToDamageMap(<-shotLaser1 <-target.x <-target.z <-DAMAGE_DIST 1000000  <-DAMAGE_DEPTH  * true)
ApplyToDamageMap(<-shotLaser2 <-target.x <-target.z <-DAMAGE_DIST 1000000 <-DAMAGE_DEPTH  *  true)

or

Code: [Select]

ApplyToDamageMap(<-shotLaser1 <-target.x <-target.z <-DAMAGE_DIST 1000000 * (<-DAMAGE_DEPTH) true)
ApplyToDamageMap(<-shotLaser2 <-target.x <-target.z <-DAMAGE_DIST 1000000 * (<-DAMAGE_DEPTH)  true)


[Vertu]

So, Vertu, we have identified the issue. 

Hours of work. Work that could have gone into development of the next game. Long  amounts of time staring at a game running at 9 UPS. Even lower under the debugger.

And the root cause? Well, a typo of yours in one of your many scripts. You forgot that you're writing in RPL and didn't have variables in the correct stack order.  As a result, some 4RPL call has to iterate over a range of 3,000,000. You mistakenly multiplied a value of 1,.000.000 by 3.  You issue this call twice in succession.

Hopefully that gives you a clue and you can fix it from there. Good luck.

In 72 hours I will update this post with the source file name and the line numbers of the calls. That way you get a chance to figure it out if you are so inclined.

Just kidding:

Lines 219 and 220 in "Vertu Advanced Fighter.4rpl".

Code: [Select]

ApplyToDamageMap(<-shotLaser1 <-target.x <-target.z <-DAMAGE_DIST 1000000 * <-DAMAGE_DEPTH true)
ApplyToDamageMap(<-shotLaser2 <-target.x <-target.z <-DAMAGE_DIST 1000000 * <-DAMAGE_DEPTH true)

The distance is being multiplied by 1000000 rather than the depth.

Correct code, depending on stylistic choices would be:

Code: [Select]

ApplyToDamageMap(<-shotLaser1 <-target.x <-target.z <-DAMAGE_DIST 1000000  <-DAMAGE_DEPTH  * true)
ApplyToDamageMap(<-shotLaser2 <-target.x <-target.z <-DAMAGE_DIST 1000000 <-DAMAGE_DEPTH  *  true)

or

Code: [Select]

ApplyToDamageMap(<-shotLaser1 <-target.x <-target.z <-DAMAGE_DIST 1000000 * (<-DAMAGE_DEPTH) true)
ApplyToDamageMap(<-shotLaser2 <-target.x <-target.z <-DAMAGE_DIST 1000000 * (<-DAMAGE_DEPTH)  true)


Yeah, that would do it. Sorry for the inconvenience.
Thank you so much for finding it. I would not of been able to find this myself. It is exactly what happens when a fix had to be done for this where I had to copy and paste "1000000 *" in 5 units using specific orders of code. One slip and suddenly the game has to apply a damage size of 3,000,000. At least only one of the 5 I have done this on but I will be sure to make certain of that.

[The Apocalyptic]

Case Closed!