{"id":416,"date":"2026-11-07T10:00:44","date_gmt":"2026-11-07T10:00:44","guid":{"rendered":"https:\/\/www.me3tweaks.com\/blog\/?p=416"},"modified":"2026-11-07T17:03:16","modified_gmt":"2026-11-07T17:03:16","slug":"porting-mass-effect-3-multiplayer-to-legendary-edition","status":"publish","type":"post","link":"https:\/\/www.me3tweaks.com\/blog\/modding\/porting-mass-effect-3-multiplayer-to-legendary-edition\/","title":{"rendered":"Porting Mass Effect 3 Multiplayer to Legendary Edition"},"content":{"rendered":"
\n
\n
\n
\n

\"Image<\/p>\n

Legendary Edition Multiplayer Launches!<\/h1>\n

The ME3Tweaks group has been working to port Mass Effect 3 multiplayer in full to Mass Effect Legendary Edition since November 2023. On November 7, 2026, we finally shipped! Legendary Edition Multiplayer brings back the classic Mass Effect 3 multiplayer experience, with changes throughout brought to you by the experts who modded the original extensively, with plans to expand and improve further in the future.<\/p>\n

 <\/p>\n

In this post I’ll go over a bit of history of the project.<\/p>\n

 <\/p>\n

Basic timeline<\/h2>\n

2023\/2024<\/h3>\n

This project started literally the day I launched Mass Effect 2 Legendary Edition Randomizer. The Discord got set up a few days later so we would be less likely to accidentally leak the project.<\/p>\n

\"Image
The opening messages for the private development Discord<\/figcaption><\/figure>\n

The name Project Milan comes from the ME3Tweaks’ group talks with BioWare before release of Mass Effect Legendary Edition. One of the developers was screen sharing with us, and we saw a Google Drive folder with their project codenames, like Dylan and Bowie. For some reason, I misremembered one of them being ‘Milan’. Years later, when this project was starting, I decided to reuse that name as the name of this project – hence, Project Milan.<\/p>\n

 <\/p>\n

We made rapid progress getting a basic level up and running with a multiplayer kit, taking about two months to get it to a state where you could actually complete a full match (technically it would crash as soon as you finished wave 11). A ton of scaffolding needed to be brought up for this – an entirely new pipeline system, similar to CrossGen-V, but using what we learned from that to allow it to scale better. At the time we didn’t know the scope of this project would grow this large.<\/p>\n

 <\/p>\n

I made a small internal trailer back in 2024 to try and motivate myself and the rest of my team after we started to burn out on the project. It shows some of the early gameplay prototyping we had going at the time. It’s kind of cringe, especially with how AI has changed since it was made.<\/p>\n

 <\/p>\n

We planned to implement Redemption and Rejection early on in the development process, splitting its pipelines off into a sub-project called ExtraContent, or EC for short. It lets us build them standalone as DLC mods or as part of the main mod with full integration. We started work rebuilding Rejection from scratch, using new class compiler system to let us define a lot more of it in C# than in package files. Rejection got put on the backburner once we got it prototyped, since it was planned for post-release.<\/p>\n

\"\"
A prototype change of the Forerunner. The hair mesh of the original pawn is mixed with the embedded hair in the single mesh that multiplayer uses.<\/figcaption><\/figure>\n<\/div>\n
\n

 <\/p>\n

One big thing to come out of this year was the prototype for the Texture Override system, what would eventually later become M3TO. This allowed us to replace textures at runtime, something we wanted to have since Mass Effect Modder would significantly complicate modding multiplayer given the additional restrictions.<\/p>\n

\"\"
Look, it wouldn’t be a blog post without the Edmonton Cheeseburger<\/figcaption><\/figure>\n<\/div>\n
\n

We pivoted to Pinnacle Station 2.0 for 2024’s N7 day, using the pipeline tech we built for Project Milan to handle its lighting build. Lighting was easier to build for Pinnacle Station because we had the data from ME1 available to build shaders in UDK, which are required for a proper lighting bake. Pinnacle Station was a proof of concept for what we would be doing in Project Milan’s later builds.<\/p>\n

 <\/p>\n

2025<\/h3>\n

Not much work was done in 2025 due to real life issues. Some work was done – mainly shader research – but we didn’t make too much heavy progress. Shader compiler research was slow, extremely challenging, and the scope of the work was immense. We used UDK to help figure out how some of the shaders would have compiled, even though it wasn’t the same as BioWare’s shader compiler system.<\/p>\n

 <\/p>\n

\"\"
Screenshot of the shader serialization hook for debugging with the team<\/figcaption><\/figure>\n

I discovered during reverse engineering that the HLSL Translator – the system that converts a Material export into HLSL for compiling as part of the complicated web of USF HLSL files – was still left in the game, but unable to be used without significant hijacking of the game. Eventually I was able to force the game to produce these HLSL files, which saved us a ton of time – but unfortunately, this was actually just the easy part.<\/p>\n

LE3 has dozens of vertex factories and hundreds of types of shader classes – many of which can be mixed to produce even more permutations. In the original C++ source code, this was templated C++ code, which made it hell to reverse engineer. I developed ShaderHost and ShaderClient. ShaderClient would inject into the game and force it to compile shader data, which it would pipe out to our C# ShaderHost which could capture it and store it into usable ShaderCaches. It would also orchestrate building shader levels that would trigger ShaderClient, as well as preview them.<\/p>\n

 <\/p>\n

\"Image
2025 view of ShaderHost – previewing compiled shaders for review<\/figcaption><\/figure>\n

I also prototyped integrating with the Discord Social SDK to provide more platform features like direct friend invites. We actually have a semi-working ASI for this, but there are some serious features lacking in the overlay that made us de-prioritize this. Discord unfortunately hasn’t really fixed it so the utility of the ASI is pretty low.<\/p>\n

 <\/p>\n

2026<\/h3>\n

In 2026, work picked back up on the project throughout the year, as different components started to come together: Wwiser.NET, shader compiler, unattended lighting bakes, among other things. We started to be able to compile the full game and have it feel like a playable game. Things were still broken – progress saving was really spotty, we had no matchmaking services, and shaders were compiling but often felt off, mainly because we didn’t have the correct macros that BioWare used to compile the shaders from the HLSL and the USF files the game ships with. Mass Effect 3 (2012) doesn’t ship with them, so there’s very little to compare against.<\/p>\n

 <\/p>\n

I spent some time looking at porting Pinnacle Station maps from LE1 to LE3 and what cross-level porting would require. I had ported LE2 maps to LE3 before this project started as part of an abandoned project called Project Wardle<\/em>. I had ported Jacob’s Loyalty mission to LE3, with working cover. In early March we got some basic working versions of Pinnacle Station, at least visually. Cover was effectively non-existent, since LE1’s cover system is extremely basic and lacks most of what LE3’s cover system needs.<\/p>\n

\"Splash
Loading splash screen for Milan UDK – A custom install of UDK we use for building lighting<\/figcaption><\/figure>\n

I spent some time researching the cover system for LE3, trying to build some sort of tool that could at least build basic working cover. I did get a super basic working version of dynamically generated cover, but it falls apart when the level geometry doesn’t follow standard cover height or has ramps, or weird spacing. It got shelved to focus on Project Milan development.<\/p>\n

 <\/p>\n

\"CoverClient
CoverClient showing different types of cover data the AI uses to determine the optimal place to position itself<\/figcaption><\/figure>\n

Around April of 2026 we made the decision to fully split Legendary Edition Multiplayer (LMP) into an entirely new game. It still requires you to own Mass Effect Legendary Edition, but it won\u2019t interact at all with the original game anymore – settings, saves, mods – everything is entirely separate. This was done to ensure mods developed for LE3 must be properly reimplemented to work in Project Milan – there is a much larger set of barriers for mods being used in a replicated environment.<\/p>\n

This task added a lot of work – Mod Manager, Legendary Explorer, and all sorts of other tools needed updating, which took significant amounts of time to develop. We also started using AI at this point to begin accelerating some of the work for our tooling – such as making Legendary Explorer have a dark theme.<\/p>\n

 <\/p>\n

Near the end of July 2026 we set the target release for N7 day, not knowing that there was still a mountain of work ahead of us. At this point we had most of the assets working properly, the rest of development was polishing and adding new features. Most of the team started to come together for this release – textures, playtesting, feedback, among other things.<\/p>\n

\"\"
Splash screen for development builds of Project Milan<\/figcaption><\/figure>\n

 <\/p>\n

We picked up a new workhorse member, Stumpy, who was vital to getting this thing out the door. I tricked him into joining the project by telling him I was doing a settings overhaul. Once he joined, his first message was ‘I guess “mod that overhauls the settings system” is accurate… in a way’<\/em> once he joined the development Discord server. Give Stumpy a big round of applause for making it through the grueling torture he endured trying to build all of the private versions of our development tools. He crashed out multiple times.<\/p>\n

 <\/p>\n

We have a lot of new features for Legendary Edition Multiplayer, too many to show pictures of, but we wanted to focus on things that would make the game feel better to play beyond just a texture upscale and higher quality lighting.<\/p>\n

Some of those features include:<\/p>\n

    \n
  • Improved pause menu showing player death status, invite generation, and player pings<\/li>\n
  • Player names showing their health status during gameplay so you can tell if someone is in critical need<\/li>\n
  • New banners to unlock for more personalization<\/li>\n
  • In-game configurable Field of View (FOV) and aim assist tweaks<\/li>\n
  • Heavy weapon options to change up gameplay<\/li>\n
  • Entirely new splash menu that showcases each map<\/li>\n
  • Integration with the main singleplayer campaign by unlocking content via achievements (LMP will not progress anything achievement related)<\/li>\n
  • New wavelist options: Coalition (random enemy faction per wave) and Unified (random enemy waves, scaling per wave)<\/li>\n<\/ul>\n
    \"\"
    Heavy weapon selection with the cleaned up Talon Mercenary<\/figcaption><\/figure>\n

    We integrated a lot of new debug features for future mods and laid a lot of groundwork for future expansion that you won’t notice as an end user, but will become relevant later. We have a lot of ideas we wanted to implement that we just didn’t have time to flesh out, some of which haven’t been discussed publicly yet, so stay tuned for updates for when they do come out.<\/p>\n

     <\/p>\n

    We’ve been working on this literally up until 12 hours before launch time. I spent way too much time writing this blog post when I should have been designing the mod page instead.<\/p>\n

     <\/p>\n

    Using UE4 to build lighting for a UE3 game<\/h2>\n

    In the latter half of August 2026, as our level porting began to fully take shape, we started focusing more on the lighting quality. Baking static lighting for levels is important for performance, and our detour releasing Pinnacle Station 2.0 in 2024 was our initial implementation of lightbaking via UDK. We spent a significant amount of time comparing lightmaps from ME3, LE3, and UDK\u2019s Lightmass.<\/p>\n

     <\/p>\n

    We learned that Unreal Engine 4 also has Lightmass, and SwarmAgent – the coordinator that UE3 also uses for lighting compute. Lightmass in UE4 is a direct continuation of the UE3 version, taking a scene, light sources, materials, shaders – and does a lighting simulation. The UE4 version has better light bouncing and performance and has a very similar interface.<\/p>\n

     <\/p>\n

    Using our UDK injection dll, we were able to deploy a shim that could redirect UDK\u2019s scene export into UE4\u2019s lightmass, have that process the lighting compute, and then feed it back through the shim (which translated it back to UDK\u2019s format) and then put it back into the packages.<\/p>\n

     <\/p>\n

    Production lighting on my workstation (128GB memory, Ryzen 5900X) for each map at a 2x lightmap scale from BioWare\u2019s ME3 version takes about 30 minutes, and originally used about 55GB during the bake until we reduced the importance volume so lighting quality was more focused. A full production build of Project Milan takes about 9 hours when lighting bake is added.<\/p>\n

    \"\"
    Top right: UE3 Lightmass, Bottom left: UE4 Lightmass (WIP), Bottom right: original ME3<\/figcaption><\/figure>\n

     <\/p>\n

    Tuning this took quite a while, given how long light bakes take, and that some of the information needed to bake lighting like BioWare did was stripped from ME3 at build time. Being able to tune this allowed me to finally develop an idea I had for Redemption mod back in the day, but could not get working: A proper night map that makes use of flashlights.<\/p>\n

     <\/p>\n

    \"\"
    Night mode Hazard Giant with photo mode. This picture shows the brightest part of the map, other areas are nearly pitch black.<\/figcaption><\/figure>\n

     <\/p>\n

    Tooling used in the project<\/h2>\n

    Project Milan had a very wide set of tools that were used at just about any time. Development would regularly involve 6 or more open Visual Studio solutions along with Ghidra and multiple copies of the game. Different tools that were regularly open:<\/p>\n

      \n
    • ME3Tweaks Mod Manager<\/li>\n
    • Legendary Explorer<\/li>\n
    • Ghidra<\/li>\n
    • Visual Studio Solutions \/ Projects:\n
        \n
      • ME3-ASI-Plugins (dump ME3 profile)<\/li>\n
      • MilanClient + MilanServer (ASI and Matchmaking)<\/li>\n
      • LECCLI (AI investigative tool)<\/li>\n
      • LExASIs – Debug Logger, Function Logger, PNG Screenshots (for some advanced photo systems) etc.<\/li>\n
      • Project Milan\n
          \n
        • ShaderHost<\/li>\n
        • LEDecooker<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

           <\/p>\n

          New content<\/h2>\n

          We spent a good deal of time planning new features that didn\u2019t come together until near the end of development. We didn\u2019t get all the things we wanted in time for release, but here\u2019s a couple highlights:<\/p>\n

          Photo mode<\/h3>\n
          \"\"
          Photo mode in LMP. There’s tons of options to follow, change smoothing, or just flycam. It remembers your settings for the next time you die.<\/figcaption><\/figure>\n

          Photo mode was a new addition to Legendary Edition. However, it doesn\u2019t really work in a networked, multi-player setup. It took us several weeks to refine Photo Mode to work in the new environment, including camera transitions, player switching, hiding of different UI elements, and then backing out all of that when you regain control of your character.<\/p>\n

           <\/p>\n

          Photo mode is accessible when in spectator mode. Photo mode effectively is an enhanced spectator mode, allowing full-map freecam, motion smoothing, photo filters, and more. We plan to add more photo filters once we get a better material editor in Legendary Explorer, as it\u2019s pretty difficult to preview. We plan to allow you to use photo mode from other parts of the game, but we have to make sure it makes sense – the host going into photo mode in a public match significantly degrades the experience. But in private matches, you should have expanded freedom – something we’re planning for multiple other features too.<\/p>\n

           <\/p>\n

          Banners<\/h3>\n

          Banners are a feature of Mass Effect 3 Multiplayer that was introduced in the Retaliation DLC (MP4). They allow you to have a background for your lobby slot in the game lobby. They provide a bit of fun customization, and by the end of ME3\u2019s development there was a fair number of them.<\/p>\n

          We added more than a dozen new banners, with more on the way. They drop via Mass Effect Legendary Edition achievements, store drops, and other mysterious ways. We plan to have a community banner contest like BioWare did to feature some new ones for everyone to use.<\/p>\n

          \"\"
          Banner selector that shows all unlocked banners, accessible from the main multiplayer menu<\/figcaption><\/figure>\n

          We added an in-game UI to select a banner you’ve unlocked. We added the ability for banners to unlock via Legendary Edition achievements, as well as various ones in the store packs. We included new items from across BioWare\u2019s catalog of software and various communities related to Mass Effect. These don\u2019t have a meaningful impact but I do recall enjoying having a new fun banner to wear.<\/p>\n

           <\/p>\n

          Accessibility for screen overlays<\/h3>\n
          \"\"
          Krogan Rage on Firebase White Hazard. Left: Normal (like ME3), Right: Reduced<\/figcaption><\/figure>\n

          Some of our playtesters brought up some longstanding annoyances with the original game, including issues with colorblindness for certain screen overlay effects. Since we have a working shader compiler, we were able to patch in some additional inputs to the shaders that let us tone down the effects. By default, overlays stay at their ME3 defaults, but you can adjust a few overlay effects in the options:<\/p>\n

            \n
          • Geth Scanner \/ Hunter Mode (does not affect enemy overlay)<\/li>\n
          • Krogan Rage<\/li>\n
          • Bloodlust<\/li>\n
          • Repair Matrix<\/li>\n<\/ul>\n

             <\/p>\n

            We left some of the other screen effects alone that don\u2019t have much impact on the visibility of the viewport, such as the effect from Barrier. We may add more as needed. You can change these in the Options > Accessibility > Screen effects menu. I recommend Geth Vision and Krogan Rage set to Reduced.<\/p>\n

             <\/p>\n

            Hazard Map changes<\/h3>\n

            We made changes to three of the hazard maps. We thought about changing the others, but didn’t have time to prototype anything else out. Some of them don’t really have any interesting gimmicks beyond limited fog visibility, which does change things up but isn’t really unique.<\/p>\n

             <\/p>\n

            Giant Hazard<\/h4>\n
            \"\"
            Combat feels quite different on Giant Hazard now. Playtesters really like this map, we’ll probably make more night versions, but as separate copies instead<\/figcaption><\/figure>\n

            Some of the hazard maps are pretty dull. Hazard Giant for example is just darker, but still very bright to the point where the darkness doesn\u2019t really make a meaningful difference. There\u2019s a light flash and small screen shake from the cannon, but it\u2019s not very often. In the script that controls the cannon, it looks like the other two were designed to be used, but ultimately got disconnected. When connected, they fired a lot more, which actually provided a hazard, but it\u2019s also annoying to get blinding light flashes all the time, so I understand why they likely pulled the plug on those two.<\/p>\n

             <\/p>\n

            A concept for a map I worked on for Redemption back in 2019 was the area on Tuchanka where you have to use flashlights. It at one point was playable in multiplayer, but the flashlights didn\u2019t work off host and eventually it got axed, but it was fun in testing.<\/p>\n

             <\/p>\n

            I carried that idea into Hazard Giant. By tuning the lighting – at runtime for character lighting and at lighting bake time for static lighting, we were able to create a much darker version of Hazard Giant, that actually uses flashlights that dynamically spawn on the player. I actually expected this to play poorly in my first tests, but it worked out really well, and after a week or so of tuning we had it dialed in pretty good. The hazard is now a significant reduction in long range visibility, but not due to blinding like White Hazard or Dagger Hazard. In playtesting everyone really enjoyed this map as it feels very different. We likely will expand on this concept for other maps in the future.<\/p>\n

             <\/p>\n

            Glacier Hazard<\/h4>\n

            Glacier Hazard already has a semi-interesting mechanic with the roaming bees. I\u2019ve made videos about the bees in the past and how they work. Due to either an oversight or something intentional done by BioWare, the script that controls who the bees follow has logic for which player to follow, but it never can reach players 2\/3\/4. So it follows the host player in every zone they are in. The bees are slow enough that this isn\u2019t super noticeable.<\/p>\n

             <\/p>\n

            We had bigger plans for the bee swarm that didn’t make it in time for release, which may come in a future update. The notable change is that the bees are now triggered by enemy damage as well as player damage, so stormtrooper aim will be punished. We didn’t find this to be too disruptive in playtesting, because enemies don’t randomly fire into them unless it’s between them and you, which didn’t happen very often. Enemy Area of Effect (AOE) attacks don’t affect it either – something we plan to work on for future updates, as it enables us to do more interesting damage-based events.<\/p>\n

             <\/p>\n

            Reactor Hazard<\/h4>\n

            This map got some notable changes that likely won\u2019t be noticed unless you played a lot of the original multiplayer. The level gimmick is a button you can press to close the reactor door, which after a few seconds closes the door and cooks everything inside for 5 seconds. It\u2019s great for trolling your friends and we left that in.<\/p>\n

             <\/p>\n

            But that\u2019s about it. It\u2019s a pretty boring hazard – you can choose to entirely ignore it and it works just the same as the normal map. So we added hitboxes to the buttons, similar to how the hitbox for the bees causes an event to occur, in this case, a button press. Doing a bit of damage to any of the buttons while the reactor is primed will now trigger the event as if you pushed the button.<\/p>\n

             <\/p>\n

            The buttons now turn red when the reactor venting is triggered to provide more feedback. This means a firefight  might end up cooking people inside, or you can snipe the button from distance to shut down enemies you routed through it. In playtesting it led to more advantageous reactor cooking and also great trolling on Stumpy. Right now it doesn’t work with AoE attacks, similar to the bee swarm on Glacier, but we want to fix that so large enemy attacks also can trigger it.<\/p>\n

            \"\"
            You can now trigger the hazard remotely… friend or foe!<\/figcaption><\/figure>\n

            As for bugfixes – the main one is that the doors now properly block enemies from walking through them. When enemies are on the pathfinding network and traversing it, they actually ignore collision for some things. This includes the doors. As a result enemies would just walk through the closed door if they were already on the way to attacking you, something that greatly angered me back in the day. Enemies no longer can walk through the doors because we disabled the pathfinding nodes near the doors when closed – which means they can\u2019t be on the pathfinding network when closed – and thus can\u2019t walk through them.<\/p>\n

            This also required a change for the escort drone – something I have a personal vendetta against from Redemption map making – if the drone can\u2019t find a pathfinding path to the endpoint on spawn, it immediately gives up and finishes the objective. If you were to activate it right as the doors slammed shut, you could cheese the objective and have it finish immediately.<\/p>\n

            As much as I love cheese, this one wasn\u2019t something I\u2019d let go, so when nav points are temporarily turned off, we track how many disabled. If any are disabled, the escort drone just waits. Once they are all enabled, it can then fail if it can\u2019t pathfind, like normal, but it closes the loophole introduced by locking the drone in the oven.<\/p>\n

             <\/p>\n

            Upcoming Content<\/h2>\n

            We have quite a bit of planned content for post-release, starting with some polishing of the initial release, plus some features we cut for time.<\/p>\n

             <\/p>\n

            As for larger content drops, we have at least three content packs planned with varying levels of prototyping already completed.<\/p>\n

             <\/p>\n

            Redemption Map Pack<\/h3>\n

            Redemption Map Pack in the original game was my DLC mod that added multiple new maps to the game, ported from Singleplayer. It includes maps such as Shipwreck (from Leviathan DLC), Sanctuary, and all the Armax maps, to name a few. <\/p>\n

            \"\"
            Playtest for Redemption. As you can see it’s very broken<\/figcaption><\/figure>\n

            With new tooling available to us, we plan to remake this DLC from the ground up to have correct lighting, pathing, and less networking issues. We also plan to attempt to build an entirely brand new map with working cover – something nobody\u2019s actually been able to do yet. We played a map on Armax Classic as a playtest and it worked, but the visuals are pretty broken and none of the interactive features work yet.<\/p>\n

             <\/p>\n

            Rejection<\/h3>\n

            The Rejection DLC mod added a new faction called the Rejects. It was essentially a collection of singleplayer enemies that never got put into multiplayer – CAT6, Adjutant, Rampart, plus some smaller enemies like the Geth Sniper (Legion). I had tweaked this faction to be more difficult, and they proved challenging, but it was not the most stable mod at the time.<\/p>\n

            \"\"
            Playtesting Rejection in 2024<\/figcaption><\/figure>\n

            We prototyped Rejection back in 2024 and 2025, and it plays, but we haven\u2019t actually done a network playtest yet. There\u2019s likely a lot of work to do to fix the problems the original version had, which had enemies with code that executed on host only without proper client replication. We\u2019re also planning to change up the roles a bit now that we have a team for development.<\/p>\n

             <\/p>\n

            Reinstatement (working name)<\/h3>\n

            Part of developing Project Milan\u2019s pipelines involves building the code that generates all of the config changes required for kits, as well as compiling the assets. For example, provided a set of meshes, we can compile a kit using a base set of animations, port in powers, hook all of it up in config so it drops from the store and can be selected.<\/p>\n

             <\/p>\n

            We don\u2019t have this working yet, however, we do have a single kit that builds and is quite overpowered right now. This one\u2019s still a way off, but once it\u2019s up, making new kits should be much easier.<\/p>\n

             <\/p>\n

            Other changes<\/h3>\n

            In the short term, we plan to add some things we didn\u2019t get into the final build for release. This includes things such as:<\/p>\n

              \n
            • Banner selection in the multiplayer lobby<\/li>\n
            • Direct-purchase store rather than random loot drops (they\u2019ll still be around)<\/li>\n
            • Downed UI showing your medigel count and distance to a nearby teammate<\/li>\n
            • Implementing the Battlefield 3 Infiltrator – we have it working, but its powers are weak and we wanted to spend more time tuning it to be less boring<\/li>\n
            • Making the \u201cpizza run\u201d work as proper running rather than requiring dexterity that not all players will have which puts them at a disadvantage<\/li>\n
            • Completely replacing the Challenges UI – it\u2019s a total disaster in ME3 and it\u2019s still a disaster in our version even though we attempted to fix it<\/li>\n
            • Entering invite-codes in game – this was delayed because Microsoft completely broke controller keyboard input in recent Windows updates<\/li>\n
            • In-game text chat improvements<\/li>\n
            • Configurable lobby sizes – we have tested this and it\u2019s mostly working now across the entire game, but a few UIs don\u2019t support it yet so we didn\u2019t ship this<\/li>\n
            • Improved blind firing<\/li>\n
            • Splitting up the omni-key so you can rebind each part in-game (or keep it as it is)<\/li>\n<\/ul>\n

               <\/p>\n

              Information for modders<\/h2>\n

              Package File Format changes<\/h3>\n

              Files made for Project Milan are not compatible with the other Mass Effect Legendary Edition games. We purposely broke LE3 direct compatibility to increase the difficulty of porting content between games because a mod developed for LE3 is very unlikely to properly work in LMP without breaking replication. A player hosting a broken replicated lobby will cause clients to try to join and immediately have problems, which degrades the experience, so we have purposely broken this compatibility.<\/p>\n

               <\/p>\n

              We also made significant changes to the basegame, so files for LE3 will not natively work in LMP without changes. If you attempt to do it manually the game will simply crash. By breaking compatibility, we are able to leave any baggage behind and force new mods to be redeveloped, rather than using ancient incompatible versions. We don\u2019t have plans to support mods for the initial release version, but we will open up modding for it once we have a more stable foundation for mods to build on and tooling that is more aware of these issues. We also want to make it so changes mods need can be done at the basegame level, so that DLC mods can work without having to edit the packages. An example of this is having us expand what is marked as config, so you don’t need to ship packages to tune various things.<\/p>\n

               <\/p>\n

              You’ll be able to open packages with newer builds of Legendary Explorer, which will come out shortly after release while we sort out merging the private codebase back to the public one.<\/p>\n

               <\/p>\n

              Use of AI in this endeavor<\/h2>\n

              When I started writing this blog post, there wasn\u2019t much AI used in our scene for modding. In the past two months or so, it has exploded.<\/p>\n

               <\/p>\n

              For the first two years of this project, we did not use any AI – all of the initial prototyping work was done manually – reverse engineering, native patching, controller support in user interfaces, mod building, pipeline development, exporting to UDK and building lighting, etc. Development time during the first two or so years was almost entirely devoted to asset porting and creation – audio, lighting, shaders, etc. Big chunks of this were part of the LEDecooker project – a system that converts the Legendary Edition games into a system UDK can support loading without crashing.<\/p>\n

               <\/p>\n

              In the final 5 months of development, we began to use more AI to help expedite bug fixing, UI prototyping, pipeline performance, and feature research. <\/p>\n

               <\/p>\n

              I developed a custom agent tool called LECCLI to help perform game research. It\u2019s a  command line tool that wraps Legendary Explorer Core, the library that powers most of the scene\u2019s modding software – we developed it. This command line application runs a client\/server model, with the AI harnesses invoking the client, which then interacts with the server. This lets invocations be cheap (performance wise) and allows the server component to cache things for near-future tasks.<\/p>\n

               <\/p>\n

              This tool was explicitly designed only for research: it purposely cannot save game packages, but it could be used to initiate its own investigations, combing through decompiled classes, textures, user interfaces, configuration files, etc. It can render meshes, preview UIs in scaleform, resolve localized strings, search the entire game at once for usages, among other things. This allowed our AI tools to get a view of the entire game all at once and was very useful for finding bugs in our own edits. An example of a few things it was able to quickly figure out for us that weren\u2019t immediately obvious:<\/p>\n