Modding Requests from SupCom Modders

Obviously any kind of binary scheme (DLL etc) suffers from platform incompatibility and security issues.

Ok, so we need a way to save info persistently but it doesn't need to be normal file i/o.

Now that we mentioned WoW, I'd like to have some way to script map events, so I could make new game modes. Maybe even a script to generate the map in some way, put some waypoints, etc.

I'm thinking something like Strand of the Ancients battleground from WoW, the attacking team would have 30 min to complete a number of gated objectives while the defending team needs to stop them. When an objective is completed, the teams switch places. The winner is the one with most objectives completed.

I'm thinking something like an alien attack from outer space, moving on from the outer planets/asteroid rings to the inner planets/main planet.

Since I want speed, I'd like to give more resources to both teams so they can start faster, plus maybe allow insta-build of units or teleportation from other dimensions/hyperspace.

Yes. Ultimately, the actual form of I/O in question doesn't matter, as long as we can chuck in potentially large quantities of data and get it back out again (a virtual file system or smth would be fine). Super-ideally, we could do it in a cloud-based fashion.

You could use a localstorage-like thing for "file I/O" (which Google Chrome does)... for Chrome, its a SQLite database.

As for internet communications, I'd like that to be left to the player for confirmation / denial, as well as to which specific IP addresses / hostnames a mod can communicate with.

And mods that do network communication should come up with a warning / notice requiring confirmation / configuration on first-load... not something silently done in the background.

I'd like to see a lot of possibilities for mods -- you could imagine something streaming data to a tournament website, for instance.... or even some kind of 'galactic economy' mod (inspired by that other guy's post a while back).. though again, I think users should be given notice and option to override network transfer.

Or you could treat everyone as adults and consistently warn about, but not disallow, the downloading of non-sandboxed mods. Giving them an explicit nomer such as "unsafe" could work as a proper deterrent.

"This is an unsafe mod. It can break all your stuff and sell your house. Use it at your own risk and only if you trust the mod maintainer, DrEvil1337."

Stuff on my useful list would be:

• HTTP Requests (safe)
• open arbitrary TCP/UDP sockets (safe)
• open text or binary streams between any clients (safe)
• open text or binary streams between any servers (safe)
• run code asynchronously/non-blocking (safe)
• Parsing JSON / dumping JSON (safe)
• read & write files in the mod's own directory (safe)
• run any appropriate type of game/sim code (safe)
• read and write client or server game state (safe)
• load, generate, and display images, sounds, meshes (safe)
• write arbitrary files with current user permissions (unsafe)
• run arbitrary code with current user permissions (unsafe)
• start arbitrary processes / load modules (unsafe)

Quite frankly, I could forsake the unsafe stuff assuming all the safe stuff makes it in.

I'd still be bummed without a decent asynchronous library. And I also think that unsafe binary mods should not be excluded, just relatively rare.

I agree that real file i/o and network transfers shouldn't be forbidden, but the game should be able to discriminate safe mods and unsafe mods, and warn the players about the unsafe mods before he activate them.

I've seen people suggesting a permission based system elsewhere, so rather than just saying "This is dangerous" you say "This mod requires X, Y and Z, continue installation?" which is a little more informative. I agree with the sentiment though, I think it's better to have an expansive modding API and allow users to choose.

Sorry, but I completely disagree.

Auto-distribution of non-sandboxed mods means that the average user will still install them. Defaults are very important in security, because whatever the defaults are, the average user will follow. Remember all those warnings in Windows Vista? Everyone just clicked YES and OK.

I think your list has some good capabilities, but here are my suggestions:

• HTTP Requests (Permission Required)
• open arbitrary TCP/UDP sockets (Prohibited)
• open text or binary streams between any clients (Prohibited)
• open text or binary streams between any servers (Prohibited)
• run code asynchronously/non-blocking (Default?)
• Parsing JSON / dumping JSON (See comments)
• read & write files in the mod's own directory (Prohibited -- should be through a VFS)
• run any appropriate type of game/sim code (Permissions may be required)
• read and write client or server game state (Permissions may be required)
• load, generate, and display images, sounds, meshes (Safe)
• write arbitrary files with current user permissions (Prohibited)
• run arbitrary code with current user permissions (Prohibited)
• start arbitrary processes / load modules (Prohibited)

Communication between clients should be done strictly through the server, and clients should never know the IPs of other clients. If a mod wants to communicate with other clients with the same mod, this needs to be done through the server.

Here's a sketch of some permissions that came to mind:

• game.addunit - Can add a new unit(s)
• game.modifyunit - Can modify an existing official unit(s)
• game.modifymap - Can modifies map behavior beyond what the creator intended
• game.* - Can modify all aspects of gameplay (e.g., add veterancy, nuke-on-click, etc.)
• ui.* - Can modify all aspects of the UI (Potentially dangerous w/o a Secure Attention [Key] Sequence)
• storage.smallspace -Can write to a Virtual File-System with up to 1 megabyte of storage space
• storage.reservespace.$kb - Can reserve and write to $kb kilobytes of space.
• communication.client2server - Can send messages from the client mod code to the server-side mod code
• communication.server2client - Can send messages from the server mod code to the client-side mod code
• communication.http.server - Can send/receive messages to the game server IP/hostname via HTTP
• communication.http.specific.$url - Can send and receive HTTP messages to that specific URL (Potentially Unsafe)
• communication.http.* - Can send and receive HTTP messages to any URL/IP. (Unsafe)

As for stuff like JSON etc...

If they're using python, they can do either one of two things: a) Whitelist some modules (e.g., the json module).. but this MIGHT lead to some sandboxing issues depending on how sandboxing is implemented in PA, or b) Create a wrapper around functions / capabilities in certain modules

So basically, if you want to use sandboxing in your code, you should be able to just literally write it as though you were writing a python script.

As for non-blocking/asynchronous stuff, I would assume that this would be the default... but yeah, if not, there definitely should be room for that.

You don't need the IP to open binary/text stream between clients. You can use, say, SteamID. I see no fundamental reason why there should be no communication between clients that does not go through a server, nor communications between servers. Also, using a VFS is why reading and writing to a limited area should be allowed, not prohibited.

The others can be permitted with permission from the user.

Those kinds of warning are already going to be part of it as we are just going to *try* and sandbox them. Whether we are successful at it is another matter. Seriously though, security is a huge issue here. We'll do our best to give you guys good tools without causing a danger.

Anyway binary mods are pretty much out because of machine incompatibility. Mods needs to work on all the platforms which implies any coding will have to be either byte-code or compiled on the fly.

Glad to hear you guys are taking security into account early on! I'm looking forward to the modding environment once this game gets going.

Question: Can we expect to see a modding API present in alpha and/or beta builds?

Certainly something will be possible at that point. I'm sure I'll release little tidbit along the way as well so people can prepare. For example it's extremely likely that our tools will still be using filmbox as a model input format by the time the game launches.

Is this avaiable again too? http://cloud-2.steampowered.com/ugc/540 ... 5A8A261F2/ :mrgreen: