SSE Help Needed With Sort Script

[NexBeth]

All the containers were renamed by me to make them unique, if that is what you mean? I moved their references from the Object Window into the FL I created.

 

[SurfsideNaturals]

Hey Beth,

 

It sounds like the event may only be firing once on a stack of items. Strange.

 

Give this a try. I have done a sorting script using arrays but nothing like this script. You might also consider making a test of your idea only using a couple of chests and a couple of items. Once you get that working how you want it, you can add more items.

Self.RemoveItem(akBaseItem,GetItemCount(akBaseItem),True,TheCont)

[NexBeth]

SurfsideNaturals, your modification resolved the problem of rejecting multiple items. Thanks! Still have the big problem of items being removed but not being stored in these containers. I have a utility cell with all these containers. I don't test using a save. I go in coc with the default player and, right now, I'm only dumping what he (vanilla) carries with him (very few items).

Edited February 4, 2020 by NexBeth

[IsharaMeradin]

In your screenshot, you have placed the CONT object (the base object) for each of your containers. That won't work. You need to put in the references that you placed in the Render Window. You should be able to drag and drop from the object listing in the Cell Window to the Form List record.

 

Hope that makes sense.

[NexBeth]

That is something new to learn. Can you explain that? Will I need to do that for anything custom I make and put into formlists??

 

___________

Update: Tried but failed. Bit blury, but the highlighted Num. ID on FL now matches the number to the right of the Ref. Editor ID or the container.

 

Edited February 4, 2020 by NexBeth

[IsharaMeradin]

I do not have the game or CK installed so I cannot take a look at things. But if you look at my Inventory Management System mod for original Skyrim and take a peek at the formlist assigned to the abim_IMS_ModContainers property variable found on several of the scripts you will see how I set that up.

 

Something that may have an affect, all of my containers are persistent. I needed to set up a quest for each item used to access each container so that the player could have the choice to use as many of the containers as they wished (i.e quests started / stopped via MCM choices). The matching container fills a property on the player alias script on each quest. Thus the containers are all persistent. Perhaps it is persistence that allows the items to move into them even when their 3D is never loaded.

 

But as I understand it, your containers are loaded when the player is depositing items into the master container. I would think that it would be a non-issue then. Apparently tho it is.

 

Could try changing

ObjectReference TheCont = EP_AcceptedItemsContainers_FL.GetAt(index) as ObjectReference

to

Form Entry = EP_AcceptedItemsContainers_FL.GetAt(index)

ObjectReference TheCont = Entry as ObjectReference

It does the same thing but splits it up so that you can add debug statements to see what is actually being assigned to the local variables. Perhaps that will help you figure out what the break down might be.

[NexBeth]

I modified the lines above for de-bug statements, but got nothing in return. (I just copied the lines above and did not modify them.) Looks like I'm not having much luck with a sorting script....in any event, thanks for trying to work through this for me.

[IsharaMeradin]

Your alternative is to have a long list of properties for each container and at that point the formlists will need to be in individual properties too. Then instead of a nice singular block to handle everything you would have a long list of IF statements. Would make the containers persistent and probably solve the problem of items not going into them.

 

Wait!!! I just had an idea. Instead of making the master container sort the items out. Have the individual containers sort the items in when they are activated. Less overall work and a single script that could be used on all the containers.

Scriptname IndividualContainerScript Extends ObjectReference

ObjectReference Property MasterContainer Auto
FormList Property myListOfItems Auto

Event OnActivate(ObjectReference akActionRef)
  If akActionRef == Game.GetPlayer()
    Int Num = MasterContainer.GetItemCount(MyListOfItems)
    MasterContainer.RemoveItem(MyListOfItems,Num,true,Self)
  EndIf
EndEvent

Do not know if you want to go that route, but it may be worth testing... Obviously not tested...

[NexBeth]

I will test this new alternative but, IsharaMeradin, my original script posted in the OP had that long list of properties for all the containers and all the formlists and you felt it was not the way to go, right? That script wasn't working either (rejecting everything) but then you pointed out that it had the skse element in it.

 

Here is the original script which is a modder's resource. I deleted parts of it involving the keywords check and the item ID check since I only wanted to do a formlist check (for greater control of what goes into the containers). Perhaps I botched the editing though? Red print is the text deleted out in the script I originally used.

 

 

{Sends items to relevant containers when placed inside the container this script is attached to.}

;PROPERTIES

ObjectReference Property AcceptedItemsContainer Auto
{The container to place accepted items.}
ObjectReference Property SoulGemsContainer Auto
{The container to place soul gems.}
ObjectReference Property HarkonsContainer Auto
{The container to send Harkon's Sword to.}

FormList Property AcceptedItemsList Auto
{The form list of items this container will accept.}
Keyword Property VendorItemSoulGem Auto
{Keyword for soul gems.}
Weapon Property DLC1HarkonsSword Auto
{ID for Harkon's Sword.}

;EVENTS

Event OnItemAdded(Form akBaseItem, int aiItemCount, ObjectReference akItemReference, ObjectReference akSourceContainer)

;This first IF statement will check to see if the item being placed inside the container is in your Form List
If AcceptedItemsList.HasForm(akBaseItem)

RemoveItem(akBaseItem, aiItemCount, True, AcceptedItemsContainer)

;This second IF statement will check if the item is a soul gem, unless it was in your AcceptedItemsList
ElseIf akBaseItem.HasKeyword(VendorItemSoulGem)

RemoveItem(akBaseItem, aiItemCount, True, SoulGemsContainer)

;This third IF statement will check to see if the item being placed inside is Harkon's Sword
ElseIf akBaseItem == DLC1HarkonsSword

RemoveItem(akBaseItem, aiItemCount, True, HarkonsContainer)

;This final IF statement will give the item back to the player if none of the above return true
Else

;This is the message to show when an item is not recognised by the container
;or if it's an item you don't want the player to place inside.

RemoveItem(akBaseItem, aiItemCount, True, akSourceContainer)
debug.notification("Invalid Item")

EndIf

EndEvent

 

 

 

[IsharaMeradin]

On your original script, you had a long list of properties but they were not being used in the script itself thus it did not work.

The formlist / array approach is sound and works but probably requires the containers to be persistent.

The script you originally edited from works for that setup because the container being used is explicitly assigned to a property thus it is persistent.

 

Theoretically, you can put 25 scripts on the master container and have each one point to a different container and check their own singular form list of items. However, that is 25 scripts trying to run at the same time even if the item only belongs to one of them. Not really a good idea.

 

Personally, I prefer the formlist approach as the code to write is shorter which in turn means less opportunity to introduce errors that need to be hunted down and corrected. It also means that the formlist(s) can have entries added and increase the capacity of the mod without the need to edit the script again. Whereas the series of IF blocks would require editing the script every time you want to add another set. And that might mean a new game, "cleaning the save" or performing various "tricks" all depending on what it takes for the changes to be recognized. In a nutshell, if the script can be written in such a way that adding to the capabilities does not require editing the script, then that is the approach that I would find best.

 

My latest thought was a complete reversal of the system. Use the activation of the individual containers to pull the desired items from the master. This should work because the master would be persistent and the container being interacted with would have been loaded and thus memory knows about it. Downside might be that the player could see the items appearing one by one in the container's inventory.

 

An extension of that idea is to place a trigger volume box around and in front of each non-master container (assuming there is room) such that the player must enter it before they can interact with the container. The trigger volume box would use OnTriggerEnter event with a properties for its container, form list and the master container. This solves all the issues in that each container including the master will be persistent and the items will transfer before the player opens the individual containers. The system could be expanded by adding as many containers and trigger volume box pairs as desired.