Load maps last, so data in them doesn't break things

[wzdev-ci]

resolution_fixed type_patch (an actual patch, not a request for one) | by cybersphinx

---

As the subject says. Since we treat all the search paths equal, a new loop is needed, so maps really get loaded fast (similar to the videos, only those need to be first). Also attached a revert of the mapmod patch on which the other patch is based. Patches are for master, I have them for 2.3 as well though.

See also #2735, #2610.

---

Issue migrated from trac:2825 at 2022-04-16 08:29:00 -0700

[wzdev-ci]

cybersphinx uploaded file 0001-Revert-the-mapmod-support.patch (6.2 KiB)

[wzdev-ci]

cybersphinx uploaded file 0002-Load-maps-last-so-files-in-them-don-t-override-game-.patch (1.8 KiB)

[wzdev-ci]

cybersphinx edited the issue description

[wzdev-ci]

vexed commented

---

I tested this, and it works. Ran out of time, or I would have stuck it in for the next release build we do.

This also prevented bad map/mods from crashing master.

[wzdev-ci]

Iluvalar commented

---

Unzip the mods in the next release. And just tell peoples to do so when they want to save on another "unsupported" mod. That fix it on my side. I agree it's not optimal, our code should be wise enough to check for .wz files himself, but There is no need to brake map-mod support for that.

Anyway the only complaint we heard about for now is for "old-1.10-balance" and unzipping the file will solve it.

[wzdev-ci]

cybersphinx uploaded file 0003-Redo-mapmod-support.patch (3.7 KiB)

[wzdev-ci]

cybersphinx uploaded file 0004-Don-t-remove-file-extensions-from-mod-names.patch (1.5 KiB)

[wzdev-ci]

cybersphinx commented

---

Patch #3 redoes the mapmod support in an imo cleaner way. Mod savegames are still broken with that though.

Patch #4 removes the code that removes extensions from mod names. That way, the whole filename is saved in savegames, and loading them works whether the mod is explicitly loaded or not.

That doesn't work if people expand their mod between saving and loading, and old savegames without .wz in the name won't work with the .wz mod.

[wzdev-ci]

Zarel commented

---

Patch 4 seems a weird solution. The mod loader is supposed to automatically add ".wz" when searching for mods that match a savegame - what happened to that functionality?

[wzdev-ci]

cybersphinx commented

---

No idea. Since fiddling around with rebuildSearchPath wasn't successful, I tried a different approach, and grepping the source for ".wz", the only seemingly useless place it turned up was addLoadedMod. If it ever worked, nobody noticed when it broke.

[wzdev-ci]

Zarel commented

---

Patch 4 and bug #2735 seem entirely unrelated to my map-mod patch, so something nefarious seems to be going on, and I feel like patch 4 is just a hack that's covering up a different problem.

I'm going to spend some time looking for a better solution today.

[wzdev-ci]

cybersphinx commented

---

Your patch removes the .wz mod somehow from the loaded mods (as does my patch 3 btw, by calling rebuildSearchPath with force=true). So, the solution is simple: just don't bother with trying to match names with/without .wz, but use the string we have directly.

[wzdev-ci]

Zarel commented

---

Hmm. If both our patches do the same thing, why did you rewrite it? o_O

I also don't understand how matching names has anything to do with removing mods from the loaded mods list.

[wzdev-ci]

cybersphinx commented

---

Because I only found that out after having rewritten it. (And as mentioned, I find it simpler than your version.)

Me neither, I assume that's somewhere in your mod code. All that I know is, everything regarding mod saves and mapmods that I've tried works with my patches.

[wzdev-ci]

zydonk commented

---

Actually, several other mods are failing in v238, for instance, the v1.04AI mod and the scav mod. So far, only the aivolution mod works. If someone can discover why that works, then perhaps a solution will be found.