[LE] Is Object in Container?

[Kapteyn]

Well anyway, if the marker needs to be placed somewhere then it's no good. I'm using random objects to create dynamic spawns.

 

This seems to do the trick, forcing onInit afterwards makes sure it only runs once, otherwise the process repeats every time the cell loads.

 

It's also only pulling stuff from the form list if it actually needs to do so.

 

 

ScriptName Spawner_Clutter Extends ObjectReference

FormList Property Forms Auto

Int iPass

Event onInit()
If iPass == 1
iPass = 2
EndIf
EndEvent

Event onLoad()
If !iPass
Activator Thingy = Forms.GetAt(0) As Activator
GlobalVariable vEnable = Forms.GetAt(5) As GlobalVariable
If Utility.RandomInt() < vEnable.GetValueInt()
Self.PlaceAtMe(Thingy,1)
EndIf
iPass = 1
onInit()
EndIf
EndEvent

Edited October 1, 2017 by Kapteyn

[foamyesque]

 

Well anyway, if the marker needs to be placed somewhere then it's no good. I'm using random objects to create dynamic spawns.

 

How are you finding these objects and attaching this script to them, exactly?

[Kapteyn]

As I said, it's generic clutter... so I just walk into a fort and there's crap everywhere waiting to spawn stuff for me. Or a shop.

 

So yeah, I hooked a script onto the misc items and as long as they're not in an inventory they will execute it without a problem.

 

I've done the same with moths and butterflies, and since they're actually activators anyway they're even easier to deal with.

 

[JonathanOstrus]

From a fellow mod author I'm just gonna throw this out there. Your method is a horrific implementation. Now here's why. If the user uses another mod that makes use of the same record you overwrite, either you or that mod will defeat the changes of the other. This depends which mod the end user decides to put later in the load order. Last in gets priority. So while you've gone and changed every misc item to have your script on it. If I had a mod (like any sorting mod as a simple example) which changes the name of every misc item. I now just overwrote every change you made and none of your scripts will fire.

 

The common and preferred method to do what you want is to add your own markers and triggers to do it. You could reference existing vanilla markers but then the issue of other mods changing/removing the markers will cause problems. The cons: It's more work; and you can't have a dynamic system that spawns stuff in places you don't directly support.

 

Another way to get some of the functionality without needing to create a bunch of trigger boxes would be grab the OnLocationChange Event for the player and then process as desired. This is easiest done with a Reference Alias on a quest pointing to PlayerRef.

[Kapteyn]

There are always mod conflicts, it's one of the things we have to deal with. However, there is no question that sorting mods will be a regular problem and they will generally be very far down the list (for me, they are almost the very last to be loaded) - I didn't think about this. In any case, I'm far more concerned about every single piece of clutter being attached to the save file - surely this is asking for trouble. Yeah, I don't think this idea is gonna work.

 

The moths and butterflies should be okay I reckon, if anything people tend to add those rather than editing the very few already available. I've also modified the animals, but for them I simply added a spell to the race rather than each individual animal, so again that's unlikely to cause too many conflicts. I also assume they won't be persistent in the save file as well, so once the player leaves a cell where there are critters then they're gone for good and I don't have to worry about them - clutter, that's another matter I guess.

 

So far as triggers and cell changes are concerned, I don't really want to be creating anything directly on the player which is exactly why I was targetting random objects. I also don't want to be scanning for stuff. So really, the only option I have when it comes to forts in particular is to use markers - unless I can happen to find some regular objects which are never normally modified, things which will use scripts. Lights might be an option (specifically torches), I'm gonna take a wild guess and suppose most lighting overhauls modify the effects rather than the actual objects themselves.

Edited October 2, 2017 by Kapteyn

[JonathanOstrus]

Torches are a terrible idea FYI. There are many npcs that spawn with them and some scripts that add them directly to inventory. The script code for triggers won't fire in such cases but when the object is instantiated it will create the script instance in the save. It then never gets killed. IE causes save bloat.

 

As for lights, it depends. Some overhauls remove the lights entirely and make new ones. Some change how many there are. Some just change the effect of it not modifying the base object. It would be unreliable in any case. By default Bethesda doesn't put many in due to engine limitations relating to shadows.

 

Almost any way that you can semi-dynamically spawn things is going to have potential for bloating the save in an undesirable way. More script instances means more bloat. Doin triggers with markers means 1 script on the trigger with the ability to spawn at multiple markers. So only one instance then. Using your idea of lights (or previously clutter) would mean one script instance on each object every time it's respawned if it's not persistent. It's also worth noting that scripts and objects don't reset until the cell they're in resets. So the state and all data in the script instance is baked into the save until the player re-enters the cell causing the reset. Terribly inefficient way of handling the save data but I get it from a game engine engineer point of view, ie less loop case testing until it's relevant sort of thing.

[Kapteyn]

Sorry, I mean sconces not the hand-held things. If it can go in the inventory, I'm not interested in it. I've just found a bunch of things which look to be good options, stuff like dummy book markers and food barrels in particular. But whichever way I do it if it's a permanent object in the world then attaching a script is going to cause this save bloat we could do without.

 

So I'm thinking that the only viable option I have is what I've been doing all along - critters and wildlife. Since they're not permanent things, I'm assuming the script data will be purged in good time after leaving the cell. That is, the actor either gets removed from the world because the player is too far away or they are attacked and killed so their corpse is eventually removed.

 

So if I'm attaching a script to a critter, I'm not bloating the save am I?

Edited October 2, 2017 by Kapteyn

[JonathanOstrus]

Sorry, I mean sconces not the hand-held things. If it can go in the inventory, I'm not interested in it. I've just found a bunch of things which look to be good options, stuff like dummy book markers and food barrels in particular. But whichever way I do it if it's a permanent object in the world then attaching a script is going to cause this save bloat we could do without.

 

So I'm thinking that the only viable option I have is what I've been doing all along - critters and wildlife. Since they're not permanent things, I'm assuming the script data will be purged in good time after leaving the cell. That is, the actor either gets removed from the world because the player is too far away or they are attacked and killed so their corpse is eventually removed.

 

So if I'm attaching a script to a critter, I'm not bloating the save am I?

 

That's not how the cleanup works. Everything is left behind dead bloating save until the player goes back for the cell to load and render. At that point things are cleaned up. The one exception is *some* unique npc dead bodies. Specifically humans. They have a special cleanup script attached which you can view WIDeadBodyCleanupScript. It's used for unique npcs to give them a grave stone of sorts and transfer their inventory to the grave.

 

Attaching to the critters probably won't bloat the save any more than on a food barrel. It's instancing the script either way and staying until the cell reset occurs. Even using trigger boxes would do that. The only benefit of a trigger box is that you could use 1 box with something like OnCellAttach to then spawn things at like 5 multiple markers instead of needing 5 different objects to trigger those same spawns at themselves. Thus you have 1 script instance instead of 5. However you still have all the markers set as persistent (which is normal and expected) and referenced as properties. This has the benefit of having less string table allocation since it's 5 properties on 1 script instead of all the other properties each instantiated on 5 different scripts. There was a problem in Skyrim Classic (may still be present in SSE) that if the string table got too big the save became corrupted and couldn't be loaded.

[foamyesque]

As I said, it's generic clutter...

 

Your script extends objectreferences. That means you're either attaching it to the base object -- and editing base objects is always a bad idea unless you have no choice -- or you're manually adding it to individual references in the world, in which case a trigger/marker setup will do everything this does but better.

 

From what I'm hearing/seeing (I'm not a TESVEdit expert by any stretch but that looks like a base record to me) you're editing base objects. That's an awful idea. What if this kettle, say, is used in the Blue Palace? You gonna have a bandit spawn there?

 

A much better way to implement 'I want to trigger spawns anywhere' would be a quest-based system, which you can set up with much more flexibility and with a much reduced chance of conflict.

[Kapteyn]

Okay, moths and butterflies are probably a bad idea because they're activators and have very few parameters to tweak. However, the good thing with these things is they're always out in the open so while a player might not necessarily go back to a dungeon once it's been cleared, at least not for 30 days, they are surely far more likely to pass through an open area multiple times. So the risks might be negligible.

 

Animals are a different matter because they can use spells, which means I can place conditions on the spell itself and also the magic effect - only if those conditions are met will the script execute. I actually moved most of the conditions into the script because technically it's less work for the system, but maybe not if it's causing scripts to be used more often.

 

So far as clutter is concerned, yes it can result in bandit spawns anywhere and everywhere, but only if it's enabled. I could, if I really wanted to, place restrictions on the locations. No matter, I've pulled this because it will bloat the save. It's just too risky.

 

Then there's modifying base objects. This is actually the idea, the only alternative is to use spawn markers which would involve placing them (or using existing references) over what is a very large game world. If on the other hand I'm editing the race of an animal (so not the base actor itself), giving each of them a spell... the script is actually on the magic effect and not the animal. This script then creates an activator which does the main work, and it's deleted when done. It's still leading to an object reference, it's still adding forms to the file, but no massive amounts of data is being saved because I'm not using properties apart from the form list. What I think I need to do is limit all this into a single script instance, as long as I can sort it all into functions so they will be used only when needed - doing it this way I expect would prevent the references being saved because it's always being done as a magic effect.

 

I'll tell you what I'm going to do - I'll make a global variable for every script, then I'll increment it every time the script is executed... so I'll know exactly how often it's being used.

Edited October 2, 2017 by Kapteyn