Decompiling a game mode doesn't work with these specific settings

[TimeBomb]

Tested decompiling with v1.7 and 2.0preview. It failed to decompile the rules, but decompiled the settings, or at least some of the settings, with v1.7. It failed to generate any files with 2.0preview.

Decompiling just the variables and rules worked once, but when it included the settings, it did not. Oddly, deleting the ostw files generated upon decompilation, restarting VSCode, and attempting to decompile with just the settings+rules again, did not work - no files were ever generated with v1.7 or 2.0preview.

I think this is a bit different than #172 because I was only able to decompile the rules sans-settings once, and all decompilations now are not generating any files.

Here's the full game mode copied, settings and rules and all: overwatch-workshop-tower-defense-eichenwalde.txt

[TimeBomb]

Alright, update on this: Restarting VSCode didn't originally fix this, but uninstalling and reinstalling the extension fixed being able to decompile variables+rules on v1.7 BUT it only decompiles part-way, and stops at a Mccree-based rule.

2.0-preview is still not decompiling this or generating any files whatsoever though.

[Polymathical]

There's a problem in the code in EventInfo that has Mccree instead of McCree and D.va instead of D.Va and is using (for some reason) really strange custom string parsing that falls over but doesn't assert.

In addition: Hanzo's ult is listed as being Storm Arrow instead of Storm Arrows and the code needs the latter or it falls over. (ie. Heroes.cs should read .AddAbility("Storm Arrows"). Better yet, the parser should wonder why it just failed or, in this case, I believe it accepted a partial that was not delimited (by a space).

Also, several game modes and modifiers / options are missing.

In general, the code has many conditions that should be throwing exceptions or at least handing out warnings or assertions (for the developer and as a courtesy to the end user) but opts to silently fail.

If parsing fails at any point, with the way it is done here, you can bet it will all fail from that point on, but the logic says keep on truckin'.

Good stuff, this project is and I hope to see it improve.

[TimeBomb]

Great analysis, thanks @Polymathical. I renamed McCree to Mccree, D.Va to D.va, and Storm Arrows to Storm Arrow, and I was able to use the v1.7 decompiler sans the game settings.

That being said, it's unable to parse the custom strings, so it isn't able to compile back to workshop code. Looks like replacing the decompiled <@"{0} {1}" with <@"<0> <1>" fixes this.

[Polymathical]

The changes need to be done in the code or you're just trading a bug now for one later. I'll see if I am clueful enough to figure out how to post a pull request for a bug fix :>