Coming up soon... Server Mods!

Can't reproduce on Win7

Same Win 8.1

The original report was OSX; anyone else using the PTE stream from a Mac?

brian, could you test this please? It'll only take a second.

what you have to do is create the new server_mods folder next to the mods folder in appdata and edit the .json file and play on PTE as specified here : https://forums.uberent.com/threads/coming-up-soon-server-mods.59738/page-3#post-936786

Wait hold on, that's not the bug I'm talking about. I'm just talking about it crashing if the server_mods folder doesn't exist at all.

Your crash report, sir. I did the Apple crash report first, and then remembered the console log output, so separate runs. Seeing the mod list made me try it again with with mods disabled - first time worked (notable difference: I hadn't seen the welcome video because I've got a hacked start page), but I tried again and went straight to create game, which crashed. Crash occurs after the new_game page is fully visible, just about when I'd expect the server mod api calls to be going off.

Interesting; I just tried the PTE stream on a Macbook here, no server_mods folder (no mods at all actually), got into new_game just fine, hmm...

Okay, just looked at your applecrash.txt, it's definitely a crash related to spec loading. Were both your mods folders gone, or just the server_mods folder? If you still had client mods, do any mess with new_game? I'm just trying to narrow things down a bit. Not that that excuses a crash of course (we want to make the system more tolerant), but bad specs can still push a lot of buttons right now; wanna eliminate any possible complications.

I moved both server_mods and mods, and it didn't crash. I hit "disable all" in the Atom mod manager in the previous test, I'll double check what it's doing and then start the binary search.

Whee... So I used to use DeathByDennis PAMM, and then switched to testing the cross platform Atom version. Disable-all in Atom-PAMM left the dPAMM ui_mod_list mod in mods.json (and enabled) which I can only assume had an old ui_mod_list in it (I ran dPAMM to see what it looked like, and it probably overwrite with an empty one)

Definitely weird that server_mods interacted with it, but no wonder you couldn't reproduce.

Dennis? Really?
Kind of weird though. There should only be a PAMM folder, not a dPAMM folder. Although I think it used to be called that in a distant past. I'm not even sure anymore. In any case, my version uses "PAMM".

He was probably talking about having "com.pa.deathbydenim.dpamm" in the mods.json mount_order array, which is the normal behavior.

My sincere apologies for affronting your honor. I've been typing too fast today.

Right, there's rPAMM, and dpamm shows up somewhere else. Typing fast again.

*unslings coding gun*

Looks like we got some sport, folks! Time to saddle up!

Okay, I've found a rather interesting bug:

If a unit has malformed JSON in the 'tools' area telling it to attack will crash the server. I found this through experimenting with getting the whole 'Unit<-Tool<-Ammo' paradigm into just 'Unit'. While I didn't expect this to work easily, I didn't expect to crash the server so easily.

Needless to say, if one doesn't put a file under 'spec_id' and instead tries to paste in the contents of the file it causes a few... issues. It is interesting however, that trying to build does not cause the server to crash; that only occurs with attacking.

The attached file is the specific .json that replicates the issue, renamed to .txt due to file restrictions.

Yeah, spec_id is expecting a string value there, not an object value.

In terms of attacking causing the crash, what you're probably seeing is that many specs, especially specs only used because of indirect references through units (like tools/ammo), are loaded lazily. Until a unit of a given type needs to use a tool, it's possible that the tool might not have even been loaded.

Within that context, right now it's possible for many spec issues, whether they're syntactically malformed or semantically incompatible with engine expectations, to cause crashes. The game just isn't very tolerant of bad specs right now because traditionally we were the only people authoring them, so we could fix the problems as they came up pretty quickly.

Modding certainly changes that dynamic. Unfortunately, things like logging, inspection, and content protection are unbounded problems, and we don't yet know how far we need to take those things, let alone how urgently they need to get in. So for now we've deliberately taken a position of "let's see what the modders actually do and how bad of a problem this actually is". We know we need to make some improvements in these areas, but the specifics are going to be influenced by what you folks do, and your post is certainly one data point towards those kinds of decisions.

That's actually very urgent.

Not only because it's endangering the server stability, but also because it makes testing even the basic semantics of the unit JSON files a mess. (Although I'm already onto the latter issue...)

Letting arbitrary people push active code to other players clients is yet another issue. Mod signing system needs to be a thing rather soon. Especially as soon as the mod contains any type of script oder shader. You can't protect clients entirely, but you can limit the damage by revoking abused/compromised signature keys. Commonly used APK or JAR signing mechanisms would be great since the tools are available cross platform already.

At least warn explicitly when any non-signed mod attempts to push data in multiplayer.

I'd like to second exterminans. Some better logging tools and such would go a long way towards better mods, better server stability and happier players.

Remember how I tried to load stockmods with just the identifiers and it didn't work? I noticed this in the console log:

Code:

INFO LoadedLocalModCollection::loadLocalModCollection: Failed listDir call for "/Users/jlove/Library/Application Support/Uber Entertainment/Planetary Annihilation/data/streams/PTE/PA.app/Contents/Resources/media/stockmods/server"; no mods will be loaded from this path

There is no 'media' folder, stockmods is in Resources.

Oh crap, seriously? I didn't know we organized that stuff differently on OSX (you can tell how much I play on Mac, heh).

Great find, will fix. Thanks!

Edit: Oh, and workaround for OSX users in the meantime, just copy those stock mods to your user mods folders so you can use them; I'll try and remember to let you know when the build goes up that has this fixed so you can take them back out again.

By the way, are the stock mods special cased? The other day I tried to make cheat_all mod that put all the properties in one json file to simplify toggling them all at once, but it didn't work.