QQuix

(if memory serves...) ar_erase arSomeArray[2] 20 <--- now I am erasing the Key Removes the entry (both key and value). As I understand it, this is what you want let arSomeArray[2][20] := ar_null <--- if I am understanding this right... I am Nulling out the arSubArrayB This does not change the array. arSomeArray[2][20] remains in the array, now pointing to a null array. If this entry was the last reference to arSubArrayB, it will be destroyed. If not, arSubArrayB will continue to exist and other references to it continue to be valid. This is not necessary if you use ar_erase arSomeArray[2] 20 let vCount := ar_erase arSomeArray[2] 20 ar_erase returns the number of entryes deleted. E.g. ar_erase arSomeArray[2] 16:99 would return 2 after erasing the two elements in that range (15 and 25)

I noticed two things: 1. Player x PlayerRef Long time ago scruggs explained to me that, whenever it finds the word 'Player', the compiler tries to make an 'intelligent' decision whether it means the player base object or the player reference. He elaborated but i don't remember the details. I remember that I had lost many hours debugging a code and I swore I would never use 'Player' again in my scripts (unless, of course, I needed the Player base object). I took the opportunity to mention this, but I dont really think this is your problem. After all the player base object is just a ref var and, if the compiler used the player base object, the comparison would just be 'not true' and not break the code. 2. Operator precedence One possibility is that the compiler is interpreting you code as: " if rTarget != ( player && rTarget.GetInSameCell PlayerRef) " Try " if ( rTarget != player ) && rTarget.GetInSameCell PlayerRef " Or maybe eval has a better parsing: if eval rTarget != player && rTarget.GetInSameCell PlayerRef

The thing is that water level applies to the whole cell, so, a lake must be at the lowest altitude of the whole cell where it is located.

Good to know. I added a note to the WIKI page.

Unfortunately, no. I have never played with the kill function much. If memory serves, I think I`ve read that sometimes it is necessary to use some additional functions to properly kill an actor, but I do not remember details. The KILL funccion page mentions that kill does not change the health value. You may try to set it to zero.

You must complete the second condition: If ( GetTime <= 3.5 || GetTime >= 23.5 ) or If ( GameHour<= 3.5 || GameHour >= 23.5 )

CS WIKI main page: https://cs.elderscrolls.com/index.php?title=Main_Page List of functions: https://cs.elderscrolls.com/index.php?title=List_of_Functions

The link works fine for me.

What is the error message? Are you sure the array was created? (did the message "database loaded" show?) A couple of comments (not related to the error): (1) If the array contents are always the same, you only need to load the array once. Once created, it is saved in the savegame. So, instead of " if GetGameRestarted" you could use a doonce switch (I usually use the very array as the switch with something like "if itemDB == 0 ") (2) you don't need to initialize ItemDB ("let itemDB := ar_Construct array") as you are assigning the variable to a different array in the next line. (3) You do not need the ItemDB var in the second script. You may refer directly to the quest array as in "foreach iterDB <- aaMagicChestDBQuest.itemDB" (but this is a matter of personal preference)

I see...! The only way I can see to use EditorID strings is by hardcoding the conversion by pre-creating a table EditorIDstring<> FormID (like a stringmap array with entries like "let myArray["MS31BlackWaterBlade01] := MS31BlackWaterBlade01 ). With it you could get the FormID of the item placed in the chest, convert it to the correspondent EditorID, rebuild the EditorID string and convert it back to a FormID to be used in AddItem. Another way (without using EditorID strings) would be a table PlayerLevel <> FormID (like an array or map with entries created by MyArray[1] = MS31BlackWaterBlade01 . . . MyArray[14] = MS31BlackWaterBlade10 . . . etc... A third way would be using leveled items. I am not familiar with them, but maybe there is a way to (after removing the placed item) AddItem a leveled item which the engine would dynamically adjust to the playet level. Not sure if this would work, thou.

Pluggy's StringToRef is the inverse of GetFormIdString. E.g. - " let refBase := StringToRef "0000000A" will set refBase to the FormID 00000A ( Lockpick. ) Except for RuntimeEditorIDs , the game does not know what the strings "MS31BlackwaterBlade10", "Lockpick" or "Gold" mean. Even RuntimeEditorIDs does not have a function to convert these strings to refs (From what I read in the docs - I`ve never used it myself). If you really must do this conversion, you may take a look at the scripts in my "Show EditorIDs in game". It is among my Conceptuals. It reads a conversion table from a pluggy text file. But it only have vanilla FormIDs.

In a script the EditorID IS the Base Object FormID (the compiler converts the EditorID into the FormID - and that is why the EditorID is disposable thereafter) So you just code "chest.AddItem MS31BlackwaterBlade10 1" The WIKI text "You can use a reference variable as ObjectID and a short variable for count." means that you may do something like this, if you need to: int intCount ref refBase let intCount := 1 let refBase := MS31BlackwaterBlade10 chest.AddItem refBase intCount

This 'alias' is called EditorID and it is only known by the Construction Set. Only EditorIDs of cells and quests go into the ESPs/ESMs. The others do not. But shademe has a RuntimeEditorIDs OBSE plugin that should do it.

GetEditorID works only with cells and quests Use GetBaseObject e.g. let BaseID := itemRef.GetBaseObject

When I first imagined a way to better control NPCs, I made a proof-of-concept mod to see how feasible the idea was (NPC ACE - NPC Advanced Control Engine, which is among my Conceptuals), The 'engine' got WAY more complex than in this POC, but I never finished it). Check it to see if the scripts are of any use to you. From the readme:

OBSE has all the functions to implement this. OnKeyDown to detect the keyboard key press GetCrosshairRef to identify the object pointed by the mouse Several SetPackage<xxx> to dynamically adjust the animal AI package to fetch the object Activate2 to move the object to the proper container I've been away from scripting for a while and coding details are starting to fade, but this is the general idea: A simple implementation would be an ever running quest the check for the key press every frame. When the key press is detected, it adjusts a pre-existing AI Package with data about the object under the cursor. When the animal reaches the object, the OnPackageDone block moves the object to the proper container. A more complex implementation would allow for queuing objects, so you could point-and-press various objects even before the animal reached the first one.

I see . . . and, since there is no way of peeking that interior beforehand, I see two ways of doing it: 1) Dynamically duplicated interiors: Tamriel worldspace <-(door)-> interior cell >> (first frame) duplicate the cell and move the player to >> New cell The bad side effect is that the first time the player enters any interior, you would have two load screens (and you also must rig the original doors, so the next time the player enters the same interior, the doors lead directly to your new interior . . . this would also take care of companions that may come after the player) 2) Predefined interiors: but this will only work for unmoded vanilla interiors. I don't know a thing about land records , so I can't help you there.

Any reason to do it from the previous cell? Why not use GetCellChanged and do all your checking and adjustments the very first frame when the player enters a new cell?

Duplicate formIDs are not expected by the engine and, most likely, will cause problems. Just occurred to me something I did in the past for mapping non-movable references: you could create an work ESP, visit the cells, write the info to a text file and read that file in your mod before entering the cell. But I suppose you are after actors and not statics, so not a helpful idea either.

The only way I can think of (and it is UGLY) is to move the player there for a frame, collect the data and move him back. But the visual side effects are BAD: a second Load Screen, a flicker of the screen for a split second and a (low) risk of another load screen on the way back. Even worse if you have a number of adjacent rooms and need to map every one. Besides that , moving the player is tricky and may crash the game under certain circumstances.

Cells are loaded as you enter them (that is what is happening behind the properly named 'Load Screen') Cells left behind remain in memory as long as the engine does not need the memory they occupy. This way, cells are loaded not only when the player enters them for the first time, but may need to be loaded every time the player enters them, if the engine reclaimed their memory. According to a report long ago, in low memory systems, not even the last cell visited remains in memory, so you cannot take it for granted. I am not aware of any way to preload cells.

Also . . . if you go to NexusMods Oblivion and search for 'Tileset' you will find a few more. (very few, I am afraid)

Conscribe is mostly a tool for modders debug their scripts. Modders will intersperse those commands in their scripts to log information to text file(s) so they can analyse the behavior of the scripts after tests. Usually, those commands are removed before publishing a mod. By itself, Conscribe has no use to the mod user. Contrathetix just gave a better answer.

I am not sure why I wrote that (I still could not reinstall Oblivion and my notes are not helping much here) If the phrase read "Exterior ECR ..." it would be true, because saving the game after the cell expires (ECR) removes all dynamic+non-persistent actors (dead or alive, respawn or not). But this is true also for interior cells and I would not need to make this note in the Exterior Cell section. From my incomplete notes (and without the code), it seems the statement is wrong, but I can not determine the actual differences between Interior and Exterior ECRs to figure out what would be the correct statement. I will review this when I reinstall Oblivion (which may still take a couple of weeks). Meanwhile, I`d better remove the phrase from the WIKI. Thanks for the heads up.

You may take a look and adapt the vanilla lamp post script. It turns the lights on and off at certain times of the day.