Jump to content

Skyrim CK Log Warning


Migal

Recommended Posts

I know some of the logged warnings for the CK can be ignored, such as warnings about armor using non-biped slots (intentionally).  But, I'm not sure that's the case with this one.

MASTERFILE: Unable to find editor location (03036D12) for NPC KattyJanna' (05028F79) for Location 'MMStorageLocation' (05036D12)

The only time I've seen the term "editor location used is in AI packages.  I've always assumed it was a reference to where we dropped an actor into a cell in the CK window, creating the ActorRef.  I have this actor set up with its Persist Location matching what is seen in the warning message, and the location has a location center marker.  Viewing both the cell and location records in SSEedit, nothing is named "editor location."  It's simply not a term used in xEdit.  However, the cell is linked to the location.  The NPC is a temporary reference in that cell and I can see its Persist Location, and the location has references to the ActorRef.  Everything looks right, but this is a little more complicated than that.  As you can see by the formIDs in the warning message two plugins are involved.  The actor, cell, and location are in both plugins (master and slave).  Oddly, in the location records, the slave saves the actor (and static data like doors and centermarker) in a different field set than the master.  In the master's location record, actor records are stored as LCPR data and LCID data.  Statics are stored as LCSR data (the L stands for Location).  In the slave plugin, actor records are stored as ACUN and ACID data, with statics stored as ACSR data (the A is for Actor).  The slave and master contain the same location data, but they do not store the data in the same way.

I have no idea if everything I just wrote is related to the CK log warning, because "Editor Location" is a CK term and not an SSEedit term.  I can see the actor in the cell which is linked to the proper location in the CK, so it theoretically has an "editor location."  Packages that make the actor sandbox near its editor location work, so I have no idea if the CK warning is something I need to worry about.  However, I am having a problem with this actor and I'm wondering if it is related.  When this actor changes to an AI package by downgrading from a higher priority alias such as following, the actor does not walk back to its persist location in that cell.  It teleports back immediately.  Poof.  It's just gone, as if COC was used but it wasn't.  That's why I've been looking at CK warnings and location, cell, and actor records in SSEediti.  I haven't been able to figure out what's causing it.

I'm all ears if anyone has any ideas.

Link to comment
Share on other sites

In things like AI packages, a location is usually a reference to some absolute x,y,z coordinates, plus a range of error, so that the engine can accommodate two items trying to occupy the same space. The absolute reference is provided by an item placed by the editor (the CK) and that can be a visible object like a piece of furniture the AI package wants the actor to use, or an invisible marker. Editor location in this context means the object whose absolute position is needed. That message typically happens when the package in one plugin refers to an item placed in its master, but the master has been changed to delete it. 

When you run the game with the target location unresolved for the current package, the engine is likely to disable the actor to resolve the error, and then re-enable them for their next valid package, giving the appearance you described. If the target object is moved to an unreachable location instead of being deleted, the the package can have the actor travel towards the target, and fail to reach it. This is what undeleting achieves when a plugin is cleaned. The package will still fail, but realistically.

Other references to a missing object’s editor location may give the same error, but this scenario fits your symptoms.

Link to comment
Share on other sites

Hmm.  First of all, thanks for your reply.  I fear it may be deeper.  I had assumed this was a package issue and so I remade all the packages at the master level (none of the packages had been touched in the slave).  I checked to see if any packages were pointing at "Editor Location"  and none were, but I added new Xmarkers and pointed the packages at them anyway.

Still, I sense what you're saying about the game getting confused and disabling/re-enabling the actor might be valid.  I'm just not sure what causes the game confusion.  It's like, the game goes, "I don't know what to do with this character when it switches from its current package to a lower priority package (such as when the character is in an alias that gets cleared) and so it runs home to mommy and dumps the character at its persist location, where AI properly picks up again.  Note that this behavior will not take place in the persist location cell, which is the same cell where the actor was dropped into the CK window to create the ActorRef.  It's only when the actor is in another cell that this happens.

It may be worthwhile to mention some of the testing I've done to try to narrow it down.  I created an alias that used the exact same packages in the exact same order and put multiple different NPCs (including random Nexus followers) in that alias so they would run the packages.  None of the NPCs I tested with those packages exhibited the same teleporting-away-when-dismissed behavior.  It's only the NPC I created in and dropped into the cell I also created.  So, I'm thinking it's the ActorRef itself, the cell, or the location the cell is part of.  But as I said, I can't see the problem in SSEedit.  Then again, I don't know exactly what I should be looking for so I can't say for sure.  It's just that nothing jumps out at me.  I've even compared the NPC and cell settings to vanilla counterparts and it looks okay.

I think maybe I should search the cell for records that were deleted in either the master or slave and see if I can find anything.  Thanks again.  What you say about the NPC resetting makes sense.  I'm just not sure what's making it happen.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...