Give Feedback
Hi all, Mgamerz here. After reading CreeperLava's excellent post on the history of ALOT, I decided to write one for Mod Manager and ME3Tweaks. It's going to be decidedly less exciting, as both of these have mostly been projects I work on alone, but hey, why not ;)
The land before time
As a bit of pre-history to my work on Mass Effect 3, I used to mod MegaMan Battle Network games. I was part of the modding scene on The Rockman EXE Zone back in 2007, as member 328. We performed amateur reverse engineering on the ROMs (mainly MMBN6), deciphering binary data formats so we could write custom battles and make patches. It was exciting - though I had literally no idea what I was doing. We learned as we went. I wrote many guides on how to mod the game, mostly through a memory editor that lost changes when the emulator restarted. It was fun. I'm still loosely affiliated with TREZ these days.
Part of my BN6 "attack sequence" address list. I would later learn that these were function entry points.
I actually went back and did some advanced modding on MMBN3 in early 2017, as it's one of my favorite games. I used what I learned modding ME3 unrealscript (and from my CS degree) to learn how ARM and THUMB instruction sets worked on the GBA. I wrote some new assembly code for it, and developed a symbol table for MMBN3 White. I learned how to hook subroutines so I could hijack program execution to run my own code.
This one was fun, learning how to dynamically spawn new enemies, and writing brand enemy strats.
I also developed a game in Game Maker 6 and 7, and while it never was finished, it taught me a lot about basic game design, and GML was my first programming language I learned. It was a great introduction to programming, and I think it would be a great program to help students dip their toes into programming these days. It was much simpler in GM6 compared to the versions they support today.
So modding ME3 was not the first time I've been in a modding scene, nor was it was my first software rodeo. But I would say it is my first professional grade one.
In the beginning
Mass Effect 3 Coalesced Mod Manager (ME3CMM) was first conceived in late May 2012. The first time I ever played a mod for this game was in April 2012, in multiplayer on Firebase White. It was a zombie mode mod - only husks spawned, and there was probably like 80 of them. This was hosted by some random player in a public lobby - I guess not cool, but then again, if it didn't happen, I might not be writing this article, eh?
My poor laptop was not able to deal with it well, and I think it actually overheated and froze (it had terrible heat issues). Still, I thought it was fun, so I looked around for ways to reproduce this. The host in voice chat said it was a glitch - clearly a lie, but not one I knew at the time. I found a few guides on how to edit the coalesced file - essentially a serialized configuration file that was used to make sweeping changes to the game (that would be much slower to balance test if baked into game files) via simple text editing - but there were no guides on how to edit waves in MP.
BioGame.xml, decompiled with TankMaster's compiler
After doing some exploratory research on some of the MP stuff, I designed a few coalesced files. Mostly simple edits - slightly beefier enemies, more enemies, lower gravity - the simple stuff. This quickly became tedious as I had no idea what was installed and I hated dealing with renaming files to Coalesced.bin. I was a university student at the time, with only one "real" language barely under my belt - Java. So I started development of a Mod Manager in Java Swing.
ME3CMM OG - That lack of 5 pixel borders I always use is triggering me on the app sides.
The overall main window design is still very similar to today's - but it's far uglier and barebones. Mod Manager 1.0 literally could only do coalesced swaps, and that's it. You would have a folder with a Coalesced.bin file in it and a moddesc.ini that changed the mod description panel. It was pretty much a file copy tool back then. Still, it made my life way easier for modding, so I cleaned it up a bit and shared it on my blog (detailed below).
In the beginning, I knew nobody who had this game. So testing my mods and getting feedback was not possible. I could ask, but where? I didn't want to give up my identity and get banned. So I did something that probably offends some people - I played my mods in public lobbies. I didn't go full ham in my mods - I did tweaks that a person might think was a mod, and that they'd message me going "was something up in that game?". A two shot nemesis, and extra enemy, slightly different gravity - something you could think was lag, but could be more. The more interested users would message you. And one of them eventually did, and their name started with X. And so, I found my first tester.
The start of ME3Tweaks
ME3Tweaks, which is essentially the name I put all my modding work and services under, started in May 2012 with a post on a blogspot blog. It detailed a very basic modding guide for coalesced. I chose the name FemShep as my modding name for the scene - originally so that it would be hard to google, in some naive attempt to stop BioWare from identifying me as easily. (Apparently I did not think that they could just check server logs for irregularities). Now it's kind of a hindrance having low google-ability, so I've shed the name FemShep and gone back to my original alias Mgamerz.
Ah, it reeks of age.
ME3Tweaks was a blogger blog for 2 and a half years until I got a real hosting site - but we'll get to that later. Sometimes when I google I can find my "oh hey check out this site" post on the gaming stackexchange, where I first advertised ME3Tweaks to the world.
Mod Manager 2
ME3CMM was pretty barebones for a while. I may be remembering the dates wrong, but I learned about ME3Explorer in November 2012, coming across its forum when trying to google some modding stuff. Back then it was lead by WarrantyVoider - a person with still unbelievable modding and research skills. I remember he would write posts and I would literally have no idea what he was talking about, it was leaps and bounds above than I knew.
ME3CMM 2.0 - Ah, my classic 5 pixel insets.
Eventually, ME3Explorer gained the ability to do SFAR editing in what I think was early 2013, which greatly expanded what could be modified - significant limitations of the coalesced modding had come up as BioWare added DLCs. DLC for Mass Effect 3 was all contained in a single SFAR file for each DLC. SFAR files are like zip files, except propietary, so someone had to figure out how to edit them. Every DLC has their its own coalesced file - which are all processed and applied after the main one. Without the ability to override or modify DLC coalesced, some things (such as the entirety of wavelist editing) became locked out.
I forked ME3Explorer at this point to add some automation to DLC injection. Knowing pretty much nothing about .NET or C# at the time, I just hacked in some UI automation so Mod Manager could call it from command line arguments. Instead of calling a true command line program, it literally booted the interface and programatically clicked everything. The UI was actually never shown, because the program would exit before the main drawing thread could execute (because all the work was forced to be done before the screen would draw). It was a gross and dirty hack, but Warranty Voider seemed fine with me shipping a fork, so I did with Mod Manager 2.
Mod Manager 2 came out in 2013, and was heavily inspired by Slipstream Mod Manager, the mod manager for FTL: Faster Than Light. Mod Manager 2 supported DLC editing as it's main feature, with some under the hood improvements. You could replace any file in an SFAR, and it would stuff the new file in and change the pointer of the file to where it was in the SFAR. This significantly expanded moddability with Mod Manager, and my work on MP greatly expanded due to the ease of one-click installation of changed files. Back then, replacing files in SFARs was extremely tedious. We didn't know you could unpack DLC at the time. Automating this took a huge amount of work out of developing mods.
Mod Manager 2.0.2 was where I took a break from ME3 modding for about a year. Battlefield 4 was out, and I played that game to death.
Web development
In my final semester of college for my computer science degree, I took an elective course in web development. We were required to build a web site without a framework that could have user input. Originally, I was just going to make a comment system for my guides. I was setting the bar pretty low.
No more new content. Huh.
That plan lasted about 3 days when I completing coding to my scope. It's really unbeleivable how much work you can get done when you're in an Art class and pay 0 attention. I needed something to keep me busy - the previous semester I took four(!) CS classes in one semester, this one only had two. Protip: Never take 4 upper CS classes at the same time. It was brutal. I literally started my final project for my Operating Systems class a day after it was due and took an immediate 20% hit on my grade.
A screenshot of ME3Tweaks' homepage in development, ~October 2014
I liked tweaking stuff in coalesced, but it was time consuming and very easy to forget what you've done. It was also not user friendly at all, and as someone who loved having a good user experience, I thought maybe I could mock up a way that could be user friendly. So I decided I was going to add a small proof of concept to the my site that you could input data into, that would be stored in a database. Eventually this data could be output in some format that could be used. It would act like an online web app, but I didn't actually plan on making this ready by the time I was done with the class. So I set to work and made it, and within about a week, I had a very basic version of ME3Tweaks ModMaker's editor in place.
Oh you, CSS.
The basic part - editing gravity and the number of enemies in multiplayer, were done. You could make user accounts for ModMaker, make mods, fork mods, etc. I got bored pretty fast just making some mock up version of an app I kind of wanted to build, so I started fooling around with the code in Mod Manager to see what it would take to parse server input and make a mod from that. Spoiler - way more than I expected.
Mod Manager 3
Mod Manager 3 was a significant rework of Mod Manager - many things under the hood changed or were completely swapped out. The entire installation engine was redone, while I made sure to maintain backwards compatibility. I also added basegame file file changes so you could edit more than just coalesced in the original game. After what took probably a few months of coding - I had a basic implementation of a compiler that could take my server side output and generate a mod from the information, which I called ModMaker Compiler. The core code of ModMaker Compiler today is still from this version.
Development version of Mod Manager 3
ME3Tweaks.com launched with a few guides I wrote in my spare time while I worked on ME3Tweaks ModMaker. On the presentation day of my web development class, I put ModMaker into production mode and demoed my site live on https://me3tweaks.com/modmaker. I'm sorry I went first everyone - I just wanted to not have to keep working 80 hours a week on it. Literally almost all of my awake free time was getting this thing off the ground.
ME3Tweaks ModMaker used TankMaster's Coalesced Compiler. Without this compiler, I would have had to use Gibbed's compiler, which would have caused a serious challenge due to it's lack of Type 1, 3 or 4 support. ModMaker significantly changed files, which allowed me to stress test his compiler and uncover bugs in the implementation. Without TankMaster, creating ModMaker would have been a much harder challenge.
Release version of Mod Manager 3
Mod Manager 3 also included a bunch of user friendly features - an in-app updater (which was broken on the first release, heh), a mod merging utility (so you only had to install 1 mod instead of 2), mod-based AutoTOC, autobackup of modified files in the basegame, etc. Writing a self-updater is quite a challenge, because it has to be mostly bulletproof. If it breaks while moving files, the user is totally stranded. I've written a few different implementations of auto updaters over the years, and I'm actually amazed Mod Manager's is reliable as it is. That's not to say I haven't had any faults in my updaters, but I haven't had any large catastrophic stranding of users (except for when Github pulled TLS 1.0/1.1 on ALOT Installer).
Hand issues
Due to the amount of work I spent on a keyboard during my final semester at college, my hands suffered serious RSI and I had to lay off playing games on keyboard/mouse. To this day I still don't use keyboard and mouse to play games as it hurts my hands to use them for more than just a few minutes for games. You won't beleive the amount of entitlement some people on PC have - I tell people I play on a controller, and some people are just offended. I don't get it - PC elitists tout PC as the platform providing choice, but apparently not when it comes to input methods.
Hand braces like these were pretty much worn literally all of the time. Also, hi Stubby Mo.
In early 2016, Moonshine showed up with his original version of the SP Controller Support on the ME3Explorer forums. I remember the installation method was... prone to error, given what I read about people trying to install it. I tested out the mod, and it worked pretty well, even in its unfinished state. I made a video demoing it, and somehow it's one of my most viewed videos, even though it has some of the literal worst gameplay ever, since I was not used to a controller at all.
I wanted to be able to support installation of this mod in Mod Manager, so I extended Mod Manager in Mod Manager 3.1 to include CUSTOMDLC (DLC mods) and TESTPATCH support, which contains some patch stuff that can only be located there. I also modified Moonshine's mod to work with this new format, as I was going to show him how it could be installed easier with better compatibility than the current process. Moonshine disappeared though, and I never got to ask him.
After a while of him being gone, I started to update the mod with some fixes of my own. Part of the UI was scaled, the rest was not, leading to some overlap of items in some areas. There was also broken stuff (character creation), no translations for other languages, and no MP support. I knew this mod was going to need several iterations before it was actually done, so I added a mod updater to Mod Manager 3.1 that could read a manifest for a mod on ME3Tweaks, and notify the user of the size difference. Clicking yes to the update dialog would synchronize the server to the client which would update the mod for them, making it really easy to keep mods up to date.
Most of Mod Manager today is based on code from Mod Manager 3.1, which I specifically built to support controller mods. Internally, the project is still named modmanager3. I recreated Moonshine's mod using some clean assets I extracted from the Xbox 360 version of the game, including writing a decompression algorithm in QuickBMS (oh lawdy that was difficult) so I could extract resources from files compiled for a different endianness.
Expansion of ME3Tweaks
Following getting my degree for computer science, I significantly expanded ME3Tweaks. I added new guides to help new users with modding. I greatly expanded what you could edit on ModMaker.
Just a normal day in ModMaker testing life
I'd like to thank the people that significantly helped test and create the resources for ME3Tweaks ModMaker - it contains thousands of images that many times had to be taken with another person. ME3Tweaks ModMaker may seem mostly simple on the surface (okay, maybe not that simple), but the back end is huge. ModMaker's footprint (not even my main site) is over 100,000 lines of PHP code. The publisher - the part that creates the delta file that Mod Manager uses to create the mod - is over 3000 lines of code, not including any whitespace.
End users don't see this SQL menu in the menubar. It was for ModMaker development.
Inside this SQL menu were parsers I wrote that would be able to parse and output a huge amount of code I would implement serverside in ME3Tweaks. It would take coalesced file input (xml) and spit out code for my server. For example, each powercustomaction (essentially a power) generated 7 different pieces of code that I had to add to the site - publisher, forking, loading (which was two parts), saving, validating, and the web page to edit the stats on. I had to also test each piece to make sure everything loaded correctly, validated correctly, saved correctly, published correctly, and then was compiled correctly. I also had to research what each stat actually did (many were shared so I could just copy paste them), and I also had to get images for each power that would help a user quickly see what the box it contains was for. It was a very laborious task. I figure on a good day I could do 3 full powers a day, but that was pretty hard on my hands.
The phantom has some stats that aren't even used, further complicating things.
Fun fact, the Mod Manager compiler for ModMaker mods has such deeply nested conditional checks that tabbing all of the if statements in one level literally puts a good chunk of the code off the right side of the screen, forcing you to scroll. The compiler is very complex, but I'm actually very happy with the result - given how many mods there are on ModMaker, and how I've got only a few bug reports over the years, it's been amazingly stable for the can of worms that it is.
Mod Manager 4
Mod Manager 4 was a slight extension of Mod Manager 3.1, that primarily added MixIns. MixIns are premade binary patches for vanilla game files that you can stack and "mix and match". In retrospect, export patching would have been better, but it's too late to change it now. MixIns allowed me to ship to end users a library of small patches they could apply to any mod, and Mod Manager will update the local cache every 2 days.
MixIn library
I added this feature to ME3Tweaks ModMaker - so users could just pick and choose binary patches to add to their mods. This significantly expanded again what you could edit, as there was lots of things one could binary patch. It also allowed for basic unrealscript modding as you could edit in-place as long as you didn't change the filesize (which would always bust the file anyways with unrealscript).
I also added a keybinds injector that could take a bioinput.xml file and inject it into a mod. This was primarily done for ModMaker mods so you could keep your keybinds while updating all the coalesceds for MP. It doesn't see too much use, but the users who do use it appreciate it. I also started installing LauncherWV automatically as many users would not do this step and the game would not work with mods.
Mod Manager 4.1
Mod Manager 4.1 was another feature update that got a new version number. It added support for adding and removing files from the game, as well as supporting unpacked DLC, which is actually significantly more complicated to support than one might expect. Being able to determine if it should inject into the SFAR or install as unpacked required large alterations to the installation engine.
In Mod Manager 4.1 I started looking to improve the developer experience for people who used Mod Manager. While Mod Manager is a program primarily focused on end users, I actively used it during mod development, so I would write in automated things that would make the tedious, repetative things faster and more reliable. Things like mount.dlc editing also were added so I could edit mount.dlc files and ensure accuracy of the edits.
I also added a feature called VARIANTS - essentially a small coalesced delta that could be applied. This feature is only really used by the controller mods, to turn on/off aim assist without shipping a whole new file. It's clunky, and I'm not really proud of my implementation of it, so it's probably best that it's not widely used.
Finally, I also added a dynamic help menu that would be built from a server side xml file. This would let me build my own list of items in the help menu without having to ship a new build. I use this feature a lot, but I doubt many users notice. I could add changelogs, update links, add help topics for common issues, etc. Does anyone actually read the help menu in programs these days?
Mod Manager 4.2
At this point, I was burning out a bit on modding Mass Effect. I knew there were features I needed to add in the event my server disappeared. So I made it so you could sideload files (like ModMaker deltas) and did a lot of testing to make sure the app worked without contacting my server.
I also started bridging the gap of Mod Manager and non-Mod Manager mods by adding support for importing installed custom DLCs. This would allow the user to put it into Mod Manager, so if they needed to reinstall the mod they could just do a one click installation. Additionally I implemented Starter Kit, which allowed users to generate a blank, ready to start using Custom DLC mod. Creating one by hand always took like an hour, getting all the files ready and modified, and something that could easily be automated. Automation is my jam.
I made an interface where you would input all the required information for making a DLC mod, and it'd do all the boring work for you. This feature is often cited in users' credits for DLC mods these days, so it's nice to know it's getting good use. It took a good chunk of testing ;)
Some of the readers here probably have used this.
I also added a feature to Mod Manager called soak testing, which is a concept I knew about from back when I was attempting to get updates on my Motorola Atrix 4G. Essentially you only push an update to certain users, and over time you widen the "soak" so your audience absorbs it. In the event your update has a significant issue, you can stop deployment and keep most of the userbase on a stable version. I would do soak testing for all releases in the future after adding this. If you're a software developer with an automatic app updater, this is a good feature to implement. I would always soak at 10 users for a day, then 35, 100, and then finally uncap it.
Too many numbers
During the development of Mod Manager 4.2.5, Oracle (the developer of Java) decided to completely change their numbering system for updates to something that I can only describe as completely nonsense. Mod Manager is a Java program - I wrap it inside of executable using a program called Launch4j, which only supported detecting the installed Java version up to two digits. With Java's new scheme, they went to update 101, which means it could no longer find a suitable java version. So when java automatically updated for my users, Mod Manager was dead. This was pretty scary - I had a sizable userbase, and Oracle out of left field just killed most of it off.
I had a fix out in a few days, but without Mod Manager able to even boot, it was a manual update. My website showed a large drop off in traffic to the serverside components of Mod Manager. This taught me that I should just bundle my own copy of Java rather than using the built in one, though I would not implement this until I switched to 64-bit Java about a year later.
4.2.5 also added dynamic mixins, though support for them on the ModMaker would not be live for a bit. Dynamic MixIns are binary patches that the server would generate with your values. Beleive me, writing binary data with PHP is not fun. I really had to read up on how JojoDiff patches were read. Lots of time was spent in HxD. But it was worth it, as you could now edit package files with just the web interface. This was another significant milestone in my modding journey, as editing movement speeds and other pcc only stuff was now way easier. Today there's over 900 dynamic mixins you can customize.
An early version of Dynamic MixIns on ModMaker
The Dynamic MixIns ModMaker page was fun to design - a friend and I took a good chunk of time making some sweet banners for each enemy. The end result was pretty swanky.
UI work
I spent a good chunk of my time during 2016 working on UI mods. Controller mods and interface scaling, to be precise. Learning how to do scaling, learning how do assembly modding on flash player P-code.
Trying to design a scaling offset algorithm, before I figured out I could just turn on scaling mode
I developed the MP Controller mod, which couldn't be merged with the SP version because for some reason adding the Xbox PowerWheel UI causes the game to be unable to connect to other players. Before you ask, no, it has nothing to do with the fact it's from Xbox, it seems to have to do with adding packages, as I ran into this issue when adding maps too. The powerwheel is literally the only UI that is exclusively in each platform. The Xbox files have Powerwheel, while PC has PC_PowerWheel. All of the other UI files in the PC version of the game also contain the Xbox version. So changing this UI was much different than just stuffing an updated UI file back into the game.
I also had a second system that I had hooked up to my TV - and I know some users wanted a bigger UI without a controller, so I also made a mod that scaled up interfaces. This would also ensure this game continued to work in the future with higher resolution displays. Mass Effect 3 for some reason does not scale the HUD like ME2, even though most of the interface is literally ripped right out of ME2. I would have preferred to shrink the scaled UI so it was more like 1600x900 sized, but the way the scaleform files are, it's just not flexible enough.
Trying to figure out how to properly align the subtitles to the conversation wheel
Mod Manager 4.3
While previous minor versions of Mod Manager included a good chunk of new features, 4.3 was relatively small, adding readonlytargets to moddesc and ASI mod support. Adding read only targets was a feature requested by Kinkojiro for Expanded Galaxy Mod - some files are installed and should not be modified by end users, but are in a folder with other end user files that can be modified to their liking. On installation of these files, they are tagged as read-only.
The other feature, ASI mod support, was pretty easy, but required some extra restrictions on their use to prevent security mishaps. ASI files are dll files that a special version of binkw32.dll bypass can load. This allows the game to run custom executable code, which can be dangerous (see some of the keylogger GTA V mods), so I ensured all ones I would make easily available were open source and were hash checked to match the server manifest. I won't lie, I can't write ASI mods, as I'm a terrible C++ programmer. But the ones available are nice, like turning off the cursor when using a controller.
The UI could use some work, but then again so could JTable's ugly default look.
I also finally got on the real AutoTOC bandwagon and just made AutoTOC run after every mod install. In Mod Manager 4.3 I started focusing on simplifying the modding process, and taking out the "make sure you run AutoTOC" step was one of the first steps.
In Mod Manager 4.3.1, I started taking security of the program into account. I would sanitize potential user input, such as ModMaker mods having a name containing "..", which could potentially cause Mod Manager to try and write data outside of the mod's directory. I would also detect if it was nested too deep in the filesystem, which would trigger limitations on the win32 API.
Mod Manager 4.4
Mod Manager 4.4 is when I added my first "diagnostics" implementation into any of my programs. It would collect information - installed DLC, me3logger logs, installation information, system information - and put it into a nice file to give someone a high level overview of a game.
I also added automatic patch configuration. On installation, Mod Manager would detect what's installed, and compare it to a list of conditions in the installing mod's configuration file. If the condition was true, the task would execute. For example, if SP Controller Support detected DLC_CON_DH1, it would install the Genesis2 version of BioP_Char.pcc to enable that DLC's features. This would require no user intervention, and would be completely transparent, again making it easier for end users. This feature is pretty complex, but once configured is very nice for the user experience.
EGM using this feature to autoconfigure the mod
I also made sure all connections to ME3Tweaks were encrypted with SSL - it took almost 2 months for me to figure out this was the issue causing MixIns to not work for some users that were downloading new ones (rather than using their cached ones).
Near the end of Mod Manager 4.4, I dropped the word Coalesced from the name, since it wasn't really a coalesced mod anymore. Most of the mods I shipped were not coalesced only mods like they were at the beginning. The name was now officially Mass Effect 3 Mod Manager, though the internal name of ME3CMM sticks around. I think it's easier to say.
Mod Manager 4.5
Mod Manager 4.5 was released around the same time I started working on the ALOT project. As such I started adding ALOT features into Mod Manager, such as checking if ALOT is installed and warning or preventing actions that would completely break the game.
I also added some telemetry to Mod Manager in 4.5, allowing me to see what features were used. I wanted this earlier, but I was hesitant as I did not want to have to deal with the privacy issues of collecting usage data. I eventually added it anyways though - my server telemetry contains no identifying information, which is nice, but also kind of a hinderance - I can't accurately distinguish the count of things, but that's OK. I used the telemetry data from the mod importer to build a database of mods and their information so I could reliably identify what mods were installed and show the user in human readable names.
Part of my server-side telemetry dashboard
I also added some swanky new DLC togglers for both official DLC (for developers to test with) as well as Custom DLC for end users to quickly test turning on/off a mod.
Mod Manager 5.0
Mod Manager 5.0 was supposed to be the final feature release for Mod Manager. Development on this tool had been ongoing for a long time, so I wanted to make sure I packed in a lot of stuff before I put it into maintenance mode. This was probably the longest development time for a new release since 3.0, and I had to maintain 4.5.x at the same time and backport a bunch of fixes.
It contained a ton of small things like granting write permissions on the game folder, allowing multiple installation directories (very useful for testing) that also could let Origin boot it, and tools on demand, which would download some modding tools into a folder if they were not present and you wanted to use them (MEM, ALOT Installer, ME3Explorer, etc).
Someone also re-released it as a trojan. They did a pretty poor job, as it didn't actually work properly.
The other big feature was that I no longer included ME3Explorer with Mod Manager. I built command line tools to perform the same operations, but with huge speed improvements. Building Zombie Mod now took like 1 minute, where with ME3Explorer in the older builds would take over 7. It also allowed me to finally switch back to the mainline version of ME3Explorer so I would not have to keep maintaining a fork for hackjob features. Significant speed improvements were due to me switching to using MEM code which is much more optimized, especially for decompression.
Mod Manager 5 had a very bad pathfinding viewer in it.
It didn't work very well.
I also added a Deploy Mod feature, which would package your Mod Manager mod into a nice, easy to import (or extract for manual install) 7z file with high compression settings. 7z as an archive for ME3 mods is far, far superior to zip and rar. On SP Controller Support, Zip is about 800MB, RAR is about 300MB, and 7z is about 180MB. It's crazy how different it is. 7z files are not random access, which allows it to have much better compression across files.
Mod Manager, today
The current version of Mod Manager is 5.1 Beta 6. It's labeled as beta as one of the features, ModDesc editor, is not functional yet, even though I spent months of time on it already. I added the ability to import most third party mods using telemetry data and heavy use of my NexusMods premium subscription.
Importing a mod without a moddesc.ini file
At this point I would consider Mod Manager to be in maintence state. I would like to finish the ModDesc editor at some point, but I absolutely hate writing Swing code and the final parts of it are going to be a huge amount of work that I just don't feel like I have the energy for. I still fix bugs in it but I don't really plan on adding any new features.
ALOT Installer
CreeperLava covered most of the ALOT aspect of ME3Tweaks involvement in ALOT Installer, but I worked on ALOT installer heavily for some time in 2017. It was my first WPF application, a design language I love and hate. It's incredibly powerful and when it works, it works wonders, but it can get really ugly at times.
You also can put a few fun things in it.
I remember seeing the batch file to build the addon before I started working on ALOT Addon Builder. I offered to help with the batch file, since I knew a lot about batch scripting. I read the comments on the mod, how often it failed during building of the Addon - seeing this terrible of a user experience on a project like this was disheartening, so I started making an interface to build the addon.
Slightly older version of ALOT Installer.
After a while, it became the main installer, and I learned about working in a team. I learned about how to make 2 processes communicate to each other so that the main installer interface can show what MEM is doing in the background. There were definitely times where I had disagreements with other team members, but in the end I think we've made a very respectable product that stands on its own and we worked through issues as a team.
Some beta ALOT Installer icons
ME3Explorer - ME3Tweaks Fork
For quite some time it looked like ME3Explorer was a finished project, with no active development. I needed some additional features for my Rejection and Redemption mods for editing pathfinding, so I forked the project (again) and started working on my Pathfinding Editor tool. I also took the time to implement many quality of life features that were missing that frustrated me when using the tool - pressing enter not automatically pressing the associated form submission for example. With this fork I started working with Kinkojiro significantly, adding features that he requested.
The biggest addition to ME3Explorer has been my Pathfinding Editor tool. It allows you to view the pathfinding network for a file, which in turn allows you to modify how enemies and allies move in a level. It let me make new MP maps. As an example, I removed a wall on the upper floor of the atrium on Grissom Academy and made pathfinding nodes through it. I also expanded the width of hte links so that large enemies would be able to properly path. Pathfinding Editor also lets you view where objects are placed in a 2D overhead view - 3D is simply too much for me (and very expensive in terms of performance).
A lot of work, but it was definitely worth it.
Looking under the hood for ME3Explorer has been enlightening. There's a very strong property parsing engine in place that's fairly robust (PropertyCollection), and the interface implementations for packages seem very professional and makes using files from all 3 games easy. I expanded this a bit for a few new features I added, but overall, I was impressed by the core property parsing and file handling. None of this existed at the point in time when I originally forked ME3Explorer.
Beyond Pathfinding Editor, the biggest change I made in my fork is the relinker. The relinker will relink properties to point to their updated correct ones (when possible) when dragging a tree from one package to another. You used to have to do this by hand, as well as setting all of the classes, archetypes, etc. It was an absolute huge time investment. To fix textures in my Redemption DLC I would have to port some trees, which I was not going to do by hand. So I spent weeks instead making an automated solution, that is wildly complex and works like 98% of the time. That 2% is really difficult to support given the mental gymnastics that are required just to even debug it. All in all though, it saved me unbeleivable amounts of time making Redemption and Rejection.
Relinker relinking the classes. It also does the property values in the exports.
The relinker also supports binary objects, to a small degree. I also made a binary editor, which is like interpreter for binary data. It require custom code for every class though, so it's a lot smaller in scope. It's good to document the known class structures though in code so others can view it if necessary. I also fixed a lot of bugs in ME3Explorer code.
Things I learned from modding ME3
Going from a small utility to having a stable of software that's used by thousands of people has taught me a great deal about software development.
- Having a good logging setup is absolutely necessary for debugging end user stuff. When you start building an app, add a good logging system so you can easily debug and trace what a user is doing.
- Making stuff easy for users will make them do it more often - ALOT Installer game diagnostic is something I am particularly proud of, as it lets users identify issues on their own, and greatly reduced the burden of supporting the ALOT mod.
- Licensing is important. This is something I think should have been taught more in my computer science classes, as licenses can be very confusing but have a large impact on how you can use other's code in your project.
- Backwards compatibility is paramount. I strove to keep things backwards compatible, but I have seen some programs in the scene that are not and users have like 5 versions of the program. It's just a bad user experience.
- People who pirate games are pretty much never worth your time to help support (I don't). The ones who come in asking for help often put forth almost no effort in fixing their own issue.
- I hate designing Java swing interfaces that are complex and dynamic. I'm not really a fan of swing, but it's too much work to change to .NET for no real benefits.
- Good commit messages will make writing a good changelog much easier. While many users probably won't care about changelogs, a well written changelog is always something to be proud of.
- Always strive for a good end user experience. Nobody wants to use software that is a chore to use. Automate things that are repetitious, as they significantly drain resources.
- Never assume the end user actually read and followed the directions (ok maybe this doesn't apply to only programming).
I mean, I put a lot of effort into my installation directions.
Could you at least try to read them?
A note on donations
I have had many users request to donate to me over the years for my work. I have always turned them down. While I don't mind the idea of getting donations, my work is based on others' work, so I don't feel like being paid is acceptable. I don't really care if other modders want donations, but it's my philosophy.
Some users are also like, why don't you get something like Patreon? Well, I thought about this idea for some time, but Patreon is kind of like paying for a service. People put stuff in, and most times expect something out on some sort of regularity. I do my modding work and programming as a passion project, not as a way to help supplant my income. I stream games on twitch for fun - but I don't want a schedule to make me feel like I am bound to do it, something I share with my modding work.
The only thing that I would really consider donations on is my work building ME3Tweaks ModMaker, as it's pretty much all my own original work, and running my online services costs me several hundred dollars a year. I run advertising on my web site to help offset the bill - but another tip, if you want to make money through advertising, you need to have an audience that is not tech savvy.
If only ads weren't abysmal these days.
Closing
There's also a few other modding programs here I didn't talk about, like Mass Effect Ini Modder or the GUI Transplanter tool. They each presented challenges (especially GUI Transplanter) but were fun and taught me a good deal about programming for production use.
It's been fun creating content and creating user experiences that can make even the most novice modders able to create what they want. I'm not actually even a huge Mass Effect aficionado, I did not play Mass Effect until February 2012, and I've only played through the series maybe twice since Mass Effect 3 came out.
I'd like to end this with a personal note to the people who worked at BioWare during the creation of the first 3 games in this series, mainly the third. If you're reading this, this is addressed to you!
When I started playing these games in 2012, I never knew the kind of impact ME3 would have on my life. Many years and many thousands of hours (6+) have been dedicated to this game, and through this game I've met some of my best friends. Over the years I have definitely been critical of ME3, but not because I don't love it - but because I could see where it was weak, and where it was strong. I wouldn't be modding this game for 6 years if I didn't love it. It isn't perfect, I wouldn't even say it's close - but you definitely changed someone's life with this game. You created a universe one could get lost in, and that's what happened to me.
Thank you.
When I started playing you, I had no idea what kind of impact you'd have on my life.
It's been a fun 6 years. I wonder what my next big project will be. I think this one will be pretty hard to top.
1 comment