Modding compared with Sup Com

Perhaps premature, but I'm interested to know if we can expect modding to be similar to that of Sup Com (using LUA and similar model formats), or if mods and units be structured completely differently.

Anything neutrino or another dev can tell us about plans for modability, compared with Supreme Commander?

I intend to start work on a community bugfix patch as soon as I get my grubby paws on the beta Every scrap of useful work we can put in can save time and money for the developers to spend on areas we can't access.

Different engine and it doesn't use LUA.

Well, I guess I expected it not to be the Moho Engine. I mean, it would be a tad out of date by now. Plus, the whole rights thing. But I'd be glad to use a real language/environment like C++, it was a bitch having to deal with the engine from Lua in Moho Engine.

Thanks neutrino, is it possible to let us know what scripting/other languages & tools we should start skilling up on?

Or Python, if possible.

.. or just something mainstream

I'd suspect, personally, that there will be no scripts and any mods will be written in C++.

I'd be surprised if that were the case, given the definite "pro-modding" vibes they are giving.

I'd like for some kind of sandboxing/restricted-subsetting to occur as well... so I'd be against limiting mods to binaries.

While I'm sure 99.99% of the community will have the best intentions when it comes to mod development, having a permission-based structure and sandboxing code will go a long way to ensuring security and reducing malware.

There's NO reason new units should have any access to the internet or my harddrive, as the only file/communication I/O it'll need is communication with the game itself.

Edit:

With a well-done permissions based and sandboxed system, it should also mean that players can connect to a modded server and be able to download the mods necessary to play right on the spot (like Tribes).

Well, it may surprise you, but IMO binary is the most pro-modding approach.

It's cheaper to expose APIs, because you can just expose your internal APIs, no wrappers or glue codes. Especially with a garbage-collected only language like Lua, wrappers and glue code can be a serious headache. Let some helpful modder like myself or BM, who are more than capable, write a script exposure to whatever languages are in demand, instead of making Uber pay out of their limited budget to do it.

C++ code executes much faster and is much more reliable than script. This makes it more viable to write mods in C++. The simple fact is that non-deterministic garbage collection is not very conducive to game code, and RAII is. There's a reason why most engines are in C++. Also, real exceptions.

A C++ program can access the operating system or do anything you want. A Lua script can only use what's provided by the engine. For example, a mod written in C++ could utilize concurrency. It could perform arbitrary I/O- stat tracking, say, or LiveReplay-style functionality, or live video casting. It could do virtually anything you want, with relatively little effort on the part of Uber. They don't have to waste their time exposing file handling APIs, etc, because C++ already has file handling APIs. There are vastly more pre-existing libraries for C++ than you could find for Lua to work in your own personal sandbox.

Oh, I totally understand the many big advantages of C++, but it's a less friendly language to deal with for modders compared with the simpler scripting languages, and that will limit the modding community quite substantially (depending on the requirements for adding 3rd party units, of course).

TA's unituniverse (http://units.tauniverse.com/?p=all) alone has over 4000 units whereas Sup Com came nowhere near that amount - I'd say due to the much higher barrier to entry. The easier it is to mod, the bigger the community it can build, and that can only help the game.

I don't know enough about the relative advantages and disadvantages to say which approach they should take, and personally I'm fine with C++, but I'd imagine many casual modders would lose interest in modding if they see "C++" as a requirement.

If you expose C++, then you, me, BM, Neruz, or all of us can write an exposure to script ourselves. If the devs expose C++, that doesn't mean we actually have to use C++. The same is not true if the devs expose Lua.

The main reason TA has way more units than SupCom is because the art assets of SupCom took far longer to create, due to the much more high fidelity and complicated art.

I can vouch for this first hand, the higher fidelity required for SupCom units ended by being a pretty big reason when there are fewer big unit mods, there just isn't enough artists to go around.

Mike

Actually yeah I agree. I was shielded from this a bit, since most of the assets for my mod already existed, but the models were still the bigger part of the work.

While allowing for C/C++ extensions to the game would certainly allow for vastly more powerful mods, it comes with significant downsides as well:

• Source code not distributed with mods => can't easily sandbox code, can't ensure that code is limited in functionality, can't enforce permissions
• Buggy code can bring down the host system, cause memory leaks, etc.
• Speed increase will have marginal, if any, effects on anything other than AI

I'm not against a dual-approach, where binaries could be used to really transform the game into something else, but I think the primary path for modding should be through an interpreted scripting language based on a subset of Python or JavaScript or something otherwise familiar and mainstream.

Combined with sandboxing and permissions, this would allow for users to download and install most if not all mods easily and without worry, and could allow for clients to automatically download and run mods when they connect to modded servers (assuming the clients agree, and the servers are set up to distribute the mod content).

Presuming that the vast majority of 'mods' will be new units with potentially new and interesting capabilities, it would be nice if I didn't have to expose my entire computer to every unit creator out there whenever I install and run a new unit.

So could Lua code in the Moho Engine.

That's not true. The source code doesn't *have* to be distributed, usually, but there's no reason that you can't only download mods that are open source, or only from someone you trust. Or Uber just runs a server which is used for downloading mods, and you can only upload to them if you upload the source too.

Hell, most applications running on everybody's machine do not have public source code.

I mean, if you're running a server, most such things already run in their own dedicated virtualized environment. If you have trouble, you just re-image it. The viability of infecting such a thing with a virus is minimal.

That may be true of Lua, but not for all embedded scripting. For example, embedded python does not have memory leaks, and has the same exception handling that non-embedded python has.

The arguments for 'open source' and 'only from people you "trust"' are not sufficient for preventing poorly-written code from causing problems, or for preventing malware. Even if you were to scour the source code of a C/C++ app, the only way to verify that the binaries you received were the same would be to compile it yourself.

The proper way to ensure safe, malware-free mods is to force mods to run within a sandbox and to force mod-developers to request permissions for their mods on-install, whereupon end-users can then decide if they want to install the mods or not. This is also because end-users will need to install mods locally, and there are many legitimate arguments why malware on servers is just as bad, if not worse, than malware on desktops.

It is possible in all languages to create memory leaks. Even garbage-collected ones. Especially when you have the capacity to call into native code.

That's really not a big deal.

Yes, it does give a greater guarantee. However, you need to remember what it is you're trying to protect against. People who want to infect your machine with viruses can find much easier attack vectors than through mods for a game. I mean, the potential targets is, at maximum, what, ~10% of the playerbase? At best? That's a really bad return on investment. Even if there were malicious mods going around, that would be only the tiniest fraction of all mods. I've never heard of viruses distributed through user-created content. In return, you seriously cripple the kind of mods that can be made, and how easily they can be made.

Not to mention, as I said to raevn, if this turns out to be necessary, it can always be added at a later date. It doesn't have to be out of the box.

The problem you are trying to prevent is, as far as I can tell, basically theoretical in nature, and not a real problem.

Sure, if you're calling native code through an API and the API calls don't release memory after being called, then obviously a mod could "cause" memory leaks.

But really, at that point we're criticizing buggy code from the developers of the game, rather than the modders...

Having a sandboxed, permissions-based system allows for players to automatically (or semi-automatically) safely install many if not most mods without needing to worry about who wrote the mod, or what the mod code actually does, or if the mod code is buggy, etc.

This allows players to jump into modded games without having to leave the game interface, and it also encourages people to try out new mods and 'game mutators', as well as trying their own hand at writing their own units.

For example, unit mods would use a permission such as "Adds new unit(s)", a mod that changes how existing units work might use a permission such as "Modifies existing unit(s)", and a mod that sends statistics back to the internet would use "Communicates with the Internet", etc. Depending on how this will be done, maybe users can even choose to opt-out of certain permissions.

Anyways, the point is, having fully sandboxed and 'safe' mods encourages users to try new mods, encourages greater mod adoption (through both self-install and through discovery via joining modded servers), and prevents both buggy as well as malicious code from damaging end-user systems.

Combining a system like this with a lower-barrier-to-entry scripting language for modding would also allow for more users to write their own mods. Depending on the particular approach that Uber Entertainment wants to take (e.g., in-game unit design and scripting), this could really boost the modding community a lot.

This kind of thing (as with all things security..) should NOT be a last minute or post-release decision, but rather should be incorporated during the development of a modding API.

(On that note, if in a year, the modding interface is a C/C++ interface without this, I'd be happy to collaborate with you guys on a script-based, sandboxed modloader system for the masses)

No, you misunderstand me. Any language, even GC, can create leaks without the help of external code. It's simply more likely when they depend on scripts to free native resources as well.

Is the first mod most of us would create (and we would, of course, collaborate). Binary mods would be the exception, not the rule. All I'm saying is that, in my opinion, having that capacity is important.