Oh noes! What have you done! Code: // inject per scene mods if (scene_mod_list['new_game']) loadMods(scene_mod_list['new_game']); handlers = {}; handlers.game_config = function (payload) { ...... Handlers are defined AFTER the mod is loaded in new_game.js. On further inspection, this is a bug. It seems to be only in new_game.js EDIT: It's also the case for the new building_planets.js, but not for the new armory.js
This is BAD for PA Stats. Gonna have to shadow that file. Edit: Actually double bad, I cant add shadow files. Maybe I can hook into some call that is done in the handler...
Thanks. I actually think I don't need to hook into the handler anymore. I only had to due to a bug in the js code. That bug is in gone. EDIT: A timeout is probably pretty hard to get right. The calls that register the handlers with coherent happen like 10 lines below. Don't think a timeout can do that.
So you need to make your thing before it's registered to coherent? Yes, then a timeout would not work. JavaScript is single threaded, so it would not be possible to get in between there.
Just wanted to pitch in here again, and I pray that Sorian reads this stuff, *please* make AI at least semi-moddable.. please give us the access we need to add and remove AI actors from specific units or currently in-play factions. A switch that lets us dynamically give units and pull units from different AI actors along with access to the AI's script... that would be amazing. Can't say how many of the best WC3 mods would have been impossible without having access to computer player's AI and such.. (try making Dota without being able to touch unit AI..)
Why does the ui_mod_list.js file need to be shadowed? Are you planning on changing this to something similar to the mods.json implementation? It just seems really sloppy *requiring* what amounts to a mod for mods, especially when it's one file that has a similar function to the mod loading order. Just out of curiosity
Because you can't simply put it in the default folder anymore because of the new launcher. It's better organized this way, the PA folder stays completely clean of mods.
Been wondering, what will the 'signature' field do? Will it be a checksum of the mod? Or some sort of signed certificate thing?
Still TBD; trying to figure out how heavy-handed we need to make it. It'll be more relevant when we start moving towards published/persistent mods, but that's still a little ways out. Don't worry about the signature field for now.
Hey folks, just a heads-up. Up until now, the modding system has been okay if you didn't have a mods.json file in your mods folder (and now, on the PTE stream, the server_mods folder as well) to control the mod mounting order; when the file was missing it would just mount whatever mods it saw underneath that folder, in whatever order it encountered them. The addition of stock mods (for cheats etc.) has thrown a wrench in this, and made the lack of a mods.json make far less sense, since there's no one obvious fallback approach for the game to take any more. Therefore, starting with the next build the mods.json file will be required, both for the (client) mods folder and the server_mods folders. If you already have one, no change is needed on your part. If you don't have one, now's the time to set one up; if you don't have a mods.json file with a valid mount_order array, your mods will no longer be loaded. Just FYI!
PAMM manage this file automatically (for client mods), even for mods not installed through PAMM, but I guess the new thing will be to be able to enable stockmods by adding them into it.
Yeah, the plus side of this is that the stock mods do not have to be copied into your user data's mods or server_mods folders. All that should be required should be to put their identifiers in your mods.json mount order.
Just as a refresher, here's what the mods.json files look like (this one from a server_mods folder): Code: { "mount_order":[ "com.uberent.pa.mods.stockmods.server.cheat.allow_change_control", "com.uberent.pa.mods.stockmods.server.cheat.allow_change_vision", "com.uberent.pa.mods.stockmods.server.cheat.allow_create_unit", "com.uberent.pa.mods.stockmods.server.cheat.allow_mod_data_updates", "com.happyfuntestmods.mycrazyenergyplantmod.woohooenergy", "com.someotherdomain.bombbots_are_nuclear" ] } and this one from client_mods (or just plain "mods", which is used if client_mods isn't found): Code: { "mount_order":[ "com.uberent.pa.mods.stockmods.client.cheat.server_browser_show_cheat_servers", "com.whatever_other_client_mods.perhaps_your_mod_manager_will_handle_this" ] }
Will the "enabled" field still be relevant? It becomes redundant, and I wouldn't mind if the mod managers stopped reformatting my modinfo ;^)
The "enabled" field is actually legacy and is considered true by default, so you don't need to have one. Specifically, the logic for us when loading a mod now is that if the json has an "enabled" key, it's expected to be of a boolean type and the value of that boolean is expected to be true, otherwise the mod will be skipped. So take it out if it's causing you trouble.
PAMM will have to use the mods.json to enable/disable mod, because it can't obviously modify the modinfo enabled property anymore (can't touch stockmods) How do you plan to manage scenes integration ? The server_browser_show_cheat_servers client stockmod doesn't specify when it should be loaded, we have no clue for the ui_mod_list.js update.
That server browser cheat is an explicit thing that sits outside the scenes integration; we don't use those scene-related modinfo.json fields natively so I believe those are just PAMM-related fields for ui_mod_list.js generation, and I didn't want this cheat to be tied to that (because PAMM is optional). So I admit we're in murky territory there right now, and I sidestepped it with this particular cheat, at least I until I figure out how to get the ui_mod_list.js and mods.json worlds together under one banner (raevn's done a fantastic job navigating that mess btw; I just want it to be less of a manual process in the future, but I haven't figured that out yet).
