A addon loader/manager for WZ

[JamesNZ]

Hi all,

I've been working on addon manager for a wee while, and I think it's ready for release. I called it 'Moodloader' (who doesn't love FOSS naming? ).

Features:

• Lists all installed addons
• Can install and remove addons
• Allows you to run multiple mods at once
• Scans maps and marks the map-mods

The only requirements are Python 3.x, and PyQt4 (for python 3). It works fine on Windows and Linux, but I haven't tested it on a Mac.
Note: If you're going to use it on Windows, make sure that the archs of Python and PyQt match.

To use it, just get the source from here and run './moodloader.py' (or double click on moodloader.py from your file manager). I'm working on getting binaries for Windows users.


Feedback would be great if you have any. Hope it's of some use

[AWarZoner]

So far its looking/working great!

[NoQ]

Yay, very nice. At a glance, probably a "start game" button could be made more visible (eg. a button rather than a context menu) (?).

Then, great, you've got some stuff for looking inside the addon, and use it for map-mod detection. You can do a lot more with that. For maps, you can count number of players and number of oils, display tileset and probably even minimap preview. For mods, you can try to vaguely analyze what exactly they affect (textures, models, game rules, game balance stats).

For example, while ago i've made a simple python script for counting oils on the map (useful for addon review) [1]. I didn't know python very well back then, so it's very ugly and unpythonic (now i'm only a bit better), but you'd be able to grasp the idea (not just count oil resources and derricks from inis and binary files, but also take their coordinates and check if some are on top of each other, with all combinations possible and valid, and counting as one oil iff at least one oil resource or derrick is mentioned in at least one of the map's structure/feature files in this location).

The exact procedure of map-mod detection used by the game itself is coded in CheckInMap() in src/init.cpp, you can try to make sure it's the same as what you implemented (though the result should be identical anyway, as the notion of map-mod seems to be more or less well-defined).

If you'd ever like to make a map preview, here is an example of parsing the heightmap. That's not enough for preview yet, the next step would be to understand tile types (cliffs, water, etc.) from the *.ttp file (format of which is also quite obvious as long as you're familiar with map editing for wz).

P.S. the PyQt4 package is called "python-pyqt4" in my archlinux (yeah, python3 by default).

[NoQ]

I mean, i'm really interested in simplifying map and mod installation, so that it was no longer needed to explain personally to everybody how to install a mod (:

Another idea is handling single-player challenge maps somehow. The story is as follows: we have the /challenges/ folder in the physfs to store custom challenge.ini files, which were designed to be shipped as a separate addon (take existing map, take the .ini file and put it into ~/.warzone2100-xxx/challenges/, yay you have a new item in the challenges menu, click it and have fun). But in fact these two don't make sense without each other (and challenges on built-in maps didn't turn out to be popular, as multiplayer-oriented balanced maps are not good for fun challenges), which is why most single-player challenges we have are *.wz packages containing both the map and the challenge.ini (and not exactly qualifying as map-mods: they may even contain *.js files for custom rules, but these do not overwrite existing rules and are only activated by reference from challenge.ini file in challenge mode, not even in skirmish). And to install such addon, you need to install it into both maps folder (to have the map file to find once referenced from the challenge.ini) and into the mods folder (to have the challenge in the list of challenges before map list is initialized). Unless a better way is found to handle such addons (such as map.ini mechanism, not sure what it would turn out to be at the end), probably you could make a fancy UI to cover this issue, as a workaround (?)

[JamesNZ]

Yay, very nice. At a glance, probably a "start game" button could be made more visible (eg. a button rather than a context menu) (?).

Not sure whether I want to do that, it would complicate the design a lot.

Then, great, you've got some stuff for looking inside the addon, and use it for map-mod detection. You can do a lot more with that. For maps, you can count number of players and number of oils, display tileset and probably even minimap preview. For mods, you can try to vaguely analyze what exactly they affect (textures, models, game rules, game balance stats).

For example, while ago i've made a simple python script for counting oils on the map (useful for addon review) [1]. I didn't know python very well back then, so it's very ugly and unpythonic (now i'm only a bit better), but you'd be able to grasp the idea (not just count oil resources and derricks from inis and binary files, but also take their coordinates and check if some are on top of each other, with all combinations possible and valid, and counting as one oil iff at least one oil resource or derrick is mentioned in at least one of the map's structure/feature files in this location).

The exact procedure of map-mod detection used by the game itself is coded in CheckInMap() in src/init.cpp, you can try to make sure it's the same as what you implemented (though the result should be identical anyway, as the notion of map-mod seems to be more or less well-defined).

If you'd ever like to make a map preview, here is an example of parsing the heightmap. That's not enough for preview yet, the next step would be to understand tile types (cliffs, water, etc.) from the *.ttp file (format of which is also quite obvious as long as you're familiar with map editing for wz).

That sounds like a good idea Maybe that could be displayed in a sort of properties dialog?

P.S. the PyQt4 package is called "python-pyqt4" in my archlinux (yeah, python3 by default).

Thanks, will add that to the README (though for the life of me I cannot figure out the reason for that insanity ).

Another idea is handling single-player challenge maps somehow. The story is as follows: we have the /challenges/ folder in the physfs to store custom challenge.ini files, which were designed to be shipped as a separate addon (take existing map, take the .ini file and put it into ~/.warzone2100-xxx/challenges/, yay you have a new item in the challenges menu, click it and have fun). But in fact these two don't make sense without each other (and challenges on built-in maps didn't turn out to be popular, as multiplayer-oriented balanced maps are not good for fun challenges), which is why most single-player challenges we have are *.wz packages containing both the map and the challenge.ini (and not exactly qualifying as map-mods: they may even contain *.js files for custom rules, but these do not overwrite existing rules and are only activated by reference from challenge.ini file in challenge mode, not even in skirmish). And to install such addon, you need to install it into both maps folder (to have the map file to find once referenced from the challenge.ini) and into the mods folder (to have the challenge in the list of challenges before map list is initialized). Unless a better way is found to handle such addons (such as map.ini mechanism, not sure what it would turn out to be at the end), probably you could make a fancy UI to cover this issue, as a workaround (?)

Hmmm, maybe. Is the file layout of a challenge mod standardised? If so I might be able to do it automatically.

[AWarZoner]

Just wondering? Why don't/didn't you write this program in C++??

[JamesNZ]

Just wondering? Why don't/didn't you write this program in C++??

IMHO C++ is overkill for a project of this size.

[JamesNZ]

Alrighty, I implemented a very rudimentary properties dialog (for maps only ATM). There's quite a lot of space though, which I'd like to fill with a map preview. Any thoughts/comments/ideas?