Legendary Edition Multiplayer Launches!

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.

 

In this post I’ll go over a bit of history of the project.

 

Basic timeline

2023/2024

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.

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.

 

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.

 

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.

 

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.

 

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.

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.

 

2025

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.

 

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.

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.

 

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.

 

2026

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.

 

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. 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.

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.

 

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’t 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.

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.

 

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.

 

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’ 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.

 

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.

Some of those features include:

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

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.

 

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.

 

Using UE4 to build lighting for a UE3 game

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’s Lightmass.

 

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.

 

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

 

Production lighting on my workstation (128GB memory, Ryzen 5900X) for each map at a 2x lightmap scale from BioWare’s 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.

 

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.

 

 

Tooling used in the project

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:

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

 

New content

We spent a good deal of time planning new features that didn’t come together until near the end of development. We didn’t get all the things we wanted in time for release, but here’s a couple highlights:

Photo mode

Photo mode was a new addition to Legendary Edition. However, it doesn’t 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.

 

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’s 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.

 

Banners

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’s development there was a fair number of them.

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.

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’s catalog of software and various communities related to Mass Effect. These don’t have a meaningful impact but I do recall enjoying having a new fun banner to wear.

 

Accessibility for screen overlays

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:

• Geth Scanner / Hunter Mode (does not affect enemy overlay)
• Krogan Rage
• Bloodlust
• Repair Matrix

 

We left some of the other screen effects alone that don’t 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.

 

Hazard Map changes

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.

 

Giant Hazard

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’t really make a meaningful difference. There’s a light flash and small screen shake from the cannon, but it’s 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’s also annoying to get blinding light flashes all the time, so I understand why they likely pulled the plug on those two.

 

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’t work off host and eventually it got axed, but it was fun in testing.

 

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.

 

Glacier Hazard

Glacier Hazard already has a semi-interesting mechanic with the roaming bees. I’ve 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’t super noticeable.

 

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.

 

Reactor Hazard

This map got some notable changes that likely won’t 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’s great for trolling your friends and we left that in.

 

But that’s about it. It’s 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.

 

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.

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’t be on the pathfinding network when closed – and thus can’t walk through them.

This also required a change for the escort drone – something I have a personal vendetta against from Redemption map making – if the drone can’t 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.

As much as I love cheese, this one wasn’t something I’d 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’t pathfind, like normal, but it closes the loophole introduced by locking the drone in the oven.

 

Upcoming Content

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.

 

As for larger content drops, we have at least three content packs planned with varying levels of prototyping already completed.

 

Redemption Map Pack

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. 

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’s 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.

 

Rejection

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.

We prototyped Rejection back in 2024 and 2025, and it plays, but we haven’t actually done a network playtest yet. There’s 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’re also planning to change up the roles a bit now that we have a team for development.

 

Reinstatement (working name)

Part of developing Project Milan’s 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.

 

We don’t have this working yet, however, we do have a single kit that builds and is quite overpowered right now. This one’s still a way off, but once it’s up, making new kits should be much easier.

 

Other changes

In the short term, we plan to add some things we didn’t get into the final build for release. This includes things such as:

• Banner selection in the multiplayer lobby
• Direct-purchase store rather than random loot drops (they’ll still be around)
• Downed UI showing your medigel count and distance to a nearby teammate
• 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
• Making the “pizza run” work as proper running rather than requiring dexterity that not all players will have which puts them at a disadvantage
• Completely replacing the Challenges UI – it’s a total disaster in ME3 and it’s still a disaster in our version even though we attempted to fix it
• Entering invite-codes in game – this was delayed because Microsoft completely broke controller keyboard input in recent Windows updates
• In-game text chat improvements
• Configurable lobby sizes – we have tested this and it’s mostly working now across the entire game, but a few UIs don’t support it yet so we didn’t ship this
• Improved blind firing
• Splitting up the omni-key so you can rebind each part in-game (or keep it as it is)

 

Information for modders

Package File Format changes

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.

 

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’t 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.

 

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.

 

Use of AI in this endeavor

When I started writing this blog post, there wasn’t much AI used in our scene for modding. In the past two months or so, it has exploded.

 

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.

 

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. 

 

I developed a custom agent tool called LECCLI to help perform game research. It’s a  command line tool that wraps Legendary Explorer Core, the library that powers most of the scene’s 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.

 

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’t immediately obvious:

• Kits are hidden by a ‘show if locked’ flag – something that BioWare used to drip feed MP4 content back in the day, but has been entirely irrelevant since, so it’s not really well known
• Identifying why opening a lobby would not respect your settings after the first time opening a lobby
• Explaining how the grinder system works (challenges) – a quasi-database progress tracker implemented in config that is awful to read due to the huge amount of text and properties it involves, which allows us to expand it to include new items
• Fixing off-host health regen being broken to bad fixes made by me that were implemented to allow you to play with bots. ME3 had basic bot AI (for QA), but when it took damage, you’d get its blood overlay effect, causing massive flickering issues

 

In some advanced scenarios, we used it to help track down issues such as incorrect UV mapping in ME3’s original data (such as Hydra’s black plane near the spawnpoints) and generate top-down geometry maps to help us locate in-game where an asset is at that we fixed UVs on, for verification. It also helped us set up the Blackstorm render, because the orientation and lighting data wasn’t part of the shipping game, and there is no documented information about how to generate one.

 

We had working prototypes for two major components that we essentially had AI rewrite for performance: Wwiser.NET for converting audio banks and ShaderHost/ShaderClient, a C# server and C++ ASI mod for the game, which triggers its internal HLSL translator that is required to build shaders. In 2025 we discovered that BioWare didn’t strip this out of the build of the game, which saved us an unbelievably huge amount of work.

 

AI helped us convert these into more performant versions that could be targeted to specific use cases; for example, ShaderHost/ShaderClient required building the entire material package, loading into a level with meshes that had the materials with the graphs, then hijacking the game to run it through the MilanShaderCompilerLib, which compiled shaders using my own custom tuned list of shader compiler macros. It worked, but it was pretty inflexible and game boot alone added multiple seconds to every compilation session – and there were hundreds of packages, constantly needing recompiling for testing. A full shader compile for all materials literally took hours, and fixing a macro for a shader type would necessitate a recompile to then check if it’s accurate or not.

We do have some AI-assisted UnrealScript and C++ code. As part of the process of development, I reviewed every generated line before commit, changing quite a bit of it. Certainly there are some parts that are missed, and some parts got less review than others, but I took significant time to review code, and not commit it until it was fully reviewed and verified working (much to the chagrin of others – committing parts that were verified, but depended on other parts not yet fully verified, broke the build many times… especially for Stumpy 😊)

 

No AI was used to generate audio or art assets, however AI/ML was used to upscale textures, similar to how it was done in ALOT, but many textures were manually remade, such as the main branding image the mod uses, which was quite a task to recompose.

 

Future plans

We plan to support Legendary Edition Multiplayer with updates to the base install in the future – more banners, more accessibility, more bug fixes. We know that modding on top of a moving target is really annoying, so we’re trying to design around that up front, but we don’t plan to try to provide a stable interface for mods until at least the first major update. We also need to figure out how to solve conformance and net indexing in tools; something our tools pretty much don’t support but will cause serious problems in multiplayer if they fall out of sync – which they will on just about any mod install.

 

Special Thanks

I’d like to extend thanks to all the people who helped develop this mod over the years, which now consists of over 20 people. This all started because I was frustrated with trying to make another multiplayer mod for the original game, thinking it’d be easier to port multiplayer to legendary edition instead. I don’t think I’d agree with that statement anymore, but now I can start making mods for multiplayer again. Maybe someday we can do the bungie batarian again.

 

Extra Special Thanks

We’d like to extend our extra special thanks to PCGamer for not reading our introduction email’s confidentiality request, doing what looks like no due diligence, leaking this mod a week early, and then ghosting us. Thanks!