Coming up soon... Server Mods!

Just an idea. Maybe have a permission system like android.

Where each mod has to define permissions it uses.

This would prevent malicious mods from installing viruses or doing bad stuff.


But why for only server mods?
Well because these mods will get downloaded automatically, on a client mod you have a choice so you can look at the source. On a server mod you don't

Good point, and security is definitely on my mind. Permissions are a tricky thing though; it may start out as something simpler like just reporting what kinds of files are changed in the mod. For example a mod that only changes .json files has less risk than one that changes script code. So we're trying to figure all that out.

This is one of the reasons I'm planning on testing this stuff on the PTE stream first (or maybe even a totally separate dedicated stream) because I'd like to see what kinds of abuse scenarios really warrant early attention.

Oh and just to be clear, regardless of whatever security stuff we may or may not get in, modded games are always going to be an Opt-In kind of thing. Modded games aren't even listed in the server browser by default, unless you enable the filter to show them.

Huh, I hope that changes at some point, mod servers not being shown unless the player already knows about that kind of potential could really hurt the visibility aspects of mods....

Mike

The filter isn't hard to see or get to (it's right alongside the filters for planet count/size/etc), we just wanted something to indicate "this is not going to be the original PA experience, just so you know".

It's the cheating servers that have a higher barrier to entry, and that one's very deliberate.

Can't wait. Sounds like a lot of fun to mod.

In my experience ANY Barrier is supremely effective at unintentionally blocking people out that don't already know about it. GPGNet had the Vault built right into it as a major feature and still the people that took part were such a minority of the people playing overall despite it being right there already.

Of course this isn't a problem that has a "silver bullet" that can provide a single perfect solution but that to me just means Uber needs to be all the more careful to make sure everything works together to achieve the end goal properly.

Mike

Does this mean we will get access to the dev editor, where you could bring up a planet and you had a little box with all the units and could just drag them into the game?

This is great, but IMO change the barrier of entry to a setting in the menu that's turned off by default. That's something a.. I guess power user? would be more likely to see, but wouldn't necesarily launch the launcher. It would just allow anyone to see that the option is there, and still know what they're getting into, while increasing the potential player pool for modded games.

Perhaps it would be better to have them listed by default, but perhaps in a seperate list and/or with a separate red [MODDED] tag.

Would it be possible to detect when a json file is loaded, and alter it before being used? Instead of shadowing the file and causing maintenance busywork whenever the game is updated, we could make json mods that wouldn't break when looked at funny. It would also make it possible to blend certain json mods together.

I'm naively thinking you're using something in js like $.getJSON to load the json. Making it so we could hijack the 'on success' function would be very powerful for json mods.

We're gonna have to get a group of people together and make a kick *** balance.

Do you already have an ETA on publishing what will be possible to mod with server side scripts?

To be more precise: Which parts of the simulation are actually hard coded in the engine and which are scripted?

Even more detailed:

• Will it be possible to inject data sets of new type into the history server?
• Will it be possible to provide additional brushes for planet geometry generation?
• Will it be possible to redefine rules for visibility and alike?
• Will it be possible to attach new dynamic attributes to arbitrary units?
• Will it actually be possible to have scripts which run in every single frame of the simulation?
• Is there multi-threading capabilities for scripts?
• Will it be possible to overwrite stock scripts, like e.g. visibility computation?

Didn't care about the client side modding capabilities much since I'm neither a visual artist nor a GUI designer, but I've been waiting for server side scripting support for quite while.

A spark of hope for a T1 = basic T2 = specialized, no paper-units balance!

We're gonna work on it!

The thing you're referring to is our internal "sandbox mode", and while we do want to roll that out at some point, we can't quite yet since it currently relies on being able to run a local server (which you folks can't do yet). So we're taking baby steps in that direction.

However, there's nothing stopping you folks from making something substantially similar in a UI mod, once you have access to the Create Unit cheat (which is basically copy+paste for units); that's how the sandbox UI works under the hood anyway.

There's also the cheap version which uses the avatar commander; if you make the avatar commander buildable you can make pretty much anything almost instantly, so that's another alternative that's independent of any heavier UI requirements. All are good simplified alternatives to our sandbox mode.

This is a slippery slope, and not something we've engaged with just yet because it's very risky. I definitely support the idea of mixing & matching mods together and/or dynamically changing spec properties for new units (it's something we've talked about a lot internally and plan to get to at some point once a few other history system prerequisites are dealt with), but it'll probably be implemented in a way that's a bit less obscure and stealthy than json loading hooks. So I might be saying no to the implementation suggestion, but I still agree with the general premise.

We don't do dates. For now, understand that this first phase is focused on transient content mods, not server scripting. We've been changing the server stuff a lot lately during the introduction of Galactic War and will probably be churning on it for a little while, and it'd be best for everybody to let that settle down more before we deep-dive into the server scripting world. In the meantime, content mods should allow for a lot of fun possibilities that previously weren't available to modders, so let's start with that.

A lot of the simulation is native code, for performance reasons. This goes for the history system as well. If we tried to put a lot of that stuff in script, the performance would fall over very rapidly; we're pushing machine boundaries as it is.

I reordered your questions and put these two together because they're actually very similar questions; unit data is mostly made up of history curves. Right now a lot of the history system works with generated code that is created prior to compilation, so completely new dynamic fields aren't really feasible right now. I won't rule anything out (this kind of thing is more constrained by engineering resources than by performance fundamentals), but don't expect this any time soon.

I can't speak for the planet geometry generation; that's not my current area of expertise and I know some of our CSG behavior is in flux so I'm not the best person to comment on that right now. Maybe jmavor (neutrino) could say more about how that stuff works.

Also merged these questions; broad-scale visibility on an army-by-army basis is controlled via script (we call these "vision bits"), and per-unit visibility hooks into this via observability flags, with native code behind it. So custom visibility work needs to take a "big picture" view of things.

The server script logic is in JS, so think less in terms of threads and more in terms of callbacks. There's a lot of flexibility in terms of updates, but again think "big picture"; for example one thing you will definitely not get is an update callback for every individual unit, simply due to performance limits (the closest thing we might add there is some kind of "watched units" list that specifically has those kinds of hooks enabled, but it would have to be used sparingly and/or forcibly limited).
The theme here for scripting is "big picture" stuff, rather than fine-grained per-unit stuff. Changing game rules, special events and triggers, stuff like that. Those tend to get a lot of bang for the buck in terms of scriptability without heavily impacting performance. Anything too fine-grained (e.g. on a per-unit level) is not feasible simply because it would make the server fall on its face, and in fact would probably still make the server fall on its face even if the machine were 10x faster. We use native code in many situations simply because we have to, and modders will have to work around that. But we'll try to stay flexible in areas that don't hit up against those kinds of performance barriers.

Okay, so I feel like this is kind of related, in galactic war with the cards it uses a ve r you basic version of server modding, right? Is it possible for us to use those cards in a normal game or are the json edits only enabled when the mode=gw flag is passed to the server?

That's really good news! It should make mods like my unit renamer a ton simpler and a lot of other cool ideas possible.

Thanks!

It's GW-only right now; the server-modding facility being added is similar but not identical, even though they use some of the same underlying facilities. Eventually they'll probably converge to the same mechanism, but for now they're different.

I'll explain, since it kinda shines a light into the chaotic process of game development.

When we were first thinking about general server modding and the scenario needs of GW, we knew there'd be some commonality. However, GW took precedence for a variety of reasons, and our resources are limited. So the primary concern was adding in the kinds of modding facilities required to get GW to work, and if we could make some of it usable for our eventual (but more nebulous) server modding plans, then great, but GW came first.

One thing we knew would be common for both scenarios is the ability to memory-mount files on top of the existing disk files in the file system. GW could use this to make dynamic unit specs and lists, and server mods would probably eventually use the same kind of facility for its own mod bundle mounting. So we added that, and it's in there, and GW uses it. But beyond that, GW evolved in its own way, since its design was more well-understood compared to the server modding ecosystem which is much more open-ended and still in its infancy.

So yes, GW somewhat does a "server mod" type of thing with its memory file mounting, however its usage by both the client and server are their own thing specific to the GW script logic. As the server modding system matures, it may eventually absorb a lot of the GW-specific logic into its own, more generalized, view of the world... or it may not, if we run out of time. To be sure, we'd like all this code to be the same (it's less divergent stuff to maintain), but game development is a messy thing.

That unfortunately confirms a lot of stuff I already expected. Full conversion mods are pretty much off the limit without the ability to overwrite or extend core attributes, same goes without the ability to iterate over the entire set of units - and even if it was just a full iteration in every 5-10 server frames. (Actually serious about the latter one, for most tasks which don't involve directly scripted movement or alike, deferred iteration cycles are still very much suited.)

What I missed out on, was to ask if it was possible to create additional layers parallel to the ones in the existing navmeshes, for the purpose of storing arbitrary data in it since I actually expect that datastructure to be highly optimized, rather easy to duplicate and considerably memory efficient when limited to the same resolution as the nav mesh and a depth of no more than 16bit. Also the methods for sampling at the position of arbitrary units as well as optimized methods for drawing to that texture on a large scale (without attempting to write every single pixel one by one) should already be in place.

But then again: Accessing native data structures from JS still adds a lot of overhead, and the fact that a callback based system is essentially single threaded with additional overhead from scheduling, doesn't make it any better. Batch operations can be sped up easily on the native side, but iterators implemented in JS are ... lacking.

So in short: No actual full conversion mods possible unless eventually a native moding API is created for the use on private servers.