Yep, I'll do a proper installer at some point, which will include atom shell. And you're correct, pamm won't be included as-is, but re-written to work for pahub. Mostly because a lot of the content functionality (browsing, installing, enable/disable, dependencies, updating etc.) will be native to pahub content handling. All the Mod Store (and other content stores) need to worry about is what "enable/disable" actually means (eg., writing out the required mods.json / ui_mod_list.js), and how to find content (since for mods, it's in a different format - modinfo.json instead of content-info.json), with some slightly different fields. It also adds filters & sort methods to the content hub specific to mods.
No problem by using pamm-server for the mod list content from pahub. You could even bind your "mod content upload" to the api directly, but the github auth could be the tricky part.
Update - 2/10/2014 All under-the-hood changes, very little visible. Updated: pahub com.pahub.content.plugin.store.plugin com.pahub.content.plugin.contenthub Changes: Content dependency checking (partial): Content is now loaded in an appropriate order to ensure dependent content gets loaded and enabled first. Any content missing dependencies will be loaded but not enabled. Cannot enable content if it's depencies are missing or disabled. Does not yet disable dependent content if you disable a required content item though. Local/Online versions of content are now compared; if the versions differ this will be logged (precursor to update functionality) Finding & Loading of local content changed to make extension/custom loading easier while retaining core functionality like dependency management. More reliable pahub directory detection on windows Check for updates to pahub no longer blocks loading of pahub Bug Fixes Minor style changes Code refactoring & cleanup API Changes addContentItem - order of parameters changed addContentItem - 'local_path' parameter replaced with 'url', no longer refers to folder but url of json config Added contentItemExists getContentItem - replaced 'store_id' with 'local' applyFilter - added parameter 'toggle' toggleFilter - removed. Functionality now included in applyFilter with toggle set to true. getContentItems now returns array, rather than ko observable.
Update - 3/10/2014 Concentrating on the content hub still. Added an information panel, which displays information on whatever your mouse cursor is over. There was simply no room on the previous content tiles for all the information that needed to be shown. What the info panel does show will be determined entirely by the content store of the item you are looking at. So a content store for sharing system for example could include information on the system. Or a store for individual units could show specifications for that unit. I'll be adding more basic information to the default display, such as version, author, requires etc. Updated: com.pahub.content.plugin.contenthub Changes: Added information panel for current hover content item Re-styling of the content items: Enabling content will now first try and enable all dependencies Disabling content will now first try and disable all dependent content Local content items with updates available now display an orange name in the installed/find content tabs. Content parameters 'online_content' and 'local_content' are now ko observables Code re-factor/cleanup API Changes: added pahub.api.content.getContentItemDependents added pahub.api.content.contentStoreExists added pahub.api.content.getContentStores removed pahub.api.content.getToggleFilterResultCount (merged with pahub.api.content.getApplyFilterResultCount) pahub.api.content.getApplyFilterResultCount - added parameter 'toggle' added pahub.api.content.refreshAllOnlineContent removed pahub.api.content.getFilterList removed pahub.api.content.getFilterOptions removed pahub.api.content.getSortMethods
Update - 4/10/2014 Finally got zip functionality in, so content from the online content tab can now downloaded with just a click. Yay! Unfortunately, there's not much to do right now, as the mod content store isn't ready yet. Soon (TM). Updated: pahub com.pahub.content.plugin.contenthub Changes: Change: Content installation from Online Content view Change: Reduced height of footer area Change: More accurate reporting of what is currently downloading Change: Added ko deferred updates library Change: Added JSZip library Change: added tab "display" to content hub. This will eventually house display options for content. Change: added show/hide options button to content hub Change: cached icons are now saved in an icons folder Change: major perf improvements to adding content Fix: properly disables content that is set to enabled on load, but cannot be due to missing dependencies Fix: Check for updates really no longer blocks loading of pahub. Fix: loadResource in save mode will now create the destination folder if it does not exist API Change: added pahub.api.content.removeContentItem API Change: added pahub.api.content.installContentItem
Updated 3rd post with a to-do list and some community questions. Cast your votes! Also open to new questions if you think of any, but it may be a bit too early for functional ones, since a lot is simply not yet implemented
Rather have the Client Mod in standard blue, and highlight server mod in a different one. Kind of like the purple (+1), proposed (0) also another colour already in PA Hub palette too Side note : Title input should be longer (whole width ?) and Text one should be a block
D'oh. screwed up the colours. That blue is for plugins (since it's a theme colour), the server mods are actually a reddish purple. I've updated the 3rd post, let me know if this changes your vote? Currently, they appear like this: I haven't styled the add news page at all, really That should be on the to-do list.
You should have a look on http://commonmark.org for your news content. Lots of news wasn't only plain text. I tried it for a news api on pamm-server, seemed to work pretty well, you just have to be carefull that your line ending are not mangled by jquery during http post.
Update - 9/10/2014 Mod Store plugin released! You can now manage mods within PAHUB, including installing/updating! There are some known issues still, such as not taking mod ordering into account yet, but these will be fixed. Make sure the "PA Mod Manager" mod is enabled (this is hidden in PAMM, and force enabled, as it is required). WARNING: Make sure you back up your mods folder. I haven't done extensive PAMM <> PAHUB testing yet, and PAHUB does not yet make a backup before it deletes content to replace it. Also, content hub dependency checking overhaul. Dependencies can now be listed in two ways: The existing way done in PAMM, by listing the content id The following way: Code: { "content_id": "<content id>", "min": "<version>", "max": "<version>", } Min & Max are optional, and allow you to specify what versions the content must be within. Updated: pahub com.pahub.content.plugin.contenthub com.pahub.content.plugin.store.mod com.pahub.content.plugin.store.plugin Changes: Release of mod store plugin Change: Added semver library Change: Content Hub information panel content is now determined by content store Change: Stores can specify custom install functions Change: Dependency checking improved, can now accept version numbers for dependency Fix: If content is unable to be enabled due to dependencies, it will now be set to disabled & saved (previously was not saved)
Hi, Regarding dependencies, I think you should use npm package mechanism : Code: { "dependencies" : { "foo" : "1.0.0 - 2.9999.9999" , "bar" : ">=1.0.2 <2.1.2" , "baz" : ">1.0.2 <=2.3.4" , "boo" : "2.0.1" , "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0" , "til" : "~1.2" , "elf" : "~1.2.3" , "two" : "2.x" , "thr" : "3.3.x" } } Some readings : https://www.npmjs.org/doc/files/package.json.html http://semver.org/ #A very usefull nodejs library: #https://github.com/npm/node-semver #edit: just saw this lib in your post ... :> Just as a side note regarding PAMM, I switched from "requires" to "dependencies" list to have exactly what Uber wanted us to have in the modinfo.json, even if they still don't enforce it. Bringing a new dependency system could cause issues in a near (or not) future.
I haven't looked much into it, but npm seems to have a few requirements that would limit pahub functionality; the required presence of a package.json file, for example, removes the ability to have custom content loaders, meaning existing mods would need to be repackaged, and future content types would also have this limitation (as another example, I wanted it to be possible for a content store to be able to have pictures as it's content, without the need for any additional content-info.json or other content definition files for each one). It would also appear to require a complete re-write of the content management system. The use of the dependencies parameter in PAHUB is backwards compatible; it can accept either a string (as per PAMM) or the new object with min/max version numbers. If Uber change how that parameter is used, it shouldn't be hard to incorporate that too. If I've got the wrong idea about npm though, please correct me Hehe. It should time out after a while, but I'm not 100% sure
I was talking about the way npm package express dependencies in its packages, not about using npm. Having a min and a max properties seems a bit odd. I don't think adding illegal data in the existing dependencies array is safe, keeping the modinfo Uber properties as they intended them to be could avoid some crisis. If they decide to enforce the existing dependencies array, how do you plan to patch PAHub to no brake PA ? I can't see any easy solution if you go this way. It would be safer to use another property for the new mechanism, and merging its content "in memory" with the "dependencies" array for back compatibility. Using your previous "requires" property may not be advised, because there are still some old mod using it, and PAMM rewrite it "on the fly" as dependencies array. Or maybe, you could have a "content.json", a new format to replace the "modinfo.json", which would allow you to keep the old format viable, while allowing a soft migration to the new system. If the content.json is provided, you don't need the modinfo.json, because PAHub can write it on the fly for PA, and it could be easily patchable if Uber change anything, while removing any limitation or compatibility issue. If it's an old mod with a modinfo.json, you keep the existing loading behavior and hope for people to migrate asap.
Oh, right. I'll look into it. Min/Max still lets you do any of >, <, =, <=, >= and "within" which is why I chose it. Have uber actually defined what the dependencies parameter should be structured as? If not, it's possible they'll break anyway. When I was talking about backwards compatible, I meant that PA Hub could read any combination of formats; I didn't really think of the other way around Agreed. This actually won't be hard - each content item, once loaded, is actually made up of two parts - the "data" part, which is what was read from (and gets written to) the content-info.json/modinfo.json files, and the in-memory part, which contains any run-time info needed by pahub, and which shouldn't be written to file. It's somewhat like this: Code: //run-time information { content_id: "content.id.string" store_id: "store.content.id.string" local: true/false, //true = installed store: <reference to store object>, icon: <path to icon>, url: <local or remote url to mod>, online_content: <reference to online entry for mod, if local>, local_content: <reference to local entry for mod, if online>, data: <contents of content-info.json / modinfo.json> //data part } So it would be easy to just add the dependency as another run-time attribute which is populated on load, and the population of it can translate between the different formats - the same thing occurs for the "identifier" attribute of mods, which gets transformed into "content_id".
It's probably making your version validation over complicated. With only one value, your code would simple as semver.satisfies(othercontent.version, dependencies[othercontent.content_id]). Personnally, I like when an API do all the work for me In fact, they have, even if the rule has never been enforced :] The dependencies property should be an array of identifiers. And you can see this array of strings in game with the api. https://forums.uberent.com/threads/beta-mod-changes.51520/page-8#post-938728 It would also avoid some crasyness like identifier + content_id in the modinfo.json like we had previously with the id + identifier :] You will be free to define your content-info.json format ... freeeeeeeeeeeeeeeeeee
See my edit at the end Having said that, I'm also currently writing out content_id into the modinfo.json file, but this is needed, and I'll be changing that.
Hum, since I tried PA Hub, PAMM has no effect on enabling / disabling mods PA Hub has full control on the current mod to be mounted. Any way to change it back ? EDIT : Related ? Code: [20:53:43.000] INFO Loading mod : rPAMM [20:53:43.000] ERROR Cannot load mod C:\Users\Fr33\AppData\Local\Uber Entertainment\Planetary Annihilation\mods\rPAMMwith identifier "com.pa.raevn.rpamm", a mod with that identifier already exists EDIT 2 : Ok, removed "com.pa.raevn.rpamm" folder from mod folder and everything seems back to normal