Having difficulty porting a map between TF2 Classic and Retail TF2

[Panegyr]

Essentially I've been working on getting cp_airship_race set up so I can compile it once and pack the files so it will load correctly in both versions without issue. However I've hit a major snag in the process: Every released version snapshot so far, even when recompiled using retail hammer, immediately crashes Live TF2 to desktop on map load, enabling verbose console logging hasn't helped determine the cause, and windows reports the following in the event viewer:

Faulting application name: hl2.exe, version: 0.0.0.0, time stamp: 0x6142721b Faulting module name: ntdll.dll, version: 10.0.22000.856, time stamp: 0x92321736 Exception code: 0xc0000374 Fault offset: 0x000ea939

Which isn't much help, one of the users on the discord suggested it may be an issue with area portals or lightmap luxels, but this is occurring even on fast settings and the map currently does not use any area portals in any released version.

meanwhile, the map continues to play perfectly fine inside of tf2 classic, I can even take the versions compiled in retail hammer and load them in TF2C fine, but they will crash the main game.

Honestly? This feels like a weird one that doesn't have an easy answer, but I'm hoping there's something silly I'm overlooking here.

If it's any consolation I'm able to cordon off just the spawn in the first released version snapshot, compile it using fast settings, and load it fine in Retail, which feels like progress? I'm not entirely sure why this affects the first version as well, which aside from placing a few dozen static props and tweaking some gameplay logic, didn't really change much from the baseline balloon_race_v2b, which compiles in both, and runs in both still.

Update: The map with this cordon crashes live tf2:

Update 2: And this one does not:

zooming in on the weirdness, this cordon crashes, but the one that stops just before the first control point is fine:

and this one has the unique property of loading into the map on live TF2 but crashing after an arbitrary amount of time while noclip inspecting the map:

 

[Panegyr]

I appear to have found A cause of the crashing:

This brush entity that was misconfigured upon leaving the confines of TF2C, changing nothing else but removing the bad keyvalues takes the map from crashing immediately to working perfectly fine. I wonder if there's a way to automate scanning a vmf for stuff like this for moving between the different development environments.

 

[spruce]

I appear to have found A cause of the crashing:

This brush entity that was misconfigured upon leaving the confines of TF2C, changing nothing else but removing the bad keyvalues takes the map from crashing immediately to working perfectly fine. I wonder if there's a way to automate scanning a vmf for stuff like this for moving between the different development environments.

Not exactly an "Automatic" way, but much better than manually checking each entity on the map:
Go to Map > Check for problems, this will give you a list of any "Unused" keyvalues, here's an example of a value I added myself (Image)

If there's any other consistent error after this, let us know.

 

[Panegyr]

It feels a little silly that I didn't mention this was one of the first things I tried, this seems to be a corner case where these are keyvalues that are superficially accepted by the trigger_capture_area class but cause crashes in game when they are actually referenced.

 

[spruce]

It feels a little silly that I didn't mention this was one of the first things I tried, this seems to be a corner case where these are keyvalues that are superficially accepted by the trigger_capture_area class but cause crashes in game when they are actually referenced.

Well, mine still fires an error albeit just one, and if I delete said keyvalue the next one shows up in the problem list

I believe it's either "Check for problems" not refreshing correctly or Hammer++ not recognizing those as non-existant values, unless it's a crash completely unrelated to invalid keyvalues

 

[Panegyr]

Strange, when I'm back at my desktop later today I'll reinstall hammer++ in my retail directory (and maybe just clean out and re-verify my retail folder with steam to redownload the relevant binaries) in case there's some weirdness there or I accidentally grabbed the source MP 2013 SDK version and stuffed it in tf/bin

 

[Panegyr]

Probably the last major update for this thread, cleared my binaries and redownloaded them, verified hammer++ was using the correct build, hammer++ still does not recognize the bad keyvalues as a problem, but standard hammer does:

I'm going to mark this thread solved because I feel like we have sufficiently drilled down the source of the issues, thanks for the help spruce!

Edit: (How do I mark a thread solved?)

 

[spruce]

Probably the last major update for this thread, cleared my binaries and redownloaded them, verified hammer++ was using the correct build, hammer++ still does not recognize the bad keyvalues as a problem, but standard hammer does:

I'm going to mark this thread solved because I feel like we have sufficiently drilled down the source of the issues, thanks for the help spruce!

Edit: (How do I mark a thread solved?)

I think the thread had to be marked as a problem to begin with for you to be able to set it as solved, however I assume a Staff member can edit that.