Will was gracious enough to spend some time recompiling UA into C# for us on a mod-branch which is now actively accessible on the main Underworld Ascendant app. You can switch to this at any time by right-clicking Underworld Ascendant on Steam, selecting “Properties,” then the “Betas” tab, selecting “mod-friendly” and then the Close button.
He also put the Challenge of Ishtass and the Split Ruins of Gwern level back in for your purposes, since some of the larger levels were harder to decompile.
Note that to access those two latter levels, you’ll need to be able to use the dev console.
When launching Underworld Ascendant from Steam, you’ll need to set your launch options to “-console” from Properties and then play the game. While ingame, you’ll now be able to access a dev console by pressing the Shift and ~ keys simultaneously. There are a couple of mod menus we’ll let you browse. @Dewi_Morgan, you’re free to distribute the mod commands we taught you if you need them as well.
Neither, as I understand it. It’s a version that was not compiled to C++, but rather C#.
That lets us mod it and view the source, but it’s the source from the bytecode, so no comments, and some variablenames are generic rather than specific.
It gives us all we need for modding, but is one step shy of a full source release.
This is the least we can do, short of a full moddable release, which we wouldn’t have the development tools or budget to squeeze in.
The dev console access allows you to do some minor modding, if you need it at any point in your adventure, but it’s not open to much customization. Most of it was for QA purposes. (The invincibility cheat is probably the one I used the most often, shy of the teleportation cheats.)
As to Csimbi’s question, I don’t see why not, but you would probably need to insert your own levels from Unity and mod it to the game. You can use some of the given models though, which might be fun… I wish we had more Meridian time in the main campaign, for example…
So far, I’ve been able to insert and modify objects and game logic. I see no good reason why we couldn’t do more, adding levels and NPCs and so on.
In theory, there’s essentially no limit to what we can do, but:
there’re things we likely don’t want to do, since doing them will likely force OSE to withdraw support for modding. But anyone who’d make a “hang the black guys”, “gas the jews”, or “rape the babies” level is unlikely to take the community’s advice on this, so…
More likely and relevant: there’re still some challenges around asset manipulation, in that the assets are all packaged, and the extractors I’ve found so far do an imperfect job. So for example I don’t know yet how to edit the fabric of an existing level, the static ground and walls.
Dewi…would it be possible (if you can tell at this stage) of adding NPC dialog trees etc? Of course, this would mean a colossal amount of work when you factor in the story elements, overall arc, and testing elements etc…
You can add new methods and classes, and also wrap code before and after any method in the existing source tree, so… yes, absolutely :) Like you say, it’s work… but there are no unreasonable extra hoops to jump through to do that work, over and above adding them to any other game, even if we had full unlimited source access.
It’d involve speech UI changes, and loading in some kind of dialog-tree resource file. Then as stretch goals there’d be things like adding voice acting audio resources in, and getting lipsynch working, which mostly wouldn’t happen unless the project had a champion.
I’m working on another free-time project at the moment, but hoping to have that nailled down in a couple of weeks. Then I want to return to UA modding: since they’ve bent over backwards to make it moddable, I really owe it to them to help make modding as easy as we possibly can.
That sounds great.
I’d like to replace the convoluted controls with simple (absolute) controls. I.e. remove acceleration/deceleration, choppy controls, dying hitting edges or bouncing (taking flight) off of stairs, corpses and whatnot.
How would I go on about doing any of that? (rather, how would I try starting doing it and testing the code changes?)
As I remember the control system is managed by a library that handles key remapping and controllers, so hooking into it takes a bit deeper understanding than just using the usual C# commands to check the keyboard state and moving the character if the keys are down, but is probably possible.
Basically, you’d install and use dnSpy to figure out the layout of the code and where things need changing, and to test that your changes work. That’ll get you 90% of the way there, but the last 10% gets funky, because while dnSpy lets you change any code anywhere, writing it as a plugin means putting code before and after existing methods, rather than changing those methods, so converting your proof-of-concept code to a plugin that you can then compile as a DLL in Visual Studio will take some work.
I’m still hoping to document that “last mile” bit in more, but in the meantime I’d recommend getting started with dnSpy - it has its frustrations but in many ways is honestly more of a joy to use than the IDEs I use at work, with a faster turnaround.
But you’re going to have your work cut out, making the controls behave differently. Remapping them, as Sandro asked, is only the start. Changing the behavior of the physics engine on your character controller object is a whole other kettle of fish. I wouldn’t say it’s impossible, but there’s likely no simple place in the code where you can just say "change the forward key to be “move forward at B units/sec”, instead of “accelerate by A units/sec/sec, with a max velocity of B units/sec”. There almost certainly isn’t ANY code about what happens around collisions with stairs and corpses; that’s going to be magic from the physics library, and changing the behavior would in many cases mean changing the physics of the world and its objects.
As a vague general rule, which doesn’t always hold: game features that are subjectively bad, just a matter of opinion, are probably by design and can be easily changed. Any objectively bad features would’ve been fixed if they had time, so it’s likely that fixing them will be an exercise in deepest rabbitholes and hairiest yak-shaving.
Update on this project: I originally set Nov 1 for looking into modding this again, because that was the deadline for my project at work that was taking up all my time. However, on releasing the project, my work promptly laid me off.
So, I’m afraid I’m putting modding work on the back burner, at least until I have found and settled into a new role. I don’t feel I can commit to anything else that might eat into my time until then.
Sorry about repeated delays. But I’ve documented everything I’d looked into in the comments above, if anyone else wants to take up the modding mantle before then :D