On November 7, 2024, the ME3Tweaks group released an update for Pinnacle Station for Mass Effect Legendary Edition. This update aimed to polish the DLC further, as well as make it more fun and engaging. I’d like to go over the changes and technical challenges of its development, as well as some other changes in the scene since my last post. We wrote an article back in 2021 detailing the process of the original port, a worthwhile read before reading this one.
Pinnacle Station
As a recap, the original Pinnacle Station DLC was released back in 2009 by Demiurge Studios, the same porting company that ported the original Mass Effect to PC the year prior. It received mediocre reception at best, being a combat simulator DLC with little story, which was at odds with the strengths of the first game.
Talking to Ochren in the 2021 release
When BioWare requested the source code from Demiurge after the DLC had been published, it was found that the live copy and the backup copies had been corrupted, which is why the DLC never appeared on any subsequent releases. BioWare chose not to recreate the DLC for Legendary Edition, as it would take significant effort on a project that likely was already behind schedule due to COVID-19.
In the later half of 2021, we ported this DLC to Legendary Edition using the modding toolset our development group maintains, Legendary Explorer. We coded a porting pipeline that we named VTest, which is the main part of the Pinnacle Station porting project, which we call CrossGenV. We were able to port it due to our tooling being designed to work on “cooked” game files, whereas BioWare’s editor tools are designed to work on non-cooked game files. Many people like to say ‘BioWare was lazy’ or ‘They could have just done it themselves like the modders did’, but would it really have been worth the time and effort? I don’t think so.
We, as modders, conveniently don’t do this for a living, so we don’t really have deadlines. We took a few months to do the initial port, and now we’re back with a few more months of work to polish it up a few years later. Let’s go over some of the big changes and the challenges they presented to us back in 2021 and how they compare to today, three years later.
We brought a few additional members into the development team for this update – DropTheSquid and NaNuke, both leaders in their respective fields of modding. We also heavily cleaned up the code for VTest, making it an actual project, rather than a few huge files with a couple of methods in them.
Static Lighting
The main goal of Pinnacle Station’s 2.0 update was to improve the performance of the DLC so it felt like a regular DLC and not a mod. In the original release, we marked this mod as requiring higher-end graphics cards (at the time), because the game had to render real time lighting. This type of lighting setup is very performance heavy and is mostly meant for things that move – characters, vehicles, muzzle flashes – etc. As such, for entire level lighting, it doesn’t look very good.
In Unreal Engine 3, ‘Static lighting’ is precomputed lighting from light sources that don’t move on mesh objects that also don’t move. The lighting for these objects can be precomputed with a tool called Lightmass, which emits ‘photons’ from light sources and calculates the resulting light and shadows, mapping them as textures on static meshes. These are called Lightmaps, and they are very computationally expensive to compute – each of our 5 maps took about 10 minutes each to compute on a 16-core system. As Unreal Engine 3 is from the mid 2000s, it doesn’t use the GPU to compute this.
When we originally ported this DLC, we made a system for VTest that we called the ‘donor’ system, which is used when porting assets across games. When an asset with the same name existed in the Legendary Edition of Mass Effect (called LE1), we would port that asset to the destination instead, providing higher fidelity assets and requiring less conversion of data to newer engine formats. Due to how lightmaps are calculated, this yielded many unusable lightmaps, as they no longer correctly mapped onto the meshes.
As a result, we opted to use ME1 (2008) versions of some assets rather than the LE1 versions, in order to improve performance. In some cases we could re-use the lightmaps, in others the reduced polygon count improved realtime lighting performance. But some objects looked bad no matter what we did, and for those we choose to use the performance heavy dynamic lighting. Incorrect lightmaps as produce really ugly results, akin to the following:
We manually repainted parts of the Volcanic map’s lightmap hours before launch of the V1 release back in 2021. It greatly increased performance.
With the 2.0 update, we no longer use ME1 assets that also exist in LE1, we only use the LE1 versions. In the time since the original release, we figured out how to import Mass Effect maps into UDK without it crashing (well, crashing less). Back in 2022, this proof of concept was shown by mod developer Pietrasgin, and has been used by another developer to create the Hot Labs Restored mod’s lighting.
We spent a few weeks debugging UDK so we could export enough of our maps into it that we could compute lighting textures. The lighting quality AND performance would both get a huge benefit from this. But for proper lighting, we would need to have fairly accurate representations of meshes for diffuse photon bouncing. This required us to be able to compile shaders in UDK, which I talk about later in this post.
Left: V2 lighting, Right: V1 lighting
The static lighting we made for this update is uncompressed (as opposed to DXT1), which uses more memory, but provides a much higher quality light texture. In a few areas we also bumped up the lightmap resolution to provide more accurate lighting and less ‘stair stepping’ effects. The Improved Static Lighting (ISL) mods exist mostly because of the artifacts produced by DXT1 compression the vanilla game uses, combined with low res lightmaps being used on large meshes.
Low resolution lightmaps on large unpatterned surfaces, combined with DXT1 compression, results in ugly stair-stepping.
Interestingly, we found that you don’t want too high of a resolution for a lightmap. A perfect example of this is when we were trying to bake lighting for the apartment you can win. A small overhead bar casts a really ugly shadow with the standard lightmap resolution, but if you crank the resolution too high, it also looks bad, but in a different way.
At the bottom of the shaft shadows you can see them splintering.
With a higher resolution lightmap, each emitted photon from light sources becomes more visible. For large objects casting a shadow, this means you get a more detailed shadow. However, for small objects, it means you start to see how each photon coming out of a light source is at a slightly different angle than the one next to it. With a high enough lightmap resolution, you start to see ‘slivers’ of shadows with light between them, which looks terrible.
This effect is ultimately why we chose to not make lighting changes to the apartment map, as it is full of these small objects. We plan to revisit this in a future update, but the apartment is complicated due to our early development decisions.
Oh, and terrain lightmaps don’t work properly. We kept the same lightmaps for terrains. Terrains are just awful.
Touching terrain in this broken state instantly kills you and often sends you flying.
So this is an accurate representation of how it feels to work with it.
Shaders
In the original Pinnacle Station DLC blog post, we talked about shaders a bit, saying that we could not port these from ME1 to LE1, something that remains true as of the time this article was written. Shaders are tiny individual programs that are used to draw 3d surfaces, and without them, you can’t draw a 3d object.
Since our original release, a few enterprising modders have created a way to enable basic shader editing – using tools that allow us to decompile and recompile DirectX 11 shaders to and from High Level Shader Language (HLSL). This allows us to change shaders in fairly minor ways. For example, changing hard coded colors in the shader, adjusting transparencies, or adding a few effects from other shaders. It’s still pretty tedious, and our editing tools for it currently are very basic – but they’re slowly coming along.
Using RenderDoc to identify which shader applies the effects we want to edit
Messing around with the material editor in UDK yielded interesting information – Materials, which are what generate shaders for use in different contexts, generate the information used to compile them and store them in the package files UDK saves. Conveniently, Demiurge shipped a lot of uncooked files in the PC port of ME1, which included all of the material packages. These packages include the material expression data needed to compile shaders. Cooked files strip out most of the expressions, as they are not needed except for compiling shaders.
Using the ME1 files, we were able to rebuild most of that game’s shaders in UDK in DirectX 11, the same version of DirectX that the Legendary Edition game uses. These would be the ME1 versions, rather than the LE1 versions, but they are fairly similar.
For building lighting, these were sufficient to produce an accurate diffuse, which allowed us to properly bake lighting. Someday in the future, we may be able to port shaders out of UDK and use them in Legendary Edition. But that’s still a ways out from even being able to be tested.
UDK showing a water material we ported out of ME1. It’s even animated in the editor.
NaNuke, our scene’s expert on shader editing, contributed some modified shaders to CrossGenV to improve a few lower quality donors we used back in 2021. Notably, the capture mode rings being able to be tinted in realtime and the frost on the station glass are two examples of shader editing for our 2.0 update.
UDK Tooling
To support baking lightmaps for this update, we had to make significant changes to our Unreal Development Kit (UDK) file support. UDK is the free version of Unreal Engine 3, but it comes with serious limitations that I think would make it difficult to make any real game with – lack of access to engine source code makes debugging anything very difficult.
When exporting our game files to UDK, we often would find UDK simply crashed upon opening level files. This instability is why we didn’t dedicate more resources to making UDK a viable editor for many tasks – it often just crashes in native code, and only a select few people in our scene know how to debug native code.
UDK’s log showing a native crash.
With advances in our reverse engineering efforts of Mass Effect Legendary Edition games, we were able to apply that knowledge to UDK to track down crashes. Reverse engineering UDK is both easier and more difficult than the Mass Effect games – it has a lot more debug strings built into it, making it far easier to determine the context of something. But it also uses Address Space Layout Randomization (ASLR), which is really annoying when trying to follow a stack trace.
The primary crash we faced came from stricter rules in UDK about how files are laid out.
The main issue we faced was not understanding that UDK only supports the concept of exports under exports and imports under imports. All of the Mass Effect trilogy games are fine with putting imports under exports or exports under imports, but UDK does not like that.
Imports are just stubs that point to objects that should already exist in memory. When a package is loading, and the import table is enumerated, the engine attempts to resolve them by finding the object in the GObjects table using the full name and class specified by the import. If the object is found, references to the import become references to the found object instead. If the import cannot be resolved, it converts to None, which is Unreal’s version of null. Commonly shared objects are often promoted to a higher tier file (such as a file always loaded in a map), and lower tier files will reference this preloaded object. Imports in package files are indexed using negative values starting at -1.
As the export metadata table is enumerated during file load, if a same-named object and class exists in the GObjects table, references to the current parsing export become references to the object already in memory, and the engine skips reading the data of the export, which speeds up file load. Once the file finishes loading, objects that are unreferenced from a level or a pinned object are dumped from memory. Exports are indexed using only positive values starting at 1.
In cooked game files, there is a concept of ‘Forced Export’, which means export objects are being forced to live in a different package file. The game is compiled this way so that dependent objects don’t incur seek time on a hard disk drive or a disc. This had a bigger impact back when these games were originally released.
This concept doesn’t exist in the Unreal editor – imports instead point directly to other package files and will be loaded automatically to fetch object dependencies. All exports reside within that package; package exports at the root of a package file that have the ‘Forced Export’ flag all were standalone .upk files in the game editor. This is also why ME1 (2008) has so much extra unused content in it – those extra uncooked packages include tons of unreferenced data, that in the later cooked games, would never be forced into other files.
Legendary Explorer, and before it ME3Explorer, were all coded against the idea of Forced Exports. As such, a very large part of our codebase makes assumptions that it’s fine to pull in data that belongs in a different package, and our codebase struggles to work well with files that don’t use this system, which are often BIOG_* files.
Exports under imports, or imports under exports, will cause an immediate crash when the package file loads in UDK. It took significant engineering effort to find a way to export our level files in a way that UDK would accept; in the end, we did not make too many changes to our internal porting code, instead writing specific iterative passes to convert files to be compatible with UDK. This means that using UDK for lightmap baking and map editing now requires ‘decooking’ the game, which moves everything back to standalone packages, a process that takes lots of memory and lots of time.
CCMid, the middle room of Pinnacle Station, loaded in UDK. The little light bulbs are different light sources.
Once decooked, UDK accepts our generated packages, and in theory, so would BioWare’s editor. We potentially could fully convert Pinnacle Station back into usable source form for BioWare, though it would take much more effort. We only export a subset of objects to UDK, and our understanding of all object types is still incomplete, let alone what data is stripped during cooking.
However, this system isn’t perfect, even for the subset of objects we export. Testing this with some LE3 files to help other mod developers with their static lighting woes resulted in a different crash trying to get surface data when Lightmass begins. For this to be fully reliable we will have to continue work on debugging this conversion process.
Load screen updates
In the original Pinnacle Station DLC mod for Legendary Edition, we made load screens that show the view from the observation window of the simulator. We felt these were a nice touch, but we could do better. Showing the simulator actually loading would be quite interesting – and while debugging static lighting, we found that we could see the lighting actually loading when you disabled load screens, when using streamed lightmaps.
The load screens for all simulator maps now show what the level would look like if they were loading without a load screen blocking the view of it. It requires a special streaming lighting build of the mod to generate the same effect.
An interesting stretch goal with our more advanced tooling would be to change the materials on all objects to a loading effect, then resetting them a moment later to create a cascading load effect. Maybe someday we’ll experiment with that idea to see what it looks like.
Audio updates
Back in 2021, audio editing tooling for both ME1 and LE1 were pretty much non-existent. Both games use ISACT – an absolutely archaic sound engine that very few games appear to have actually used.
We have since found a copy of ISACT that matches BioWare’s version number (1.64). After dedicating some time to it in 2023, we developed tools and documentation on how to create new streaming audio (and replace non-streaming to a limited extent). BioWare has a custom fork of the ISACT sound engine, but with minor changes to ISACT’s output files, we can make our files compatible with BioWare’s engine.
ISACT when authoring the new Volcanic music track. It really is a product of it’s time. It crashes on boot if your screen is above 1080p.
We updated music to loop better for the Volcanic map, which provides a much better audio experience than our original track that had a lot of silent and lead-in. We also added enemy soundsets to the Salarian enemies, which provides more audio feedback to combat, with enemies grunting in pain. In the future we hope to expand this to the built-in enemy types to provide a more engaging experience.
Enemy Replacements
We wanted to make some functional gameplay changes to Pinnacle Station as well. We strove to ensure you could turn these off if you wanted the ‘vanilla’ experience, but it is no secret that Pinnacle Station often has to compete with Firewalker from ME2 for last place on Mass Effect DLC tier lists.
Our original task document listed having Rachni enemies as a ‘Nice to have’, something we never got around to implementing. A large focus for this update was making an extendable system that could provide ‘wavelists’ – lists of enemies that could replace the originals, so you could fight batarians, asari, salarians, or mixes of different enemies.
Making new enemies for the simulator turned out to be a significant amount of work, not only because the pawn system in the first game is really complicated to use (it’s powerful, but probably far more than necessary), but the game locks files that are dynamically loaded until you restart it. Any change you make to dynamic loaded files requires a game restart, which adds a lot of time. This used to be a big problem in LE2, until we developed the Hot Reload ASI, which changes how files are opened to not lock them.
Designing the appearance of the pawns so they were visually unique was a learning experience, as the appearance system is unlike later games. It uses numeric indexes when selecting the mesh and materials (starting at 0), that then translate to asset paths using letters and numerals that are indexed starting at 1/a. These assets must exist in memory or be available in packages as non-forced exports, and meet an exact naming standard. 
In order for export 4: GTH_TRO is the asset prefix defined in an appearance, NKD means the ‘Naked’ armor level, a means the 0th mesh, MAT is the asset type, 1 means the 0th material config, and a means it’s the first material to place on the mesh (if more were needed, it would be b, c etc).
A big help was DropTheSquid’s Appearance Modification Menu mod, which could be used to preview different assets, making iterating time much faster. You could also make gems like these:
Further complicating this was the first game’s use of the Bio2DA format – which are essentially excel spreadsheets, but used in a database like fashion. You often have to translate what a numeric value actually means mentally, which is error prone and confusing.
The component of the mod that actually distributes the enemies into the simulator logic behaves similar to Mass Effect 3 Legendary Edition Randomizer’s (yes, that’s still in development) enemy spawn randomizer, where an object in the Kismet graph modifies other Kismet objects, rather than the objects they point to. You can dynamically modify Kismet, if you like to live dangerously.
To enable the player to configure options such as this, we added a new simulator settings to the console on the right side of Ochren. This is a standalone version of the menu system from the Mod Settings Menu component of the LE1 Community Patch. You can tweak settings such as getting XP for first place finishes, enable/disable music, toggle difficulty ramping, and choose from various enemy wavelists. Of note is the ‘Mixed’ wavelist, which can use enemies from all other loaded wavelists, including the original enemies. This was unusually fun to play.
The simulator enemy selector. Developers can add their own wavelists via config files and they will automatically appear here.
Difficulty Ramping
With this update, we put a large chunk of development time into difficulty ramping – increasing difficulty over time to make a game mode require more and more player skill to continue playing, while remaining fair for players of lower skill level to complete the base challenge.
Pinnacle Station is not too difficult to beat above level 50 with higher level gear (on Veteran). We wanted to ensure it can still provide a fun and engaging challenge that players may want to come back to. In our original release, we had one implementation of difficulty ramping – over time, your healthgate thresholds would decrease, which let enemies do more and more damage even when you had the strongest armor. This was a way to counteract health regeneration and armor making you nearly impossible to kill. We spent a lot of time tuning this to feel fair, and I think we did a great job on it – I haven’t heard people saying it’s too easy or too hard.
Given my formative modding years being all based in Mass Effect 3 Multiplayer modding, I wanted to make combat more chaotic and engaging, especially for survival mode. Making bullet sponge enemies is a very boring way of increasing difficulty – which is why I wasn’t really a fan of Platinum difficulty for ME3 – so we added in multiple methods of ramping up difficulty over time.
The primary one is having additional enemies spawn over time, which increases player pressure – suddenly your reaction times are shorter and cooldown management becomes very, very important. We put this on a timer in Survival mode and as you complete each capture point in Capture mode.
Kismet sequencing comparing the current match timer to predefined values, then checking if spawn ramping is enabled, and then enabling a respawner if the value is true.
But that’s just more vanilla gameplay. I wanted more.
Stealing code from LE1Randomizer (yes, that’s still in development), I implemented a way for enemies over time to start gaining inventory mods (such as weapon rails, ammo types, amps, etc) and talents. This is all chance based as enemies spawn in, with the chance going up over time (Survival) or as you capture points (Capture). Adding inventory mods required us to generate new AI classes that would drop their inventory on death, rather than have the player subsume it, which could give you hundreds or thousands of items.
This can trigger a steep climb in difficulty, because enemies that roll abilities like singularity, sabotage, or high explosive rounds are extremely dangerous. We made it so the list of talents and powers enemies can be given is configurable in configuration files, so other developers can add to the lists.
Oh yeah, did I mention we can now merge configuration files in LE1 like the other two games?
Difficulty ramping config file shipped with the 2.0 update.
One game mode we really wanted to improve was the Capture game mode, which is very unengaging. The objective is to capture all points as fast as possible – but since the mission is timed, you often just ignore enemies entirely. In the original DLC, touching a capture point often deleted enemies in the vicinity – something we marked as wanting to fix in our original release, but had to cut for time. Enemies also didn’t attempt to close distance, often staying in zones outside of the capture point.
We made some functional changes to this game mode, making enemies near the point not automatically despawn when you start to capture it. This appears to have been due to the list of spawnpoints changing to be near the capture point, but it led to a really poor gameplay experience. Enemies that are far from the capture point will still be killed, but they won’t be immediately deleted anymore.
Another change was for the capture point indicator and capture ring. We switched to a new material (with a shader modified by NaNuke) that changes over time. This helps provide more visible feedback to the player that they are nearing capture completion. We used our new Asset Viewer feature to load the ring into a level, and then we used (or, tried to) use our live Material Editor tool to preview live changes.
Testing out what different parameters of the new shader did.
We also made enemies change their AI to close distance when you touch a capture point. This tends to force you to engage with the enemies more, though it often makes them engage your squadmates instead. LE1’s AI system doesn’t seem to have a way to reliably force a pawn to only target a certain enemy. If we come back to this DLC, we’d probably look into what we can do with the game’s AI.
Frameworking
A modding concept new to the Legendary Edition of Mass Effect games is what the scene colloquially calls “Frameworking”. In level files in Mass Effect games, interactable NPCs are often hardcoded into the files. You may see the same NPC in multiple locations, which means that their assets and dependencies are all hardcoded into multiple files. Thus, if you want to change a character’s outfit or other properties, you’d have to edit multiple files. And because level files often contain multiple NPCs and other logic, this gets ugly really quick.
The LE3 Community Patch mod introduced the concept of frameworking in 2021, which follows a similar design as the henchman files from BioWare. These files are level files, but each one only contains the NPC. Using a ‘handshake’ system, they can be streamed into a level, and then polled if they are loaded and ready. Once ready, the level file can set them up wherever they’re needed.
Frameworking essentially makes new level files, with the only thing in them the NPC, which other files then move around.
As part of the Pinnacle Station 2.0 update, we updated VTest to automatically strip out all hardcoded pawns and move them into framework files, so if you want to edit an NPC’s outfit, you only have to edit their file. It improves mod compatibility, and it’s all done in code – we made no manual edits to package files for this feature. We could disable the whole thing just by flipping a boolean in the pipeline.
This requires significant changes to the underlying game files, replacing direct references to pawns with soft references, as well as changing some logic to require a completed handshake. We also had to install ‘teleport signals’, which are pieces of logic we hooked up to fire when certain events in game sequencing happened. An example would be teleporting Ahern back to his normal post after telling you ‘Better luck next time’ in another room. If we didn’t teleport him out, he’d just stand around in a room he isn’t supposed to be interactable in.
In the original files, the station had multiple copies of pawns in the areas they could move to, but in our frameworked version, we teleport a single copy around, which required some additional work to ensure correct placement.
New female turian model from LE1 Diversification Project. Done by simply overriding the NPC file for this pawn.
I’d like to say the system we built for this would work on other level files, or LE2 – but it requires very heavy analysis of game sequencing to properly set up and use. It’d probably help to start the process, but it likely would require significant effort to replicate elsewhere.
Bugfixes + Misc
We made some additional bugfixes and changes for this update as well, many which are minor or not super obvious.
Ragdoll teleport
In the original version of the game, as well as our V1 release of this mod, you could get softlocked if you got ragdolled when the game attempted to teleport you out of the simulator map. This could happen for a few reasons – you were rolling down a hill and the game ended, or you got hit by your own grenade after your input got turned off.
When we added enemy talents to this update, this issue became much more common, as you could be in ragdoll state much easier, and for longer. After investigating the Kismet teleport action, we found that it would return that it successfully teleported the player, but didn’t actually do anything. Because of this, files that needed to be loaded didn’t, and the flow of game logic essentially hit a dead end, softlocking the game.
The
To remedy this, we made a custom teleport Kismet action, which terminated the player ragdoll and forced them to the new position. This worked great, except you lost the ability to use powers and fire weapons until you got ragdolled again. Ragdolling, like many things in LE1, is all done in native code, which means it’s nearly impossible to work with.
The logic for the LEXSeqAct_ForceTeleport kismet class.
Writing a few new features into Legendary Explorer’s Script Debugger tool, we were able to dump all properties to a text file, and compare them between for differences on the player pawn. After a bit of experimenting, we located two variables that seem to control your input, a stack and a queue. Resetting these on teleport ensured the player would retain full control. We don’t really know what they mean.
Texture streaming improvements
We put a bit of effort into improving texture streaming around the map, to reduce textures from being blurry on first sight and then becoming more high resolution. About a year ago I wrote a way to calculate a basic TextureToInstancesMap, which the engine uses to preload textures in a certain vicinity. This greatly improved some areas, but didn’t cover everything. We also changed level load to stream in all material textures, but it doesn’t seem to work every time.
There’s still improvements to be made. The new frameworked pawns often teleport into view, which doesn’t give textures the time to properly stream in, and we could probably stall the load screen coming down until the game’s streaming system indicates it is no longer loading textures.
Polish localization
After years of hearing about various folks getting me permission to do the Polish localization, I finally was contacted by one of the team members of the unofficial localization of Pinnacle Station, who gave us written permission to use it. It may have taken us a bit over a year to get to it, but all text should now be available in Polish, except for the new text we added in 2.0, as it’s still pending full localization.
Collision improvements
In our original V1 release, there were a few areas that we knew of that had really bad collision, especially the area to the right of Ochren. If you walked into it, it would teleport you up and right over the wall, and it was incredibly easy to trigger. We spent a bit of time moving the collision boxes to prevent you from being able to do this while still feeling natural. It’s a small change people are unlikely to notice, but once you know it’s there you can’t unknow it.
Gestures on Pawns
Some of the dialogue in the original game caused characters to ‘snap’ to their next line’s animation, such as a fist going into a hand immediately going into hands at their sides. This DLC is full of problems like this, and while we didn’t fix them all, we fixed some of the more egregious ones, like when you tell Vidinos you don’t have time for sore losers.
Known issues
A number of features didn’t get the full level of attention they needed for a clean release, and several features got cut for time, which hopefully we’ll be able to get back to.
Music on Warehouse map
The music on the Warehouse map doesn’t play again unless you restart the game after the first time it plays. We aren’t really sure why this does this, because all maps are scripted to get the exact same music triggers. It’s likely the audio bank itself, but we didn’t have time to look more into this. This is also present in the V1 version of our mod.
Holowipe effects on enemies
This was a pain in the original release we made, where visors and weapons didn’t have the holographic effect applied to them. We manually fixed things up back then, but now we have an expanded cast of characters to fix, so we’d like to code something up to automatically fix these issues. Our options for fixing this are much better these days, especially with our 2DA merge features.
Cut factions
We had basic prototypes done for Asari and Monsterous enemy wavelists, but they got cut for time because they needed a lot more work. We’ll be working on implementing these, with a focus on biotic powers for Asari and… well, we’re not really sure for Monsterous yet.
What’s next
We will probably make a few minor bugfix updates for Pinnacle Station 2.0 to address a few of the areas that could use a bit more improvements, and possibly see about baking lighting for the apartment, if we can solve some of the unique challenges it presents.
This year we made Asset Viewer, which lets you preview various game assets. Here we are previewing the legendary Edmonton Cheeseburger texture on the material of the floor mesh of the viewer level.
As for the ME3Tweaks group, we’re going to be taking a break and then embarking on another ambitious quest, like we seem to every year.