Retera
Somewhere a == is confused with <=
I noticed in https://www.hiveworkshop.com/threads/simple-tower-defense-v3.80868/ that requirements act differently in WSh and WC3.
You can:
- Build "Detector (Lv1)"
- Upgrade to "Detector (Lv2)"
- Upgrade to "Detector (Lv3)"
On WC3: If you have "Detector (Lv3)" and something requires "Detector (Lv1)", you can build it
On WSh: If something requires "Detector (Lv1)" you need exactly "Detector (Lv1)" and for "Detector (Lv3)" it will be grayed out
TODO: is this fixed in the "techtree-and-ai" branch (which btw does not have working enemy player AI yet)
Also, for what it's worth, I don't think it's as simple as == confused with <= even though the symptom is that way.
For example, if we have:
htow : Town Hall
hkee : Keep
hcas : Castle
And then suppose we have a unit called Footman who requires htow, and a unit called Siege Engine who requires hkee, in this scenario if we build an instance of hcas in the map it needs to back-propagate to htow and hkee that they have techtree unlocked +1, and likewise when our instance of hcas dies we need to propagate -1 to htow and hkee in the map, or something similar.
Anecdotally, at least one regression has been introduced where this system of counting down would count down double. I'll have to check if it's currently resolved but as a result it would essentially mean that if we construct an instance of htow, then kill it, the regression would apply -2 to htow, and then if we build another htow and upgrade it to hkee, so that we only have one instance of hkee but with it leaving behind +1 to htow upon finishing its upgrade, the resulting state was:
htow: 0
hkee: 1
hcas: 0
... and then, getting back to our example, we would nonsensically be allowed to train Siege Engine but not Footman.
Because even though the hkee added one to htow, the formerly dead instance of htow had subtracted -2 due to a bug.
Maybe there should be some kind of unit tests. It is annoying if merging a large pull request can introduce a regression, even if the specific issue you are facing might actually be the result of something never having been implemented correctly rather than the specific regression I am recalling.
NOTE: There is at least one case years ago where I ran "units" in circles on Warsmash and uploaded some social media video alleging that these were "unit tests," parodying the fact that I was doing this as a hobby and not always engaging in professional software design if I could instead simply know the entire codebase and ensure that everything was correct, as was surely the case with the original Warcraft III given what happened to it when some kids in California tried to Reforgedify it. So... that's not the kind of "unit test" I am referring to above, I was thinking of actual unit tests, probably using the JUnit library.
It could also be something else. I only played it once in WC3, but I think the crystal converter had an ability "Detector (Lv1)".
For simple scripted test maps it would probably be enough to have a cli argument that directly exits warsmash once the map is won (return 0 to terminal) … and one for a timeout after which the warsmash gets closed (return 1 to terminal). That is indeed not a unit test because it tests multiple things at the same time, but you quickly notice when basic things break.
Edit: Maybe it would be good to base it on an old version that "definitely worked" and then merge into current main. That could help with bisecting commits + merge + run test. Though bisect probably would work faster/better with a rebase 😬
Edit2: If it can run headless on the server it could probably also be run as CI tests.