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:

There 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 a 23d8 ppears 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:


Which references? The ones referencing the spawned item, or the spawned item itself? Permenance is suggested if the later, but not the former.



Umm... so what were the results? Sorry, I am dying to know as this is a big part of something I'm working on, and I've seen every answer from there isn't any permenance to there is permenance looking on these forums.

On persistence - seems pretty clear from Quarn's and Scruggsy's results that there isn't any persistence.

Sorry.
What I meant was: permanence yes, persistence no, regardless of whether there's a pointer to the reference stored in a script, and including disabled references.
At least that's what I'm finding.

Time to try and clear this up a bit, rather confusing…


Persistent Reference:
-A persistent object (Persistent Reference ticked for the object in the CS) will store its information (position, enabled, disabled ect) in your gamesave every time you load the area with the object.
-Seems it doesn’t matter if the inventory item is persistent or not as it will go back to its default start location in the cell when the cell resets as long as you didn’t pick it up into your inventory (as its original reference is removed now and re-created into your gamesave as a persistent one).
-Moving any default non persistent object will make it persist in your gamesave (moved with setpos, moveto ect, provably made persistent too when enable/disable is used on it).
-Using PlaceAtMe is persistent no matter what as ALL the information about the object is stored in your gamesave. PlaceAtMe creatures get cleaned away on cell resets through.

What I was talking about was the permanence of objects placed down with PlaceAtMe, I was thinking of persistence as permanence.

In short anything placed with PlaceAtMe is persistence and shall remain in your gamesave forever unless it’s an inventory or a new object from a mod (as removing the mod will remove its new objects from your gamesave when you save again).

By "persistent", I thought we were referring to references which remain loaded in memory, and therefore can be referred to, even when their cell is not loaded.
That's the definition of a persistent reference from the CS' point of view.

That's definitely what "persistent" should mean. (Incidentally, this is the same as the meaning in Morrowind.)

aight, I think I'll make a very simple version of my last post:
(ctrl+c from pm to devakm)
"Yes, I am working on my project, need help concerning moveto function. I have a blank cell for the npc to be during most of the game, how do I do something close to a place at me, but with moveto instead,(like a teleport thing). I would very much appreciate something of a simple code, or a small explanation on what I should do and why."

hum de dum. where is everyone?

Maybe you could be more specific about what problem you're having with it? It sounds like you've got the basic requirements taken care of.

Did you give your NPC a named reference ID? If you've done that, then doing:

<yourNPCRef>.moveto player

should work perfectly. See the MoveTo page for details.

In this case I don't see what advantage you'd have with using PlaceAtMe.

Dev, is there any more info about the possible PATHGRID issue?
I have had a few people mention CTD's in my mod after leaving the Ranger camp where I had edited some of the grids.

Is the best method to simply do an auto generation and leave the pathing nodes alone?
I wasn't sure if it was ever concluded that this was an issue with crashes but, it seems likely to me, as this appears to be a problematic area for people with my mod.

What I find odd is that I have never experienced this problem.

Any suggestions?

Why is that Scruggs?

Unfortunately, the information we have on this is inconclusive right now.

Just out of curiosity, are you using the official Oblivion 1.1 patch? Are the people who have the problem also using the patch? There's been some suggestion that it may be related to this, but no confirmation yet.

Your best bet is probably to recruit somebody who has the problem to help test, then keep tweaking the grids until you get it to go away. Not a very scientific solution, I know.

Has anyone else run into a problem where using AddTopic unintentionally causes an NPC to behave as if you were using StartConversation on the player?

In other words, without specifying:



in the NPC script, you still end up with an NPC who forces you into conversation when you load the cell he is in?

I first encountered this problem a long time ago with Centurion's Castle Domrose, which is my player's home. I solved it for myself by removing the AddTopic statement in the script on the guy who sells you the castle. Otherwise he would keep forcing conversation with me every time I entered the same cell with him.

I'm pretty sure Centurion never resolved the bug, and now Painkiller_Rider is reporting the exact same bug in a mod he is working on.

Has anyone else run into this and/or figured out how to resolve it?

This one probably deserves a spot on the Troubleshooting page.

Because Robert Sledge is Jesus.
And because the compiler sometimes gets confused when it sees things like:

It seems to interpret 5 as an integer rather than part of a variable name and then doesn't know what to do with the "ForFighting" part.

That's interesting. The reason I ask, is I used that method more then a few times in my mod. I found it easier to organize my spells/weapons/items and such by adding a "0" to the name.
I haven't had a problem with scripts not recognizing the variable but, it is def something to consider, as a precaution anyways.

Thanks

I will have to defer to your expertise on Robert Sledge's genius.

The 'start with 0, 1, _, aaa, zzz' approach is particularly bad when it comes to mod integration (which we're doing more and more of these days).

Best practice is to pick a leading character key and stick with it. E.g., all my personal ids start with 'wr'. All of COBLs ids start with 'cob'.

You can immediately reach all of your items simply by going to any of the lists and typing the beginning of your key -- the list will autoscroll down to the first item that starts that way. This is almost as fast as having the names begin with a number, or 'aaa' or 'zzz' or _, and much more flexible. E.g., for cobl, there are subgroups e.g., cobAlchxxx, cobAlchyyy, so by typing 'cobal' I zip right to the beginning of that group.

Hey Wyre, can you elaborate on why it's bad for mod integration?
Is that to avoid duplication of names?

On the Pathing issue:
I did a little clean up in my mod with the path grids and made sure there weren't any buried or floating nodes (as suggested in another post). I never experienced the crash bug but I did notice much better performance in that area after I had done this. So, if I can find a beta tester who was experiencing the problem I would be interested to see if the crash issue was resolved.

Here's another one that can kill a script at run-time:
Don't mismatch if's and endif's.
An extra endif will slip by the compiler sometimes, but in the game your script will stop running as soon as the offending line is encountered.

Two related issues: block order matters and blocks can overlap. Both rely on the same script example, and one leads into the other.

Block order matters - This causes a CTD upon equipping:


To fix it, you just have to put the onActivate block first. However, if you try this in game you'll see these results: 5 "Equipped == 0" lines and 6 quills in your inventory. To fix this, switch 'Activate...' and 'set Equipped':

Now everything will seem right - you'll see "Equip = 1" and 1 quill.

I take 2 lessons from this - the script can continue from the onActivate block into the MenuMode block, and Oblivion doesn't follow the script line by line, waiting for a return before starting from the beginning.

I'm not sure how to explain this. My only guess - The Activate call seems to fire up a parallel script process while the first one finishes - thus the 6th quill. This continues 5 times before Equipped can be set to 1 (in the original script or in a parallel one, I don't know) - thus the 5 lines and other 5 quills. So, I put a counter into the script:

This returns "Equip = 1, Counter = 1"..."Equip = 1, Counter = 5"
so, I don't think they're parallel scripts.

Yes. Now that we have several ways of integrating mods, this more of consideration. But there are additional reasons for using the namespace approach (e.g., where leading 'wr' or 'cob' is a the namespace):
1) Using a single namespace id sets new content apart from original content. E.g., Combat Torches (now a part of OOO adds several new torches to the game. If I look at the names, there's no immediate way to distinguish them from regular oblivion torches, but if they were something like wrTorch01, wrTorch02, I'd spot them right away as part of the "wr" namespace, and distinct from Oblivion.esm. So, if you have to go in and understand/debug mods it makes such distinctions clearer.

2) It causes related content to group together in the TESCS view. Granted, using '0' does too -- but it also mixes all content from everyone who uses this trick. (This was a common problem in Morrowind where mod integration was easier.)

3) The namespace code ('wr') also usually gives a reasonable clue as to what the source mod is (e.g. "wr" for wrye, "cob" for COBL, "lcv" for living cities of vvardenfell (morrowind mod)).

4) Outside tools can key off eid, which is a lot easier to work with than formid. E.g., Bash has a feature which allows you to import names into a mod from a csv (spreadsheet) file, where the first column is the eid. That may seem like an obscure feature, but it allows you to force similar spells, armor and weapons to group together in spell and inventory lists (e.g., my Rational Names mod). Somewhere on my to do list, I've got in mind similar functions for say weapon balancing, and other misc. bits of data which could be tweaked. So this function requires unique object ids.

Update on this from Painkiller_Rider:



I asked him to please go ahead and test it further when he gets a chance so we can include a good description of this strange error.

Would you mind describing these in more detail so I can add them to the page?

Hmm, I think this might be the topic to post this under. I have a summoning station that allows me to summon a few baddies to fight. I've opted for the moveto function, and simply gave the monsters a persistant reference and tucked them away out of the game screen. They are called, created a copy of, and moved to the area to fight. However, the deletefullactorcopy doesn't seem to work when they die. As this can cause a rather large number of corpses just laying around (depending on your savagery, I guess), I'd like to know if you guys have any idea of a way around this. Here's a snippet of the code I used to do this.

As you can tell, it's menu driven, and works peachy except for the corpses. Any ideas?

More or less as-is. Getself!= player, when called in a scripteffect spell, sometimes evaluates true for the player. Scruggs has encountered it too IIRC, the easiest solution is to add a "getdistance player>0" condition into the code as well.
The hurling across a mountainside was just martial arts move scripts .

Okay, cool. Thanks!

Hello,

Been a long while since i last visited these forums, not since Morrowind and I must say it's great to be back.
I started to try TES for oblivion a while ago and made some small test mods and just recently I started to script in Oblivion (used to do it in Morrowind).

What im trying to make is one of those organic containers from Oblivion, that when "summoned" by using a spell, grows out of the ground and you can store items in it.
I started to check on the wiki and found MoveTo

I decided to use that and made this simple test, using the Notes about containers moved by moveTo:

The script is placed on a deadric mace (OBOHW) and OBOHCR (i know bad choice of variable names... it will be changed when im done testing...) is an Persistent Reference on an container i placed under the arena (random place...)

Now to the problem. The first time you "summon" the container it works. You can open it, add remove etc. But then when you summon it again it do look like it has worked but the container cannot be clicked and can be walked right through.

I choose to post this in this thread because you where allready working and debating moveTo.

//excuse my english, it's usually not that good and now it's 3am here so thats not helping =)

Stefan, that's an issue with MoveTo in which the collision shape doesn't move with the object.
The Talk page for moveTo on the wiki has some good info.
Calling disable after moveTo, and then enable a frame later, may fix it for you.

GetDistance is okay unless the player is swimming.
getIsReference player seems to be the best solution.

:bump:

Great! I have one to add:
When you call on a game setting, make sure to use the GetGameSetting function. The script will compile, but won't run at all in Oblivion - at all, and not 'it acts as a Return function' or it CTDs, it just doesn't run.

One that nails me often (along the lines of the comma for period thing), is mismatched parentheses. The CS will refuse to save the script, but won't tell you what's wrong with it, either. IIRC, it also disables all error messages for that session, too. Very frustrating.

Can you clarify here?
The compiler will accept a non-existent game setting, which will cause the script to fail silently during gameplay.
Is that what you're referring to?

The same thing occurs when you fail to follow an elseif with a condition.

Sorry, let me give the example. I was doing checks against the minimum Apprentice level like so:

This would cause the script to compile, save, etc. just fine, but not run a single line of it in game. Once I used the proper command:

everything started working again.

Oh, okay. I'm surprised it compiles in the first place - definitely a gotcha.

It seems like an appropriate time for a bump. Let's see if I can add one too:
Be careful with containers/NPCs in Oblivion realms. When the player closes the gate, the entire realm is reset including your containers/NPCs. At the very least, this means the inventory will be reset and they will be returned to their original locations. It might also reset any script variables on the objects and so would also affect activators, etc. For containers, simply move them back to a safe cell when you're done with them. For NPCs, it seems that they will automatically follow you out of Oblivion if they have a follow package going at the time and they are quest items. See these threads for more information and a way to detect if the gates are closing.

Some great additions here lately!

Sounds like I should also add some mention of Quarn's black screen bug discovery.

You remembered the thread! So, what exactly is going on with the wiki page?

A topic, since someone else seems to have also run into it - scripted items do some really weird %*!# when there are two items with the same script added about the same time. It seems incredibly spotty, though, so if any ideas on what causes the problems would be a great boon. From my experience, I can tell that the problem is with two items that have the same script (at least, two CloneFormed items, that have different FormIDs), not just two of the same item that, of course, have the same script.

My esperiences:
I have 'buttons' in my containers. These are misc. items that run onAdd/MenuMode blocks. They all seem to initialize when added by another script to my container. They are all set to do some processing once the player selects them (adds them to the player's inventory) and then remove themselves. However, if the player presses "Take All" some of the buttons won't do anything, and won't even remove themselves (even the ones that don't do any processing, that only remove themselves). The buttons that do this seem to be random. Also, if you double-click on the buttons, so that you take two of them very fast, then one of them will process, while the other won't (won't remove itself).

My other experience was even stranger - I had an item that would initialize itself, clone itself, add the clone to the container (which would in turn initialize itself, etc. until the end of the list), and then move itself to another container. At first, I had the item set to add the new CloneFormed self immediately after initialization (immediately being the next line of code). This resulted in one of them initializing, but not finishing the script by moving to the final container, while the other would move to the other container, but wouldn't be initialized - almost as if one started running the script from where the first left off. I fixed this by waiting until moving to the final container before adding the new CloneFormed item. (I now use a totally different system, so this is no longer an issue)

What really gets me, though, is that my latest form of buttons don't have any of these problems. I'm really stumped on what's different, other than a less active script when set to remove (though by no means less active when processing). So there must be some way around the problem. Anyone else have some good examples of this problem?

Of course!

I think it's pretty complete other than the latest new stuff suggested here recently. I'll try to keep adding any new material suggested here.

Lots of info, not enough time to go through each post looking for specific info. Where is this 'list' at? I tried the link at the bottom of dev_akm signature and couldn't find it. Specifically I was looking for info on the PlaceMeAt and MoveTo functions.

Ah, the link is in the main post, repeated here just for you: Troubleshooting.

Very useful thread!

[monthly bump]
Lots of good stuff in this thread (and I think most of it is on the wiki page too).
One thing that might be worth adding (common mistake?):
Can't place functions on the same line as an 'if' test, as you would be able to with any other programming language.

There seems to be quite a bit of confusion going around about the vanishing landscape issues now that TES4Gecko includes a way to fix the problem (based on proposals by Lightwave and others).

I've updated the description of the issue on the Troubleshooting page, but really we need a bit more detailed info, so I'm asking for anyone who has solved the issue using TES4Gecko or some other means to post additional details here -- it would be especially good if we could lure Sandor or someone like that into writing a bit more detail about their experience.

Tom Supergan asked me to include something about this in my old Tutorial: Creating Clean Masters, but I think it really deserves more detailed treatment than that (although I should probably make reference to it there). The point of that old tutorial was about how to split a plugin so that you can make a clean master -- which in terms of landscape, means avoiding any references to the Tamriel worldspace so you don't cause Tamriel landscape to vanish. The article does not address the issue of how to get a new worldspace to work regardless of the load order, which I think is really a topic worthy of a separate tutorial (repeating myself here). We would need someone who has experience fixing a worldspace with TES4Gecko's Move Worldspace function to write that.

Here's the post from Gloomwing that got Tom's attention:

Common MessageBox Mistakes:
All of these are avoided if you use the MessageBox Tutorial (shameless plug? nah, I wouldn't do that...)

1. The script has to run every frame to catch the button press. For persistent objects (activators, containers, tokens, etc.) this means the object needs to be loaded in memory (i.e., in the same cell as the player). For quests, this means you have to set fQuestDelayTime to a low number, like .001. For all of them, that means you have to use a blocktype that runs every frame (i.e., GameMode, MenuMode, etc.)

2. If you plan on having multiple menus displayed from one script, you need to use a governing variable to tell which menu you're currently displaying. For instance, make a short MenuShowing variable and set it to 1 to display your first menu, and 2 to display the second menu.

3. If any part of your code after the button catch (that is, after if (Button > -1)) requires more than one frame to process, and you've set up your code to set the button variable every frame, such as:

then you need to change it to catch the button only when the player's decision hasn't been caught yet and make sure to reset Button after displaying the menu:


4. If you're using a scripted magic effect for your messagebox, make sure to make it last a couple of seconds (at least). It is strongly advised to use another method. You can have the scripted magic effect start up a quest, or an activator, or add a token to the player and run the messagebox from those.

Sweet! That's a good one, man.

It's especially good when we can nail both the problem and the solution/workaround like this.

Another possible Gotcha.

Thanks for your PM (related to the vanishing landscape issues now that TES4Gecko includes a way to fix the problem).

This was solved with the help of Deathless Aphrodite (who gave valuable input for the missing land problem) and of course with the coding skills of ScripterRon.
I'll write a short tutorial and send it via PM.

Awesome! Thanks so much!



Wow! So, how would we categorize this bug?



SetScale CTD?

I was hoping for someone to come along and confirm it first.
I just tried to replicate it, and it seems to be working fine for me.

Actually that's why I didn't post it here earlier. I figured it may be difficult to reproduce and so far I've only noticed it for my scripted ingredients. There's a lot of stuff going in on in my mod but the same script is used for a variety of throwable items, including knives, axes, hammers, darts and potions. Tracking this down was a process of elimination - luckily, I noticed my watermelons seemed to work

BTW, the SetScale command didn't create the CTD immediately - it was the subsequent frame when the object was supposed to appear. Occassionally it wouldn't happen until the third or fourth throw, e.g. after I restarted my mod from scratch and come to a new area. The only other variable factor I can think of might have been FPS.

As promised my tutorial.

----------------------------------------------------------------------------------------------------------------


How to create a load order independent (including the LOD) ESM?


Abbreviations and general info.


Use the TES4Gecko v14.4 or a higher version.

I take the Silgrad_Tower.ESM as an example.

VWD = Visible-When-Distant.

Mod index == Determines the load order of the ESM and ESP files via the time stamp.
The Oblivion.ESM is loaded as the first file (normally) thus has a mod index of 00.
ESM's are loaded before the ESP files (always).
You can use Wrye Bash (or OBMM) to change the load order (move the files) of the ESM and / or ESP.

An example of a possible load order:
00 Oblivion.ESM
01 Silgrad_Tower.ESM
02 ESP1
03 ESP2
etc.

The Move Worldspaces option will shift the LOD files into mod index 00 (the same as the Oblivion.ESM) which makes it load order independent.

The Split Plugin option will move (amongst others) visible-when-distant references to the OUTPUT_ESP.
These VWD objects caused the problem of the disappearing land when the ESM was loaded in a mod index of >=02 (not directly after the Oblivion.esm).
This also applies to interiors with VWD objects (e.g. trees).


The process step by step.

Method 1.

1 Check before the release if the ESM is clean (otherwise clean the file).
2 Make sure the LOD (full) has been generated and remove the Distant LOD folder.
3 Open the TES4Gecko to split the ESM (before you do so, convert the ESM to an ESP, Split Plugin, don't check independent ESM/ESP pair).
4 Rename the OUTPUT_Silgrad_Tower.ESM to Silgrad_Tower.esm
5 Load the ESM/ESP pair (OUTPUT_ESP active)
6 Generate the Distant LOD for your worldspace('s).
7 Close the CS.
8 Open the TES4Gecko and move the LOD to mod index 00 (Move Worldspaces), insert a "placeholder" for the ESM.
9 Repeat the Move Worldspaces for the OUTPUT_ESP (don't insert a "placeholder").


Method 2.

1 Check before the release if the ESM is clean (otherwise clean the file).
2 Make sure the LOD (full) has been generated including the Distant LOD.
3 Open the TES4Gecko and move the LOD to mod index 00 (Move Worldspaces), don't insert a "placeholder"
4 Open the TES4Gecko to split the ESM (before you do so, convert the ESM to an ESP, Split Plugin, don't check the independent ESM/ESP pair).
5 Rename the OUTPUT_Silgrad_Tower.ESM to Silgrad_Tower.ESM



Why does Silgrad Tower use method 1?

Because we merge an Travel ESP (*) that alters the Oblivion.ESM including a number of VWD references (related to the Silgrad_Tower.ESM) to the OUTPUT_ESP before step 5. The VWD references are updated through the newly generated Distant LOD (step 6).

(*) The LOD (meshes and textures) was generated (step 2) with this ESP active (depending on the Silgrad_Tower.ESM).
We don't want to merge this Travel ESP to the ESM because it alters the Oblivion.ESM.

If you don't want to merge files to the OUTPUT_ESP, use method 2 (it's faster).


The game will halt during the loading screen when using a modindex >=2 for the Silgrad_Tower.ESM and you have to reboot.
What to do?

Move (directly after step 9 or 5 depending on the method) the split ESP (OUTPUT_ESP) to the first position after the last esm in the list.
So if there are 4 ESM's (including the Oblivion.esm) move the split ESP (OUTPUT_ESP) to position 5 (mod index 04).
After that the mod index of the ESM/ESP pair can have any number.
Not everyone has this problem.

----------------------------------------------------------------------------------------------------------------

Please acknowledge ScripterRon and Deathless Aphrodite as well.

I hope it helps.

Regards,

sandor

Has anyone noticed that ScriptEffectFinish does not seem to run if the ScriptEffect spell duration ends while the player is resting/sleeping?

One other possibility might be that resting/sleeping merely acts as a trigger to cause a failed GetSelf != Player/Return block, which then causes the ScriptEffectFinish to get skipped.

If it's confirmed, then it would be a good gotcha to add to the list.

I have not noticed it. I tried to duplicate it and couldn't, although the script I was using had a Dispel statement and I don't know if that makes a difference or not. See here for script used and discussion (its at bottom of page).

Hrm. Perhaps the limitation is what kinds of statements will work from a ScriptEffectFinish block while resting?

In the case I tested, the scripteffectfinish is trying to remove ability spells that were cast on the player earlier. I'll do some further tests to see if I can pinpoint the issue.

Thanks, man.

I remember hearing rumors, a looong while back (the first few months of modding, back when Tegid and MrFlippy were testing everything) that there were several circumstances that could cause a ScriptEffectFinish block to not run and a spell to wear off without the "clean up" that was presumably contained in the ScriptEffectFinish block. Unfortunately, I don't remember the details. The conclusion was that it would be better to keep script effects short, to decrease the chance of any of the problem scenarios appearing.

By the way, today I found another stupid typo that the compiler will not catch - an apostrophe anywhere in a line will be ignored (unless it's in the middle of a function name or something), but will cause the script to silently fail.

On the topic of compiler issues

will not throw up any compile errors, but will cause the script to fail. Had me scratching my head for ages before I noticed it.

Ok, I did a bunch more testing on this and it seems that ScriptEffectFinish itself works fine during sleep/wait/travel. What doesn't work reliably is ScriptEffectUpdate, especially if you rely on GetSecondsPassed for anything in the ScriptEffectUpdate. In this particular case I was trying to fix some problems with scripted potion effects, in which case GetSecondsPassed is necessary in the ScriptEffectUpdate so you can keep track of whether the ScriptEffect expired normally or was aborted due to another scripted potion being consumed. The workaround I came up with was to check for MenuMode 1 and IsTimePassing during the ScriptEffectFinish, like so:

[codebox]
Begin ScriptEffectFinish

If ( refPlayer.getIsReference player == 0 )
Return
Endif

If ( refPlayer.getIsReference player == 1 )

if (MenuMode 1)
; ScriptEffectFinish caused by another potion, meaning the current potion has not expired yet. Don't RemoveSpell.
Set TimeLimit to 0
else
if IsTimePassing == 1
; ScriptEffectFinish caused by normal timer expiration or during sleep/wait/travel
Set TimeLimit to 1
endif
endif

If TimeLimit == 1
; Legit expiration of potion effects
Player.RemoveSpell MyPotionEffects
Endif

endif

end
[/codebox]

(The logic is a bit verbose to make it more readable).

I did also notice an oddity with MessageBox while debugging the ScriptEffect phases: only the last MessageBox statement in the logic chain will execute. I'm not sure if this is also true in other script phases, but it's a pain because it makes debugging a much bigger hassle than it should be.

Odd, have you tried ScriptEffectElapsedSeconds as well?

Are you sure? Messageboxes will overwrite each other before you have a chance to respond or even see the original. Have you tried PrintC instead (they won't overwrite each other, but are mostly unusable if you're using GetInventoryObject or GetNumItems)?

I didn't try it. Would be a good test to find out whether the problem is specifically GetSecondsPassed or the ScriptEffectUpdate in general.



Well, that would make sense. The end result is the same either way. They're almost useless for debugging.



Not sure what you mean. You talking about the OBSE function PrintToConsole? I wasn't using OBSE.

I didn't find any matches for PrintC when searching the wiki.

Yes, I meant PrintToConsole, and it's about the only way to debug (btw, using OBSE won't create a dependency, just make sure to comment out the PrintC lines before release - or even better, use Oblivion without OBSE running for the final tests).

I added PrintC to the Wiki, by the way, since you were right, we were missing that.

Ah, cool. I'll give that a try next time.



Thanks!

So, we still need some further tests to determine whether GetSecondsPassed always breaks during sleep/wait/travel in a ScriptEffectUpdate. I can definitely verify that it works fine in a ScriptEffectUpdate during gamemode but is flaky during sleep/wait/travel. Using ScriptEffectElapsedSeconds is probably a good workaround, but this needs further testing as well. Might also be worth documenting any other differences between GetSecondsPassed and ScriptEffectElapsedSeconds.

Here's an example of what I'm talking about:
[codebox]
Begin ScriptEffectUpdate
If ( refPlayer.getIsReference player == 0 )
Return
Endif
If ( refPlayer.getIsReference player == 1 )
Set LimitTimer to LimitTimer - GetSecondsPassed
If LimitTimer <= 0
Set TimeLimitReached to 1
Endif
Endif
End
[/codebox]

During gamemode, this works fine. LimitTimer will count down nicely and eventually get to zero, so that TimeLimitReached can be set to true. But during sleep/wait/travel, it never gets there.

Well, despite the fact that I never got a conclusive answer on that last one, I added another one today. Please, everyone check this and make sure it's at least somewhat accurate, ok?

CTD from MessageBox on a Terminating Script

There's probably a more accurate way to describe it, too. If you can think of any way to improve it -- or disprove it -- let me know!

(Haven't tested, but...) I remember seeing a lot of CTD problems when people used RemoveItem instead of RemoveMe (erm... I think, it's been a while). I guess this is along the same lines - the CTDs would stop if you used DropMe instead of Drop. Still, odd bug - I guess the messagebox sends a button press to it the next frame even though it no longer exists. I wonder if there are other ways to get the bug (like another script removing the item later that frame)?

Yeah, I'm especially curious about this because it might help to explain some of the odd random CTDs that seem to occur with crafting mods (since they usually launch a script attached to an ingredient, popup several dialogs asking what you want to do, and then replace some ingredients with crafted items -- which might result in the original ingredient that contained the script getting removed while a dialog is still active, or something along those lines).

When I was testing it I definitely noticed a few cases where it didn't cause a CTD on the first test but then did cause a CTD on the second test (of course this could've also been due to other issues, but I definitely noticed it being somewhat random).

Summary: Over-use of blank message statements to block standard equip/unequip/additem messages results in complete block of all messages in some cases. (unverified)

I ran into a very strange scripting problem last night that may be another good one to add if it holds up under scrutiny.

I've been working on improving the way OOO's version of droppable lit torches (DLT) works so we can avoid having message spam to the screen when dropping torches and using the custom torch hotkey (previously OOO did this mostly by taking away the Torches name, which is pretty a unpopular "feature").

So anyway, I made a new scripted "torch hotkey" as a generic misc. item (something that can't be equipped), made some general optimizations to the DLT scripts, and added two blank message statements before any equip/unequip/additem/etc. statements. Simple, right?

Works like a charm, too (assuming you have the standard "you can't equip this" message removed, which is pretty typical these days anyway). No more message spam when dropping, hotkeying, etc. Sweet!

Unfortunately, the message removal is a bit too effective. For some very strange reason it's blocking all messages, all equip/additem messages, and even scripted Message statements. It's acting like the blank message statements are constantly spamming the screen all the time instead of only when the script conditions are met.

If I comment out the blank message statements, then I get normal messages again, but of course I also get the message spam.

It seems like there may be a gotcha at work here, like perhaps the onequip block for the hotkey is never ending or something similar. Then again I may have just overlooked something silly.

Here's a rough summary of the droptorch script attached to the standard torch02:
[codebox]
begin gamemode

if (Player.IsWeaponOut != 1)
Return
else
; weapon is out, so drop the torch if player also has
; a shield out or is using a 2-handed weapon
; (actually drops a separate torch object called torch04)
if (player.getEquipped torch02)
if player.isshieldout
Message " "
Message " "
player.additem torch04 1
Player.equipitem torch04
player.Drop torch04 1
Player.RemoveItem Torch02 1
elseif (player.GetWeaponAnimType > 1)
Message " "
Message " "
player.additem torch04 1
Player.equipitem torch04
player.Drop torch04 1
Player.RemoveItem Torch02 1
endif
endif
endif

end
[/codebox]

Since this script runs in gamemode, it seems like the most likely culprit, but if those Message statements are constantly being run then I should also be dropping torches everywhere constantly, which isn't the case.

The other possible culprit is the hotkeytorch script, summarized here:
[codebox]
Begin onequip

; if already using a torch, put it away
if player.IsTorchOut
Message " "
Message " "
Player.unequipitem torch02
return
else
; if not using a torch, equip one, if you have any
set torches to Player.GetItemCount torch02
If (torches > 0)
Message " "
Message " "
Player.equipitem torch02
else
Message "You do not have any torches."
endif
endif

end
[/codebox]

Pretty straight-forward stuff. So why the problem?

If I comment out the Message statements, then normal messages start working again. If I leave them in there (I even tried putting some debug text in them) then no messages ever reach the screen after adding the hotkeytorch object to my inventory.

The next steps to debug this will be to comment out the Message statements one at a time to see which ones are the exact culprits, but this will take quite a bit of testing time.

Has anyone else heard of or encountered anything like this before?

Just to be clear, you mean that no messages appear ever again? The bug does disable all messages for a second or two (about the time the message would have been displayed), but shouldn't be doing any more than that.

The only things I could see - removing the Torch02 doesn't necessarily remove the equipped torch, does it? Do you have an unequip block?

Otherwise, try toggling the scripts on and off, or removing the torches from the player - if that takes care of the problem than it's something on the scripts.

Exactly. I get no messages at all anymore whatsoever if those Message statements are present. If I comment them out:

;Message " "
;Message " "

Then everything works fine again.



No, it's only necessary that the torch count gets decremented so the player doesn't get free torches by repeatedly dropping/retrieving them.

EDIT: the Player.equipitem torch04 statement replaces the normal torch02 you have equipped with the temporary torch04 so the next statement will then drop torch04 (torch04 itself has a separate retrievetorch script that works OnActivate to add a regular torch02 back to your inventory). This is necessary so that torch04 will keep burning when dropped (regular torches go out when dropped IIRC).



Oh, it's definitely in the scripts somewhere, but like it gets stuck in an endless loop. I can unequip my torch, drop the hotkey and disable it, yet the message blocker still remains in force.

That's odd... umm, maybe seeing the whole scripts would help (or are these the full scripts)?

I seem to remember something about not using UnEquipItem in an OnEquip block because it would cause loops, but I can't find it anymore, and I never understood/verified it in the first place.

Yeah, I thought I had seen something similar before, too, but I couldn't find it when searching today. Here's the complete scripts:

[codebox]scn droptorch
; optimized & modified by dev_akm to block torch message

short weap

begin menumode
if player.getitemcount torch03 > 0
Message " "
Message " "
player.removeitem torch03 1
endif
end

begin onequip
set torchisequipped to 1
end

begin onunequip
set torchisequipped to 0
end

begin gamemode

if torchretrieve
set torchretrieve to 0
endif

if (Player.IsWeaponOut != 1)
Return
else
; was if player.isweaponout
if player.getEquipped torch02
if player.isshieldout
Message " "
Message " "
player.additem torch04 1
Player.equipitem torch04
player.Drop torch04 1
Player.RemoveItem Torch02 1
set torchisequipped to 0
elseif player.GetWeaponAnimType > 1
Message " "
Message " "
player.additem torch04 1
Player.equipitem torch04
player.Drop torch04 1
Player.RemoveItem Torch02 1
set torchisequipped to 0
endif
endif
endif

end

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

scn hotkeytorch
; modified by dev_akm to block torch message

SHORT torchkeyheld
Short torches

Begin onequip

if player.IsTorchOut
; previously this condition was
; If torchisequipped
; but I wanted to avoid potential problems where this global might not have been set properly.
; I should probably test using the global instead of IsTorchOut
set torchisequipped to 0
Message " "
Message " "
Player.unequipitem torch02
return
else
set torches to Player.GetItemCount torch02
If torches > 0
set torchisequipped to 1
Message " "
Message " "
Player.equipitem torch02
else
Message "You do not have any torches."
endif
endif

end

Begin OnDrop
StartQuest AddTorchKey
End[/codebox]

Warning: there's some old cruft in still in there that may be confusing. For example, I don't think I'm using the torchisequipped global anymore. I might try switching back to that just in case IsTorchOut is unreliable.

Well, after a lot more testing and variations, the message issue does not seem as cut-and-dried as I first thought. Not surprising, I guess. Things rarely are.

*sigh*

Turns out I am getting the loss of messages even without the blank message statements, so the problem is likely something entirely different. I'm going to keep pounding on this one until I get it sorted out.

I'll report back with my findings when I have some.

Not too surprised, the scripts looked fine. One other thing to look out for - you can approximate the same bug by playing the same message every frame (see Phoneix Amon's Ingredient Shelves for an example). However, that bug plays out a bit... odd. If I remember correctly, if any other message came up while it was blocking out the messages, the messages being blocked would appear again. Or sometimes it would just flash all of the messages very quickly, including itself. See if there are any messages being played every frame, and that may be the culprit.

That was my thought, too.
If you're using OBSE, try sticking a PrintToConsole in with the messages. If you get a barrage of messages in the console, some portion of your code is running more frequently than you expect it to.

I have a question about the player moveto console, I am not sure how this would work because apparently you need the id of the NPC in the samegame, not the generic ID you find in the CS but the id you see when you click on the character, which is a pain when you don't know it especially since it's different I believe in each savefile. So it's annoying not able to find a NPC and then restorting to Player.PlaceAtMe (I only do that for fun buyt don't save thing)

It's not exactly different for each savefile. Each time you use PlaceAtMe an ID is assigned to it. Which ID depends on what other IDs have been made up to that point in the game. You'll have to save the reference in a script variable, and use the script to move the NPC. If you meant NPCs placed in the CS, then those have a constant ID and you can use the one found when you edit them in the Render Window (not sure what happens when they die, though).

Well, the answer turns out to be pretty interesting. If using a non-equippable object to launch an onequip script, then you have to specifically tell the script to unequip itself. Otherwise you run the risk of starting an endless loop when the player invokes the object (may be especially true if the object is the target of a hotkey, i.e. invoked outside menumode, where onequip usually gets called).

Here's the fixed version of the hotkeytorch script. OOOTorchHotKey is the object the script is attached to:
[codebox]Begin onequip

if player.IsTorchOut
set torchisequipped to 0
Message " "
Message " "
Player.unequipitem torch02
player.unequipitem OOOTorchHotKey
return
else
set torches to Player.GetItemCount torch02
If (torches > 0)
set torchisequipped to 1
Message " "
Message " "
Player.equipitem torch02
player.unequipitem OOOTorchHotKey
else
Message "You do not have any torches."
Message " "
Message " "
player.unequipitem OOOTorchHotKey
endif
endif

end[/codebox]

Did I just miss an obvious warning about this somewhere on the wiki or is this a good new gotcha?

EDIT: In other words, for some reason the OnEquip block will keep running endlessly unless you explicitly stop the script by unequipping the object it is attached to -- despite the fact (or perhaps because of the fact) that the object cannot actually be equipped.

Crazy, eh?

That would be a new one. Odd, though, I've never had that problem (and I don't think I've seen any mods that unequip the item afterwards). Maybe it's because of the return, or that you're equipping other items I'll play with it, see what I can find.

Very odd, that. This does seem somewhat similar.



Thanks!



Right. None of the examples I looked at either, which is a big part of the reason I assumed it wasn't necessary.


I was thinking the same thing. Most 35f0 mods that use non-equippable items to launch a script probably don't call equipitem. Or, it could be the return, or maybe (worst case) the combination of equipitem and return.

Yes, I used this technique quite a lot too, it works great.

By the way, this thread is really useful, thanks once more to dev_akm.

Thanks, but the credit really goes to all the great contributors who've posted stuff here and in the troubleshooting section. I'm just the instigator.

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

Speaking of which, do you think it's worth mentioning the fact that you probably can't make a script take very large amounts of gold from the player at once? (i.e., more than about 32,000)?

Since RemoveItem only accepts a short integer argument, it seems that you can't, say, make the player pay for a castle by using:

RemoveItem Gold001 125000

AFAICT this will only take 25,000 gold from the player (instead of 125,000 gold) because the max value of a short is 32,767.

You'd probably need to do use multiple RemoveItem statements to get the right amount, as in:

RemoveItem Gold001 30000
RemoveItem Gold001 30000
RemoveItem Gold001 30000
RemoveItem Gold001 30000
RemoveItem Gold001 5000

Worth mentioning?

Hey dev_akm,

Haven't had a chance to test these, but I did notice something else? Were you using the "'Cannot Equip' Message Remover" mod by any chance? Seems I get this bug whenever I use it and equip a non-equipable item... because I completely deleted the setting sCannotEquipGeneric... changing it to a simple space " " gets around this (still takes the time to display the message, but you don't see the message since it's blank). I think I've seen some info on this bug, but I don't remember where. Anyone remember?

Hi

I think I've found a gotcha. Atleast I haven't been able to NOT reproduce the problem so either it's something wrong with my oblivion or it's a real gotcha.

The problem: when I have a creature cast a touch spell using cast spellid player his magicka gets reset to it's max just before the cast. So if he has 200 magicka and it's down to 50 (because of other spells or simply modav in the console) and then I tell him to cast the spell (lets say 20 cost) on me his magicka is suddenly 180. I've tried to determin at which point his magicka actually gets reset and it's just when the casting animation starts.

I've even tried it with vanilla touch spells to see if it was the spell itself and I've tried turning the spell into a self-targeted spell. And then this problem didn't happen.

I do not yet know if it's the same with npc's, I'm gonna test that now. Though I did test different creatures and it happen with all of them. Also I still gotta test target spells

So I hope I'm wrong about this and someone can tell me what I did wrong cause now I cant use cast spellid player to have the creature cast buffs on the player.

So to summerize it a bit: using cast spellid player to have a creature cast a touch spell on the player causes his magicka to be set to his max just before the cast begins.

-Kyoma

::edit:: Ok, just tested it with stock oblivion spells, creatures and npc's and it all happens as stated above. As soon as they begin the cast of the touch spell on the player their magicka gets reset.

::edit:: Now it gets really weird, even a cast magic package has this problem. Please tell me I've messed something up cause now I cant have the creature cast spells on the player at all

Yes, I definitely used MRP - Can't Equip.

It could very well be the cause.

Problem is I think a space would still cause the message icon to appear if you run an un-modded HUD.

If anyone knows more about this, please do let us know.

Thanks!

Hrm. Very interesting possible gotcha here. Sounds like it might be worth investigating.

Um did you link to the correct post? Cause I dont really see any problems in that post

::edit:: nvm, I think I';ve found the post your talking about

Sorry, that was just the first post of several on the subject. This one explains it better, and a few more after that as well.

It looks like problem is directly related to variable position issues, but I haven't been able to find any good documentation about how variable position and compile sequence impacts external access other than a few posts like this. Has anyone written a detailed explanation of this?

For example, although the problems with the Oblivion compiler and variable position indexes in general are fairly well documented, I couldn't find anything at all on the CS Wiki about how this manifests when using an external script to access a script variable. In fact, the whole notion of being able to access non-quest script variables seems largely undocumented. Is this because it's so problematic or just because nobody has gotten around to writing about it yet?

I think a bit of both. Although it is somewhat clear as to how it works it's not a 100% clear. But that thread should definitly be added to the wiki, or atleast a link to it.

Interesting. I've never tried this before since the Cast page claims that many creatures cannot be forced to cast spells at all since most don't have any Cast animation.

Oh I'll note that they were creatures (and npc's) with a casting animation.

IMHO it's just the opposite - I've never had any problems adding variables to a persistent activator. I've never paid any mind to changing the order and never had any problems, but I'm not sure if I've tried it. Might be different for scripts on NPCs . I'll run some quick and dirty tests - haven't read the Overriding Script Variables topic in a while, so there might be some overlap.

Question 1: Will changing the order of variables change the internal script's ordering?
* Answer 1: Looking at the script variable order in TES4Edit - The order stays the same, regardless of the order in the actual script. However, those are on the script data. The order might vary on the object itself.
* Answer 2: I have a character with some set variables on the Keychain item in the Keychain mod. Changing the order from 'Mode, ScanNumber...' to 'Mode, ModeChangedTo1...' and looking at the variable number with a message - The old variable ScanNumber keeps it's proper value (41) regardless of the variable order on the script.

Question 2: Will deleting a variable and then reinstating it move it around?
* Answer 1: On the Keychain mod again, commented out a variable (Using). Using TES4Edit and looking at the script (before deleting), that variable was the 13th for the script. The 12th and 14th variable were KeyCount and UsingCounter. Once deleted the 13th/Using variable is gone, but KeyCount and UsingCounter remain the 12th and 14th variables. Also, the last variable is the 53rd variable before and after commenting out Using/13th variable.

Adding the variable back: The Using/13th/deleted variable gets a new place on the variable list. It is now the 54th/last variable, and I would assume would be a new variable. I would assume that, in-game, this would play out as any other new variable - starts at 0 and any call to it will be to it and not the old/13th variable.


[Umm...] From MD's posts I'm not really sure whether we're really talking about overriding scripts (via external mod) or replacing them (saving mod), so this information might not be relevant.

EDIT: I think what you described is related, but not the complete picture since we're also trying to figure out why/when/how external calls to those variables work (a process that seems to be almost entirely undocumented).

So, then if you commented out all variables and compile, then add the variables back, they should all get new positions, right?

If so, then perhaps doing this same comment/compile/uncomment/recompile sequence on the external script after doing it to the main script will point it to the correct variables?

Or, does the external script always just link to the first variable position regardless, as scruggs post indicated?

if I am following this thought...

that is definitely not right, or at least not entirely accurate, because I have a mod that give bears my special touch stagger spells to bat around the players as they fight the bears (and other giants).

Duke Patrick’s SCA style combat mod:

http://www.tesnexus.com/downloads/file.php?id=9446

In the game it looks like the bear is only hitting you with their bite and claw attacks.
But the spell (cast at various times in the fight) pushes and staggers the player.

Yeah, you followed it perfectly.

Perhaps the restriction is only on targeted/ranged spells rather than touch spells?

Thanks!

(BTW, your mod sounds cool, too!)

The tests might serve as a base-line, at the very least.

I would think so, again that's for the original and I'm not sure what will happen with an override (I would think that it doesn't work, and that they would point to new variables which may not even be formed).

This is what I think would happen. Essentially, if you delete a variable in the override script (say the 2nd of 4 short variables), save, then add it back the external script would point to a 5th variable, but the only the original 4 would be created. I'm very much guessing here, but that's what I think would happen.

Looking back, I have an example of external scripts accessing new and reordered variables (but, again, not overriding scripts/external mods) - between v1 and v1.1 of the Poison Equipper mod I moved some variables from my Options script to a second Options script, as well as reordered some of the originals. I never had any problems when testing that the old options remained after upgrading (though I don't remember how specific the tests were), and no one's ever said anything (though that may be because I made the options a bit complex), but it's at least something to test with. Should I re-upload v1 somewhere? What tests should I do exactly?

Agreed. I'm not at all sure what difference an override would make -- in other words I think you'd get the same exact result with an upgrade that you would with conflicting overrides. This is the problem we encountered with upgrading from MMM 3.0 to 3.1 (if active NPCs/creatures had the old variables data loaded, then the conflicting new variable positions caused CTDs, but the problem went away if you waited until respawn so the old script data was flushed along with the actors).

It should be fairly simple to devise a test for this. I'll give it some thought.

Hi

I'm still looking for some confirmation to wether this is accurate or not.

Yesterday I noticed that I've changed something to some existing NPCs. They have evil *, but I haven't remembered to change anything. Then, after a long time of breaking mind, I've realised that if we click on 'ok' instead of '×' or 'cancel', we get *, although nothing was really changed.

Dunno if this has been stated before cause I didn't read the entire thread but I think I got another gotcha. Having varA / varB while they are both 0 causes the script to terminate.

I noticed it while I was testing something and at first I thought it was my script. But when I added some debug messages I found where the script stopped running. The only messages I got were the one from the OnActivate block and "MessageBox 1" (see below). At first I still didn't know why until it came to mind that in the line "set sDaysSupply to sFoodSupply / sCaloriesNeeded" sFoodSupply and sCaloriesNeeded were still both 0. Oh and when I commented out that line it did work. I dont know if it's just 0 / 0 or also x / 0 and if it only happens with variables and not pure numbers. I'll test it more tomorrow. If this is already know then I'm sorry for your time

Anyway, here's (part of) the script:



::edit:: Ok, couldn't resist testing it now It's x / 0 that causes the script to terminate. Wether they are variables or solid numbers.

Thanks, kyoma!

============
RE: token reference issue. Looks like it was the compile history.

Only thing is I'm not really sure how to best word the description of this gotcha ATM. Any suggestions would be most welcome.

I've been meaning to get back to this, but I've been busy. There are probably a few specific steps that had to be taken, but maybe for now you could simply describe the symptoms, and the remedy? There are a few tests that should be done, to see just how the variable history can affect it.

Which is why I hate to do this, but new topic -
When will scripts run before a game has even been started/loaded? I vaguely remember having the problem when I first started, and here's another person with the problem (Problem with specific assertations), but I'm not sure what it means. I know that when the player loads the game, every object script will run once (not sure if it's only the first time a mod is installed, I have some notes on it somewhere...) - I thought it was limited to persistent objects, but apparently it also applies to non-persistent objects. However, I wasn't sure when/if scripts will run during the Main Menu. Maybe all scripts run when the "Bethesda SoftWorks" logo comes up, and only scripts that keep setting a variable on themselves and keep running will show up in the Main Menu? Maybe it's true for quest scripts as well? Anyone else had these experiences?

Adding an item to a container in a remote cell won't fire its onAdd block, but the rest of the script will run as normal (i.e., GameMode blocks, MenuMode blocks). If anyone has suggestions about stopping the entire script, especially scripts from items in other mods, it would be much appreciated.

Maybe a GetInSameCell player to see if the container is in the same cell as player. And put it in an extra GameMode block at the top of the script with a return. But that's hardly a solution, more of a quick fix

Good point, but I mean for items from other mods

Alright, found a way around it. If you use a PlaceAtMe followed by Activate to add the item the script won't run. However, the wiki suggests that the script may sometimes run - anyone had experience with this? Otherwise, I'm using PlaceAtMe to create the item in a remote cell, and that seems to work 100%.

I was about to suggest that when I woke up. Guess you already thought of it

Here's another one: If a mod makes any changes at all to Tamriel cell AnvilMainEntrance (-47,-7), it will cause Oblivion to crash on exit from the main menu. This may also be responsible for the crashes-on-exit via other methods (ie Exit Game from the Esc menu or even qqq in the console) as well. Details in the post. The form ID of the seemingly bad CELL record in Oblivion.esm is 0x569A, and this record being present was the determinant, not the actual changes, as even with all the changes removed but the CELL record present it would still crash.

If ScripterRon, dev_akm, KomodoDave or anyone familiar with the structure of these records could have a look at this one and see why it's borked, this would be most helpful.

Very interesting. Definitely worth checking out if my crash-on-exit's are caused by this. (they aren't a very big deal but it's always nice to know what causes such things

And, as is utterly typical, everyone benefits but me. I removed all refs. and the cell header for (-47,-7) and the thing still crashes on exit from the main menu. This means there's at least one more cell, or something else, that also does it. There goes the rest of my evening. I'll edit this post if I find what it is. I hope it's another cell as I can find that somewhat more quickly.

Edit: It's another cell in the negative side. Trackin' 'er down...

Nope, I give up on this one... I tracked it to -46,-10, but it won't recreate. If I create a mod with a change (or many) to this cell it doesn't crash, and removing changes to the cell doesn't stop it. At least I found out about -47,-7 but I'm no further ahead.

Oy, great work, man!

I will take a look to see if I can find anything when my current deadline crunch is over.

Yay... you saw it. Was going to PM you if you didn't reply here.

Looking forward to any findings.... hey if you find why this record is bad and pass the info to ScripterRon, it would make a great Gecko feature to find any cells in an ESP or even in Oblivion.ESM itself that are similarly bad so we avoid making mods that cause this.

Edit: Since I have your attention I had another idea for a Gecko feature.... find duplicates. Scans an ESP or ESM's cells and finds refs. that have the same base object and the same X/Y/Z co-ordinates. Should be easy to write (spoken like a true non-programmer...)

dev_akm said I post it here:
My companion in my companion mod uses a restore health spell after battle. In case his attributes were lowered I added the Altar of the Nine blessing to it. At that point my companion acted weird. He wouldn't attack monsters. I asked TTT for help and he pointed some possibilities out. Personality being on of em. So I bug tracked and found out that Blessing of the Nine adds 100 points to attributes. Just yesterday I accidently casted it on him instead of me and had to kill him as his Personality, Int, Str and Dex were increased.
Anyone else noticed it? You can test by Bless some NPCs.

bump

If I remember correctly, a high Personality will prevent a creature from attacking as if it were in the same faction. I know I've seen a wiki page on it, but I can't seem to find it... maybe this will jog someone's memory.

Yes, I know that. The problem is that restore attribute is bugged. It increases the attribute by X for NPCs and not restores it. At least that is my observation.

I know this one is old but I figured I'd add my own input: From what I found when adding items with game mode blocks to NPCs in external cells, the gamemode block would run ONCE, but not again after that. Not sure if that's useful to anyone but there it is.

In short, that's the same as any other object - it will only run for a single frame in a remote cell, but if one of it's variables is set it will run the next frame and will continue to run as long as a variable is set. In long, here are some more tests of what will run when.

So, the question is whether casting restore attribute actually works on NPCs or instead gives them a stat buff.

Yes, and the buff lasts until death.

I hope you're wrong about this, but it wouldn't surprise me if you're correct.

You can easily verify it by modifing the blessing to 0 mana and novice spelllevel and cast it on someone. The buff doesn't stack though.

This doesn't seem to be mentioned anywhere - it's not a CS bug but a general engine bug so

Oh, and [bump]

I thought this was interesting:



Anyone been able to figure out what the limit is?

Here's one I just found as it "Gotcha"'d me in the UOP. It looks like there is a bug with SetFactionRank. There may be an invisible boolean flag of whether an NPC is in a faction or not that is independent of the faction rank of -1 which is supposed be the only criterion of not being a faction member. Calling NPCRef.SetFactionRank {SomeFaction} -1 on an NPC who is already not in the faction (-1) will toggle the flag so they will be counted as a faction member, yet NPCRef.GetInFaction {SomeFaction} will still return 0.

You can verify this with any generic NPC who is not a member of one of the playable factions if the player is and will be expelled for murdering a faction member. Do a getfactionrank {faction formID} check on them and it will return -1. Now do "setfactionrank {faction formID} -1" on them, then murder the NPC. The player will then be expelled from the faction!



Yup, either do a GetFactionRank and if it's -1 don't set it to -1 again, or SetFactionRank to 0 then to -1 and the flag will toggle appropriately.

I'm editing this into the existing post rather than making a new one as this is one of the most useful threads in the history of the forum and it's nearing 200 posts.

Ouch! So, is there a safe way to boot an NPC out of the faction so the player can kill him/her without getting in trouble?

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

Has anyone run into problems with inventory item multiplication?

For example, an NPC has a robe or potion inventory item defined with count=1, yet when you loot the corpse you find many more than that?

Seems to happen most often when the NPC or creature dies away from the player, perhaps while the cell is being unloaded or reloaded.

Happens even more frequently with death items on creatures, perhaps because there's no count defined for death items.

Likewise, it seems to happen even more often with leveled item lists that have "calculate for each item in list" flag set.

I think it may be a vanilla bug since I remember encountering an oddity like this with getting 90+ healing potions from a single enemy during the Boethia quest. In fact, now that I'm looking at the UESP notes for Boethia's quest:

http://www.uesp.net/wiki/Oblivion:Boethia#Notes

I see that it says:

"Many of these combatants have dozens of Strong Potions of Healing..."

Yet looking in Oblivion.esm the most any of them have is 5 healing potions!

Is there something about that quest or the scripts it uses that makes the bug more likely to appear there?

Has anyone else encountered anything like this (outside FCOM, where it seems to be a common problem)?

Do you already have a playsound gotcha in your thread?

If you script all the ghosts for example to playsound "ScreamInYouFace" when they dip below 1/2 health,

all the ghosts in your cell will play that sound even if they are 600 feet away and fighting someone else.

AND you will hear this sound FULL BLAST out of your speakers.

I am now using playsound3d to solve this, but sometimes this will not play the sound at all, I think this has to do with the way the sound is attenuated in the sound tab of the CS, but at this time not 100 percent sure.

Anyway in that case I do this:

if getdistance player < 100
playsound ScreamInYouFace
endif

This will work everytime!

I thought PlaySound(3d) was very reliable. Guess not that much. Anyhow, could it be cause some other (3d) sound is already playing or is also player right after you used it?

I am not saying playsound3d is not reliable.

I use that most of the time now.

But a few custom sound effects had problems.

I suspect because of the custom setting in the sound tab was not set properly.
Using playsound (instead of playsound3d) on those same badly set sounds would bypass the sound setting and play at full volume (the volume the wav file has in it) thru your speakers...I think.




I was only giving the other method as an example to clarify the Gotcha.

The Gotcha being that an actor or whatever told to do playsound (rather than playsound3d) could
result in some very LOUD mysterious sounds from "nowhere" in the game!

I went thru and fixed all my own mods with playsound 3d or in some rare cases the distance check method.
But I still hear these loud mysterious sounds once in a while.

Sounds that I have not worked with.

So I suspect other modders may have made the same mistake.
When I get some time, I will be going thru the scripts of the other mods (made by other people) to see if that is the case.


BTW...is it MODDER or MODER...or

... MODTOLOGEST?

Is this one documented anywhere already? Is there a workaround?

Ooo... that's particularly bad. Damn, not sure how to fix that. Anyway, no, no it's not documented.

What's the current knowledge status regarding PlaceAtMe savegame bloating?

After reading this thread I took a look at the Shambles' script and was quite surprised - it uses PlaceAtMe to cast spells, but doesn't place an activator into the world, but a bone item.

Anyway. What I know is that several things done with PlaceAtMe cause savegame bloating: Activators, quest items, quest or respawning actors, and the like. Now Oblivion uses PlaceAtMe in several other ways - like nonrespawning actors (Oblivion Gates), and now this bone... thingy. Is that save, or unknown, or known to be not save, too?

Hi

I think I got another Gotcha. I'm not sure if it's already known but I didn't know about it and after briefly skimming this thread I didn't find anything on it.

It appears that when "ActivatorRef.Activate player, 1" is used while the player is mounted, the OnActivate block does -NOT- run, but as soon as the player unmounts it starts to work again (after it's called again). When I replace player with some dummyRef it works while the player is mounted but I'm assuming if that dummyRef is mounted it would also not work.

So I think ActivatorRef.Activate ActorRef, 1 does not run the OnActivate block of the activator if ActorRef is mounted.

-Kyoma

Has anyone seen details of the potion script gotcha posted anywhere?

I just got reminded about this today when a user asked why loading a mod that changes potion scripts (like a thirst mod that alters beer, for example) would cause a savegame not to load.

I only know about the problem because Sotobrastos had put this note on the LapDrunkPlayerTest script, which is completely commented out (so it does nothing) but still attached to ale, beer, etc. in OOO:

Belated confirmation... that's really annoying and means I need to go back and update all of my mods (oh, wait, I needed to do that anyway )

wrt Potion scripts: I wonder if it's general to all scripts and objects, but I've never heard anything about it.

wrt Thread limit: it's coming up on 200. I noticed there's an option to save a thread (haven't tried it yet), so maybe I can save it and upload it to the wiki. Would anyone mind that?

Yea tell me about it. All this time we used ActivatorRef.Activate player, 1 because we thought it was safe. Now it seems it wasn't as safe as we thought it was.

Good idea about putting this thread on wiki. Or atleast making a page with a summery of the list of known gotcha's.

@kyoma: Which dummy ref did you use for Activate?


The last 2 or 3 pages haven't really been researched enough to put into an article/the Troubleshooting category. We can either type them up or upload a zip, either way.

I usually just created one but it was always an actor. Dunno if that is nessecary though.

Potions: Just got another report of this problem. The only areas where I've run into this issue is with potions and perhaps gems, but you may be right.

Thread limit: I'll start a new one, but yeah that's fine with me.

==================
New Thread
==================

[bump] from trashbin - please continue to use the new thread.