Of FormLists and References. How to use them

[dpcollier128]

Okay. I've run into a snag for my Glowing Items "revival" project from last week (the mod in question is here). The original mod author had the bright idea to use FormLists to help control which objects in the cells get painted with an effect shader (he only used it for painting Stimpaks, but still), and I wanted to give it a try for everything else... It didn't work as expected. I'm using the IsInList function to attempt to check a list of items I'd like to be painted by the mod's scripts, but it seems that this function doesn't check for object references in the list but just base forms (whatever-that-means). I tried using ListGetFormIndex in conjunction with some midling boolean algebra... no luck there, either. I even tried using both ListGetFormIndex AND IsInList checks connected by an OR operator, still nada.

 

I then tried listing out a chain of checks for the reference being an instance of specific item ids connected by OR operators. This worked with mixed results (some of the items listed didn't glow until I took them then dropped them from my inventory)... but it doesn't make for any sort of clean code at all. I've looked into whether arrays were implemented in the Fallout 3 scripting system or FOSE... but it's only been implemented in NVSE, in a system for another game. Also, there's another reference-based function called IsRefInList which I'd like to try, but that too is only used in NVSE. It's starting to look like I can't do this the easy way. The first easy way (FormList checks) didn't work and all I have left is the VERY messy way (ItemID checks).

 

My question is this: is there some way in either FOSE or the base Fallout 3 scripting architecture to successfully check an object reference from GetFirstRef and GetNextRef against a FormList? If there's some kind of type-casting to be had from a reference to a base form, that would likely do the trick, but it's late and I have yet to find such a thing. Another thing that might work is some way to easily unpack a FormList and check each element, but I don't see this being a very good way to do it as there's no "for" or "foreach" loop to speak of in Fallout 3 (NVSE has a "foreach" for arrays though). I'm running out of truly viable options for checking a list of items for the mod to paint.

 

Thanks in advance for any pointers and suggestions... I'll be in the corner cursing at my computer for being dumb.

Edited November 9, 2018 by dpcollier128

[GamerRick]

It would be a lot more efficient to check the refs against the TypeID (GetType) than to check each one against a formlist. The formlist would have to have every item in the game you would want to find. So it would be like checking it against a formlist with every piece of armor in the game versus a typeID of 24.

[dpcollier128]

The mod already does this, but typeIDs like 27 for containers tend to freeze my game when painting everything in certain cells (tons of filing cabinets, lockers, boxes, etc). Is there something like a "subtypeID" which I could use to narrow all these objects down to just a few? If not, using a FormList with the items I'd like to check from each category is the only thing I can think of right now.

[GamerRick]

What exactly are you trying to make glow? This could be a cool idea that just isn't feasible given the limitations of the game. But, I like it that it you are testing the limits!

[dpcollier128]

I linked the pre-existing mod I'm working to improve in the OP. It's called "Glowing Items" if you can't seem to get that link to work. The basic concept is to make every item or container in the game glow different, customizable colors based on categories. The plugin version of this mod doesn't replace any of the meshes, unlike the first version. Both versions work to some degree... I just think the categories used in the plugin version are too broad for my installation to handle all at once. Also, the replacer version conflicts with some other mods I use (mostly dealing with fixing collision meshes).

 

So, I'm trying to make the mod's scripts narrow each category down to only what the user (or myself) want via some form of sub-categories or pointing to specific items. The problem with this is that many objects in the game (containers in particular) have multiple base IDs which get used all over. For example, there are over 30 entries in the GECK named "Locker" in-game, some of which are empty, don't have very many appearances, have various groups of useful items ranging from weapons to medicine, etc. I'm trying to only make certain items glow so that the useless or unwanted ones don't. This saves the mod some processing time, my computer some struggling, and my head its usual aches when the game crashes or freezes.

 

It's not any specific thing but a whole host of different things: weapons, ammo, medicine, first-aid boxes, ammo boxes, crafting components, other junk, pretty much EVERYTHING but in a customizable fashion for each item sub-category or individual group of named objects (such as "all lockers" instead of "just one form of locker"). The thing is, I'm so close to making this sub-categories idea work, but the methods for getting it to work either require knowledge of systems I don't have or messy coding skills I'd rather not use as extensively as they are required. This is why I'm asking for help.

 

If there isn't any way for me to use a reference to compare with entries from FormLists, that's fine. I just need to know if there's an easier way of narrowing the categories down to manageable chunks than to simply spam the same command with a different editorID connected by OR operators. If there were some form of NOT operator, it would help the messy way of doing this quite a bit. Instead of checking for items to include, one could check for the few NOT to include. So, I have multiple methods in mind for solving this particular problem, but using the first method of choice is preferred.

Edited November 10, 2018 by dpcollier128

[GamerRick]

From what you have said, I can't figure out what your issue is. Yes, to do IsInList on a ref, you need a FormList that contains every single FormID (or Editor ID) of all of the objects you want to check for. You would need to create patches for mods that add additional items to have them get included.

 

The BaseID is the hex number you see in the GECK in the first column. You don't care about those. You should be able to do IsINList with each ref you get from GetFirst or GetNext. You also can use that ref (if you know it's a container as the concept of type casting doesn't exist in this language) to do functions specific to containers. The same would go for other functions that apply to other object types.

 

So go for it! Create that monster FormList of all containers that you want to have glow and see what happens. Maybe you can make the whole script work on demand by a hotkey or something. Maybe after a lot of trial and error, you can find out what you can get away with without causing CTDs.

 

Good luck!

[Mktavish]

Not sure what kind of tedious geck side set up it would take , But you could try utilizing some of the other info held in base forms & Refs. Like ownership , value & weight.

[Mktavish]

Okies so looking at this more indepthly ... I gather it is the process side effect that is your biggest concern.

Not necessarily a more customizable list of objects to play the effect shader on ?

In which first , I would forget the replacer method since it involves the hard drive.

 

Then I can see a few spots to trim the code and put bottle necks for what ends up glowing at any one time.

 

For starters , just put in a get distance check , or maybe even a line of sight with that ?

Also raise the script process delay on the quests , to something like 1.5 or higher.

 

Then you might even want to split up the code for what color and dimness has been selected.

Which means a bunch more quests and scripts for each color , instead of every script always checking what the color selection was in a gamemode block.

 

Hope that helps.

[dpcollier128]

Those are some very nice ideas. I didn't even know about the quest script process delay. That alone might help immensely. I'll likely try that and the get distance/los checks first as they make the most sense. I don't know if I can split up the color/dimness checks as those properties are innate to the effect shaders... unless I could change those values in the effect shaders on-the-fly. Hmm... this last part is worth looking into. I'll do some more research into what's available for changing effect shader properties in a script. Otherwise, I don't think splitting up the effect shader property checks will work well.

 

EDIT: Also, I'm curious to the viability of checking an item's weight or cap value with a script. If it's possible, I'd like to know how. Also, if one could check the weight or cap value of an item, does that also mean one could change those values dynamically through a script? In that case, would it be possible to change anything's data properties from the GECK (including effect shaders) from a script?

Edited November 10, 2018 by dpcollier128

[Mktavish]

The mod author sets a global variable for what is selected in the terminal per color.

Then the game mode block of the quest script constantly checks to see which of those globals are set to 1

Iterating through all 6 colors , but also filtered for the dimness first. On a possibility of up to 13 different types (quest scripts)

 

Which the effect shader has nothing to do with the check , just what is the result of the check.

 

So I am saying , each Quest / type could then get split into 12 more quest scripts to only have one of the 12 effect shaders in the code ... hence no checking that global in a gamemode block. Or even needing that global.

Because the terminal result script would just say "StartQuest ThisItemColorQuest" or "StopQuest ThisItemColorQuest"

 

But then again not sure how much process efficiency you would actually pick up for all that work. So might as well save it for a final need to effort.

 

By the way to mention about your other thread. I believe you could at least turn off the "Ingredients & Clothing" categories. By just changing the result script setting their applicable global from within the terminal. (slap a semi colon in front of it)

They may have just been the authors attempt at covering everything not realizing those aren't used or may be duplicated in the Armor type.

 

Add edit : Also wondering if you added more form lists ( the dynamic one)

One for each type , instead of a catch all for everything ... could possibly help ... not sure though ???

 

And by the way ... if it is the exterior cells giving you the most reliable slowdowns ... you can change the cell depth flag on "GetFirstRef {form type} 2 0" with " 2 " being the cell depth... change that to " 1 " Since it will decrease what is checked by a factor of about 3 . Which yields a dynamic distance of 4097 game units up to 8192ish ... vs up to 12288ish in all directions , on a cell depth of 2 .