Coming up soon... Server Mods!

Hi folks! I wanted to post a quick teaser about something new coming down the pike for you modders out there.

Server Mods!

Now this will not just be a single all-at-once feature; this stuff takes time, so it's going to be an incremental thing. This should in no way try to take away any of the thunder of all the awesome new stuff that's being pushed out with the Galactic War builds, which is why I haven't talked about it until now. More info will be rolling out about this soon, but I wanted to give you guys the early heads-up.

Just to be clear, we are not releasing the server executable at this time. Rather, we will be adding support for you to host modded games on our servers. This has high potential for abuse, so we're taking this slowly to see how it plays out.

"Wait," you say, "modded games? On your servers? Huh?" I'll explain. For this first phase, we're focusing on "transient" server mods, and here's how it all works:

Right now client mods exist underneath your computer's user data folder for the game, and those mods only affect you. What we're adding is another folder as a sibling of the client mods folder, specifically for server mods. This is a separate folder with a separate set of mods, and a separate mount order configuration file.

If you join an existing game, these mods will not be used at all. On the other hand, when you create a game for other people to join, any server mods that you have mounted will get temporarily uploaded to the game server, specifically for that game session. Any other players who join your game will get the server mods downloaded to them as well, that way the server and all the client players should be synchronized with your changes. The server and the other players will only apply these changes in memory, and no additional disk files will be permanently written; this is why we call these mods "transient".

So what kinds of things can you mod with this? Well, how about one example that a lot of you have been asking for: Unit Balance Mods. Unit .json files are small and fit very well into this approach. Think a certain unit has too much or too little health? Make a mod to change it! Think something should be cheaper to build? Change it! Think bomb bots should explode like nukes? Change it! (that last one is silly, but we admit that we tried it too, just for fun).

You can also add new units too, or remove them, but those are a bit more involved and we're still working out the details of how to demonstrate that; changing existing units is definitely an easier place to start. More details on all of that coming soon!

We'll also be rolling out a few stock server mods to enable a handful of cheats, useful for iterating on server mods and/or playing a more experimental silly game with your friends. Right now those cheats include allowing vision of other players (like you can when you're a spectator), allowing a change of control to another player, and copy&pasting units (fun for sandbox testing; please don't be abusive of this or we'll have to add a unit cap to it). There's also a cheat to allow publishing of an updating version of your server mods while a game is still running; there are some restrictions to this, but for a lot of changes it works pretty well!

The server mods, and any active cheats, are visible in the game lobby so you know what you're getting into. In addition, although modded games will be visible in the server browser via a new filter, cheat games will not be visible unless you are running a (stock supplied) client mod yourself which enables viewing of cheat games. This gives us a minimum barrier to entry so that people have to bring themselves into the mod ecosystem at least a little bit, so they know what they're getting into when it comes to cheating. But non-cheating modded games will be available more widely, without this restriction. And because the changes are transient, nobody has to download anything beforehand to play your modded game! They just join in, the modded files are downloaded automatically, and then you can play. Fun!

As said above, this is just the first step. In the not-too-distant future we'll be adding more features, including mods for victory conditions and other game rule modifications, server logic scripting support (within limits; this is something we need to be extremely careful about while we're still paying for the servers), and persistent versioned/signed server mods that people can keep cached on their machine so they don't have to transiently download them every game (in the meantime, try to keep your mods small, which with .json files is thankfully pretty easy). So this is just the beginning.

More details forthcoming, but start thinking about what you'd like to create! I believe there'll be a lot of fun in store with this stuff. Happy planet smashing!

- Chris

can't wait, best news of the day

Awesome!!!

Cool! Any chance we'll get custom planet & biome types relatively soon? (at least ones that use in-game brushes only?)

Excellent.

Soon.

You will all see that flat balance is the way.

Will there be a way to toggle mods on and off? I'd prefer not to have to move/delete all of the data in my mod folder to turn mods off.

One like is not enough for this post

I'd like to think I inspired this, but Uber is pretty clever by themselves, after all. https://forums.uberent.com/threads/...he-fastest-way-to-an-effective-balance.58493/

That's a question I was wondering about myself as well, when it said "stock" mod. Well at least for pure UI mods it isnt actually hard to do that even now ingame.

Right now everything is done by mounting, via the mount order present in the server mod folders' mods.json file. This is the same way that client mods are used; any mod that is present but not mounted is ignored. The intent is that mod managers can use this to organize/mount server mods in the same way that they do for client mods already. Make sense?

The stock mods are a new thing; we want to deploy some mods with our build distribution, like cheats and sample content mods (some useful, some silly). So we have a folder for those as part of the rest of our media, and the mod system loads those mods as well as the ones from the user data folder.

The mounting is still entirely controlled by the user's mods.json files (for client and server), so all the stock mods really add are some stock mod identifiers which can be used in the mount order list alongside other user mods. All of these start with the identifier domain prefix "com.uberent.pa.mods.stockmods", which nobody outside of Uber should be using. For example, "com.uberent.pa.mods.stockmods.server.cheat.allow_change_vision".

Wow, this is really awesome! Can't wait to start playing with it.

Me too

Wow this great news. Nice way of doing it too.

I was hoping Uber would experiment with pulling client mods into server to implement server mods, amongst other things, like loading player saved replays into the game to load a server with the replay and stuff.

So the news in general is a landmark and you are a saint.

This is truly most excellent news. I'm really looking forwards to getting to play about with this stuff.

Can I make a really unpopular suggestion? Dont release this until I'm back at my computer in 3 weeks? Thanks

Are there any current limits with regards to the size of the server mod files?

Lrn2phonecode nub!
(Visual C++ for phones... That's a chilling thought.)

This transient mod thing is inspiring. Can replays handle modded games?

Not yet, but be reasonable. The smaller the better, since it's additional time and bandwidth for all the other players who join your game; we just want people to be respectful of their fellow players.

If I had to put in a cap today, I'd probably start around 1MB of total server mod data per game max, which is actually quite a bit when you focus mostly on the .json files (for comparison, adding up every .json file currently available to the client totals less than 3MB, and that's including a bunch of localization files etc. And the media/pa folder with all the units and such specifically is under 700k... you get the idea. So 1MB is a lot of room). If you decide to experiment with meshes or textures, those will eat up space faster, so plan accordingly. Once we have persistent mods later on down the line, these kinds of size limits won't be as much of an issue.

Actually, they can! Or at least, they should; I haven't tested it much yet, as I only got that feature in yesterday. But there are caveats.

The replay files for modded games will have the mod data bundle embedded inside the replay. Keep in mind that our replays still have very primitive versioning support, so they don't always work, and this complicates things a bit more, since there's an additional level of compatibility required (not just the replay history data, but now also compatibility of the mod content with whatever source files they're shadowing, which may now be a different version). The simpler the mod data, the less of it there will be to conflict with other content files that may have changed.

This is still an open question on how far we can take this particular feature; it's a tough problem.

We'll also probably be disabling replays for modded games which utilize the cheat to publish updated mod files mid-game, since that's a huge rat's nest of problems that aren't really tractable for us to solve in the time we have available, and there's not sufficient enough utility there really. But I'm trying to keep those kinds of truly disabling cases to a minimum if I can.

Wow this is fantastic !

The wh-what now!? That's obscene! (-ly good.) Does that rat's nest affect chrono-cam as well? I never could figure out if it was related to the replay system.

Indeed, they are very related! The replay data is primarily a written form of the history server information, which is what feeds Chronocam. So right now yes, if you publish an updated mod in the middle of a game, Chronocam will be affected too.

How much it's affected depends on what you change. Some .json spec data affects only new units that get created, which will then have their own independent history curves; if you change those fields in a mid-game mod update, The replays & Chronocam might be just fine. But other spec data is used flatly for all units of the given type in play (such as certain economy-related values), and if you update that stuff mid-game, it might make the pre-update Chronocam footage seem a bit off.

Bear in mind that I do have a potential solution to this, by encoding the mod update bundles into the history data directly as their own step curves. But it's not something I can easily do yet until we get some other prerequisite tech out the way, so that's going to have to wait. In the meantime, Chronocam with unchanged mods will hopefully work fine, but mid-game-updated mods could be a bit wacky depending on what gets changed. Make sense?