`tile` tuple-type doesn't work at init

[Cokemonkey11]

Cokemonkey11/the-gorge@3662954#diff-a3f636d1e541c7692fd4ddf2f7f7a9f2R54

If you remove the doAfter(), the init block will fail at runtime.

It looks like this is related to the tile type being a bit weird

[peq]

I could not reproduce it -- there is no error message shown when starting the map with the doAfter() line removed.

Also I don't see anything strange in the generated code for the init function.

Please include more information on how to trigger the error and how the error is visible ingame (e.g. screenshot showing the runtime error). Of course the best thing would be to have a small counter example that can be triggered with a unit test.

[Cokemonkey11]

Hey @peq

Sorry for wasting your time :( . I checked out that branch and also didn't manage to reproduce.

But I was sure of the behavior, so I checked again on my latest branch, and managed to reproduce it again: Cokemonkey11/the-gorge@b3a993f

There are no compile or runtime-errors. The game starts and much of the map script seems to have not run.

My current hypothesis is that enabling this code generates a lot more global variables, and we're hitting the 14k limit. Could that be possible?

Cheers,

[Frotty]

any update on this @Cokemonkey11

[Cokemonkey11]

@Frotty as above, the specified commit should be a repro which has no compile or runtime errors, just fails quietly to launch map, and my hypothesis is that the change mentioned produces a lot of globals -> breaks the global var limit

I think for next steps:

• someone other than me should repro with the commit provided, and see that the same minor code change can resolve the issue
• if that someone agrees that it could be the global variable limit, we could test that theory by hacking the war3map.j to delete a lot of globals from the broken mapfile, and test again

If that is confirmed to be the issue, I think we could close this question with a fix that causes compiletime failure or warning if there are too many globals