WurstModders / WurstMod

Deli mod for H3VR to load custom scenes into the game!
MIT License
24 stars 2 forks source link

3rd Hold Point fails to finish #22

Closed tgrosh closed 4 years ago

tgrosh commented 4 years ago

Hey, I have created a custom map using this project and the unity package that comes with it. I was about to publish it, and then during testing we started seeing that every 3rd hold point fails to finish. We beat the hold point, but the yellow orb stays there, the music stays running, and the barriers are still up. We get the sound that it finished, and the voice telling us its over. But it is still running. This happens on the 3rd hold point every time, regardless of whether or not you beat any of them. So you can fail at them all too, and it still breaks at the end of the 3rd one. Does this make sense? I have tried everything I can think of and I cannot resolve. I also tried the debug scene as well, and it does the same thing. We have no other mods, and aside from this (which didnt happen until somewhat recently) there are no other issues.

Nolenz commented 4 years ago

Will investigate. Is this on Update 96 Alpha 1?

Nolenz commented 4 years ago

I was able to complete a 5-hold run of the debug scene on WurstMod v1.4.0.0 (latest release) and H3VR Update 96 Alpha 1. I encountered all of the new encryption types, so those shouldn't be causing the problem.

tgrosh commented 4 years ago

Thanks for looking at it. I was afraid you were going to come back and tell me it works for you. The base map, and Monolith also work fine for me. But my map, and the debug map do not work anymore. They used to, so it’s frustrating. I can say we are using those versions. Definitely verified last night the game version. That’s easy to spot. I have checked the wurst version but I will triple check it again. But ya, feel pretty confident it’s correct too. I will locate the logs after work and attach here.

Thanks again for looking at it.

tgrosh commented 4 years ago

So, I grabbed the logfile of just launching the game (not running my map). See below.

I looked through it. Interestingly, it says I am loading WurstMod 1.3, but that's not possible. I have never even downloaded that version, and I most certainly downloaded the 1.4 version and installed it. So what gives?

I will be running through my map shortly and will attach that one soon.

output_log.txt

Nolenz commented 4 years ago

Ignore the 1.3.0.0, that's just because I forgot to bump the version number when I released 1.4.0.0. Heh.

I don't see any errors in the log, which is concerning. I've fixed an issue similar to this in earlier development, but it always produced an error. The log file you provided came from a session where the bug occurred, correct?

tgrosh commented 4 years ago

No, that was not a log file that included the error. I am getting ready to invoke the error now. Will post the logs shortly.

tgrosh commented 4 years ago

Ok, thanks for pointing me at that logfile. Once I found that, I found the error. It was as below...

ArgumentOutOfRangeException: Argument is out of range. Parameter name: index at System.Collections.Generic.List1[UnityEngine.Transform].get_Item (Int32 index) [0x00000] in :0 at FistVR.TNH_SupplyPoint.SpawnTakeEnemyGroup () [0x00000] in :0 at FistVR.TNH_SupplyPoint.Configure (FistVR.TNH_TakeChallenge t, Boolean spawnSosigs, Boolean spawnDefenses, Boolean spawnConstructor, SupplyPanelType panelType, Int32 minBoxPiles, Int32 maxBoxPiles) [0x00000] in :0 at FistVR.TNH_Manager.SetPhase_Take () [0x00000] in :0 at FistVR.TNH_Manager.SetPhase (TNH_Phase p) [0x00000] in :0 at FistVR.TNH_Manager.HoldPointCompleted (FistVR.TNH_HoldPoint p, Boolean success) [0x00000] in :0 at FistVR.TNH_HoldPoint.CompleteHold () [0x00000] in :0 at FistVR.TNH_HoldPoint.Update () [0x00000] in :0

I determined this means I need more spawnpoints for enemies in the Supply Points. The prefab only has 4, and I am betting that was fine until the recent update 95 that added zombies to TNH. But I am betting it needs more now. The game appears to increment the spawns at the supply points after each Hold. Hopefully there is a ceiling.

I am also betting your local has more than that also. Which is why your local debug level works and mine that I generated from the package does not.

I have my code working now and can proceed with fine tuning and publish out. I have a few suggestions for you to improve the usage and avoid this issue for others as well

  1. I didn't know the log file existed, so I might suggest it would be good to add that to the readme so other developers can troubleshoot on their own like I did once I found it.
  2. Your readme mentions at least 9 defenders for Hold Points, but it needs to mention same for Supply Points as well I think. That is how I solved this.
  3. Do we know what the real limit is? And I just gotta know (how did you even find out what the limit is?) What are you looking at to determine how the game works to be even able to build out this WurstMod? Curiosity is killing me... :-)
Nolenz commented 4 years ago

Thanks for the analysis, definitely saved me some time! I will have to think about ways to make everything more resilient to changes in spawn counts like this for 2.0. It makes sense that a new character would come around that spawns more enemies than was previously supported.

I'm not sure what the solution will be, but I'd like to effectively remove the minimum as a consideration for map developers. The less to think about, the better.

As for your other questions:

  1. That's a good point. Documentation is very lacking. Nathan's been helping a lot with that, but we could always use more. Adding it to the list.
  2. With any luck, I will find a solution that removes this complexity altogether.
  3. I think I dug it up at one point, but it has obviously changed as new functionality was added to the base game. Again, going to try and come up with a bulletproof fix. All of this reverse engineering was done with decompiled Unity assets and scenes. A bit of a gray area so I'd rather not provide a step-by-step.
Nolenz commented 4 years ago

(Hopefully) fixed in WurstMod 2