UPDATE

All the issues described in this thread are being accumulated (after discussion) in the

Troubleshooting

category on the CS Wiki. It's not complete yet and will probably be rearranged, but it's shaping up into a nice list of issues (and solutions, where they exist).

=================

How it all began:

A recent discussion I had with scruggsy in the Reneer's Corpse Mod thread prompted me to start some digging on common problems related to savegame bloating. It wasn't easy to find good information about this issue, and in the process I remembered some other old nightmares that don't seem to be very well documented, either.

So, I'm wondering if anyone knows of a good place where this sort of info has been collected already? If not, it surely seems like it would be worth creating a resource like this.

Any thoughts on this would be greatly appreciated.

Here's a brief list of some common mistakes and their effects on players. Please suggest more ideas if you can.


PlaceAtMe Bloating Savegames

I was most surprised to find no mention of this issue whatsoever in the high-profile tutorial Casting Spells From An Activator, which apparently gives very bad advice by giving script examples that will leave garbage in your savegame. The problem is that disable doesn't remove the reference from your savegame. It's mentioned on the Etiquette page, but this is a pretty weak warning:



The PlaceAtMe page has a good warning and the Talk:PlaceAtMe page has some additional details, but these issues are not mentioned in the places where people really look for answers (i.e., tutorials), so I'm not sure how effective this is.

This really scares me because in the last month or so my primary savegame has ballooned from ~12Mb to more than 26Mb. I have no idea which of my 100+ mods might be doing this (maybe more than one of them!), and there's a reasonable chance that disabling the culprits won't repair this damage even if I do find them (I do have to find the culprits to prevent further damage). Does anyone know what some of the most common culprits are?

I certainly suspected weather mods right off the bat, so I already disabled GetWet and PJ's Lightning Strikes During Storms, but this didn't have any obvious effect. I haven't had time to check the scripts in those mods yet.

I found a post by Wrye on the UESP site saying that a companion mod has caused problems like this, but it was pretty old and didn't mention any names.

I'm guessing the reason this issue hasn't been more widely discussed is that it seems to be a bit tricky to use MoveTo on a persistent object instead of PlaceAtMe/disable on a temporary reference. There's some discussion about this on the Talk:MoveTo page, but it's far from being concise or clear.

Has anyone written a good tutorial on how to properly use MoveTo instead of PlaceAtMe/disable? Deathless Aphrodite recently posted some good teaser/hints about using a check on loading screen with begin menumode 1007 so that MoveTo will work when you go from exterior to exterior, but I didn't find much else on the subject.


Pathgrid CTDs

This is an older problem that plagued both UL and OOO for a while. Basically, changing pathgrids is risky and requires a lot of testing to avoid CTD issues. I didn't find any surefire solutions for this either.

Anyone know if this topic has been written about in any more detail than the introductory Path Grid Generation article and Path Grids (simple)?


Changing Script Variables

This issue is best summarized in Wrye's thread Overriding Scripts and CTDs based on discussions started in MentalElf's thread In desparate need of a save game editor, but it seems like this info really hasn't made it into popular circulation yet.

Perhaps the CS Wiki should have a prominent page about Common Gotchas or something similar where we can accumulate this sort of stuff?

I think a common gotchas or maybe a "Troubleshooting FAQ" would be very helpful. Break it down by systems like: scripting, AI, Door placement, etc. I spent alot of time debugging my mod only to find that the AI was going berzerk because I didn't have a location specified. AI can really sink alot of time if you aren't careful.

Good suggestion!

I take it from the lack of responses that nobody knows of any good resources other than what I've already identified?

I've just had the time to read it, bookmarked it 10 minutes after you posted, some people only check here once or twice a day. Give them a little more time to respond.

I always follow these kind of threads with great interest, and I'm sure there are more people who do. This is the kind of information that's still lacking and is hard for beginning modders to find if it's documented at all. ESF thread come and go quickly and cswiki pages are not always easy to find, even if this gets a page in the cswiki everyone still needs to know that it's there. This has to be available at so many places you'd have to be blind not to notice it.

I had the same sort of idea after that discussion, dev.
A Debugging page, or a list of commonly overlooked sources of errors would be a great addition to the wiki.

I just discovered a less severe one, but one which can cause severe headaches for the scripter: The compiler will accept a comma in place of a period in reference syntax, but the script will silently fail in the game when the line is encountered.

Easy to miss when you're looking for logic errors.

Yep, I'm in favor of a common problem page. And yeah, it will probably get large after a while, so subsections for dials, scripts, ai is probably wise.

Two categories of problems: Doh! and WTF?
Doh: Oops, should have known better.
WTF: Some bizarre weirdness in TESCS or the Oblivion engine cause a problem.

One thing that might be useful would be a utility that scanned a mod for known problems. E.g. the periods/commas problem mentioned above. Or the different whitespaces on different sides of an if test problem. Or an AI with no location specified. Sort of a spelling/grammar checker for a mod. Or a GREETING that tries to add a topic.

Now that Bash has expanded its understanding of records, a fair amount of this could probably be done as a Bash function. I'll say right now that I don't have enough time to do this. But on the Bash programming thread I've been encouraging other people to take a look. If someone wants to take a shot, I can help. Might be a fun programming project for someone interested in learning a bit of python.

Although I think it's already mentioned in the wiki: the 'add topic' bug regarding dialogue. I've played many mods that had this bug nevertheless (and so I could only play one of them at a time).

Maybe you could also add the bug that vanilla doors can't be moved in mods without incompatibilities with most existing savegames since their position is stored in the savegame data once you come near them. Modders should try to avoid moving doors from the original game.

Another one: the 'remove item' function doesn't work properly with more than one item sometimes. The in game message (produced by the game) is correct, but the number of items the player loses is not. ('5 ogre teeth removed' message, but only 3 less in inventory eg). This happens randomly, no matter which item you remove or how much 'remove item' functions (or other functions) you use in a single frame.

Does anyone really know why the pathgrid CTDs happen? The last thread about it I remember didn't find a solution.

Great feedback, guys! We're gathering quite a list!



Awesome! Glad to know it got you thinking, too.

Yeah, that's less severe, but could leave you stumped and frustrated for hours trying to spot the typo, so a good addition to the list.



Good suggestions! I'll start compiling the page next week if nobody else starts it first.

That definitely would be a great tool. I really hope we can find a volunteer. I guess if I get burnt out on TES4Gecko I might give it a shot, but that probably won't happen for a while.



Definitely the add-topic bug! Good suggestions on all those, for sure. Thanks!

I don't think a final surefire pathgrid solution was found in that thread I linked -- just that you have to try removing and recreating them.

Do you guys think we need to create a tutorial for using MoveTo instead of PlaceAtMe, or is the current wiki page good enough as-is?

The warning needs to be cleaned up at least. The only uncertainty about references remaining in the savegame comes from a Bethesda dev who assured us that deleteFullActorCopy would delete the references.

I think a link to a brief description of how to replace placeAtMe with moveTo (it's not complicated) would suffice.

Has for the Radiant AI packages common problems and solutions . There are so many of them where would one want to start on that..Correct Package Usage, How to Stack them in Ai to work right..

Most of these issues are usually solved by having the right location, time, duration, target, etc..what is needed in the package..

I have seen alot more AI question's come up in the past few weeks ..There is really not a good guide on the wiki about making AI Packages work, how to stack them..Condition Data that is used in Radiant AI Packages..

there are a few but nothing like really complicated with ai packages stacked like so

example :

travel/eat/sleep/wander/useitem/usemagic

Yeah, I saw that bit of confusion. I suppose that would naturally cause quite a bit of lag in getting this issue properly dealt with.

Sounds like a good plan.

Thanks, man!



Good suggestion. Thanks!

Its the same with the patched game? If certainly the mod has been started and finished with patched esm.

Two from me:

1. don't assume that if-tests stop at the first non hit.
if (myref.isactor and myref.isincombat)
could cause a crash because myref.isincombat is always checked, even if myref isn't an actor.

2. Don't use existing object names as variable names. The existing ones get priority:

ref bed
set bed to ThisBedref
player.moveto bed

probably causes a CTD because 'bed' is also a topic id and will get priority here.
Other possible mistake names: enemy, accept, contract, creatures, gift, help, inventory, positions, placeholder, tasks, themage.

Mentioning the crazy issues with getself!=player in certain spell scripts is probably worthwhile. I've had spells misfire and throw the player miles across the landscape thanks to that.

Plus, perhaps an exhortation against the evils of "ForceAV" could be added in, just in case .

Doing



then



on a NPC that has a negative item count doubles the items every time you do companion share. That means that the NPC will have 65536 items of a kind after 16 shares, 16777216 items after 24 shares and 4.2 bilions after 32 shares

I'm gonna be honest with you dev. 90% of the 'tutorials' on the wiki are in greek to a brand new modder.

When I was working on Crypt of Decay, I used that page on MoveTo and PlaceAtMe for my coffin traps. It was so not understandable to a new modder that I had to finally go with PlaceAtMe because I could understand 'how' to use that one. Even after spending hours trying to decipher the explanations, I ended up having to come on the forums and ask for help.

May edit this later or add another reply, gotta get daughter to school =)

Good one!



Thanks, man. Sounds like it does need some work then.

Along similar lines as the add-topic bug, perhaps we should mention something about removing GREETING dialogue?

Lots of good info in this thread so far.
I'm thinking, though, that we're talking about two different types of issues.
It would be good to have a page with common causes of crashing, freezing, or script failure (scripts stops running but OB continues without issuing a warning).

Quirks associated with specific functions like RemoveAllItems or GetSelf which don't result in script failure or CTD, on the other hand, probably belong on those function pages.
A page collecting those various quirks in one place would also be useful.

I don't know if you are collecting "gotchas" on this thread, but here is a list off the top of my head that new modders may run into that would be of help knowing about before they run into them. I won't bother with lengthy explanations until the Wiki page gets started.

1. Don't ever hit the CS button "Recompile All"
2. Don't run "Generate All" pathgrids or "Generate Entire World"
3. Don't try to copy things from one ESP into another ESP unless the items come from Oblivion.esm
4. Don't modify cells in Oblivion.esm in another master.
5. Cells not modified by your mod shouldn't have asterisks next to them (use TES4 PU to "clean" your mods before release)
6. Texture paths need to be relative to the Data folder, not higher (not C:\Program Files\...)
7. Package mods so they can be unzipped in the Data folder without extra subdirectories.
8. The README should be named ModName-README.txt so as not to overwrite existing READMEs from other mods.
9. .7z (7-zip) is the currently preferred format [This can cause a debate, but new modders need to know about it.]

Where can I get TES4 PU?

Get TES4Gecko, which is the latest version of TES4PU.



Agreed. Definitely need to separate them in some logical way.



Yes, we are indeed collecting "gotchas" here. Great list! Thanks, man.

Do you guys think we should include the infamous black screen bug?

I know there is a way to prevent it from happening (possibly more than one way), but I'll have to track down the details. We had this problem a lot with OOO in the early days and one of the graphics guys on our team figured out how to solve it. I know it's caused by a bad mesh/material combo with HDR on Nvidia cards, but I need more specifics.

I noticed that Floydian1 recently got the same problem, but it doesn't look like he got any responses.

I did find one possible cause/solution posted by nicoroshi. Here's what he said (about his Bow of the Drow mod):



If anyone else has details on how they were able to solve this problem, please let me know.

Thanks!

Hm, all I can say about the black screen issue is that it can be solved in a lot of cases by updating the tangent space of certain mesh nodes in a .nif file (NifSkope's got a spell for that).
Once you've narrowed down what .nif is causing the issue simply open it in NifSkope, right-click each NiTriStrips/NiTriShape node and select Mesh -> Update Tangent Space.
This has worked for me most of the time.

X.

Awesome! Thanks!

^ Yes, I had that problem with one of my meshes and X suggested the same thing. Fixed it right up.

A minor gotcha for the list: don't start an ID or variable with a numeral.

Looks like this problem may also be caused if you have an opaque texture assigned to a transparent portion of your mesh. This was apparently the case with some items that caused black screens in early version of OOO 1.3.

Might be a bit late to add to this thread. But another way to prevent unwanted dialogue, whether in greeting or other dialogue like conversation, combat etc, is to add to each ones condition : getIsID myNewNPC == 0. Then your NPC will never choose them. It will take a while, so make good use of the copy/paste condition function.

If you have created your own dialogue, just make the condition true (==1).

BTW, I dont really understand why RemoveAllItems routine will bloat save files. I thought this function just transferred items from one place to another, rather than create new instances of them. Can someone explain it further as I am in the process of making a chest that does the same thing.

It's an issue with calling removeAllItems on an actor or container that has a negative count of one or more items.
Negative quantities mean the item is restocked when it's depleted.
See the first page of this thread for an example of how this can cause bloat.

Be aware that if two or more mods try to alter the same topic in this way (or any other way, really), only the changes in the mod loaded last will take effect.

So Reznoids Easy Companion share is ok to use as long as the NPC doesn't use negative counts in there inventory by typing -1 when you give them things like arrows in CS. Or do all NPCs have negative counts for items in there inventory. I noticed arrows I handover - ingame- to the NPC always stay the same. During the game I gave 4 glass arrows but the NPC is able to fire them indefinately. Is that how it is?



... things are never easy are they. Its driving me to oblivion

I noticed the item doubling when i used a dynamical companion mod that could give you an NPC army. I dragged a mages guildie along, and she had a book on her (-1 amount) and it cloned itself every time i did companion share. So i took a peak, did my own mod to see why it happened and found that doubling issue.

As for NPCs, i *think* pure archers can fire arrows indefinitly, even without ammo. I *think* that archers with a secondary weapon switch to it when they run out of ammo for their distance weapon or if the target gets too close. I have never seen a pure archer NPC switch to destructive magick or hand to hand.

Things you give to them get doubled, too. In my case I had a massive number of books and weapons stored in my savegame. The books were a stock item given to the companion by the mod, but the weapon was one I gave him.

FYI, motub has posted a great guide for dealing with the GREETINGS/ADDTopic Box bug. I've asked her if we can include it in the Gotchas page.

And so, here it is:

Just to summarize the issue for those just joining our program, the GREETINGS/Add Topics box bug is one that a lot of modders miss when creating their mods, because 1) it's a bug in a perfectly legitimate CS function that one thinks one ought to be able to use; and 2) the bug is only triggered under specific circumstances that many modders and users don't necessarily encounter, because it requires both the affected mod and another mod which changes GREETINGS to be loaded after the affected mod.

Neither the affected mod nor the triggering mod is bugged; the bug is in the game engine. For that reason, I've made a minor crusade of publicizing this bug and documenting mods affected by it, because a number of really good mods have been blamed for errors that are totally not the mod nor the modder's fault, and that many modders don't know to watch out for when creating their mods.

The bug itself:

To make a long story short, if a mod changes GREETINGS, and also uses the AddTopics box to add topics when the new GREETING is played, this functionality will work fine unless another mod which also changes GREETINGS is loaded after that mod (whether or not the second mod also AddsTopics). The deal is that the engine is supposed to increment the AddedTopics IDs when another mod then later changes GREETINGS and doesn't (or doesn't do so correctly, or something along those lines)-- in any case the result is that the topics are still there, but the "connection" between the name of the topic and the ID the game thinks that topic has is lost, so the game can't find the topic to load, so it doesn't (of course). But this will only happen if another mod which changes GREETINGS loads after the mod using the AddTopics box; what's worse is that both GREETINGS themselves play normally, so the mod seems to be working fine.... except that you can't get the quest or whatever, because the topic itself does not appear.

If the affected mod is the only one that actually uses the AddTopics box, then moving it to the very end of the load order will solve the problem functionally (meaning that the topics will then appear, which is why KotN was advised to be moved to the end of the load order until it was unofficially patched). Problems arise if you have two mods that unfortunately use the Add Topics box-- moving one to the end of the load order breaks the other and vice-versa (because they both change GREETINGS, so no matter what you do, you'll have a mod which changes GREETINGS loading after a mod that uses the Add Topics dialog, which is the whole problem).

Fortunately, once you identify the mods affected (easy enough, because they're the ones that inexplicably have no new topics for the NPCs), they are quite easy to fix in the CS, by removing the topics from the Add Topics box and adding them instead to the Result Script:

1. Open the affected mod in the CS.
   
   
2. Go to the Characters => Filtered Dialogue menu.
   
   
3. Select GREETINGS (which will have an * asterisk after it, indicating that it has been changed by the mod).
   
   
4. Scroll down the GREETINGS list and look for the dialogue topics that have a * asterisk before the dialogue in the upper section of the window-- so you'll see a topic name in the first column and "* Whatever the NPC actually says" in the second column, and select the first of these dialogue lines.
   
   
5. In the rightmost box in the lower half of the window when you have selected an individual topic, you should see one or more topics listed in the box labeled "Add Topics". These are the problem, or rather these are the uses of the bugged function of the engine-- if another mod loads after this one that also changes GREETINGS (whether the second mod itself AddsTopics or not), these topics will not be loaded correctly, resulting in a broken mod. What you need to do is move these topics one box to the left, to the Result Script, so that they will be added, no matter what. It's real easy.
   
   
6. Point your mouse cursor at the first topic in the Add Topics box, so you can see the tooltip that tells you the name of the topic (you can't extend the box or make the columns wider, so this is the only way to see the full name).
   
   
7. Then click on the end of the last line in the Result Script box to get a text cursor, and hit Enter to start a new line if necessary, then type:
   
   AddTopic <name of the topic you just noted>
   
   There is no space between "Add" and "Topic" (the command the game recognizes is AddTopic not "Add Topic"), and capititalization of the A in Add and the T in Topic may not be required, but then again it may, so just do it, to be safe.
   
   
8. If this is the only topic added for that particular line of dialogue, then click the "Compile" button next to the Result Script. If multiple topics are added, then add them to the Result Script, one to a line, as before, then click the Compile button. If you get an error saying that the topic is not recognized, you've spelled the topic name wrong; point your mouse cursor at the topic in the Add Topics box again and correct.
   
   
9. When the Result Script compiles successfully, select each topic in the Add Topics box, right-click and choose "Remove" (or Delete, whatever it says, just "the selection that gets rid of the entry" ), until the Add Topics box is empty.
   
   
10. Repeat for all GREETINGS dialogs changed by this mod that use the Add Topics box.
    
    
11. SAVE THE EDITED PLUGIN.
    
    
12. That's it; you've fixed the GREETINGS/AddTopics box bug for your copy of that mod, and may now load it anywhere in the load order and it will work fine. It looks complicated when you read it like this, but trust me, it's really simple when you see it in the CS in front of you.

The main mod that I know of that still shows this bug is "Against the Zealots of the Nine" (JolardHome.esp), but most if not all of the others I came across while tracking this issue have been updated to fix the issue (sometimes even when the modder didn't believe me that it was an issue ). However, a few older but still popular mods which exhibit this issue have had their authors disappear, so you'll have to fix them yourselves. Hopefully that should be a bit easier now .

One more:

Do not create object or variables with generic names, say "SECRETPASSAGEDOOR".

Use a unique identifier that you prepend/append to the name of the stuff you create (in my case it could be: "IchininSECRETPASSAGEDOOR") this will make your mod less likely to collide with other mods.

Thanks, motub!


And felix, too!

Not sure if this was mentioned, or if you caught my thread on this dev, but deleting a quest target crashes the CS. b3w4r3 solves this by

I probably still don't have time, but I'm looking at it anyway. (Got hit with one of the known bugs last night.) So, I'm looking for input on what to add to such a "mod checker" function for Bash. Keep in mind, complex stuff is still beyond Bash, but simple stuff is possible. E.g.

* Check to see if variables names in scripts start with a digit or underscore.
* See if bows have reach <= 0. (I forget why, but UOP fixes this.)
* See if any weapon has a reach > ??. (What's a reasonable value.)

Bash can't yet check dialog topics, cells or worldspaces (it doesn't understand complex block structures yet), but most other records can be checked in simple ways.

Anyway, so what other useful checks would there be? (And what value should I test for on weapon reach?)

2 more things:

1. The Scripting section in the Quest/Topic editor seems to be for very generic scripting like setting global variables and doing things like setstage. Be aware that while some things may compile clean and seem ok, they just dont work ingame.

2. Avoid using Windows Vista for the next few months. Not even the bug loving guy at Sheogoraths shrine would do it.

I'm sure there are some instances where PlaceAtMe is ok? I used it to generate a daedroth at a stone:

The 3418 re didn't seem to be a problem, or are we looking at "unique" objects?

Well you can certainly delete any PlaceAtMe object that can be put into an inventory. You should be able to use CreateFullActorCopy/DeleteFullActorCopy for summons-like effects.

PlaceAtMe is a very general command and I'm not sure all items you can create this way will be automatically deleted after 3 days but certainly the ones I've messed with seem to. I suspect that by Disabling an object you might actually be making it more permanent wrt savegames.(?) With LTC I used the teleport method but re-used a set of the critters.

The PlaceAtMe problem is in fact a general problem with orphaned objects ( objects without a reference to them )

When you use :


the object is created as part of the cell, with a non-persistent reference. You can create many of them without problems. They are stored with cell data and are removed after the usual 3 days.

but if you use :



the object is created as a persistent object referenced by myref, and is stored as a persistent object.


If you use :


a second time, while myref was already pointing at the first object, this first object is now orphaned, without any reference to it. When trying to save, the game will not be able to decide where it has to go, causing a crash.

This means that you have to destroy the object when you no longer need it if you want to be able to create another one later :


But this simple code can also create corrupted saves. WHY ?
Because when you save the game, the script is stopped in the middle, and the end of the script will never run because the instruction pointer is not saved. . When you load the game, it will restart from the first line, and if it stopped between PlaceAtMe and RemoveMe, you will create an orphaned object.

This means that you have to test the reference and destroy the first object before attempting to create a new one :



this last code will never generate a corrupted savegame

The same problem appears with CreateFullActorCopy, and is solved the same way.

Another way to cause a crash is using a reference to an object that was deleted, or, in some cases to a dead actor.
One case I know of is when using GetSelf in ScriptEffectUpdate or SccriptEffectFinish blocs for area of effect scripted spells. GetSelf can point to a dead body, causing a crash if you try a function that requires it to be an actor, or even null if a summoned creature has been killed in the area.

No. IIRC, the trouble with Reznod's Easy Companion Share was in regard to scripted items being cloned, not negative item count ones. CreateFullActorCopy/DeleteFullActorCopy cause bloating if the Companion involved had a scriptedd item in his or her inventory. That's a totally different issue than the negative item bug with RemoveAllItems.

This is when testing mods:

When testing AI packages, do note that they will remain in effect if you should load a saved game to test something again. If you want to be sure you have a "pure" sandbox, restart Oblivion from scratch for proper results.

I don't know if the PM's I sent in reply got through as the send function seems to be broken, but thanks for referring me to this thread. It's pure gold... one of the most informative useful threads I've yet seen. All of this info will, I hope, get archived somewhere (ie cs.elderscrolls.com) as it's too good to be lost.

The crash was for bows with Reach = 0 and IIRC occurs when they are equipped by anyone (player or NPC) Good thing to avoid as a "Gotcha".

Other than this, as far as a requested checking function, checking for "dirty" records where the record in the ESP is the same as in the parent ESM would be highly useful to ensure mods are lean-and-clean (this would also catch instances of the previously mentioned accidental use of Compile All.)

Yes, the intent here is definitely to compile material for a Gotchas page on the Wiki. I'm going to try to get it started this week if I can. I meant to start it last week but got distracted by a lot of other stuff.

Nice! Here's a possible "Gotcha" as it's caused a couple of bugs with vanilla that we've fixed so far: check for AddScriptPackage not being followed by EvaluatePackage/evp. Without the evp the engine is not consistent applying the new package so it may not take effect even if it fulfills all the conditions. Sometimes an added package isn't to be used immediately so it isn't always a problem, but it's at least worth a warning as if the added package is to start immediately it will definitely break for some players.

Edit: Scruggs has posted below indicating that they should not be followed immediately as he's seen it cause crashes.

I've gotten an annoying bug when trying calling ForceFlee on an item script without using a reference.


The ModAV2 ended up infinitely looping and the RemoveMe was never reached. Took me a while to find that error. Not sure if this happens with other actor-specific functions or not.

Also, I learned from TheTalkieToaster that ModAV2 doesn't take floats. That is what it says in the wiki but it's easy to assume it takes floats.

Seems like send server was having problems on Saturday night. Anway, repeating my pm'ed answer for the benefit of other folks...

Unfortunately, it's not that easy.
1) Formids all have to be remapped.
2) The structure of a record is not actually determinate -- i.e., the same data can (and will) be stored in different ways, plus there's junk in the records (i.e., there are actually data fields which seem to be filled with random data), plus older Oblivion records are stored differently than newer records. Also, Bash does not yet handle cells or dialog, which are where such errors are probably most likely to be.
3) Also memory requirements are pretty stiff since it would be necessary to access and analyze the full Oblivion.esm file. Not small.

I'm busy compiling a document with all these Gotchas in it for a number of reasons. Can you tell me when this list is compiled? I'm trying to be as helpful as possible with this.

Porject is A Complete modders resource.

I'm just wondering but can CreateFullActorCopy be used in place of PlaceAtMe's for casting spells? You can make them invisible with SetActorAlpha and they have the advantage of being deletable.

How much of this have you confirmed? I ask because I had troubles getting myref.RemoveMe to work, especailly in the same frame it was created. Usually RemoveMe has to be called by the object itself when in the same 'cell' as the player. This sounds more Java, in which case you would expect orphaned objects to get deleted too. It also sounds unlikely to me that the following would automatically create 'orphaned persistant objects':

There are several factors to consider including the persistence time for the calling/creating objects, cleanup factors vs. when things sequentially get deleted and the way BS handles multiple scripted objects running game mode at the same time. (Throwing multiple Dwemer Axes in Throwing Stars showed some weird behavor here - only one script would run at a time in some frames.)

????


CreateFullActorCopy is too slow. DeleteFullActorCopy is instant. As I said, it is for summon (like) spells.

You can cast from almost anything, even disabled items that can be put into an inventory and removed:
Removing PlaceAtMe items

But personally I keep an X-marker or two for this purpose and use MoveTo - much quicker and always invisible.


This code couldn't be a better example of what not to do.
1) GetSelf should never be used in GameMode OR
2) RemoveMe is not good to use outside of GameMode/MenuMode (isn't applicable to spell scripts)
3) ForceFlee doesn't really work unless the actor is already in combat (see cs wiki) (and frame scripts on NPCs in combat dont work reliably) [Needs a reference if the above is an item script.]
4) ModAV2...

Yay, I'm a bad example. I feel so rebellious.

Anyways, I simplified the code a bit and it was done from memory so might not be very accurate. The getself is done in the OnAdd block. The rest is gamemode. As for forceflee, it may have been playgroup. The lack of a reference was my point. The script still compiled so it could be hard to find such an error. This was from a while ago.

Ah... just remembered another goody that I think Quarn discovered. If there are any changes whatsoever in one's mod made to Tamriel worldspace cell (3,3) then all the map markers (player's and locations') in-game will disappear until the changes to (3,3) are removed. Weird engine bug I imagine. That may be something that can be checked for as well.

Really?
I've fixed several crashes in my mod by removing evaluatePackage calls following addScriptPackage.
ForceFlee followed by evp (even with a delay of up to a second or so between them) is also a first-class ticket to a crash.

Don't even get me started on this.
Oblivion is lazy about resetting the game state when loading a savegame from the in-game menu.
It's particularly a problem when loading a game saved within the current cell.
Besides the AI package thingy, other problems include inventories not being reset - for instance, I call removeAllitems on a container when the game is first loaded. If I then reload that same game, or any other one saved prior to the removeAllItems call, the container remains empty, breaking my mod.
Stupid.

I'm curious as to how and where you came up with this information.
Almost all of it contradicts what I've observed in my scripts and tests.
I'm not doubting you, just confused.

Finally, I found a new way to cause mayhem: don't call activate on an object which is destroyed (had setDestroyed 1 previously called on it).
All scripts in the cell will stop processing until you change cells.

Interesting... well, scratch it as something to be checked that they are close together then if it needs the delay (in some circumstances, as I've never seen that happen yet.) And thanks for the info.

Okay, I've posted a ROUGH DRAFT of the new Troubleshooting category on the CS Wiki. It doesn't have everything in it yet, but it's a decent start I think.

I'll work on it some more tomorrow.

Please feel free to contribute new articles and corrections, etc.

It's a very good summation and it's good to see someone's doing this, thanks! Can you place a link to it from the Main Page of the wiki? I only have 2 comments - could you sum up the script variable override posts? (Talos knows I can't!) and the remove item bug - is it random? I've only had the problem with the Guild Ownership mod (v1.2) and any ingredients that were changed.

Also, I have another bug to add. Should I directly post in the Wiki or place it up here first?

involving evp, how then could someone fix the bug in the origonal reznod companion share so that they evaluate their inventory instantly or shortly after you use it, and they equip both weapons and armor? Also, concerning PlaceatMe functions, you just solved one of my big bugs, thank you very much, but is there a way to have npcs spawned this way stay for more than a few days if you leave the cell? I imagine I could do this with about 20 (delta)refs and a script that attaches them to my mercnaries when the two ai packages are used,(wait and "you are stationed here"), but besides that, I have not yet checked the new compilation, but does it include a proper way to use moveto, fullactorcopy,placeatme et cetera, also considering if multiple, randomized npcs are being spawned?

as a small example, what would be the correct usage for this with npcs that I would also like to delete with a "fire" option, but don't want to let disappear after a few days unless they are dead, and all npcs involved are using the reznod companion share?

if this is discussed in the wiki thread, which I am about to check, i would prefer you delete this post as it just clogs up the actual topic of gotcha's collecting. I was planning to post the fix for add topic as how I had found it during production, but it was already done and all that remained were a few questions involving what had been said. but yes,
later

-edit
aight, i checked the wiki page, it doesn't seem to discuss it very much... anywho, do the placeatme's disappear like normal objects if you don't use spells or disables(stayed away from these intentionally, for the record), or do they still bloat the save?(still want to know if moveto teleport thing works better for this situation(though I doubt it), same with fullactorcopy/delete)

Thanks!

Aye, there's a bit of work to be done yet summing up a few of those things.

I'll add it to an easy-to-find spot once it's a bit more polished.



Your choice. I'm a big fan of getting feedback first, though.

It seems that having another script with a reference variable to an object will make it permenant. Thorskin mentioned it a few posts back and Wyre's done some tests. Not sure about NPCs or whether that means they'll respawn their inventory, etc.



Alright, I suppose I'll mention it here too. The bug - I'm getting CTDs whenever I have exactly these 3 conditions (all are required for the CTD):
1. A scripted item in a container (script doesn't matter, even a script name will cause a CTD)
2. Activate that container with the '1' flag so it's onActivate block fires
3. Activate the container from an object script (no CTD if the player activates it directly, or if a quest script activates it)

Did you even test any of this or is it just assumptions? What you've said here is false, I've gone and tested it and doing set myref to actor.PlaceAtMe object does not make the object persistent at all and doing set myref to actor.PlaceAtMe object a second time does not cause a crash because the old one is an orphan now either.

As it is anyway even if it did make them persistent it sure wouldn't have any effect on anything other then creatures as everything else remains through cell resets, if a creature is placed down with PlaceAtMe the next cell reset will clear it away unless it is a quest item, essential or set to respawn.

Besides ref is a variable like short, long ect, it stores the ID of the object eg 0009843E, sounds to me the way you think it works is it actually stores the entire object in the script or something...

Edit: BTW I did these tests with a quest script.

I guess I should admit that I am doubtful about this.
I wanted to double-check, so I went back and tested again.

Regardless of whether I spawn a reference with someObject.placeAtMe newObject or set questRefVar to someObject.placeAtMe newObject or even a ref var in a script on a persistent object, the references behave the same.

As soon as the cell is unloaded from memory, the reference is as well, and trying to reference it results in an error.
Further, all of the references remain well past the respawn point.

Tried this with a coin and several activators including one which is scripted to disable itself and then print a message in its onLoad block to tell me it's still there after > 3 days.

It seems Quarn has found the same.
Am I misunderstanding thorskin here?

I'm confused. To me, there are 2 different things being discussed - persistence (in memory no matter what cell the player is in) and permenance (remains in the game past respawn points and savegames). Wyre seems to have tested permenance. Quarn, you seem to have tested persistence, but not permenance - I say that because of this line:


Scruggsy, you seemed to have tested both, but I'm confused about whether there is permenance or not: