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.