On November 7th, 2021, the ME3Tweaks group released Pinnacle Station for Mass Effect Legendary Edition. Pinnacle Station was a DLC developed by Demiurge for the original Mass Effect game in 2009. Demiurge also handled the PC port of Mass Effect. Sometime after the DLC was released, the source code was lost, which is why it did not appear in the PS3 version of Mass Effect Trilogy, and was subsequently not included in Mass Effect Legendary Edition.

In this blog post, I’d like to go over some of the technical challenges and how the ME3Tweaks group ported Pinnacle Station from Mass Effect to its Legendary Edition counterpart, as well as detail a few of the changes we made. For clarity in this post, when I say ‘ME1’, I mean Mass Effect from 2008, and when I say ‘LE1’, I mean Mass Effect (Legendary Edition) from 2021. These are how the games are referred to in our modding scene to help avoid confusion.

Pinnacle Station

First, let’s start with some context. Pinnacle Station is a combat-focused DLC where Shepard must top the scoreboard on 4 different maps across 4 different game modes, though only 3 maps are available per mode. There is also a special map after completing all of the other scenarios, upon which completing you get access to “Shepard’s Apartment”, a small building on a remote planet.

It is somewhat neat prize, but the DLC does not offer any story of any actual substance and nothing is referenced from this DLC in future games (as far as I am aware). I’m pretty sure this is often considered one of the worst DLCs in the franchise.

Origins and initial feasibility

This project started on September 18th, 2021, after I came back from a complete modding hiatus after working pretty much nonstop on modding from March until the end of July.

After seeing someone comment about wanting Pinnacle Station in Legendary Edition, I began to look into seeing just how capable our tools would be at attempting something like this. Our tools could already port assets from ME1 to ME3, and the LE games are based mostly on the ME3 version of the engine (not entirely, but data formats are mostly the same).

Initially it was only going to be Shepard’s Apartment, which is the prize for completing Pinnacle Station. This would be fairly easy since there is not much sequencing involved, and only a handful of meshes, something that could be done in a mod without too much work. Over time the project evolved into the entire DLC, with a focus on making it feel more like part of Mass Effect Legendary Edition, rather than feeling like a port of content directly from Mass Effect.

The starting question for this project was simple, yet complicated: Is porting the entire DLC actually possible? What are the things we absolutely can’t port? Do we even know what they are?

Material Shaders

For years we’ve known we cannot port material shaders across games, even between LE games, because of some unknown data that trails the embedded shader files in the shader caches. I’m no expert on shaders, but shaders from my understanding are essentially how the graphics card draws surfaces of polygonal models. If you don’t have a shader, the graphics card can’t draw the polygon. Materials in Unreal Engine reference a shader by a GUID and provide inputs to it, such as color, textures, and other items. If the loaded shader caches don’t have this ID, the game instead uses the default material, which is the checkerboard pattern.

Modders can work around this limitation by finding other materials that provide a similar effect, cloning them, and providing different inputs to them. Not all parameters of shaders can be changed; some are meant to be widely changed (like tintable armor materials), others have no configuration options at all (like some VFX shaders that don’t even use textures).

We could never have ported shaders though, as Mass Effect and Mass Effect Legendary Edition run on different versions of DirectX.

SHADERS: Couldn’t be ported

Audio

Audio was the big question mark for this project. When starting this project, most of ME1’s audio system was not understood. We knew both ME1 and LE1 used ISACT, but we weren’t sure if the versions changed – though it was unlikely as ISACT has been dead since 2007-ish. If audio could not be ported, there was almost no reason to try to port the main part of the station, where dialogue is part of the story. Additionally, we currently cannot replace or add new audio to either ME1 or LE1 due to several unknowns in the audio pipeline for the games.

While porting the apartment, we found that audio would work if one just took the original ISB (ISACT Sound Bank) files from ME1 and put them into LE1, and porting over the objects that referenced it. This worked for all audio in the DLC.

AUDIO: Could be ported

Lighting

How will the maps be lit? Porting prebaked lighting across may or may not work. For a few years we’ve had a workaround for adding or moving new objects in levels: turning on dynamic lighting. This means the game could compute how objects should be lit. This is done all the time in the game already, moving objects for example use dynamic lighting to cast shadows and to shade them when they move into less lit areas.

SirCxyrtyx a few years ago wrote an experiment to turn all lighting on a level to dynamic, which yielded both terrible lighting (compared to the prebaked lighting) and terrible performance. But it was possible, and could possibly have acceptable performance on smaller, less complex levels.

LIGHTING: Maybe could be ported

Differences between games

We were not sure how much under the hood had actually changed from ME1 to LE1. Did things move around in game files? Were some things cut? Were some things added that needed to be used?

As part of the discovery phase, I built a system to generate an object database, which maps every unique game object to the list of files that contained them. Game objects in this context mean things like meshes, textures, particle systems, and more. This database differentiated objects by their full instanced path, as shown below.

This database would be used to build our donor system, which would be checked every time an object would be porting over from ME1 to LE1. The instanced full path would be used to find an identical asset in LE1, and if one existed, it would port that instead. This would mean we would extensively be using existing LE1 assets, such as shaders, updated meshes, textures, etc. Without this system it would not be possible to do this porting as we would have to manually point to LE1 only assets, such as Materials (which reference the shaders).

Using this system, we were able to determine that there is not a lot of internal differences between the original and the Legendary Edition version of the game, which meant porting levels would not require an enormous restructuring of the DLC. Some things would need changed, but nothing insurmountable. We also learned that Pinnacle Station has very few unique art assets, which is something it shared with Bring Down The Sky.

DIFFERENCES BETWEEN GAMES: There were minor differences that could be easily worked around, hopefully

Using VTest to port the DLC

Our porting process uses a workflow that became known as VTest, which means ‘Vegas Test’, as the original code was meant just to be a test. Vegas was the code name for Pinnacle Station during it’s original development. We used Vegas in the codename for our project, CrossGen-V.

VTest is a porting pipeline that takes a slightly modified set of files from the original DLC, runs them through a converter, and outputs converted files. As development progressed, we built in ways to improve development time, such as automatically telling Mod Manager to install the mod and run the game at the end of a VTest session. At the end of initial development (November 6), VTest takes about 6 minutes to run and uses about 7GB of memory.

The set of ME1 files to be ported are known as ModdedSource files. We made minor changes to these files , such as renaming things that need to be memory unique, or to take a specific donor object when porting. We also made changes that only have to occur in a single file here, like basic sequence fixes. These files would almost certainly crash ME1 if you tried to put them back into ME1, as they are specifically tailored for use with VTest.

The VTest pipeline is quite complicated and technical, but it can be broken down into a few main stages. Glossing over a lot of the very technical bits, the pipeline looks something like this:

1. The destination mod folder (located in the Mod Library) is cleaned out, and files we never have to process are copied in, such as 2DAs and TLKs. These are known as PrecomputedFiles. These are files that don’t need conversion at all so they are simply copied into the mod folder.
2. The ModdedSource files are run through the VTest conversion code one at a time. The ME1 file is loaded into memory, and we make ‘PreCorrections’ to this file, such as renaming objects so the donor system will use different objects. This also is done to make changes to the files so certain unnecessary assets are not ported over, but we don’t have to modify the original file (in case one of our edits breaks things).
3. Each ME1 file is then run through the VTest converter, which does the actual conversion. It behaves differently based on which type of file is being converted:
   • Level files are run through a level porter, which starts by generating a blank LE1 level file. It then ports the ME1 level actors over, as well as all of their references. The donor system pulls in the LE1 versions of assets automatically, or our own specially crafted donors, if one is available.
   • Localization files generate a blank LE1 package file, and then port over the ObjectReferencer, which is used to tell the engine to keep the listed objects in memory. Because of these references, everything in the file is ported over by our tools, using the same donor system, except it forces use of the same language localization.
4. The converted files, now in LE1 packages, are run through our PostPortingCorrections code, which is where the meat of the conversion takes place. It does things like convert properties that changed between the games (such as NavReferences), applies some fixes and applies specific changes we wrote, like fixing sequencing (such as installing BlockForTextureStreaming, which is not available in ME1) and the intensity of lighting.
5. The package is then saved to disk in the Mod Library folder, and we run some checks on it. These include things such as checking the actor count in the level is at least 2, testing import resolution, ensuring correct texture NeverStream flags, and checking all property references that their type matches. We also run our standard toolset checks such as making sure entry and name references are within the bounds of their respective tables.
6. As VTest completes, it signals ME3Tweaks Mod Manager that it should install a mod by passing it the moddesc.ini path. Mod Manager loads the mod and installs it. VTest also tells the Mod Manager to automatically boot the game afterwards.

You can view the source code for our pipeline on the Legendary Explorer GitHub .

VTest allowed us to make changes that would affect multiple files without having to do everything by hand in each file. If we needed to rescind a change, we simply commented out that part of the porting code and recompiled the mod with VTest. This ensured accurate results every time and allowed us to configure options, such as dynamic lighting, porting level models, flipping off certain levels to improve compile speeds, and more. It had the downside of typically having more up-front development time for changes, but the payoff over time far exceeded the upfront investment.

This means that manual changes after VTest were only done for testing purposes. We would install the mod, change files in the game directory, and when we acheived our desired results, we would apply those changes to ModdedSource or code them into VTest.

The result of taking Legendary Edition assets is that some things will look different, as many texture and material assets were changed. Most of these are not really an issue, but if you compare the two, you’ll see differences.

Specially crafted donors

During the porting process, we found that there are assets that are only existed in Pinnacle Station, such the simulator loading effect, the capture ring effect, and terrains that are used on maps like Volcano.

We made special donor files for these, which are inventoried at the start of a VTest session. The object database is updated in memory, allowing VTest to think LE1 assets exist, when they’re actually only part of our special donors. For example, we remade an object with the same exact instanced full path as the planet you can see outside of the window aboard Pinnacle Station; when this object was being ported from ME1, it would use our custom object instead of trying to port the ME1 version, which would not work in LE1.

Tracking progress

We used an excel sheet to track issues and how they were fixed, as well as other things such as donor materials. This project was not big enough to warrant using a larger system such as JIRA or GitHub issues. We would fill this out as we went along. As of initial release, most of them have been checked off, with a few being most to post-release.

Reusability of VTest

I’m sure some modders will read this, and see what everyone wants to see: A convenient, easy way to port content (like their own mods) from the original game over to the legendary edition of it. Unfortunately, it is unlikely this system would ever work in a generic manner that mod developers hope would work.

VTest is several thousand lines of code that is very heavily tailored to porting Pinnacle Station. The donor system however is fairly generic, but only properly works if the source files are properly formatted – same named objects MUST be identical, which for mod files is rarely the case.

For this project, we tried as best we could to adhere to the official compiler rules of every object being the same, including its references. While we didn’t hit it 100% (due to the large amounts of work it would have involved in one or two situations), we wanted to make this release feel as official as possible, even if users would never feel the impact of these changes.

Design issues

This DLC had a lot of design issues that we put significant effort into fixing, in order to make it feel a bit more modern.

Lack of audio

In the original Pinnacle Station, simulator maps had no music, and most enemies had no audio (grunts, barks, etc). It was pretty boring to hear your gun shoot for minutes while Ahern yells at you the whole time. We decided to add music to each map to make it more entertaining to play, which had a surprisingly profound effect on how enjoyable each map was.

We don’t know much about ME1 or LE1’s audio system, ISACT, so editing audio is impossible. We know most of the information required to change audio, but there is unknown data in an object named BioSoundNodeWaveStreamingData, which seems to be required to make things work. So we had to limit ourselves to the original versions of audio in the game.

We tried to pick tracks that felt appropriate for the map theme. All maps except Warehouse have a second track that is switched over to as the combat intensity picks up, and it makes a world of a difference in how fun the scenario feels. It’s one of the best new features in my opinion.

Kill volumes

Kill volumes were a significant problem when porting this DLC. In the original DLC, the maps had a bunch of kill volumes just outside the playable area, which was so enemies don’t fall out of the map and survive.

These kill volumes did not discriminate who touched it, and would immediately destroy any gameplay pawn that touched them. On top of looking pretty jank when you punched someone into a railing and they just disappeared immediately, it also had a pretty unfortunate side effect of also deleting Shepard and squadmates too. If Shepard is deleted, the game crashes shortly after. This could happen if you were ragdolled into it, or tried to use console commands to move through the air, such as ‘fly’.

There are invisible ledge meshes placed into each map that are designed to prevent the player from being able to walk off the ledge into these volumes, but due to what were essentially rounding errors when our tools converted these meshes from ME1 to LE1’s format, there were gaps in coverage (due to changes in kDOP). This would constantly lead us to game crashes as we would walk into what we thought would be solid, but instead wasn’t. This was one of the first things we had to fix.

In our remastered version of Pinnacle Station, these kill volumes no longer do anything to Shepard, in the event you somehow are able to touch them. Additionally, we changed the behavior to cause killing damage to other creatures, rather than destroying the pawn, which means:

• Enemies that touch it will die and have the normal death fade
• Your squadmates will unfortunately be having a permanent nap for the remainder of the scenario if they touch it, as they will be killed as soon as they are revived

The second point we may address in a post-release update, however, we have not been seeing squadmates touching these volumes unless you use the in-game console and get out of bounds, which cause your squadmates to teleport into a kill volume.

Difficulty scaling

The original Pinnacle Station had significant difficulty issues on both the Casual and Insanity ends of the spectrum, depending on the game mode.

Volcano Hunt Insanity

This scenario was extremely difficult because of the map design. Spawn points were so spread out that getting to enemies often takes significant amounts of time, which you don’t have a lot of in this game mode. Coupled with the time to kill on this difficulty, you had to nearly be perfect.

We’ve toned this specific scenario’s difficulty down a little bit by reducing the decay of time awarded per kill, which should take a bit of pressure off. There is still significant difficulty, but we don’t want it to feel impossible. This only applies to Volcano Hunt Insanity.

Survival engagement

Survival mode has seen significant changes in our version of Pinnacle Station that results in increased difficulty. Survival mode is based on waves – after you kill all enemies from a set of spawnpoints, it goes to the next wave, which has harder enemies. As the scenario progresses, it gets more and more difficult, and eventually you are overwhelmed and the scenario ends.

Except, if you don’t kill enemies, the waves don’t progress very fast. If an enemy takes no damage for a while, the game kills them and spawns a new one (thinking they might be stuck somewhere). By simply not engaging with enemies, you can make harder enemies take minutes to spawn, which results in an easy win. This made it super easy to cheese, especially with ME1’s poor AI. This is definitely not Mass Effect 3 multiplayer.

In our version, we’ve made it so that enemies who have not been killed after about 25 seconds will charge the player. This makes them rapidly close distance and stay within firing range of the player. It greatly increases the difficulty, which is likely what the original mode was intended to feel like. It is still fully winnable, but there’s a lot less standing around waiting to shoot.

We will likely refine this change in future updates.

Survival duration and Casual

If you play well enough, Survival can go on forever. Even with the new engagement changes, you can still be hard to kill, especially with rapid health regeneration. In fact, on Casual with Soldier Rank 6, you were practically impossible to bring to 0 health – which means you couldn’t finish the scenario without having to use the exit button, which counts as a loss!

We added a system to slowly decay the player’s healthgate the longer the match continues. The healthgate system in LE1 greatly reduces damage Shepard takes when their health would drop below 25%. Certain types of damage ignore this system, like rockets, but most weaponry is affected by this system. The result is that you could regenerate health faster than you would take it, and would constantly be stuck around 25% or more health.

This decay system doesn’t kick in until about a minute and a half into the match, to make sure you have a chance at topping the scoreboard. We don’t want to punish players, but we want the game to increase in difficulty over time. When the round finishes, your healthgate is restored back to normal. We even coded it so that if a mod changes the default healthgate, our system will respect that value.

This change allowed players to be killed on Casual (so they could win the scenario), and also made longer sessions get more difficult. Who would have guessed a game being too easy would make it impossible?

This change is applied on all difficulties, but only on Survival mode.

Smoothing out the jank

I do not think it is a surprise to anyone who has played the original Mass Effect game that there are lots of ‘jank’ moments – like modal LOADING dialog boxes, textures pop-in, and audio cutting off at times. These problems are everywhere in the original Pinnacle Station. We spent considerable effort trying to minimize them, to make for a better feel to the DLC.

• We preload files that we know will appear ahead of time to minimize the amount of LOADING dialogs that show up. If you mash your way through things like the scoreboard, the files may not load in time and you’ll still get them, but for the most part they should be gone.
• Texture pop-in should be greatly reduced. This is a very common problem in ME1. We identified moments where we could load in textures that we knew were about to be shown on screen, as well as making use of black screens and blocking for texture load to force the game to wait until textures have streamed in.
• We fixed poor lighting in a few areas that seemed like they were missing lights, like when Ahern gives you his special mission.
• We fixed strange things such as replies on the conversation wheel changing positions depending on which conversation option you last chose.

We fixed a bunch of other small issues, some of which are shown below:

Bonus content

During the development of Pinnacle Station for Legendary Edition, we had to comb over just about every part of the DLC. There was some interesting discoveries, including an easter egg and quite a bit of cut content (that is for the most part not usable).

Ahern’s easter egg

There are 3 voice lines for Admiral Ahern that he says when you shoot the viewport window while in the simulator. This window is in the top corner of every map. It has a 1 in 20 chance of triggering a voice line, so it takes several shots to trigger one of three random lines.

Given that you are timed in most missions, they start immediately, and on some maps it’s hard to even see this window, and that it takes multiple bullets to trigger the line typically – it is possible that nobody has ever found this easter egg. One of the lines Ahern delivers is one of my new favorite lines of his.

Cut content

This DLC seems like it was much larger in scope during development and had to have almost all of its story cut for unknown reasons. There are some non-finished conversations with Vidinos where he badmouths you, which we may still implement as an an ambient voice line in a future update. There are a lot of interesting small things, such as how Bryant was at one point seemingly in the role of Ahern, before he got demoted to having just a couple of voice lines.

One item that was restored was the turian bombers on Ahern’s map. Every 30 seconds or so turian ships will fly in and bombard the battlefield. I imagine this was cut due to the lack of warning when it occurs, but they don’t do much damage and create something interesting on his rather mundane mission you have to do.

Issues with our version of Pinnacle Station

While we put a lot of effort into making this DLC an improvement over the original, without actual tools and source code, there is no way we could make everything better, or even equal. If we had the tools do this, we would love to properly remaster this DLC.

Things that would have helped would be an in-game shader compiler (that outputs a local shader cache file, like ME1 did), the remaining piece of information we need to edit ME1 audio (how to generate BioSoundNodeWaveStreamingData objects), and a way to compute pre-baked lighting. Being able to generate cover data would also have helped a lot, but for this project we improvised.

Performance

Due to having to dynamically light nearly everything, performance suffers pretty heavily on some maps when the game is played using older graphics cards. Unfortunately, without the actual unreal development tools, we have no way to compute prebaked lighting, which would solve pretty much all of the performance issues. As a result, users with graphics cards lower than a RTX2070 or AMD RX6700 will likely have some framerate issues if you try to go above 60fps.

We are working to improve performance by seeing if we can convert more lightmaps, but this will take engineering time that simply is not available before launch. The type of work we are doing with lighting is not something that has been done at this great of a scale in our modding scene.

While the framerates may not be the best in the launch version, we did put some significant work into improving performance:

• We cut dynamic shadows, as they are not necessary on almost all objects. We may selectively turn some back on where they would be noticable. This only affects objects that cannot move, such as level geometry.
• We ported lightmaps from ME1 for meshes that had the same amount of vertices. For the most part, these look correct, but a few stand out as not being 100% accurate.
• We took the ME1 version of a few assets, such as stones and rocks, that make up large chunks of geometry on some maps. These objects we found don’t need to have as many triangles to still achieve an indistinguishable look, but using the ME1 mesh asset reduced the amount of vertices needing shading by tens of thousands on some maps. It is unlikely players would even notice which assets we did this on. Post launch we will likely look at doing this for more things on the more problematic maps.

In developer versions of this DLC, I had a NVidia RTX 3080 that could not even reach 70fps at 1080p. With optimizations we could reach 1440p 120hz pretty reliably on most maps.

Cover system

I will admit, I haven’t actually really played any of the Legendary Edition games. To me they are pretty much the same games I’ve modded for nearly a decade, which I’ve also only played through like once or twice (though I did play like 4000 hours of multiplayer, almost all of which was modded). That said, I still really like these games, and the challenges of modding them – finding creative solutions to problems when you have a mostly rigid set of constraints.

I’m not sure if the enemy AI improved in LE1, but they still seem as intelligent as a can of beans, which is about how I remember them from ME1. There are some oddities in how the AI pokes out of cover in our ported cover, but I don’t think this is too much of an issue besides being cosmetic. The AI could be more intelligent if we had a way to compute the dangerousness of a cover slot (a place where AI can take cover) when compared to another cover slot on the map.

Localizations

In the initial release of Pinnacle Station for Legendary Edition, we are only supporting the English voice audio. There is full text localization for German, French, Italian, and Spanish. We will update the release with audio support for other languages in the future, however there was not time to implement updates to VTest to account for localizations, as it’s quite complicated, and we had to do a ton of work to get English dialogue not getting constantly cut off.

Not porting assets correctly when accounting for localizations means you end up with a scoreboard in another language, or Ahern speaking french to you in a German language game. We also need to find some localizers to translate the DLC’s text into Russian, Polish, and Japanese, as those languages don’t appear to have been supported in the original version.

Conclusions

This has been the most ambitious modding project I’ve taken on before, as it touched pretty much every aspect of design. We had to design multiple new custom classes, code a very complex porting pipeline, improve our tools to find assets easier, invent new debugging tools, and more.

I didn’t cover everything in this post, like how we had to adjust the length of conversation matinee’s due to some strange bugs, or how we couldn’t get BioActorFactory to work at all for some reason, which is why the ‘bitsplosion’ effect on enemy death is missing. But I hope this was an informative behind the scenes look at how this was DLC was ported and improved.

We plan on updating the mod to further polish it, as well add some quality of life things, such as a weapon store on the station and adding in a bit of the cut content where it makes sense.

We hope you’ll try it out Pinnacle Station for Mass Effect Legendary Edition, and see what some extra polish can do for a DLC that originally didn’t seem to get much!

DLC modding has been a valuable system for modding the Mass Effect games for the past several years. It allows mod developers to create a self-contained mod that can be easily added and removed from the game, all contained with a single DLC folder. While they are not the perfect solution for modding, they have been a great benefit to our scene.

For Legendary Edition, we’ve had support for DLC mods in LE2 and LE3 for a few weeks, and many mods have been created already that use this system. The same can’t be said for LE1, which until today did not have DLC mod support. There are several reasons this took longer to get shipped out the door, which I’d like to explain a bit. I’d also like to explain the limitations we have on DLC mods for LE1. The July 21st update (7.0.3, Build 121) of ME3Tweaks Mod Manager supports generating and installing LE1 DLC mods.

What composes a DLC mod?

DLC mods include a variety of content; strings (contained in TLKs), packages, movie files, config file updates (.ini, .bin), Table of Contents (TOC), conditionals, among other things. In the original trilogy, DLC modules were ‘mounted’ for use all at the same time at the main menu. The DLC would be parsed, overrides would take effect, and files that needed to be loaded into memory would immediately do so (as startup packages).

In Legendary Edition, this has changed slightly. DLC for LE2 is loaded and mounted before the splash screen even appears; in LE3 the DLC appears to be read but not mounted until the main menu has completed (e.g. loading a save). This has side effects, such as being able to put certain files into DLC  that would not work in the original trilogy. The flipside of this half-loaded state is files that load before full mount cannot use certain things like TLK from the same DLC they load from.

The mounting step of DLC registers the startup packages, loads the TLKs, merges the configuration changes, loads the 2DA tables, etc.

What’s different in LE1?

LE1 is based on the PS3 port of Mass Effect from 2011. Pinnacle Station was lost already at this point, so it seems Edge of Reality (the porting studio for the PS3 version) moved Bring Down the Sky into the main game directory (CookedPS3) and gutted most of the DLC system; the game no longer looks for AutoLoad.ini files, it uses a single hardcoded path. Additionally, some features such as DotU were also gutted, even though they still appear in the AutoLoad.ini for Bring Down The Sky. The DotU system told the engine to look for unrealscript classes in the specified files and load them into memory.

In the original game, there was no override system; ambiguous packages defaulted to the first package found, which was always the basegame one. The game used a primitive version of what would later become the TOC file, known as FileIndex.txt, which listed game package files. We worked around this by just making the game never see the basegame version if a DLC version existed; we invented our own DLC mount priority system. This was achieved through updating the FileIndex file to remove the basegame entries and use our DLC ones instead. We ported this over to LE1 to allow for overrides, but instead of FileIndex it now uses TOC.

With significant engineering effort from multiple parties, we also enabled DLC mount, by hijacking the AutoLoad.ini parsing function to also parse our own AutoLoad.ini files, so DLCs in LE1 can load things like 2DA, TLK, and startup packages through the ‘GlobalPackage1/2/3…’ system. Combining the TOC and AutoLoad workarounds, we have a mostly working DLC system.

One upside of the new implementation of TOC is that we can now override movies. In ME1, FileIndex did include movie files, and as such, the game always preferred the original file it found. With TOC, movie files are included, so we can override them now.

What’s the catch?

Sadly, since there was no DLC system for the PS3 port of ME1, there was no need to include the ini merge system, and it was stripped out. This means you can’t update items you see in Coalesced.bin for LE1 like you can in LE2 and LE3. It is possible to restore this feature, but it would likely require significantly more effort than was already put in for AutoLoad.ini support, and if it does come about, it will not be for several months.

This can be semi worked around by using the merge mod format in ME3Tweaks Mod Manager, and disabling the config flag of the property you are updating. Due to the complexity of stacking mods, you won’t be able to install new structs or array items, which is a known weakness I’m looking to find a solution for in the near future. The long term ideal solution would be to allow the changes to be merged from DLC mods.

Conclusion

The LE1 DLC system missing ini merge will be a potential issue for some mods, and right now there is not a 100% workaround for it without replacing the basegame coalesced file, which is widely incompatible with other mods. Hopefully this can be remedied, but for now, you can ship DLC mods for LE1.

Hello everyone!

It’s been a couple of months since my last post. Since then, Mass Effect Legendary Edition launched, and I just released ME3Tweaks Mod Manager 7.0 BETA, which supports Legendary Edition games.

As a quick summary, here’s what you need to know:

• Mod Manager is in Beta and is not yet fully stable or localized
• Legendary Explorer is still in development, and will be released soon
• Multiple new mod formats have come about of Mod Manager 7 which will change how modding games is done
• LE1 DLC mod support is being worked on

Mod Manager 7.0 Beta

Mod Manager 7.0 is the first release that supports Legendary Edition, and took about 5-6 weeks of pretty much full-time work to get up and running. It’s not fully stable yet and is having some bugs worked out but most of the features are stable and working. This includes things like creating starter kit mods, installing mods, etc. It should become stable pretty soon.

Coalesced mods for LE2/LE3 should be done through DLC mods, not basegame coalesced edits. DLC mounts before the title screen shows up.

Legendary explorer

Legendary Explorer is still in development, and is nearly done. There have been some recent unforeseen issues come up that we are having to work out with distribution and a few remaining things. This has been a full team effort as we have had to update a nearly decade old codebase to add 3 brand new games. We expect this to start being available for use soon – we have done some testing with veteran modders in read-only mode, and a few mods were developed and released by toolset developers as ways to stress test the toolset (and we found and fixed a ton of issues developing them).

New Mod Formats

As part of ME3Tweaks Mod Manager 7.0, I have developed several new mod formats that will ease issues in the long term scene that have plagued the Original Trilogy scene.

Merge Mods

Merge Mods are a new mod file format named m3m. These files are parsed and installed by Mod Manager and apply a specific set of changes to high traffic files like SFXGame.pcc and Startup. In the OT, some mods shipped these files (like ME2Controller), which means other mods that wanted to modify those same files had to make patches built on top of those files.

This made it exponentially worse for every new mod. Users could not choose which to install – it was one or the other for most mods. Merge mods, for the most part, fix this issue by only changing select parts of the file, and is a key part of the new scene. Many quality of life changes can only be done in these basegame files that cannot be shipped in DLC mods.

As such, it is important that changes to these files be distributed through the merge format, which will extend in scope over time. Shipping full file replacements for files breaks a lot of other mods and has caused long term harm to the OT scene, I have seen many mods simply be abandoned due to having to compete with well established mods. Over time I plan to expand what merge mods can do, but for launch I have limited it’s scope.

You can update properties, scripts, and merge assets into existing entries – asset merge is like doing drag/drop in ME3Explorer and replacing existing data (with relink).

Plot Manager Sync

Plot Manager Sync is like a special version of the merge goal, targeting ME1/ME2/LE1/LE2’s plot manager file. The Plot Manager file controls a huge swath of story related progression tracking and is used all the time in the game. Due to how Unreal loads things into memory, loading the basegame one first means values in it could not be overridden. This format changed in ME3 so this does not apply to ME3/LE3.

Plot Manager Sync will find specifically named files in DLC mods and apply their changes to the basegame plot manager sync. This will allow multiple mods to modify this file without overwriting the other. This feature will require updates to mods to work, but there are only 3 known mods that touch this file, and only 2 of them are available for download, with both devs updating their mod soon.

As of writing this post, this doesn’t work for LE1, as we don’t have proper DLC loading yet.

Squadmate Outfit Merge

Note: This does not work yet and will be enabled in a future update as of writing.

In ME2/ME3/LE2/LE3, what outfits a squadmate can wear are determined by what’s listed in the BioP_Global.pcc file. As such, this has the same issue of competing for files if you want to add new outfits that don’t replace existing ones.

Squadmate outfit merge allows Mod Manager to automatically build a BioP_Global.pcc file, along with related data (conditionals, etc) to allow you to add new outfits for squadmates, and have them all work nicely together. By adding a specifically named file in your DLC mod, it tells Mod Manager which files are part of an outfit. All information is then built into a new merge DLC mod that M3 makes, and your outfit works.

This should allow wardrobe mods for squadmates to co-exist.

LE1 DLC Mods are being worked on

Unfortunately, the DLC loader that ME1 had doesn’t exist in LE1. It seems it was crippled by the PS3 port, which is what LE1 is based on. We currently have package overrides working, but DLC mount doesn’t work yet (Bio2DA overrides, TLK, etc). We have a plan to get it to work but it’s going to take some time to implement and test.

It’s going to be more difficult to support ini merges however, for things like bioengine.ini, etc, as the ini merge code also appears to have been stripped out. This will significantly complicate some mods, but a few mods have worked around this, such as Better Camera, which is a merge mod (so it’s widely compatible) and doesn’t touch Coalesced, which does not have a merge feature (text file merging is VERY complicated and error prone, and is often not able to be automated without manual intervention – which users won’t understand).

Conclusion

Glad to have some of these tools out for use, I have seen some interesting and fun mods already being made. One thing we have noticed is some very toxic users of some mods who seem to think they are entitled to the work that we do.

We have spent literally 5 straight weeks working on this, for users to use, FOR FREE. Being toxic or abusive helps nobody. People make mods on their own time, out of their own passion, and many of the recently released ones are designed to be widely compatible. They don’t owe you anything – how much work did you put into these mods you’re installing?

It is very demoralizing to have such toxic mod users who think of nothing but themselves. People who make mods are humans too. If you have nothing constructive to say, please don’t bother.

That’s all for this update. Until next time,

Mgamerz

Mass Effect Legendary Edition arrives in less than a week, and I know many of the mod developers in my scene are excited to start working on it. With that said, I am writing this to ask you to have patience, as updating the tools we’ve spent more than half a decade building is going to take some time. All of these tools were built under the assumption that there would be no more than 3 games.

TOOL UPDATES

I’m here to outline what’s going to be occurring with each of the major tools in the scene.

ME3Explorer (UI ApplicatIon)

ME3Explorer is going to be put into maintenance mode. This means that we won’t have further updates beyond just some simple bugfixes – it will essentially remain as it is now, and will only work on the original 3 games. We’re hoping to issue one final stable build.

We have been working for the last couple of weeks to migrate the existing UI application’s code into a new project, named Legendary Explorer. This application will (eventually) support the Legendary Edition versions of the games, as well as also support the original versions. We are doing this for a couple of reasons:

1. This lets us do a refactor of the project, as the app has had some pretty messy project structure for years now
2. It will better convey that the tool works for the Legendary Edition of the games
3. We are upgrading the project to .NET 5, which is a pretty significant change from .NET Framework 4.8 (do not let the numbers confuse you, this is many years of change). This will require some significant changes to how we also deliver stable and nightly builds to you, and it will take some time before we can get back to automated builds for users. Using nighties will require installing the .NET 5 runtime

The latest nightlies of ME3Explorer have exe version checks, which will prevent adding LE versions of games for game paths, in the event they use the same names of executables as the current games.

ME3ExlorerCore (Library)

ME3ExplorerCore (ME3C) is going to be put into maintenance mode. A new library, named LegendaryExplorerCore (LEC) (or just LegendaryCore, we haven’t decided), will essentially be a copy of ME3C, but with support for Legendary Edition games as well. This is being done for the following reasons:

1. Projects targeting ME3C will not be broken when we have large codebase changes. While this could be accomplished via an older branch, we wanted to make a whole new project to ensure consumers of this library don’t accidentally upgrade and break loads of stuff and waste their time. The original scope of ME3C did not include LE games, and a lot of code was written under that premise, which if we added LE support, would likely break a lot of stuff.
2. If you want Legendary Edition support, you switch to the new library, which will have a slightly different (but mostly the same) API. This will force you to update your application to handle the new game IDs and behavior. Apps using LEC can still work on OT games.
3. If a user of ME3C wants features from LEC, they can backport it to ME3C.

ME3TwEaks mod manager

I’m not 100% sure yet on the plans for M3. I’m thinking of making a ‘new’ Mod Manager named Legendary Mod Manager, but it would be just a rebrand of ME3Tweaks Mod Manager, with support for LE games as well. This will take some time – until we know what we’re dealing with in LE, it will be hard to make Mod Manager support, and I will be working on mod development tools to start with.

Essentially, M3 would be put on ‘maintenance’ mode for some time, before it upgrading it once to support an upgrade to Legendary Mod Manager, LMM, similar to the transition that occurred when moving from ME3CMM to M3.

This plan would be for the following reasons:

1. Users don’t seem to understand that ME3Tweaks is my organization’s name. Not the name of the program. I have lots of other software that I release under my organization.
2. It will take some time to figure things out for Legendary Explorer Core. M3 depends on ME3C, so until we have LEC up and running, LMM won’t really be able to depend on it. Things like opening packages, lots of helper directory classes, that sort of thing.
3. Mod Manager is far more complex under the hood than many users think and adding three more games to the codebase, even if similar, will require a pretty huge investment of time.
4. The server infrastructure that M3 currently uses pretty heavily will need some significant changes to accommodate more games in the databases, web pages, etc.
5. I want to split many core features of M3 into its own library that can be used in other projects, like how the GameTarget class is reused in ALOTInstallerCore, MassEffect2Randomizer, etc. It is a lot of effort to support these duplicates, but it is also hard to make a localizable core library, especially for programs that don’t use localizations.

ALOT Installer

ALOT Installer has some more features planned for the Original Trilogy (OT), but I simply haven’t had time to work on it. ALOT Installer will remain OT only for now.

Once Mass Effect Modder is updated for Legendary Edition (this will likely take some time) I would like to make a general purpose texture installer program that works for LE. I do not expect it to be cross-compatible with OT. A general texture installer would be nice, especially with the same UI as one of the most popular OT mods, however texture modding will not be a high priority for me to start.

Mass Effect Randomizer / Mass Effect 2 Randomizer

These will remain working for their original games. At some point I would like to revisit them for Legendary Edition but it will likely be months if not years. Work on these projects have significantly benefited ME3Explorer (+ME3C), as they stress test the library and help identify weaknesses, and also lead to new features, such as memory-safe extraction, import resolution, and new debugging tools.

ME3TWEAKS MODMAKER

ME3Tweaks ModMaker will remain as it is and only be for the OT version of Mass Effect 3. While I am very proud of the work I did for ModMaker, it is an absolutely huge project that has extremely high support requirements, and was built when I was a much more amateur programmer. 

Since there is no multiplayer in LE, I don’t really see a need for something like ModMaker, which mostly was a gameplay modding tool. ModMaker worked well because multiplayer was very gameplay focused, so changes through ModMaker would be very noticeable, and could work in short spurts. This type of modding doesn’t really translate well to singleplayer which has a lot of things that are specific to each level and takes place over the course of the entire game, and also doesn’t work well due to how the game is compiled – singleplayer and multiplayer use very different strategies for asset loading.

It is a true shame there is no multiplayer in LE.

Gibbed SAve EDITORS

Gibbed has expressed interest in updating his save editors for LE. I don’t expect this will be too much work for ME2/ME3 since it doesn’t look like much has changed in those games. As I am not part of the development of these programs, I don’t have much more info on this.

Mod Guidance

I’m sure many developers want to be the first person to release a mod for LE. In the beginning there will be lots of teething, and there will likely be lots of buggy software. As someone who has to support mods through Mod Manager, there are some things that will be very helpful for later development in the scene:

1. Do NOT use exe installers. These are an absolute nightmare to deal with in the scene, and if some new modding method comes along, nothing can really work with exe mods. Mod Manager can be updated to account for new processes or installation corrections. Manual installation directions can be adjusted. Exe installer based mods cannot have their install behavior changed.Exe installers are also opaque, so it’s hard to know what it will actually install. It makes identifying incompatibilities difficult, especially if only a specific configuration installs a file, but the others don’t.
2. Do NOT leave mod pages with outdated main downloads paired with ‘updates’. These are a huge waste of end user’s time, and also waste tons of developer time because we end up having to support users who don’t know what they’re doing. Spend 20 minutes of your time integrating the update so you don’t waste collective thousands of hours of other people’s time.The exception to this is for mods like ALOT, which are huge, but have whole systems built for handling the update in an easy way.
3. If the new games use the DLC system, DO NOT release variants of your mod with the same folder name. These are not possible to distinguish without tons of investment of my time. Many early mods in the ME3 scene did this, and the only thing it does is confuse users! What version of a mod did I install? Who knows? They’re all named DLC_CON_FUNMOD.Mods installed through Mod Manager (that are designed for Mod Manager) don’t have this problem as I tag the options selected, so even if you have 3 ‘variants’, users can see what was installed. 
4. Use DLC folders if they are supported – basegame file replacements SUCK unless they are absolutely required. They are hard to track, require lots of manual inventorying by me to identify where they came from, and are a pain to uninstall for users.
5. Be prepared for game updates. There will likely be a few months of them and they may break your mod. If files in your mod end up being updated by game updates, but your mod isn’t updated, I may blacklist the mod from installation in Mod Manager due to it leading to different ‘versions’ of games. All mods should be built from the same ‘base’ version of the game, which will eventually be the final game update, whenever that is.This may sound inconvenient to you, but it is much more inconvenient for us developers, when we have to code around poor decisions by mod developers. Make our work easier so we can focus on better tools rather than coding around your work. You may think this is a one time cost, but adding lots of edge cases just means every time we update something else we have to make sure it still works with edge case code, which has an ongoing burden.

There will be some significant pain at the start of modding these games.

1. Some formats have likely changed and will take time to reverse engineer.
2. There will be no reliable cross OT <-> LE modding for some time. Please note that when I say OT <-> LE, I mean porting individual pieces, like the properties of an object, not running a mod through a converter, this will simply not be possible due to them changing to DirectX 11.
3. There will be a lot less debugging tools – we will not have an asi loader, we may not have console access for a bit even. Pray that they leave some debugging tools in the game for us, because it’s going to suck BIG TIME if we are left with nothing. Why do you think there are so few ME2 modders 😉

Again, please be patient. There will be a lot of teething issues for setting up modding in these games. Remember that developers are people too 🙂

Hello everyone,

I’m Mgamerz, owner of ME3Tweaks.com, and the lead developer of the Mass Effect Trilogy editor toolset, ME3Explorer. I also write end user installation tools ME3Tweaks Mod Manager and ALOT Installer. If you’ve modded the series recently as an end user or a developer there is a high likelyhood you’ve used my software to do some or all of it.

Recently, BioWare announced Mass Effect Legendary Edition, which is a remastered version of the original three games. I’d like to share with you what I know about the new games, what they mean for modding, and what my plans are going forward, as I have had many people ask or tell me things that need to be cleared up.

Will existing mods work on Legendary Edition?

No. To be clear, when I say ‘existing mods’, I mean package file based mods, which is the majority of mods. Anything that ends in .pcc, .upk, .u, .sfm are package files, and are what comprise of the majority of each game.

Our files are tied to certain engine versions of BioWare’s fork of Unreal Engine 3. On top of this, each game in the trilogy is on a different build of Unreal Engine 3 with more and more BioWare changes on top, and that spans 5 years of engine development by Epic Games as well. Unless BioWare changes absolutely nothing in their game, things will not work.

Complicating matters is that while our modding tools have improved greatly recently, many mods were built with older, buggier tools, and it is more a bug that they actually work in the game, rather than them actually being properly supported. Many of my older mods even have issues, but the game somehow still works with them.

Essentially, you can think of it this way: Will vanilla package files from the trilogy games work on legendary edition? I’m extremely doubtful, there are too many dependencies on core files that are nearly guaranteed to be changed.

But BioWare says they’re working with the modding community?

BioWare may be working with some people, but I’m not sure who. I’m curious, but I also understand whoever they are, they are under NDA, and asking people things who are under NDA just makes their life more difficult.

However, I’m not under NDA, so I can tell you what I know. Nobody in the toolset development group has been contacted, which consists of three people: Myself (Mgamerz), SirCxyrtyx, and Kinkojiro. We are the ones who build and maintain the tools (ME3Explorer) that are used to make mods, and I personally am the one who also builds the tools that installs the majority of said mods (ME3Tweaks Mod Manager).

These tools are practically required to mod the trilogy (excluding texture-only mods), and all three of the developers know the engine internals in ways that many mod developers don’t – for example, the flags in package headers, various file formats, how property serialization works in our games, Unreal’s memory system, etc.

At this point in development of Legendary Edition, there is not a lot that BioWare can internally change to help with modding. You cannot bolt proper mod support onto a game, it must be done from the start, and nobody reasonable expected BioWare to do such a thing.

What are my concerns?

Ever since Mac Walters tweeted about working with the modding community, I have had dozens of people message me directly about how they’re excited to have existing mods work on legendary edition. Many mod authors are also excited to work on legendary edition.

I do feel that there is an expectation of modding Legendary Edition that is not actually based in reality, and it’s going to cause issues if the game turns out to not be so easy to work with. End users will blame both us, the tool developers, and BioWare, as they feel they were mislead.

They will also blame mod developers because BioWare’s statements made them think this was easy – we have users already come for assistance asking why these games are not easy to mod like Skyrim.

But can BioWare do anything to help?

BioWare for nearly a decade has seemingly taken a ‘do not acknowledge mods’ policy, so for them to say they’re working with the mod community out of the blue is a real whiplash for the scene. I would love to have a conversation with BioWare to discuss things that could help the modding scene that should not take a lot of effort to implement, but I’ll detail some of them below.

1. We need a way to debug the game

ME1 on PC included the application log functionality, which wrote a bunch of useful information to the Documents/BioWare/Mass Effect/Logs folder, including crash information (such as loading an unused mip).

This log functionality was removed in ME2, and all internal debug code also was stripped out, so debugging ME2 is nearly impossible.

ME3 included a blank stub for ‘appErrorF’, which we hooked to get a basic level of debugging, but it’s still pretty weak and often doesn’t have any useful information. Complicating things was the use of TOC files which for years added extra steps to modding that were not required for ME1/ME2.

If you want us to be able to more easily mod the game, we need a way to know what the game engine is doing, or is unhappy about. Can you imagine writing software where the only way you know something is wrong is when the application unexpectedly closes? Because that’s what modding is often like.

We may have advanced tools these days, but when it comes to debugging and fixing a mistake you made, it can be such a frustrating experience that you just give up. If Legendary Edition removes the logs feature and strips out debugging tools we can leverage, it’s going to seriously cripple the ability to mod these games. Even if logging functionality required another edit to enable (such as through the configuration files) it would go a LONG way in helping us.

2. WE NEED A WAY TO LOAD FILES IN AN OVERRIDE FASHION

In the current scene, we load files primarily through the use of the DLC loading mechanism for ME2 and ME3. We recently (about 2 years ago) uncovered some tricks in ME1 to also load DLC overrides in ME1, but it’s weaker and has some caveats, such as not working with movie files and the TLK files being embedded into a billion files (though I doubt this is an issue, as the PS3 version of ME1 did not use this system).

There are some core files that can’t load from DLC, such as SFXGame, which is a real problem because it has a lot of crucial edits. One system that I personally leverage is TESTPATCH in ME3, which can override classes, but we don’t understand how it works well enough to generate new entries.

If the DLC system is removed – which it very well could be, because if this is the ‘best’ version of the games, they won’t need to have post release content, and thus there’s no need for DLC loading – it’s going to greatly complicate modding. Replacing files in the main game is extremely easy to do wrong, leads to wide incompatibility, and is frustrating to support; I know this because for years I wrote multiplayer mods, which required file replacement.

DLC mod loading allowed us to override and remove mods fairly easily. There are plenty of downsides but it is a huge improvement to direct file replacement.

3. Moral support? (optional)

For nearly a decade, modders have built loads of mods – Mass Effect Happy Ending Mod, controller support, bugfix mods, new levels, same gender romances, texture overhauls, etc…

Personally I’ve built about a dozen mods, made many programs, even built an entire web application that can be used to build mods – but I can count on two fingers the amount of times I’ve ever had my work acknowledged by someone at BioWare in any sort of way that actually meant something, beyond essentially them saying ‘cool’.

This is a somewhat weird thing to bring up, but if you look at the creative scene for Mass Effect, there are many areas you look at – artwork, cosplay, streamers, etc, but the modding community is by and large completely ignored, and it is somewhat demoralizing.

We build these mods because we love these games, even if we at times are very critical of your work. This modding scene was actually created because of the critical reception to the end of Mass Effect 3, but it’s because those people loved the series, not because they hated it.

There are likely a lot of legal ramifications that bar you from coming out and endorsing mods, plus a lot of things like ‘is this a reputable person’, etc. that are not really present when you post on a picture on Twitter that someone made. I also know that by tweeting or coming out saying ‘What a nice mod this is!’, people would almost assuredly misinterpret it as you ‘supporting’ mods, rather than just ‘supporting the idea of them’.

That said, it would be nice if the work we do could at least have a way of being acknowledged. For years we have been mostly ignored, and while I’m sure some developers are fine with this, it would greatly improve modding morale if we at least knew someone at BioWare actually cared, or at least thought it was interesting, even off the record. I’m sure there are some people that make these games that do enjoy our work, but you would be hard pressed to find anyone who develops mods that knows that.

4. WE NEED A WAY TO IDENTIFY WHICH FILE BELONGS TO WHICH GAME

Yes, this is a real nitpick, but it’s actually come up when trying to parse files from PS3 and Xbox assets of ME games. If package file headers could have some way to identify their game (something unique, like package tag) it would greatly reduce complexity. It seems small but as someone who works on tools, knowing what game a file belongs to is VERY IMPORTANT.

This is of course assuming that you are unifying the engine versions, which I assume you are, since this was already done for the PS3 versions of the games.

Future plans

I plan on working on legendary edition, but I want to make it clear to end users AND mod developers that things are going to take time. One of the things that greatly concerns me is how news sites are saying how great this game will be to mod based on just a few tweets and an interview that did not really talk about modding.

I want to make sure users and developers understand that modding will take time, will not work on day one, and likely will not work on month one, and will likely have serious teething issues possibly for years.

As someone who works at the top of the modding chain, a lot of the development efforts have fallen to me – a developer needs a feature in Mod Manager for their mod? I have to implement it. Need an easier way to edit game files? One of the toolset developers typically has to do it – and we do this for free on our own time.

The other developers I work with (SirCxyrtyx and Kinkojiro) are great people who have all done years of research and development, and together we’ve built lots of great tools and features, such as Pathfinding Editor, entry porting and relinking, dialogue editing tools, and more.

I personally spent YEARS developing and refining Mod Manager and have spent years completely reworking ME3Explorer into a much more professional grade tool. Our scene is much healthier than it was back in 2013-2015 when our tools were still immature, making and using mods is far easier these days. Some of this progress is going to be reset with the release of Legendary Edition.

WILL EXISTING TOOLS WORK ON LEGENDARY EDITION?

Short answer, no. We will have to wait and see. I do not have any plans to have ME3Tweaks Mod Manager work on LE – it will require me to build a new tool, as M3 is very tailored to the current games, tools and codebase. ALOT Installer will not be necessary (hopefully!), and ME3Explorer may be forked into a new project depending on how much has changed internally, but we don’t really know anything useful yet. 

Personally, I am not a fan of trying to build a conversion tool between the trilogy games and legendary edition, as it would be a monumental amount of work, especially if we don’t understand changes to the internals of the games (including many things we currently don’t know about the existing games). The toolset already supports about 7 or 8 games across 4 different platforms, adding another 3 will be significantly complicate the codebase. But it really depends on how much is changed.

Anything else?

Yeah, the last thing I’d like to mention, is that a lot of this post is about the developer side of things. Myself, SirCxyrtyx, and Kinkojiro have all done absolutely masochistic things in the name of research and development (but especially Kinkojiro), but the flip side is that there are far more users who have little to no patience even installing mods.

If installing mods is difficult (such as a complicated system without a DLC loader), many users will not even attempt it, and this leads to diminished returns on the development side. I work on both sides of the coin, writing the tools for installing mods, as well as developing them, and over time  I’ve adjusted my software to make it easier for users.

I’ve noticed that as it becomes easier to install mods, more developers have appeared, and part of it may have to do with decreased support time for mods. My end-user tools for example have a very detailed diagnostic system that can be used to identify a wide variety of issues, which means users don’t have to ask developers how to fix things.

CONCLUSION

I believe our modding tools for legendary edition could be greatly improved if we had someone we (the modding toolset developers) could talk to at BioWare about, as there are still many gaps in our knowledge of BioWare’s proprietary changes to the engine that significantly hinder our efforts. With the release of Legendary Edition, those knowledge gaps will likely significantly widen. 

Want to have a talk about some other things the scene could use BioWare? Drop me a line at femshep AT me3tweaks.com, there are many small things that would greatly reduce the friction of modding that would really help set up the scene for success.