I have one question about 'placeatme' that I always wanted to ask. How bad is it really? The Wiki says I can use it a couple of times. Is there an average that a new reference created this way adds to the savegame filesize? How many placeatmes does it need to get a 10mb+ savegame? Hundreds? Thousands? Thing is I'm making a trap that needs creatures to be created on the fly, similar to a summon spell. I could set the creatures inside a dummy cell and use moveto, but since I only want to use it a couple of times for a couple of creatures I'd rather use placeatme if possible. Would be much less work and if, let's say, ten creatures make a difference of one kilobyte only I'd use it.

I wonder if similar CTD problems could happen with persistent actor refs after a cell buffer purge?

In other words, if you're using token-based scripts like RenGuardOverhaul, Deadly Reflex, Extra Wounding, etc. and then have Streamline or something else purging cell buffer -- then if one of the actors tracked by these scripts happens to be a persistent ref, then your CTD chances greatly increase? If so, this might be the source of a lot of CTD frustration, but it's a pretty big if.

I made some extensive testings about that some time ago: Creatures placed with placeatme get cleaned up when they're dead and do not cause savegame bloating, unless they're "Quest Items".

My tests were: Creating a bunch of creatures in a cell. Kill them. Get a FormID from one of them.

Leave the room, wait respawntime, go back -> room cleared. Furthermore player.moveto FormID works until the cell is cleared, but then not anymore -> which means the thing is purged from the save.

Also for the testing described in the above linked thread I created some thousands of mudcrabs. Savegame size went up to 15+ MB, but after cell reset was down to 5 MB.

Nevertheless placeatme should not be used when MoveTo is possible! Cell reset is a strange thing sometimes. Also if they're not killed, they stick around forever...

Hm. A directly scripted actor shouldn't be a problem (there are many out there, like Shambles or other things). Totally independent scripts like in my gotcha do cause problems. How about these "local" token scripts? I don't know, and I don't even have an idea how to test it *. Although what I experienced was a CTD on save, not a "normal" CTD.

* = Hm, maybe I have an idea for testing. Maybe kill a "tokened" guard, do the mud crab trick to go over the maximum corpse number value and see what happens? Although I doubt that this will cause issues. My "gotcha" was a specific static reference, which was suddenly gone, not a dynamic "set me to getcontainer / getself / getactionref / placeatme / createfullactorcopy" thing usually used in scripts :blink:.

That will not work for what I am doing.
The water is stolen property. The bucket is assigned to the well owner.

I tested this already (the last one I posted with the activate command) it works the way I want it to.
And with the special sound effects I assigned to the bucket it is very immersive as well.

I just do not understand why the first way would svck up the FR.

But in the end it may not, it may be something else (most likely it was)
So I will test this as I mentioned before by putting the suspect script in its own mod and turning off all my other mods for the test.

Not sure exactly, but here's an anecdotal answer: I don't think it's very bad except in very extreme cases. When I had severe savegame bloat from the Reznod Mannequin item duplication bug, the bloat was drastic: 26Mb savegame. However, I think most of this bloat came from duplicate "created" items (something I enchanted and then placed on the mannequin). Somehow I got 56,285 created weapons, 97,250 book refs, and 120,000 object refs in my savegame that didn't point to any mod.

Removing mods like the old Get Wet (which used tons of placeatme activators) helped reduce my file size a bit, but it was insignificant compared to the duplicate items.

Also, I think that placeatme is fairly safe for actors that can be killed since the corpses get cleaned up after respawn, right? EDIT: what bg said!

You should be able to easily test whether it has much effect by using Wrye Bash to compare savegame stats before and after you go through the trap. Here's what the report looks like for mine:

http://devnull.sweetdanger.com/mods/character_stats_bash_aaryth.txt

Thanks, that's good to know. The trap works in a way that the creatures always get killed (or the player). And I'm only using it in two locations, so even if the player loots the dungeon ten times and always triggers the traps the placeatmes won't create more then twenty creatures.



Thanks, but I guess for the small number of creatures I'm placing it won't make a noticeable difference when I look at your stats.

Placeatme, I'm coming!

Right. Every creature and NPC in MMM and OOO have scripts on them, so we know that's not an issue on its own.



Exactly. So, the question then is whether "dynamic" references (getcontainer / getself / getactionref) are any less problematic in situations like this. In other words, does the problem come from having a hardcoded reference to the actor in the script or from the fact that the reference itself is persistent.

Here's a http://www.gamesas.com/bgsforums/index.php?act=findpost&hl=&pid=12179896 of a similar situation.

Also, way back during the beta testing for OOO 1.3 we ran into some similar rare CTDs with Oscuro summons. The particular example I remember was if you killed one of the Oscuro "corrupted" summons using a shock spell or shock weapon, then a few seconds later you got a CTD. Something to do with the actor being disabled while the shock membrane shader was still playing on it. Sotobrastos managed to fix this before release, but sadly I don't remember all of the details anymore.

I would say that dynamic references gotten with GetSelf and GetContainer aren't a problem. Cause should that reference be deleted/removed from the game, so would the token with the script on it.

Maybe GetActionRef could have a similar problem since the reference could disappear while the (activator) script is still running.

I know this is really old, but I stumbled across this and wanted to clarify:



At the time I wrote that tutorial, I was basically hacking out lots of proof of concept things. It wasn't my intent to give bad advice. I had actually asked one of the developers about PlaceAtMe, and he said that disable would remove the references, so I didn't think any more of it. I'm glad someone figured out what was going on and edited the article

Thanks for the note! Great to see you around!

This is one of the rare cases where early dev advice turned out to be incorrect, but nobody knew this back when you were writing the tutorial, so don't feel bad about it. It's an excellent tutorial with that changed. :tops:

Holy cow! Hey, how are ya? Great to see you, man!

Another gotcha which I've seen a couple of times now - I don't know if the gotchas discovered here are summarized somewhere, but if they are, this may be worth listing:

When doing any kind of summonable or portable Oblivion gate using MoveTo commands into the Oblivion realms will screw up the realms (they won't reset, so the next time you're going into that random realm again there will be no sigil stone). Using a proper door is necessary.

But it may be even worse: Some cases indicate that even when using a door, unless a specific command when closing is called, again the realm won't reset. Which command I don't know, maybe the door needs to get destroyed, maybe DisableLinkedPathPoints is necessary, or other strange stuff. Best bet is to emulate the standard gate behaviour as closely as possible.

Wait...
One gate links to one realm and if you do not call closecurrentobliviongate, of course, the realm doesn't reset. IIRC, you can even go out of the realm via the gate to resupply and can go back in again.

http://www.gamesas.com/bgsforums/index.php?showtopic=843877&hl=. I've seen this problem a couple of times now - that realms get messed up like described when the Sigil Stone is taken (which calls CloseCurrentOblivionGate) - it seems that this is not enough to completely reset the realm.

Oy, nasty one there. Sounds like a good one to add to the list!

From the mouth of the http://www.gamesas.com/bgsforums/index.php?s=&showtopic=846900&view=findpost&p=12353957, Oblivion diviner and bringer of knowledge:

Wow, that svcks.

So many mods do this it's hard to imagine being able to avoid it completely. I hope it turns out to be only certain kinds of objects or refs that cause it.

Will be interesting to see what the best workaround is. I guess simply moving the object out of sight may be the best alternative, but that could leave a lot of unused objects hanging around and slowing down the game. Might be a choice of which evil is lesser.

Well and ofcourse using Initially Disabled to stop it from being rendered. :shrug:

Yes, but then if other mods try to use those refs, would they still be disabled? I'm not certain how load ordering and precedence works for REFRs...

Hmmm yes, but then again, if other mods are using those refs would they still need to be hidden/removed/disabled? :shrug:

Not the point for avoiding the bug, but I'm not sure that will work for games in-progress. Has anyone tried?

Yes and it's fine. I made three test minimods. In the first, I set Initially Disabled on all objects in an outdoor cell. In the second, I deleted all of the objects. In the third, I set an enable parent to player (the only mass operation available from outside the Render window) just so they were all dirty.

With #1 active, objects were gone. With #1 and #3 active, objects were all back, including if game was saved with #3 inactive and it was then activated and game loaded. With all three active, objects were all back (well, seemed to be... see below) but.... crash on exit because #3's changes loaded after #2's deletions.

An initially disabled object ref. still has the full object ref. record; any change to the object by a later mod will override the entire record including the disabling.

One more test I have to do... I'll make a bad mesh that crashes Oblivion and place an object using it that's initially disabled to see if it precaches meshes for disabled objects.

Edit: While I was at it I was finally able to confirm something I had long suspected because I'd never heard complaints about it before then: the horridly long hangs and disk thrashing of the crash-on-exit was, so it seems, introduced by the 1.2.0416 patch due to the form ID cleanup code. I tried the #1/2/3 combination above on the 1.2.0214 .EXE and it takes less than a second for the error window to appear after quitting. Otherwise it's a good 10-15 seconds of an unrendered window and disk thrashing on 1.2.0416.

This sounds like something for Wrye or ElminsterAU or dev_akm to incorporate in their utilities. All that's required is to find deleted refs. drawn from Oblivion.esm ie with a 00 index, if they are found, import the entire record (deleted refs. are missing the data segment which is probably what causes crash on exit) from the ESM replacing the deletion record and set the Initially Disabled flag.

Edit2: It doesn't appear to affect all refs. I made two minimods. In #1 I deleted Weynon Priory House. In #2 I moved it up so it was floaty. If both were loaded it would not display the mesh until I disabled/re-enabled, but did not crash on exit with it displayed. With # 2 alone it appeared properly floaty.

Edit3: Made two minimods that deleted and moved a rock respectively. No crash on exit. Something tells me it's SpeedTree objects. I'll try one of them next.

Edit4: Nope, deleted and moved a shrub in two minimods and no crash on exit.

Edit5: Just to make sure, deleted and moved a tree, and still no crash on exit.

Edit6: No go with a harvestable flora (Dominica Redwort) either.

Can't continue the testing as I need to work on getting the UOP update done and out. But I did find one other good reason to never delete anything: in four of the cases (the single deletions of the priory, tree, shrub and flower) the object was present in-game when the deletion was overriden but it was invisible. It had to be PRIDded, disabled and enabled for it to be visible. So if a mod deletes a ref in Oblivion.esm and a later loaded mod tries to use it, it may end up invisible.

Thanks so much for all the testing! That's great info, man.



Sounds like a reasonable solution. Now if we can just get one of them interested in the idea ....

;)

The deletion conflict problem may not become a gotcha until several deletions are later overridden. All I can tell you for sure is that after going through my list of mods and undeleting records with TES4Edit, my problems with crash-on-exit have all vanished. Including edits to Tamriel -47,-7 which has been pinned as a cause for exit crashes.

Were I debugging this as a C program I'd be suspecting a double-free. These don't always bite you. The risk increases the more double-frees you cause until eventually one crashes the program. Perhaps the deletion marks it in the list as NULL and immediately removes the memory, but then the modification comes along and modifies that memory. Which remains semi-valid for the duration of the game. But when quitting the code blows up because it tried to free an already free block of memory. I've seen plenty of this in MUD code where invalid memory is still accessible until someone tries to shut down. Then it crashes as it's cleaning up.

What I don't get is why Oblivion bothers. Why go through the hassle of cleaning all that memory up when you've clearly told it you just want to quit. Why not just perform a saveini and simply drop to desktop after that? Let Windows have the memory back and clean up anything needing cleanup.

BTW - Shoving an item out of view by +/-150,000 Z units ( arbitrary value ) will put it far enough away that the game won't render it anyway. So if all this disabling and reenabling doesn't work, just shove it out of sight and it's not an issue if another mod comes along and drags it back to the surface.