Sandboxing code in C# (for AIW2 dll modding)

[keith.lamothe]

Do you insist on c# scripting? Sandboxing something like lua or javascript might be easier. Or even python.

My core goals:
1) Be able to write any part of the game rules in "external" code.
2) Have modders be able to see how I wrote those rules and be able to rewrite them with the same tools I used.
3) Not increase cpu/ram cost of my implementation more than, say, 10-15%.
4) Not increase development time of my implementation of those rules more than, say 20-25%.
5) Not increase development time of 1.0 as a whole more than 5%.

I considered lua for a while, and stuff like that, but those fail 3, 4, and 5 pretty hard. C# passes them all just fine, so while I care about security and ease of installation I won't let them overrule everything else.

Can you give me an idea (if there is a pre-kickstarter document feel free to point me to it) as to what do you want to achieve. In particular, why custom (mod) code would need to be called that frequently?

The clearest case is the function where a ship takes two eligible targets and decides which one it prefers.

Or, more broadly, the logic which takes a ship, builds a list of eligible targets for it, and then sorts that list by preference.

These things happen very often.

Less frequent things would be like mapgen. Or the function which takes the entire ai "side" and has each ship decide where to go. That can take a few seconds and happens on a separate thread.

[zespri]

The clearest case is the function where a ship takes two eligible targets and decides which one it prefers.

How does it do it? Presumably in the simplest keys, each of the targets have properties, and it will compare a property of first target with a property of a second target.
Does this sound right? I'd like to get down to something measurable here.  (Point 3).

Understood your point of being uncomfortable with lua/js programming (poitns 4/5).

[Cyborg]

C# mods is fine by me. The Linux folks have some extra hurdles, though. Honestly, the very fact we are getting modding is going to completely make this game bananas. It will be completely awesome. If steam works is not supported, I think we should get something going on Nexus mods to ease some of the installation burden. Or some kind of mod pack.

[Aklyon]

We wouldn't need a mod pack, just a functional mod manager or launcher.

[eRe4s3r]

C# mods is fine by me. The Linux folks have some extra hurdles, though. Honestly, the very fact we are getting modding is going to completely make this game bananas. It will be completely awesome. If steam works is not supported, I think we should get something going on Nexus mods to ease some of the installation burden. Or some kind of mod pack.

Assuming we can replace graphic and sound assets a lot easier than we can replace game core functions Nexus would be acceptable, but dll mods are gonna be a tiny niche (and a security problem) no matter how you look at it. I wouldn't download random DLL mods from this forum nor from the nexus tbh... and sandboxing externally loaded dlls is not an easy thing to do right. And can very easily make otherwise possible mods impossible (like persistent progression - saving stuff into mod directory xml or what)

Also with the way I understand this works, we would require someone to merge mods... if we had more than 1 ;p Because I know from KSP what a huge performance penalty even -1- slightly complicated external dll can be.

[Draco18s]

And can very easily make otherwise possible mods impossible (like persistent progression - saving stuff into mod directory xml or what)

The sandbox would still have access to the game's own directories.  That's part of what this thread is about: preventing access to system files.

[Cyborg]

C# mods is fine by me. The Linux folks have some extra hurdles, though. Honestly, the very fact we are getting modding is going to completely make this game bananas. It will be completely awesome. If steam works is not supported, I think we should get something going on Nexus mods to ease some of the installation burden. Or some kind of mod pack.

Assuming we can replace graphic and sound assets a lot easier than we can replace game core functions Nexus would be acceptable, but dll mods are gonna be a tiny niche (and a security problem) no matter how you look at it. I wouldn't download random DLL mods from this forum nor from the nexus tbh... and sandboxing externally loaded dlls is not an easy thing to do right. And can very easily make otherwise possible mods impossible (like persistent progression - saving stuff into mod directory xml or what)

Also with the way I understand this works, we would require someone to merge mods... if we had more than 1 ;p Because I know from KSP what a huge performance penalty even -1- slightly complicated external dll can be.

For what it's worth, you could trust my dll's. But yes, I would agree with you. I think that the code needs to be provided and able to be compiled by the user.

[keith.lamothe]

How does it do it? Presumably in the simplest keys, each of the targets have properties, and it will compare a property of first target with a property of a second target.
Does this sound right? I'd like to get down to something measurable here.  (Point 3).

Yea, it's just a bunch of property comparisons. This article has a lot of the details from the "normal" target-sorter (engine-damage-priority stuff uses a modified version, as do some other types) : https://www.kickstarter.com/projects/arcengames/ai-war-ii-0/posts/1763996

C# mods is fine by me. The Linux folks have some extra hurdles, though.

Linux folks would need to use MonoDevelop or something like that for their C# IDE and compiler, which isn't as nice as Visual Studio on Windows, but they can definitely still write and compile C# that runs on all three platforms.

Assuming we can replace graphic and sound assets a lot easier than we can replace game core functions

It won't involve messing with dlls, and music will still be a directory you can change as you see fit (though we'll probably add support for multiple music folders that turn on/off with their respective mod), but graphics and sounds are baked into the unity .asset bundle now, as otherwise it takes absolutely forever to load them off disk. There's probably some alternate loading method we can use to just grab a texture and mesh off disk for when you're testing something, but even there we haven't worked out the workflow. And presumably before publishing a mod one would want to bake the assets (into a separate bundle for that mod, not stomping on other stuff); presumably this can be done with Unity Free, but again we haven't worked out the workflow.

If y'all know of other unity games using the .asset bundles for graphics/sounds and allowing modding of those, I'd like to know about them and how they do it. I don't anticipate it being as big a bear as working out this dll workflow (actually doing it was easy, securing it is a fool's errand apparently) but it would probably save me some time finding the examples, and if you know of such unity games where the mod support is actually good to work with in your experience, then that's very helpful info I wouldn't be able to find myself.

Also with the way I understand this works, we would require someone to merge mods...

No, I don't think so, because these would be external dlls, and the external dlls only get called when the xml tells the game to do so. So your xml would reference your dlls, and the other guy's xml would reference his dlls, and whichever mods you had enabled would determine which xml is in the game. It's possible you could have different behaviors that don't make sense together, and if you both replaced the targeting algorithm for the Bomber, or whatever, then you'd have a conflict in the xml. But in general merging would only be necessary if you were both trying to modify the same thing in different ways.

Because I know from KSP what a huge performance penalty even -1- slightly complicated external dll can be.

The mere presence of extra dlls loaded at runtime doesn't bog things down. It's all a matter of what they're doing. And if they're really bogging things down they'd still do that if they were combined into a single dll.

The sandbox would still have access to the game's own directories.  That's part of what this thread is about: preventing access to system files.

I don't think I'd let the sandbox do any File IO if I could help it, and just provide some kind of call it could make that the game's normal app-domain would later consider writing out for you, so you could do persistent state or whatever.

But at this point I still haven't found any method that will prevent file io by any app-domain in a unity game. I'm moving on to the gui workflow for Blue and I.

I think that the code needs to be provided and able to be compiled by the user.

Yea, I tried very hard to build in an environment where you'd just get the source code, and then the first time you ran with that mod enabled the game would compile the code into a mod (and if you changed it and restarted the game it would recompile it). I tried the old CodeDom approach, but unity's version of mono needs mono.exe installed on the system for its replacement for that to work. I tried the Mono-Compiler-Services appoach, but that appears to have the same restriction, and I tried Roslyn, but unity's version of mono isn't new enough to run it.

So there are various things I could do for the mod tools but they would likely be windows-specific (and exclude older stuff like XP, which the game doesn't exclude) and require a particular version of .NET . And why add that restriction when modding itself doesn't require it?

I'd like to just bundle gmcs (mono's compiler) with the game and have it be run by an external mono app, but at that point why on earth are we doing so much work when the simple approach that only cares about runnable code... works? I'd still like to require the distribution of source with the dll, though, so maybe I'll have to revisit that.

[Cyborg]

Something to think about. But in general, most of the savvy folks are not going to be installing some anonymous person's DLL blind.

[Draco18s]

Something to think about. But in general, most of the savvy folks are not going to be installing some anonymous person's DLL blind.

Just for reference, Minecraft mods can do all the same stuff a random DLL can.

Sure, it has to go through the JVM, but it can still read and write files anywhere on your computer, it can still read the keyboard, it can still download files from the internet, and still execute external programs.

[Cyborg]

Something to think about. But in general, most of the savvy folks are not going to be installing some anonymous person's DLL blind.

Just for reference, Minecraft mods can do all the same stuff a random DLL can.

Sure, it has to go through the JVM, but it can still read and write files anywhere on your computer, it can still read the keyboard, it can still download files from the internet, and still execute external programs.

And I don't install those.

[Mad Rubicant]

Have you tried doing a whitelist of permissions instead of a blacklist, as shown here: http://stackoverflow.com/a/26287330?

[eRe4s3r]

Assuming we can replace graphic and sound assets a lot easier than we can replace game core functions

It won't involve messing with dlls, and music will still be a directory you can change as you see fit (though we'll probably add support for multiple music folders that turn on/off with their respective mod), but graphics and sounds are baked into the unity .asset bundle now, as otherwise it takes absolutely forever to load them off disk. There's probably some alternate loading method we can use to just grab a texture and mesh off disk for when you're testing something, but even there we haven't worked out the workflow. And presumably before publishing a mod one would want to bake the assets (into a separate bundle for that mod, not stomping on other stuff); presumably this can be done with Unity Free, but again we haven't worked out the workflow.

If y'all know of other unity games using the .asset bundles for graphics/sounds and allowing modding of those, I'd like to know about them and how they do it. I don't anticipate it being as big a bear as working out this dll workflow (actually doing it was easy, securing it is a fool's errand apparently) but it would probably save me some time finding the examples, and if you know of such unity games where the mod support is actually good to work with in your experience, then that's very helpful info I wouldn't be able to find myself.

I know of none. All unity mods are either based on direct edit of assets bundles or loose files with directory structure (which by the way necessitates unpacking the games original assets, since you can't mod what you don't know is there). The big outlier is Cities Skylines which has a very very fancy integrated package creation and loads mods packages, but it has an integrated mod manager and in-depth steam workshop integration.

Fun-fact, you can't easily mod (add) sounds (not music) in Skylines at all ;P And it gets even more problematic when you wanna edit fonts, strings or GUI in general. If it works through Unity Free then that would be fine I guess, but again, you need to give modders a usable example for the workflow.

My disdain from Unity comes directly from the fact that so far, no Unity game really was moddable the big exception would be KSP, but KSP was really more hacked apart and extended/overhauled than modded. The way DLL mods work is absurdly dangerous (there is zero sandboxing, especially of network traffic) but at least there are trusted dependencies now, there were plenty of malicious dlls though.

It's important to remember that moddable and adding new meshes are 2 entirely different things to a modder. Skylines allows you to add new buildings, but it has very few moddable elements aside that. DLL mods now figured out how to inject in the road/traffic parts of the game, but again, we are talking about DLL mods, with all the problems these entail. KSP is the opposite (to me) it has tons of trusted DLL dependencies, and people use these and build upon them their mods. KSP itself? Is still moddable, adding new parts is easy, adding new meshes is however not. But this is primarily due to KSP using a really iffy (and horribly slow) loading system ;P

With Skylines in Steam workshop, there is also ZERO oversight over malicious dll's, but Skylines does somehow restrict "plugin" with versioning and some methods blocked afaik. But yeah.. dll mods are not safe

Minecraft mods are also a big problem, obviously as it is Java, but big (many millions dl's) modpacks are fine.


Anywaaayyyyyy.... Modding isn't easy to support. Easiest would be xml files and obj / dds  ;p Anything that obfuscates (like package files) is by default not helping modding. To know how to add a new unit, we have to see how to actually do that and how it was actually done, after all. Thinking about this in terms of workflow might be much better approach. Define workflows for each element of modding you wanna support (adding new ships/buildings to the AI) (adding new AI) (changing AI loadouts) etc. and then try to unify and condense these into workflow that a modder can follow without access to source files.


Btw. @ Keith
Mod Merging would be a thing if mods add 1 new AI (with new ships, behavior) etc. and what now, if we wanted to use 2 such mods? ;P Targeting behavior has to be merged and expanded for 2 new AI and new ships, no? If I loaded both, then whatever is loaded last would override targeting changes of the first? Mind you, that is theorethical, in reality we'd probably have cooperation between modders ;P

[Aklyon]

And then theres stuff like Xcom2 having with a modding download as large as the game itself, and the game alone is 40gb.
Modding is complicated.

[eRe4s3r]

And then theres stuff like Xcom2 having with a modding download as large as the game itself, and the game alone is 40gb.
Modding is complicated.

Only when you use engines without making modding a thing you want to support. Skyrim modding is not (per sé) complicated, and adding meshes to Skyrim is perfectly doable with a short read of the tutorials and 1h of time to understand them. Heck it took me a few hours to import a skeleton, modify existing clothing and fix a few animation issues I had (with cloaks) and adapt them for various body types of other mods including advanced skeletons...  modifying the game world is basically easy, doing anything worthwhile with the creation kit obviously is not.

Divinity Original Sin had this problem, super fancy editor, but it was heavily restricted by not giving us any of the game scripts and a tutorial which didn't even explain how to have a mod behave like the original GAME. (when you create a new mod, it is essentially a new game within that engine, not a mod of the vanilla game, because the game doesn't exist as such, the entire campaign, scripted to the core, is "the game script"). As you can imagine, this killed D:OS modding entirely. I have never seen a game with worse mod support than D:OS, even though it had one of the best editors I had ever seen. And that is saying something ^^ Documentation and workflow are absolutely vital for modders. If I can't figure out how to do something then how would someone fare who just wants to experiment with a few minor changes and gets addicted from there?

Modding is not complicated DLL modding however is far beyond my abilities ^^

And to give you an example, just a few weeks ago I modded ARCC for Anno 2070 for myself (changes a few values that I found weird). What did that take? RDA explorer, unpack, edit xml files, repack -> replace -> done. Despite that, there are only 2 mods for Anno 2070, and that is because while this action (modifying) is easy, creating something new was not explained, detailed, and for modding we still have to use the hacktool (annocookie) to even play the game properly... ^^