Jump to content

Mod Cleanup Case Study - Ambient Slaves 0.2b - Part 1


gregaaz

1,288 views

This entry is something a little new. With permission from the author, I'm going to go through version 0.2b of Ambient Slaves and talk about clean modding, conflict resolution, and some of the tools that mod authors and end users have at their disposal. The goal here isn't to criticize @gargamel9, but rather to delve into some of the hidden challenges that exist with Skyrim and how we can overcome them to support bigger, more stable mod lists.

 

Getting Started

Before we start messing around with the mod itself, we need to get it installed. Any modern mod manager is fine, though Mod Organizer 2 and Vortex are probably the best known ones. I personally recommend MO2 and that's what we'll be using here. We are also going to need a few other tools.

 

 

We're going to go ahead and install the AS 0.2b archive in MO2 and place the plugin at the end of our load order, just above our late loading patches. As you can see here, this is a pretty extensive load order, with 1081 mods and 1155 plugins. This should be a good stress test to help us pinpoint any lurking issues.

 

image.png.343818bb6b0d9d7fdc3cdfacede3c5d1.png

 

You might be wondering why I haven't put a lot of effort into load order here; why I just dumped the plugin at the end of the load order. During this process, we're going to thorough resolve all the conflicts in the mod, and since there aren't any BSA-related asset conflicts, load order isn't really going to matter. 

 

Wait, what? 

 

OK, so two important concepts here:

 

  • Asset conflicts. Skyrim will only load one copy of each asset (that is to say, the same file in the same folder). It follows a pretty simple rule for how to choose which one wins. 
    • If even one version of the asset is loose (that is, not packed in a BSA file), the last loose file in your asset load order - the left hand side of the screen in MO2 - gets used by the game.
    • If every version of the asset is packet in a BSA file, then the game will use the BSA corresponding to the highest plugin load order - the right hand side of the screen in MO2. 
  • Plugin conflicts. Each plugin (esm, esp, or esl file) contains a database of different forms. Generally these are variations of Form 43 and Form 44, though from time to time you'll see other oddball ones. These can be everything from armor, to weapons, to NPCs, to world object references, and everything in-between. Every plugin record has a Form ID, a unique 8-byte index that the game uses to find the file. When more than one record try to use the same form ID, the game will use the one from the last plugin to load. 
    • So why do I say that load order doesn't really matter then? Because it's pretty easy to create override records that we put at the end of our load order to make sure the version of each Form ID we want to "win" actually gets used by the game. We'll talk more about this later, but it's something to keep in mind while reading here.

 

 

First Checks

An important principle in clean modding is zero trust. No matter how reputable the author (or how unknown they are, for that matter), go in assuming that every aspect of their mod is suspect - check everything. The fact of the matter is that people make honest mistakes and, more to the point, the Creation Kit is kind of a mess that regularly leaves behind all kinds of dirty and problematic traces in files. Frequently, these things don't show up in the author's test environment and so don't get caught prior to release.

 

Before we open up Skyrim or any of our external tools, we'll start by scrutinizing the mod in our mod manager. We'll start by right-clicking on AS and using the context menu to choose "information," then navigating to the "conflicts" tab.

 

image.png.a514b3fb79cc22a88adeef24f9d335ef.pngimage.png.41cf01164c0e588c43a9885520858f41.png

 

In the case of AS, we can see that it's not conflicting with anything else in my load order. If we had seen things in the winning and losing file conflicts panes, we'd need to make sure everything looked the way we expected. We might need to change this mod's asset priority, hide conflicted files, or even create asset patches (the latter in the case of script conflicts especially). However, we're in luck today and won't need to do any of that here.

 

The next thing to do is to look for any external problems with the plugin. We want to look at the general warnings area and at the flags column on the right side of the screen (see below). In this case we have no warning flags for the plugin, but we do have a general warning indicator. Fortunately, a quick click on the general warnings reveals nothing related to this mod - just some unsorted files that need to be tidied up at some point (we'll square these away before we boot up Skyrim for the first time, just to be organized).

 

image.png.8e9afccc8232ce28cc182a51f943dd2f.pngimage.png.b1c1d40d91fde49e5ca08f1dc7b56d2d.png

 

Getting back to the original zero trust principle, these tests didn't reveal any problems with AS - and indeed they won't reveal problems with most mods. We still want to do them just in case. Every mod configuration is different, so diligent checking will help us avoid unpleasant surprises later on.

 

xEdit Cleaning - First Pass

xEdit is a family of Gamebryo/Creation Engine editors that are available for most Bethesda RPGs. For SSE, the program is called SSEEdit and it's one of the most powerful and useful tools we have at our disposal as modders. We'll be going into xEdit a few times, but for our first pass we are going to be focusing on cleaning. Before we go any further, let's talk about two kinds of problematic records we are going to run into here.

 

  • Deleted Records: Sometimes called UDR Errors, I don't like that term because it's kind of a misnomer. UDR stands for "Undelete and Disable Reference", and that's how you fix a deleted record. Deleted records are high risk edits that the Creation Kit often makes without consulting or warning the mod author. The reason these records are risky is twofold:
    • If a different record depends on a deleted record (such as the base form of a placed object), then SSE will crash when it tries to load that record.
    • If a different mod tries to overwrite a deleted record, SSE will crash because of a game engine issue.
  • Identical to Master Records: These are exactly what they sound like. These are records that are identical to the mod that provided the original Form ID, often Skyrim.esm. There is a lot of dubious information about ITMs, such as assertions that authors put these into mods intentionally or that cleaning these up will destabilize your game. Some people feel very strongly about this - if you want to do a fun social experiment, go to r/skyrimmods and opine that users should clean all their ITMs. The downvotes will roll in rapidly and predictably. Here's my experience, speaking from more than a decade of Elder Scroll modding:
    • The "intentional ITM" talking point seems to have its origins with anti-cleaning advocates and is often tied up with a very hard line interpretation of the parlor school of modding. While there are legitimate ITM scenarios, such as reverting editorial changes in baseline mods like the USSEP, the concept that a mod must absolutely depend on vanilla records going unchanged - and even being reverted away from changes such as those introduced by update.esm - is a red flag in its own right about the underlying mod. This suggest a level of fragility that is likely to not play nice in a large load order. With the exception of mods that are explicitly designed to revert unwanted changes (such as this one), I recommend cleaning all ITMs, regardless of the author's position on whether or not they are intentional.
    • Not cleaning an ITM doesn't just revert changes from the creation club, update.esm, and similar sources. It also reverts all changes from other mods. This can range from purely aesthetic, nuisance impacts such as mismatched water textures along exterior cell lines to fairly serious problems such as idle markers ending up hidden within geometry because changes from exterior overhaul mods are reverted to vanilla - this scenario can cause CTD under certain circumstances.

 

Ultimately it's up to every user to decide what level of Deleted Records and ITM presence they'll tolerate in their game, but for this guide we'll take a conservative view and look to eliminate all deletions and ITMs. Note that, for reasons we'll discuss later, we'll need to go into xEdit multiple times to accomlish this.

 

xEdit Setup

Before we load everything up, we first need to configure xEdit so that we can do what we need to do. First things first, in MO2 we are going to click the "two gears" button to open up the executable manager. Find your xEdit installation and make sure it has the argument shown in this dialogue box. This enables greater user control over the cleaning process.

 

Important Notewhile we're at it, if you downloaded xEdit a while ago, make sure your copy is up to date. Some older versions had problems with how they handled file cleaning and we don't want to deal with that can of worms!

 

image.png.e0d69f532105cf36ab2237cdc62a2170.png

 

Now that your arguments are set, load up xEdit and go into its options menu. Make sure Simple Records and Hide Manual Cleaning are turned off.

 

image.png.fb3f8b0839766c1944d0e84839bb3a0f.png

 

Now restart xEdit and let's go to work. For the first round of cleaning, we only want to load up the new mod and its direct masters. We'll come back and look at the "big picture" later. 

 

Your xEdit screen is going to look something like this:

 

image.png.3a6ba43fba68dbc3c1b5e35e88980e81.png

 

Right click on the new mod and choose "apply script," then choose "Skyrim - Clean edge links in navmeshes." Let the script run, it'll take a second. This will automatically fix a common Creation Kit artifact that would otherwise cause you more work later on.

 

image.png.50559b5b7aac916ad437c1064f650df8.pngimage.png.de582583913d0f02708b46dd4a4cd05c.png

image.png.90d37432a973776ab3d06957ba78276c.png

 

Once the script is done running, we're ready for our next stage. Note that your new mod's title is now listed in bold. This means that it has unsaved changes. You can save now if you want, but unless you're worried your system is going to crash or something, you don't need to yet.

 

Right-click your mod again, and this time choose "Apply Filter for Cleaning (selected files only)." You'll get an opportunity to choose additional files, but just click "OK" without adding any more. Once the operation has run, you'll only see your new mod listed - the other mods will be hidden.

 

image.png.c33f5473141f6f8d0f93e0f953dd6512.png

image.png.a8005b3627a18df7d55a2fc2ac2cf1fe.png

 

Right click you mod once more, and choose "Undelete and Disable References." Let it run. Your messages screen will return the results. In this case, we'll find 37 fixable deleted references and, more concerning, 5 'unfixable' navmesh deletions. Since you had navmesh deletions, click "Undelete and Disable References" again, then go back to your messages screen. You should only see a list of deleted navmesh errors now. Copy those in their entirety to a text or spreadsheet file - you'll need these in the future.

 

image.png.a03fc77a9dc4432bf964521c583e2d89.png

image.png.9e99883350ae16653c5094a1100d70c6.png

 

Skipping: [NAVM:000E0BB6] (in GRUP Cell Temporary Children of RiftenPlankside02 [CELL:0000BCF2] (in Tamriel "Skyrim" [WRLD:0000003C] at 41,-25))
Skipping: [NAVM:00105283] (in GRUP Cell Temporary Children of [CELL:0000BD5C] (in Tamriel "Skyrim" [WRLD:0000003C] at 34,-28))
Skipping: [NAVM:000D366B] (in GRUP Cell Temporary Children of HlaaluFarmExterior [CELL:0000B4B8] (in Tamriel "Skyrim" [WRLD:0000003C] at 35,8))
Skipping: [NAVM:000FC11B] (in GRUP Cell Temporary Children of [CELL:0000B498] (in Tamriel "Skyrim" [WRLD:0000003C] at 34,9))
Skipping: [NAVM:000BD7D4] (in GRUP Cell Temporary Children of WhiterunExterior14 [CELL:0000961C] (in Tamriel "Skyrim" [WRLD:0000003C] at 3,-3))
[Undeleting and Disabling References done]  Processed Records: 5597, Undeleted Records: 0, Elapsed Time: 00:00
<Warning: Plugin contains 5 deleted NavMeshes which can not be undeleted>

 

Now let's clean up the ITMs. Thanks to the script you ran earlier, you should have revealed a bunch of hidden navmesh ITMs that you'll be able to clean up at the same time. Right-click on your mod and choose "Remove Identical to Master records." The messages screen will report how many ITMs you removed. In this case, xEdit found and removed 203 ITMs. Note that it's highly unlikely the author intentionally included any of these. The Creation Kit regularly creates ITMs without the permission of the user from things as simple as looking at a record's properties. So even a high ITM count isn't really a red flag about the quality of the mod.

 

image.png.52e436403823532e0355c19c2d6bf6cf.png

image.png.ba967e14502add5cc23ae37d20563ae9.png

 

With that, your first round of cleaning is complete. You should save your edited file at this point. 

 

Deleted Navmesh Repair

Those five deleted navmesh records are a problem, and we want to fix it. Navmesh deletions have all the same problems that other deleted records have in terms of causing crashes to desktop, but they also have the potential to cause more complicated problems involving AI pathing. Adding insult to injury, navmesh issues are not easy or convenient to fix. They often require Creation Kit work to sort out. 

 

There are, broadly speaking, two ways to fix deleted navmeshes:

 

  • The Trim and Drop Method: In terms of risk and easy of execution, this is probably the easiest way to fix a navmesh deletion. It's a three step process using both xEdit and the CK, and it only runs into problems when you have conflicts with other mods. 
  • The Analysis and Restoration Method: If you have other mods that want to make edits to the same navmesh, then this more involved method is likely what you want to do. Like Trim & Drop, it's a three step process.

 

Let's figure out which method is most appropriate for our mod. First, we need to restart xEdit and this time load our full load order. This'll show us if we have any conflicts over the five deleted navmeshes (spoiler - it's likely. Some of these are high traffic areas). Once xEdit has loaded back up, let's look at the first navmesh deletion - 000E0BB6

 

We can see a few things immediately. First, this navmesh is indeed used by other mods - the USSEP and Rigmor of Bruma, in this case. So "trim and drop" isn't a good fit. This means we need to do Analysis and Restoration. One of the leading causes of navmesh deletion is accidental merging or splitting of a vanilla navmesh. The Creation Kit doesn't know which record is intended to be the lead record that the others are split from or combined into, so it just deletes everything and starts from scratch. In this case, we can see that AS adds four navmeshes to this zone. 

 

image.png.550a25fe01a88254d2d10fd38d134752.png

image.png.3d8061f324aa22d72e74ad29fba70b48.png

 

So the question is... are these all fragments of the same navmesh, or is one of these four substantially the same as E0BB6 and should be its sucessor. At a glance, the much lower form ID on F600593B leads me to believe that this is probably the modified E0BB6. Let's look.

 

image.png.9c80b32f0c37acb451a222e58fcf8bbf.png

image.png.a5253360f85a174251887eb580d83736.png

image.png.1cd5287b72f8bf153d53682435c9df8b.png

 

The original navmesh has 300 triangles. 593B contains even more triangles and, importantly, contains both of the vanilla doors found in the deleted navmesh. Let's compare both meshes in the CK and confirm they are the same mesh.

 

image.png.0a5ffdcad653e03f6efdabdc92e9d78b.pngimage.png.694c641ce7db74e217a2ffc1b4f83ecc.png

 

Indeed, these are the same mesh. Ambient Slaves expands it to cover the new building. It's pretty clear that F600593B should actually be 000E0BB6 and that record never should have been deleted. While we're at it, let's look at those other three navmeshes. DFF is a little island that was formerly the southwest part of the main navmesh. This is fine to leave be for now, but if you are going to go back for conflict resolution you should keep a mental note that you may need to forward some changes to that mesh rather than the main one. E01 is part of the ship that gets added (you can see it on the modded navmesh screenshot - the little isolated center part of the ship at the northwest of the mesh) and is completely safe to leave as-is. E00 is a tiny, one -triangle mesh where a little part of the ship spills over the corner of a zone line. Also fine to leave as-is.

 

image.png.3e516bbbf9d6b3b9b41cbc9bbc1cc6cc.png

 

So first things first, let's repair the deleted navmesh. Don't save anything in the CK if you were following along. We need to go back to xEdit first.

 

You might think that the first thing we would do would be to undelete the delete navmesh, but that's not the case here. We are going to completely remove it from Ambient Slaves' ESP file. Select record E0BB6 and right click on the Ambient Slaves column, then choose "remove."

 

image.png.121b39f9e5360bbdf6789cbf0ca2be41.png

 

Next, find F600593B (note - the first two bytes may be different for you since they will vary based on your load order). Right-click on it and choose "change Form ID". 

 

image.png.0c0510019be063ec8554de2b15e08bde.png

 

Type in 000E0BB6 and hit enter. A deconfliction screen will come up. Choose to update all of the records.

 

image.png.c08b7e58b7103342199cb0011c8cce57.png

 

Congratulations, we've just repaired the first of the four deleted navmeshes. 

 

But... Edge Links! Nav Mesh Info Map!

 

If you're asking about these, I'm happy you know about these things. Don't worry, the immediate concerns were handled by that deconfliction dialogue, and we'll be going back later for a more permanent fix. This kind of repair is a three step process, remember!

 

But first, let's fix up the other four deletions. The next one, 105283, is an interesting one. Compare the modded view of the cell (left) with the unmodded one (right).

 

image.png.884dd3dc2003eb38e7bfdc4b724f0d0d.pngimage.png.71855b92562e8d42051d2931e2ccd923.png

 

That's a significant difference! A whole huge swathe of navmesh appears to be completely gone from the modded version. What's more, it appears to all be wilderness. In this case, we may just want to restore the deleted mesh in its entirety since this seems like it might be a wild edit. Let's jump into the game and make sure there's nothing unusual here.

 

Thanks to that eternally helpful console command, COW (center on world coordinate) we can jump right over. Here's what we see with AS loaded:

 

ScreenShot535.png.ede92457cff7cdf8611c468eefa6e0fa.png

 

As you can see, no changes in sight. So we're just going to straight up undelete the navmesh here. Bring up 105283 and double-click where it says "deleted." In the menu that appears, uncheck "deleted." xEdit will fill in ITM data for now (we'll probably clean this later, but for now just leave it be). 

 

image.png.1de569c72b356531b2bfbda3b2cca6a4.png

 

 

D366B is a small little mesh with only a few triangles, so we'll need to look at it in the CK to see to what extent, if at all, it overlaps the four new meshes that AS adds. As you can see below, the vanilla mesh is this little corner piece in the top left of the map.

 

image.png.5357f4b87d0b20ebb13d2b0f80128176.pngimage.png.d3fd12952aa19eadad56a4324cd347ee.png

 

At first glance, this might appear to be a "righteous deletion" that we just want to trim and drop. However, you can see that the old mesh's edge links and general positioning is inherited by the navmesh for that ship - F609DF9E. So is renaming DF9E as the new D366B the way to go? Either approach is probably safe, since this is a very small edge piece that's unlikely to be touched by other mods in a game-impacting way. However, it looks like this one make pretty big landscape changes, so we won't do renaming here in case this causes problems with other conflicts. So here, we'll trim and drop. 

 

First, we need to undelete D366B in xEdit and save the plugin. Next, we'll open up AS in the CK and find the now-undeleted navmesh. You can see it here in all its glory, clumsily overlapping with the new navmesh.

 

image.png.7e242e6a8c8f5d3841894ba95788bb54.png

 

First, let's select the navmesh, click "f" to flood select the whole thing, and then hold Z while left clicking and pulling the mouse down. This will move the whole D366B mesh below the Z axis of the map and stop it from overlapping with the other stuff. This is the "drop" part of "trim and drop." 

 

Now that it's out of the way, we need to do the "trim" part. Select and delete every triangle except for triangle zero, so you end up with a runt mesh that looks like this:

 

image.png.7980785add6ad79e2502c9e528c874e1.png

 

Finally, click the Finalize Navmesh button and then save your plugin. You'll be back in xEdit later for some finishing work, but we can wait until all 5 deletions are fixed, first.

 

image.png.ef60d2a520251df7312cfc089e60f2fe.png

 

FC11B is next, and it's a tiny (one triangle only!) navmesh. Let's find out what happened to it. As you can see below, it's a mirror of that last one we worked on. So this is probably another drop and trim - though it won't even need a trim since its already just one triangle. But! As you can see below, there's a reason we check these things. Despite the huge difference in triangle count, F609DF9F is clearly the "successor" to this navmesh. So we're going to do a remove and rename operation like we did for the Riften deletion.

 

image.png.0aadbf42e5212af0309b402c3d6b1041.pngimage.png.f9f1f2646c016f0b39ea609eaef11685.png

 

That just leaves BD7D4. Right off the bad we can see that we should avoid trim and drop at all costs, because this is a heavily conflicted navmesh - notably it has a conflict with Cutting Room Floor. The vanilla version has 593 triangles (the CRF version has 599 - but we can hold off on conflict resolution for now). With 592 triangles, it looks like F6038474 is probably the same navmesh just with edits. Let's review in the CK.

 

This huge navmesh on the left is BD7D4. 38474 is on the right. These are substantively the same navmesh, so we'll do remove and rename here as well. 

 

image.png.5f3b62b9d67e661b4c8d9bfb7a70f0ec.pngimage.png.99deb634cb6e5950a151353a16aed5cf.png

 

 

And with that, all five deletions are repaired. 

 

 

Cleanup and Aftercare

I promised that this was a three step process, and I wasn't joking. Now that we've fixed the navmesh deletions, we need to go back and do more cleaning. Part of it is because the trim and drop job probably introduced a bunch of wild edits to nearby cells, and the other part is that our navmesh info map is probably corrupted. Plus, we need to verify that the CK didn't decide to randomly delete more navmeshes!

 

So first, let's load back into CK with only AS and its masters, and rerun the cleaning functions.

 

image.png.1bf5e42962e80dbcd8a7a8121e601e0f.png

image.png.c8cf712c7efeea7f8d14deb963256ca3.png

image.png.5b47e9ec2c65cf54d577ccaf033ab474.png

 

OK, looking good!

 

Now, let's take a quick look for any lurking ITM navmesh edits. First things first, let's turn Simple Records back on in the options menu and then reload xEdit. Just like last time, only load AS and its masters.

 

image.png.3033a4e0fa178acf5c4a580a0bd126ea.png

 

We aren't going to do a full conflict resolution pass just yet, but sometimes xEdit misses ITM navmeshes, and we want to get rid of any of them before we regenerate the Navmesh Info Map. So once you've loaded back into xEdit, right click on AS and choose "Apply Filter to show Conflicts (selected files only)". Just like with the cleaning check, don't add any more files - we only care about the AS plugin.

 

image.png.d7d84a9dffccac4f2d69755cff31f72a.png

 

Here's what we'll see next. We can ignore the non-navmesh conflicts for now (we'll want to look at those in the broader context of the full load order), so we only care about FC11C and FC127.

 

image.png.19f5957344bf3776f6685d02746588ca.pngimage.png.658f9ce402e1776f4f0946b2ec1de43c.png 

 

Both of these appear to solely conflict with the Dragonborn DLC, but they include the essential changes from Dragonborn such as the door links for travel to Solstheim. Since neither of these are ITMs, and they appear to be genuine changes driven by AS's requirements, we can leave them be.

 

image.png.a77984cb57c6258729b2410bcc6c3a10.png

 

So all that's left now is to rebuild the Navmesh Info Map. This last part's easy. Delete the Navmesh Info Record from Ambient Slaves, then go into the CK and save AS - no other changes required. CK will automatically rebuild the NMIM.

 

image.png.a4491354a89c689313e24b737473b2b6.png

 

 

Conflict Resolution - Everything except for landscape and navmesh

The next thing we want to look at are potential conflicts in this mod. We have two goals here - first, to avoid "soft ITMs" that revert important core records and second, to patch conflicts with other mods.

 

Under normal circumstances, all the changes I make here would be going into my private deconflict files. However, for the purpose of redistribution, I'll be putting any conflict resolutions into separate ESL-flagged ESP files. 

 

Just to set expectations, I'll be screening only for conflicts against my current load order. There will certainly be other mod conflicts that need to be looked at, but it's just beyond the scope of what I can do in a reasonable amount of time to go out in search of all of them.

 

Before we go on tour within the game world, first we'll screen the plugin in xEdit. Go ahead and load up the full load order, and then filter AS for conflicts (like we did at the end of the last chapter to look for navmesh ITMs).

 

Right off the bat we see one promising sign - the only conflicts are worldspace related. This means that we are basically talking REFR, NAVM, and LAND records. We're going to focus on REFR for now.

 

Here's a typical conflict:

 

image.png.2aa77a57e6b0a251e711274f92f69097.png

 

When we run into something like this, we have two choices. We can go into the game world and tour the location, or we can just arbitrarily choose one or the other. In this case, we need to go see it in game, because the AS footprint in this area (Solitude) is substantial enough that XPO's relocation might conflict it. So... let's go into the game and see!

 

F80E1 is a maple tree. As you can see here, it clearly conflicts the XPO furniture. However, the bigger issue is that it's hard to reach the XPO item because the gibbets are getting in the way.

 

ScreenShot536.png.7f1ee184e435c8846b92d050a123e2bc.png

ScreenShot537.png.8d7650003d83e7b6e7d07e07db048591.png

 

We probably also want to move that wheel static, since it's also hard to path to with the new stalls in place. The brazier in between the two is also from XPO and since its uncomfortably close to the ivy plant, we'll want to move it as well. 

 

This is CK work, so what we want to do is copy these three statics as overrides into a new ESL-flagged ESP file. If you've ever done compatibility patches in the CK before, you know the rest of the drill: add AS and XPO as masters for the patch, then temporarily add ESM flags to both XPO and AS.

 

In the CK, I moved this furniture to an unobstructed wall and then went back into xEdit to clean up the patch. As the CK is wont to do, it'll add a bunch of junk to the plugin from wild edits, object masking, and so forth. Once we find the unexpected records, we can just remove them from the patch.

 

image.png.0fb7ba0f9fc88ed63d852223f42899df.pngimage.png.d08b567d5a353fb6f177f7f962214858.png

 

 

 

On that note, it's time to wrap up tonight's session -- I'm told that I'm doing the ADHD hyperfocus thing and forgetting to make dinner! So, I'll leave you all with this and post the rest tomorrow.

 

 

 

 

image.png

3 Comments


Recommended Comments

Hey Gregaaz, thank you so much for this! This is incredibly helpful. Though I'll have to read it several more times to get all of it in my head, already, your articles taught me more about ITMs and wild edits and navmeshes than what I was able to acquire form the sources I studied before. Now I finally get what ITMs actually are :), and you are absolutely correct, none of them are intentional.
Awesome work, can't thank you enough!

Link to comment

I had to do an extra step to allow manual cleaning in xEdit. In the options under the Experts tab, check Allow Manual Cleaning functions. For anyone else that may have had trouble with it

Link to comment

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use