Default objects from Oblivion.esp are disabled so their references aren't removed, and their Z position set to -30000 so that the game won't load them. If another mod tries to utilize a reference that's been deleted, it could cause problems -- deleting a reference instead of disabling it doesn't mean the game will automatically crash, it means there's *potential* for someone's game to crash in certain situations.
When you select to "delete and disable" when cleaning a mod, that's what's happening: a deleted object is restored, disabled, and set to -30000 Z.
If the object's ID starts with two zeroes, it's a default object. If it's 01, 02, etc., it's been added by someone other than Bethesda.
FWIW it's also a good idea to include a readme file so that people would remember why they downloaded two versions of RoM.
So am I causing trouble for everybody by removing them, and how come no other major mods have floating objects thousands of feet under the surface? Is there anything I can do to improve the quality of mods I release? I've noticed for example I'm getting many errors in the CS loading this mod but I don't quite know how to start diagnosing them.
It's common practice actually. It's only really necessary when removing objects that were originally there (either from base game ESMs or another mod that is a master to the one being made). So in this example, all those "deleted" objects were from the original game. If any other mod calls one of them while they are deleted, the game will crash. Not a problem if no other mods affect a cell, but given the density of modding for Oblivion, it's a very high possibility.
TES4Edit has a function to find all deleted references and make them disabled and bury them that deep. That far down the game won't load them (and thus affect performance) because they are to far from the player.
The second question is tricky, depends on the errors. Are you using the extended construction set (CSE)?
This is not to dimish your work, the pathgridding and tweaking of object placement is very much appreciated. Oblivion is just a bit sloppy behind the scenes and takes a bit to learn all the caveats.
There is a reason the xEdit cleaner 'undeletes' things. I was told to just disable objects and move them out of the way, otherwise things get effed up.
I'm not an expert and do not know the mechanics of why deleting master objects is to be avoided.
If a record references to a deleted entry the game will CTD, so instead you hide the object, now while modding in the CK you can just delete whatever u want and have TES4Edit undelete and hide them automatically to avoid the aforementioned CTD.
If that's the case the buried rocks and trees must not be master objects because my game definitely has not crashed. Then again I'm running New Vegas Anti-Crash which may be doing it's job. Deleting master objects used to make it more difficult to keep one's savegame when installing a mod like this, however I believe in the long run it's better to just not have that content there.
I did also clean the mod with TES4Edit so it may have prevented that issue in the first place. I now see what you mean by "disable" and "undelete" - in the CS editor there is a secondary door to Miscarcand that is just floating there, however it is not visible in-game so it must be scrubbed.
If it mattered that much we should be able to fly under other landscape mods such as Better CIties and Unique Landscapes to find removed objects and that is not the case.
As a rule, an override-record should never delete a record included in another .esp/.esm. It is far preferable to flag it as 'initially disabled'. This will have the same effect on your FPS but without the risk of screwing up save files or crashing games.
Now if you are editing the master record directly, then you can delete the records with abandon. However, after you launch your first public release of a mod it is better to initially disable unwanted records. Not essential and sometimes unnecessary, but it can avoid weirdness when end-users update between versions.
I would also not recommend relying on xEdit to fix issues after the fact. Not because xEdit isn't beauty incarnate. More that it is better to follow best practices and avoid the need for xEdit fixing, in the first place.
The engine being held together with duct tape and broken dreams at the best of times, it's often far better to veer on the side of caution when working with Gamebyro.
8 comments
When you select to "delete and disable" when cleaning a mod, that's what's happening: a deleted object is restored, disabled, and set to -30000 Z.
If the object's ID starts with two zeroes, it's a default object. If it's 01, 02, etc., it's been added by someone other than Bethesda.
FWIW it's also a good idea to include a readme file so that people would remember why they downloaded two versions of RoM.
TES4Edit has a function to find all deleted references and make them disabled and bury them that deep. That far down the game won't load them (and thus affect performance) because they are to far from the player.
The second question is tricky, depends on the errors. Are you using the extended construction set (CSE)?
This is not to dimish your work, the pathgridding and tweaking of object placement is very much appreciated. Oblivion is just a bit sloppy behind the scenes and takes a bit to learn all the caveats.
I'm not an expert and do not know the mechanics of why deleting master objects is to be avoided.
If a record references to a deleted entry the game will CTD, so instead you hide the object, now while modding in the CK you can just delete whatever u want and have TES4Edit undelete and hide them automatically to avoid the aforementioned CTD.
I did also clean the mod with TES4Edit so it may have prevented that issue in the first place. I now see what you mean by "disable" and "undelete" - in the CS editor there is a secondary door to Miscarcand that is just floating there, however it is not visible in-game so it must be scrubbed.
If it mattered that much we should be able to fly under other landscape mods such as Better CIties and Unique Landscapes to find removed objects and that is not the case.
Now if you are editing the master record directly, then you can delete the records with abandon. However, after you launch your first public release of a mod it is better to initially disable unwanted records. Not essential and sometimes unnecessary, but it can avoid weirdness when end-users update between versions.
I would also not recommend relying on xEdit to fix issues after the fact. Not because xEdit isn't beauty incarnate. More that it is better to follow best practices and avoid the need for xEdit fixing, in the first place.
The engine being held together with duct tape and broken dreams at the best of times, it's often far better to veer on the side of caution when working with Gamebyro.