dafydd99

i don't know which references you're talking about. are you talking about the draugr ? or the trigger box for ambush ? Yup, I just mean remove the actor, sarcophagus, trigger references, and rebuild them. There's a warehouse cell with ambushes, and I'm pretty sure there's a sarcophagus one in there. If you cut and paste them from there in one go, it'll maintain all the properties, linked ref, activate parent, trigger box details etc. That's what the warehouses are there for.

When dealing with ambushs I often get tripped up by a few of things.. Don't use a save within the cell, then add the ambush - it needs to go through a cellLoad event to properly initialise. Just using a save from a previous cell might fix it. For some reason it can get VERY twitchy about bad navmesh - or even navmesh that's apparently fine! I've sometimes found cutting the navmesh at the exit of the room as a test suddenly made it work okay. From trial and error adding and removing navmesh you may be able to track down where it has the problem - could be a triangle a long way away. Sometimes I just can't get them to work right at all. No idea why! If you can't get this to work, you could delete the references and simply put them in again - sometimes this seems to fix it. There are a few ambush test cells - select all the relevant parts (actor, sarcophagus, trigger etc) from this, copy and paste into your cell. At least all the properties should be correct!

Double check the uUIDarkThemeId is also set to 1. For me these were the default settings, in the CKPE ini, and I'm not sure any others (including the original light theme) are fully supported any more.

If not a vortex user - given you'll only (hopefully!) have been creating/compiing your own assets, you could just a search in the data folder (or just browse specific folders within), order by newest, and grab those. You can actually add a prefix to the fragment names too - this article may help... http://skyrimmw.weebly.com/skyrim-modding/naming-conventions-skyrim-modding-article - which reminds me, I should do that myself!

If anyone would like to investigate or demonstrate this 'bug' I seem to have found in placeatme (and potentially discover a way to avoid it), I've written a simple mod that can demonstrate it: https://www.dafutils.com/mods/PlaceAtMeTEST.zip Just a small .esp, a .pex and the .psc as below... Scriptname PlaceAtMeTestScript extends ObjectReference static property myStatic auto static property XMarker auto event onActivate(ObjectReference actronaut) ObjectReference ourMarker=self.placeAtMe(XMarker) int count=50 while(count) count-=1 ourMarker.moveTo(self, 0, 0, 64+(count*10), true) ourMarker.placeAtMe(myStatic) endwhile endevent To test, install the files in your data folder, add it to your load order via the creations menu in game, and when playing go to the console and type... coc TESTPlaceAtMe You should appear in a small lit room with 16 levers in front of you. Maybe do a quicksave so you can test it multiple times. Pulling each of them will create a pile of 50 static nordic pots floating in the air above each lever. When you've done all 16 go back to the console and type... tcl to turn off clipping. Then back out of the room through the wall. At the point at which you leave the roombound, which surrounds the room, you should see the room, lighting and the pots disappear. If you see any remaining pots, they haven't been correctly applied to the roombound, and will only appear when outside. Currently I'm seeing around 1 in 300 seem to fall in this category. Oddly I've actually started seeing some which can be seen both inside and outside the roombound, which I didn't think was possible. I *think* the faster you pull the levers makes it more likely to happen but that doesn't always seem to be the case. If you make a save whilst seeing this problem and load it, the problem appears to be corrected. Do please let me know if you don't find any problems - could be somehow this is just my problem, and my gamefiles (or maybe graphics driver) are corrupted! Testing on a GTX 1660 super. Cheers - dafyd99

Fair enough. Bethesda don't seem to have published much about papyrus, so it's hard to be sure of the exact language definition. The closest I could find was this... https://ck.uesp.net/wiki/Statement_Reference (good to see some form of EBNF there!) - though I haven't really done an exhaustive search. I'm guessing, and I'm not really certain here, that our papyrus scripts are compiled into what is just a tokenised form of the script (probably with no optimisations) and that's parsed by an in-game .pex interpreter - it's possible the only full definition of the language exists in the implementation of this interpreter.

I'll try to talk in general terms here, as papyrus is a bit of an odd one for optimisation, and this might help some others too. I'm assuming you mean most efficient from the point of view of returning quickest in most situations. Here's a few things to bear in mind... Nearly all function calls have to wait for a frame refresh to run. The exceptions here are your own local script functions (on 'self'), or these few non-delayed functions... https://ck.uesp.net/wiki/Category:Non-delayed_Native_Function . This is a HUGE slow down, and usually the reason for slowness in scripts on you'd think should be fast. Any time you call one of these slow functions you'll get that wait, so if you're calling those three ThisActorClosest.GetDistance(PlayerRef) calls, better to store it in a temporary variable eg - float myDistance=ThisActorClosest.GetDistance(PlayerRef) and use that. The overhead for the temp variable is almost nothing. if you're ever doing a simple && condition the optimiser SHOULD drop out after the first false statement as all must be true to continue. (Nearly all languages would do this, but rarely they've been written differently). Because of this always put the LEAST likely condition first (or possibly the shortest running query, if eg it's from a local function call, or local boolean test). If you're uncertain, you can 'force' the optimiser to drop out after running the first condition by placing the rest in an embedded if statement. Sometimes this makes the code a little clearer too - Code clarity vs optimisation is often a trade off, generally I'd go for clartiy over optimistation except in highly performance dependent code, usually stuff that's being run hundreds of (or sometimes way more) times. ArrayLists are MUCH slower than arrays, so if you need to do a lot of operations or tests on an ArrayList, it might be worth caching it in a simple array first. As xkkmEl said, it's a little hard to work out exactly what you're trying to do in your statements. if you break it out into some unoptimised code we may be able to help make an optimal solution for your specific case.

Thanks Sphered! Wow - I don't think I've ever quite seen code like that before! Yes, I'm not doubting placeAtMe works well in most situations. But for whatever reason I'm finding that using it within a room marker has very rare issues (area of 1 in 20 to 1 in 100) with it binding the newly created reference to the correct room marker, hence making the reference invisible from within that room marker. If I remove the surrounding room marker, it works 100% of the time. It could be that there's something unusual with the nifs I'm using or perhaps the creation kit is making room markers semi-broken some how, but both of those seem quite unlikely. I've experimented around with whether the placeAtMe is placing a persistent reference or not, whether it's placing it disabled or enabled, whether I use a setScale on it, and an enableNoWait - all show the same results when the reference is placed in a room marker, so I don't believe they have any bearing on the issue. The reason why I'm not posting code etc is partly because the script is over 300 lines long (containing many functions) but also because I very much doubt there's a problem with it - as what I'm seeing is actually impossible to purposely make happen with scripting, so must lie in a problem with the engine. Cheers - dafydd99

Okay - finally think I've managed to isolate the bugs, and there seem to be two of them: The first bug is quite serious but perhaps understandable - placeAtMe was probably never intended to be used this way. If you use placeAtMe to place a new reference in a cell that is not currently loaded, it appears to have a small chance of creating a corrupt reference. I was using this to set a numeral during initialisation (after a random wait to avoid over stressing the scripting engine). A simple fix for this is to instead run it within an onload() - puts slightly more work to the scripting engine at cell load, but should still be okay. The second bug was very hard to track down. The locations I was placing the numeral were within Room Markers (roombounds). The pivot points of the new references were well within the bounds of the room marker, and PlaceAtMe usually handles this just fine and correctly applies it to the room marker it's been placed in - but once in a very rare while it doesn't, and the new reference is placed in the default room bound - ie outside all the room markers. So obviously it exists (hence passing all tests), but it's not visibile from within that room marker! However, 'tcling' outside the room marker makes all the references inside the room marker disappear as you would expect, and the faulty references appear. Clearly on a game load, this is rechecked and they appear again correctly. Not really sure how to fix this without removing room markers - which will obviously cause optimisation issues. There doesn't seem to any mechanism to force a new reference to a room marker. All I can think is that perhaps there might be a flag on the nif, or potentially something else I'm missing that might somehow be able to avoid it? Or some mechanism to force a reference to be rendered no matter which roombound it appears in. Does anyone have any wisdom to share? Potentially the areas containing my numerals could be forced into the default room bound at a cost to performance to sidestep this bug. Cheers - dafydd99

Okay - more testing but I'm still as baffled as before. When a numeral doesn't appear (again very rarely - like 1/100) it still passes the tests of... is3DLoaded() TRUE isDisabled() FALSE So on finding a broken numeral, I travelled away to unload all cells, and returned with an onload() test on the tablet that references this created numeral. One of two things happened... 1) it appeared correctly. No sign as to why it hadn't before, but was working as it should. This would also happen on save then load. 2) the 3d did not load. A check on the reference showed that yes, there was an object there and it had the correct base object form id. It was however disabled. On enabling it did not appear, but isDisabled() returned false. Travelling away again and returning, and it was in a disabled state again. It's still as if just once in a while it creates a duff reference. Unfortunately as all the tests return positive at the time of creation, it's hard to catch and fix. Perhaps I need to make a save with a duff reference and analyse the save more closely.

Thanks xkkmEl. Hmm. Doesn't seem to due to piled up numerals - it can be changed 20 times in a row with no problems, then is missing, and then works again fine for another 20 times. Yes, sorry - as discussed above in the reply to PeterMartyr this is only a snippet from a more complex script. The reason we have the newNumeral as a local variable is because it is temporary, and a script level ObjectReference called 'currentNumeral' is used to handle the 'old' numeral until the new numeral can take over. It is kept alive until slightly after the new numeral is created and the 3d is loaded to avoid a 'flash'. I think by 'Global' he's refering to the variable scope, and just means not local to the function, ie a script-level variable as you've given above. I'm thinking at the moment it could be the engine getting overloaded by something and bailing in those instances. Or could be something unreliable in the settings of the nif. Or potentially there's something unexpected going on in the threads that I've missed. I'll try to do some more extensive testing on just the placeAtMe part. EDIT: btw, yes, I'm starting with a clean save file without the mod just in case, and yes there's actually some belts and braces code that clears out any numeral that might be placed there but the reference has somehow been lost using Game.FindClosestReferenceOfAnyTypeInListFromRef()

Thanks for the response PeterMartyr. No - that isn't my complete code, it's a simplified snippet to just show the important parts about the placeAtMe - to reply to your points... yes a script-level variable is used to hold the current numeral. The newNumeral variable above is temporarily used to enable the numeral, then the old one is disabled (deleted and dereferenced to allow the engine to complete the deletion) - this avoids the slight 'flash' that can appear, and removes the previous numeral permanently. the code above is to point out that the numeral BELIEVES it has had the 3DLoaded, where as it hasn't actually appeared - so it is not necessary to iterate a few times to check. the creation of a numeral is done within a 'busy' state which blocks out any other attempts to create a new numeral until it has completed - so we shouldn't be dealing with a race condition. In the busy state it would also be logged if an attempt is made to setNumber() again, and that's not happening.

Thanks greyday01 - yes your suggestion should be the most reliable, and might end up being necessary. I was hoping not to need to place eleven objects for just one function - but perhaps it's unavoidable.

I've made a simple stone tablet to 'display' numerals which can change over time. It can display one of ten numerals, so I'm using 'placeAtMe' to put that item in place. The numerals are statics and have no collision, just a few BSTriShape's. function setNumber(int numeral) Debug.Trace("Setting number to:"+numeral) ObjectReference newNumeral=placeAtMe(NumeralsList.GetAt(numeral) as form, 1, true, true) newNumeral.SetScale(numeralScale) newNumeral.enableNoWait() if(!newNumeral.is3DLoaded()) Debug.Trace("3D NOT loaded") endif endfunction This works around 99 times out of 100. But just once in a while it doesn't. It believes it has made a new objectreference, and it believes the 3d has been loaded, but no object is visible. Anyone got any thoughts about this? I had thought that putting a slight delay (utility.wait(0.1)) between the setscale and enablenowait fixed it, but alas no. Thanks in advance for any help. Cheers - dafydd99

For anyone reading this thread in the future - I couldn't find a way around this 'feature'. In the end I moddified the 'doorbar' and 'barreddoor' scripts and made them work across cells.