I've thought about releasing the show cheats mod on pamm, as i.e. murder party will require people to see cheat games and I honestly think asking people to copy files around and modify a mods.json file is too much just for them to get to use some cheats. Also pamm sure can touch stockmods, just copy them to the mods folder and pamm will recognize them. Isn't the way those stock mods are supposed to be used?
A wondible hack in server_browser.js Code: // ###chargrove show_cheat_servers mod temporarily a separate thing from ui scene mod list loadScript("coui://ui/mods/server_browser/show_cheat_servers.js");
Yeah, you are correct. The other non-Uber fields are display_name, description, version, forum, category, requires, build, priority, date, forum and icon plus some localized versions of name and author for the different languages supported by PAMM. The modinfo.json file got expanded on quite a bit.
Err, looking closer at the enable cheats stock mods indeed shows that it has not written any ui mod list entry and all pamm does is add/remove it from the mods.json That's a nasty hack there, but it works just like it would if it were to use pamm the normal way. Basically you managed to support pamm and at the same time not require it and that so well I didn't even realize it, it just worked. Well done
Yeah, no doubt it's a hack for now, but it's not like we have many stock mods (let alone cross-cutting ones like cheats) so the technical debt is thankfully minor. I felt dirty writing it, but not that dirty. As for stock mods and PAMM, I'm hoping that PAMM will be extended to recognize the stockmods folder in its available mod list. The game client loads mods both from the user data folder and from stockmods; you don't actually need to copy the stockmods contents out to your user data folder or anything, as far as the game is concerned. Hopefully it won't be hard for raevn et al. to expand PAMM to match this.
So here's the current list of modinfo.json fields, as far as we're concerned. Required: identifier, context, display_name, author, description, version. Not all of these are currently used internally (e.g. version) but their existence is still checked for, as a foothold into future usage. Optional: dependencies (array of identifier strings), signature (currently unused), enabled (boolean, defaults to true if you don't have it). Everything else: Not used by us right now, so check w/ PAMM.
@chargrove, What are valid characters for the identifier field? Can it only contain lowercase and periods or can use uppercase as well as special characters? Does the other fields have any requirements as well in the modinfo file? Thank you much appreciated.
I highly recommend you follow a reverse-domain-name approach for mod identifiers, e.g. http://en.wikipedia.org/wiki/Reverse_domain_name_notation This is what we use for PA's stock mods, which all have identifiers starting with "com.uberent.pa.mods"; you use your own domain and mod naming accordingly. I also recommend sticking with all lowercase and underscores, e.g. com.some_domain.blah.another_blah.blah_blah_blah. Numbers 0-9 are also fine, and of course the dots. Other special characters may or may not be fine; theoretically they should be but I can't guarantee that every piece of script code, let alone outside mod-related tools, are going to respect them. Spaces tend to cause even more tool complications, so I would avoid those with identifiers.
I would like to point out that there is still some outstanding issues with the mod system that i had explained about 6 months ago, and that this is what some of those extra fields deal with. https://forums.uberent.com/threads/beta-mod-changes.51520/page-2#post-835524 But basically its because there is two differant mod systems the scene system in the ui code, and the shadowing/mounting system built in the engine. Imo they should be somehow merged. I would provide engine callbacks to get all mod information from the json files, then have the code that currently loads the ui_mods_list.js take that information from those engine callbacks for mods the require scenes.
Pretty much what I was saying above as well. The ui_mod_list.js file needs to be pulled completely out of the pa files so it can't be shadowed, and put in/read from the new mods directory where the loading order mods.json file is instead of being in a folder stack with unnecessary files/complication. If you don't use pamm, or just want to do things manual it's a little bit confusing at first. Just my opinion and all that Or, somehow automatically building the ui file from the modinfo.json at startup?
Sorry guys, I've been heads-down a bit lately focusing on some other internal mod infrastructure stuff; haven't had a chance to bring my head above water and check out the forums much lately. I'll be back into more fun community-facing mod stuff within the next couple weeks, but for right now my attention is elsewhere since I'm coordinating with another Uber employee who will be heading out on paternity leave soon. So, timing, and all that. Soon though. Anyway, there are already some JS facilities for retrieving the mod info for any mods that have been mounted, both client mods and server mods. We haven't integrated it with the ui_mod_list.js stuff yet just because time/reasons. But you're welcome to try ahead of us and use the facilities already there to see if something is workable already, and if a good combination of functionality is found, I'd be happy to look it over and maybe integrate it. The community is the primary customer of ui_mod_list.js, so if you folks come up with a better way to utilize or even obsolesce it, I'd happy to give it a try. The main JS method you're probably looking for is api.mods.getMountedMods, with a context of "client" (or you could use the "server" context which gets all the mounted server mods in use, if you're currently in a game; in this case I believe "client" makes more sense though). Usage example: Code: api.mods.getMountedMods("client", function (mod_array) { for (var mod in mod_array) { console.log("Mod display name: " + mod_array[mod].display_name); } } Other fields will be in there too, not just display_name. You'll also see identifier, author, description, etc. However, it is not a raw dump of the original modinfo.json files themselves, since they've been loaded and processed into an internal intermediate representation. So if you add extra fields for PAMM usage etc, you currently won't see those. Coming soon though there will be support for a "community_extra" object field that you can put whatever JSON elements you want in though, and those would be left alone through processing all the way to the getMountedMods call; I have that feature in locally, but it'll be a bit before that's out in the wild. Edit 6/26/14: Nevermind the community_extra thing, it just made things more confusing. Instead I'm fixing the internal modding APIs to use the original modinfo.json content for getMountedMods API, rather than the processed intermediate state. That way if there are extra fields from PAMM etc, they should still be there. Still not out in the wild yet though. But hopefully you can get through some fruitful initial experimentation without that. Does that help at all?
Hi, Regarding ui_mod_list.js, maybe we could avoid this file if, as convention, and like the stock mod server_browser_show_cheat_servers, you were automatically looking for a folder with the same name as the current scene, and the global one. You will have to load the files in the same order as the mounted one. Regards
server_browser_show_cheat_servers is an extra special case hacked into the code. My best idea so far is to use a known path name, perhaps /ui/mods/<identifier>.json, at which point it should be possible for a single shadowed filed (perhaps a static ui_mod_list) to attempt to load that file for each mod and integrate the ui_mod_list structure (or just execute the loads in place) at run time. This is working with what we have. The game might in the future be able to load a directory, although that might make things tricky for network mods like pastats.
Its a good start, but i don't think a full replacement for the ui_mod_list.js will be possible until the ui scenes are added into the json spec. The community_extra could be one way of doing it, but it would be putting an official modding feature into the "community" area which seams... weird. I mean to fully get rid of the ui_mod_list.js we need a way of expressing the scenes in json: Code: var global_mod_list = [ ]; var scene_mod_list = { "armory": [], "building_planets": [], "connect_to_game": [], "game_over": [], "icon_atlas": [], "live_game": [ ], "live_game_econ": [], "live_game_hover": [], "load_planet": [], "lobby": [], "matchmaking": [], "new_game": [], "replay_browser": [], "server_browser": [], "settings": [], "social": [], "special_icon_atlas": [], "start": [], "system_editor": [], "transit": [] }
How about adding a "ui_scene" array to the modinfo.json with subarrays for each scene and having the ui js file generated based on that and the loading order in the main mods.json? Maybe even force a default root folder for ui mod files listed in the scene array to prevent shadowing. Just trying to think of ways to use files that are part of the mod loading process already. Network loaded mods like pastats would be literally a folder with a file and an entry in mods.json but still follow a mod convention of sorts. EDIT: I'm on my phone, so making an example is a little difficult
It could be easily done from within PA with Coherent UI if the scenes property was already available. We shouldn't have to manage this from outside PA, but hopefully we have PAMM ... Using folder name convention like I said earlier was just a way to avoid depending from a modinfo property. But we could also, like npm packages, declare a "main" script, and like PA Stats, fill ourself the ui_mod_list array dynamically. There is so many way to manage this without the need of an external tool.
