FriedStephen

Well, this should be my final update on the plugin. I've done what I said, and merged both our previous versions. I also made a few tweaks and applied some polish. Most notably, I added a "Crafting Parts" label which is only available if Universal Item Sorter is loaded. Also, instead of messing around with "dumping everything but equipped items" with the mobile auto-sorter, I compromised and simply added the option to directly access the sorting container from the mobile auto-sorter; so it's still not very functional as a cheat-y item, but it's a little more versatile than before, just as I intended. All I need to do now is write up some documentation, then release the mod. Once again, thanks for everything you've done, and all due credit will definitely be given.

I had a bit of time to look into the plugin today, no time to make changes or test anything though. A couple of things I wanted to point out were: 1. The sorting script seems to only be activated now when the mobile auto-sorter is used to dump inventory, or when the label maker menu is open. This is actually not how I intended it to function, since the label maker should only be necessary for editing labels, and should be stored away when not in use, and people need to be able to simply drop items into the container labeled "contMain" for the sorting to activate. I think that means the quest script should really be always on, no toggle. It didn't seem to hurt performance anyway. 2. I noticed that in the sorting script, all the lines like "if contMain != 0" are replaced with "if contMain". Is this an oversight, or is it functionally the same? I guess all that line does is enable/disable the sorting function depending on whether or not the label is assigned. I think the simplest solution here would be to combine our past two versions. You cleaned up a lot of aspects that should probably be kept, like the NVSE stuff, and moving the check script into the perk entry, but otherwise we can probably re-merge the two quests, have the sorting script in gszQ run constantly, and drop the sorting script in gszAutoSorterScriptMsg4UDFScript. That'd make it a lot more manageable for me since it's really just a more efficiently written version of my last working version. It's odd that it seems to be working fine for you but not for me. Before I try making any changes, I'll do some more testing in case the errors really were just on my part. Before I tested your work, I first removed the old quest script and message box elements that were no longer in use, and updated the vanilla MagDrug exemption formlist to also include DLC items and poisons, to match the UIS categorisation, but perhaps I messed something up somewhere.

A quick update: I tried a bit more testing, and got mixed results. The menus seemed to be working again, but a bit slower to load than before. The sorting system seemed to work, but some categories were misplaces sometimes. That may have been my fault as I may have mixed up labels since I was clicking through everything quickly. Eventually, the menus starting to only appear some of the time, and then at one point they stopped appearing completely. To be clear, the MessageBoxExAlt menus were appearing properly and were very responsive, it's just my old ones that were messing up. I wonder if this has something to do with the quest be toggled off and on, maybe it eventually gets stuck in off mode. I'll need to take a closer look at the reorganised aspects, and try to see if there's a loose end somewhere.

I've only had very little time to pore over your work and a single minute to test the plugin, and I've noticed a couple of issues. The first, more pressing issue was that the "Add Label" menu did not appear when the button was pressed, so I was not able to actually assign any labels to containers to test the rest of the plugin. The "Remove Label" menu seemed to work, but without any labels assigned to a container, I could not confirm if it was still truly working (probably is since you didn't change those two menus.) The second (minor) issue, is that currently it is possible to press the "Dump Inventory" button when no container has been assigned the contMain label, meaning if someone were to do so, their whole inventory would simply disappear. I should be able to easily fix that with an if statement that checks if contMain is anything but 0, and maybe have a corner message appear to say that the inventory can't be dumped yet. The first issue is what I'm concerned about, and I'm sure there's a simple solution, but I need to go over your work to understand the process more, and I won't have time this weekend for that. Otherwise your work seems to be very organised and efficient, though I'm wondering if the quest script delay needs to be so short. I understand that the quest is no longer running all the time, but I don't see what improvement 0.01 seconds could possibly make, and am worried that it could have adverse effects on performance or stability. Then again, I don't know much about this, apart from reading delays below 0.1 seconds were not recommended. I was fine with the 10mm pistol model and junk icon for the label maker, but I'll think about alternatives. I don't think it really warrants any custom artwork, so vanilla assets should be fine. The whole equipped/hotkeyed thing should be possible for me to implement with GetEquippedItemRef and GetHotkeyItem, but I'm still not convinced it's worth the effort. I'll put it on the backburner. Anyway, if you have a chance to give another look at the main issue, that would be greatly appreciated, but I'll make an effort eventually to properly understand all your changes and do thorough testing to ensure I can maintain the plugin in the future. I only ever intended this to be my own undertaking, but you've really gone above and beyond, so much so that I'm a little bewildered. Of course I greatly appreciate it, but it'll take some time for me to catch up. Thank you!

Yup, that's pretty much it. The ability to place/remove labels while sneaking should only be possible while the "Label Maker" item is in your inventory. The buttons for adding a specific label should only appear if the existence of that label on the currently selected container is not true, and the opposite for the "remove label" buttons. The button for "Remove All Labels from All Containers" would only appear if at least one of any of the labels has already been assigned. Those are the QoL features I wanted for a nice, clutter-free UX. Technically the primary function of the mod is simply the sorting, but I wanted my version to go beyond the original, which was a little too bare to fit in with the incredibly polished mods we have these days.

At this point, I'm just glad we have a fully functional version. Since we've already got a bit of NVSE script in there, may as well make as much use of it as possible, but at least it's not necessary. As for TTW, I've only just begun looking into it, so I don't really know exactly what's happening with 3.0, but I've heard that it breaks compatibility with pretty much all existing TTW mods. I think fortunately for us, New Vegas mods that are mainly scripts pretty much all worked with TTW out-of-the-box, so there shouldn't be any issues with UIS and MAS. All I think I'd need to do is give the Label maker and Mobile Auto-sorter items to a FO3 vendor so that people starting in the capital wasteland can make use of them. Probably would give them to Moira to match Chet.

Hooray! It works! You see, I never would have guessed that OnActivate had such a limitation. It seems so clear to me now, but i really didn't think there was anything wrong what I was doing before. I'm using your MessageBoxExAlt scripts now, so if you still want to try and translate the Label Maker menu, go ahead. I think I understand how it works now, but my brain needs a rest for a while before I try and do it myself. To be clear, I no longer need the the Message that related to my original Auto-sorter menu? Also, if I want to emulate the conditions I had for each button in the Label maker menu, can I simply use "if + condition" statements before the "if iButton" statements? And finally, does each sub menu need a separate callbacks script, or can related submenus be organised into the same script? Apart from that, the one area I'm looking into is making the Auto-sorter dump only non-equipped (and maybe non-hotkeyed) items, rather than absolutely everything. To be honest, I like how it is now, because I don't intend the auto-sorter to be a "send to home base/infinite storage" machine when out in the wasteland, but I wouldn't hold it against someone if they did want that functionality. It could be nice to have the option. In the future I'll look back into extra categories, and also TTW support. TTW seems interesting but the upcoming 3.0 is apparently gonna shake existing mods up big time. Thank you so much for all your help! In case there was any doubt, of course you're also getting co-author credit for the plugin once I release it (or however this site handles collaborations). Couldn't have done it without you.

Thank you so much for the model! It works great! As far as the item dump though, I still can't get it working. I've tried changed the "set gszQ.dump to 1" to "let gszQ.dump := 1", but in game the RemoveAllItems function still doesn't happen, and no error message is printed to the console. That gets me thinking that maybe the issue has more to do with the RemoveAllItems function, although it used to work back when I just had an activation of a container scripted to run that function. Now, I don't quite understand calling references, or more specifically, when the game decides what the calling reference currently is, but could the problem be that RemoveAllItems only works when activated from the context of an actual container? I don't quite know what I'm trying to say since I don't have a proper grasp on the lingo, but I'm wondering if the function only works if a container is currently active. It's quite annoying that my final feature before cleaning up and prepping for release, also happens to be my most perplexing yet. The logic seems to hold up, yet it inexplicably doesn't work, so I feel like the problem lies with a peculiarity of the engine. I'll link a download for the current state of the mod. Could you give it a test and take a look in case the issue is only happening to me? Also, all the messages are there, so you can take a look a those too, if you like. To add/remove labels to containers, you must purchase the Label Maker from Chet in Goodsprings, then activate any container while sneaking. The Mobile Auto-Sorter is also purchased from Chet. You must drop it and then activate it to make it an activator, then activating it while standing will bring up the dump option, and activating while sneaking will pick it back up. Load order probably doesn't matter much, but I have it over UIS, and both fairly low down, after any mods that add new items. I don't want to impose a bunch of work on you, so take your time. I'm in no hurry. https://ufile.io/fdtmg

Oh, thank you! I wasn't totally decided on which model to use, but I don't want you to have to do every single one just so I can try them all out, so the briefcase detonator is what I'll settle on. The file path is "Clutter\BriefcaseDetonator\BriefcaseDetonator01.NIF". As for the scripts, this script is attached to the activator: https://pastebin.com/AZW0j5Zw And this one is the current iteration of the quest script: https://pastebin.com/pSFvJDws I only commented on the current issue, which is the "dump" section closer to the bottom. I can properly comment on the menu section later if you'd like some context for translating it to the NVSE version, I'm just tired now. This issue is confusing me because it's using functions I've already successfully used in other areas. The only things that are different now are that the logic is initiated in an object script, within an OnActivate block, neither of which I have any prior experience with. I haven't done more rigorous tests yet, because I had tried a few different ways of scripting the same logic with different functions in different scripts, but never got any different results. One source I found online was a thread that seemed to imply that there was an issue with this whole object script/quest script thing, but I couldn't find any documentation to elaborate on that. I need to get back to it once I'm more refreshed.

Ok, so I ran into a couple of snags. One is simple but annoying, the other is also probably simple, but I can't figure out. The first one is that as far as I can tell, all the models for containers lack any havok data, which is an issue for me because I want the Dumping item to be carryable in my inventory, then when dropped I need to place it wherever I want, then when activated, it is replaced by an activator in the exact same spot. All that scripting works fine, but when using a container model without any havok data the item will just float in midair when dropped. This thread here seems to explain a solution to this problem, and has a usable container model with havok data, but I'd rather not go through the process of editing a model myself if somebody has already updated a collection of models I could use. I just wanted to ask if you knew about any such resource. The second issue I'm having is that the OnActivate object script attached to the Activator doesn't seem to be changing variables in the quest script like I want it to. For example, the object script has "set gszQ.dump to 1" ("short dump" is in the quest script), and the quest script has an "if dump == 1" chain, but it never actually runs. All the spelling and syntax is correct, and there are no compiling errors, so I wonder if there's an inherent issue with changing quest variables from an object script. Once these two snags are fixed, the whole mod should be ready to go, though I'll share the menu script with you in case you can help NVSE-ify it.

What I thought was causing the issue was that some of the perk entries had conditions that would cause or prevent them from appearing depending on the results of the check that was initiated at theoretically the same time in a perk entry. Anyway, doesn't matter at this point because I rewrote the whole system to use the old message menu system (I didn't know about the new kind), and still I got crashes with Run Immediately flags, even if there was nothing that would seem to conflict with the ordering, and despite trying various quest script delays. Fortunately, the new setup no longer requires Run Immediately anyway, so it's a non-issue. I'm happy to say that my menu system is working perfectly, though it's probably a inefficient in a few ways that I'll look into in the future. I checked out the MessageBoxExAlt you linked, but I don't quite understand the formatting, or how I would translate the logic I currently have to the different format. Would it really be worth trying to update the menus for any performance gain? I'm not noticing any issues with what I have now, yet. At least the mod is still technically functional without NVSE, and is even more advanced than the original, even if someone doesn't use UIS. Since the old menu system has the button limit, I would need to switch to the NVSE alternative if I get around to adding UIS's extra categories, but that isn't really a priority anymore. Right now, my next step is to make an efficient and elegant way of dumping your inventory into only the sorting container. I'm thinking about making a special item that can be dropped, then activated to turn it into an immovable object, and then can be activated again to automatically move all items into the assigned sorting container. Seems like it should be easier than what I've done today with the menu system. After that it should be totally ready for release!

Upon further research, I think the blocktype "OnActivate" may be the solution to my problems, and GetActionRef to check the container ID. If it works with GetSelf, I may be able to run the check script within a different block from the Gamemode stuff, and effectively get the Run Immediately behaviour I wanted, perhaps even more efficiently. I'll have to make time to try that during the week. In the meantime, the simple version seems to be working well. UIS seems to be having some other wonky behaviours, in that now Aid and Misc items don't have their prefixes until after a reboot. Probably has something to do with my load order, but I'm inclined to look into it in case it's a problem for everyone I can help solve.

The script delay was originally set to default, which I believe is 5 seconds, which explains why the dump inventory script sometimes took a few seconds to happen, but after you mentioned it I tried changing the delay to 0.1 seconds. Unfortunately, that hasn't solved anything, which is probably fine because I don't really want the delay to be that short anyway. The check script is within the Gamemode blocktype, but is supposed to only run when check == 1, which is set when the "Check" perk entry is activate (which needs to be on activation of any container). After doing the check, the same script then sets check back to 0. I don't know how the game processes these kinds of scripts within different blocktypes. Only one quest script is involved in doing the check, although the perk entry "Check" runs both "set gszQ.rTemp to GetSelf" and "set gszQ.check to 1" in order to to initiate the check script. A possible conflict may be that most of the other perk entries (which are not set to run immediately) also run a script involving setting a quest variable to GetSelf, although I don't see how that can cause the game to hang, unless it's an odd engine peculiarity. I'm thinking that my idea of delaying the MAS functions is probably the solution, or at least the easiest. I'll need to do research about creating menus, though they seem quite difficult for such a small feature of the mod. A dialogue tree might be simpler as I can edit it with the Geck interface, but I don't yet know if there's any limitation to them (can they be activated from a container, or do they have to be tied to an NPC?) Before that, I suppose I should also do a test perk with the rest of MAS disabled, just to see if the Run Immediately flag is only broken in that context, or if another mod also using the flag is conflicting with it. I can't think of any of my installed plugins that may be using it. I was expecting this to be the simplest feature to add, but it seems that it may be the most complex, so I'll probably first release a more simple version of the plugin, with all the existing categories, and perhaps "Remove All Categories from All Containers" and "Dump Inventory" entries that don't require the check script for now. It won't be fancy but at least it'll be functional and improved over the original mod. Funnily enough, I've recently noticed an issue with UIS where some ammo items are not being renamed with prefixes. I need to figure out what's causing that issue, though it's more likely a different mod conflicting with it. Edit: Mojave Arsenal was causing that issue. Reinstalling it and placing it high in LO fixed it.

Well, I was able to test the logic by unchecking the run immediately box for the "check" perk entry. That way I could see that my script is otherwise working fine, but without the script running immediately, it ruins the whole automated aspect of what I was trying to accomplish. I've noticed with the "dump" perk entry, which starts a script in the same way, but without running immediately, that the script usually has a delay, anywhere from a fraction of a second to a few seconds. I wonder if trying to run the script immediately upon activation of the container is conflicting with all the other things that are meant to happen upon activation. Could the solution be to somehow reorganise the perk so that all the functions of the Mobile Auto-Sorter are placed in a second menu or dialogue tree that can only be reached after the check script has already run? As for NVSE, I'm only finding it confusing because without having memorised which functions are vanilla or NVSE, and which functions are effectively equivalent except for slightly different usages (like ListAddForm vs AddFormToFormList), I just don't know yet what is or isn't possible. NVSE just makes the list of functions longer so I have more documentation to read. Anyway, I'm fine with NVSE, and I'll definitely look into using it more effectively. For example, I'm thinking that my list of integers could be replaced by an array, but I don't know yet it a perk entry condition can be set to search for a value in an array. Also, I'm having trouble using commands in the console during gameplay. Are the expressions supposed to be the same as when writing scripts in the Geck? I can't seem to figure out how to actually be told what the current value of a variable is. Say, if my script was supposed to run "set gszQ.contMain to GetSelf", how can I ask the game to return the value of "contMain" while in game, and would it show me the actual form ID of the referenced container, or would I just receive "GetSelf" as the value?

I'm using the powerup NVSE plugin and launching with the nvse_loader.exe -editor shortcut. I didn't install any Powerup files except the NVSE plugin dll, should I have still installed the Data folder files too? From what I could tell, the only NVSE functions you added would only run if Universal Item Sorter.esp was detected, which recquires NVSE anyways. I assumed that if that plugin wasn't detected, the NVSE functions would effectively be dormant, and the rest of the script could run without need for NVSE. I'm really only trying to work around this limitation because the original mod was intended to work without NVSE. If push comes to shove, I'll drop that condition and go ahead with NVSE for efficiency. As for the confusion, I only mean NVSE adds to it because it adds a whole bunch of new functions to keep track of, with different syntax to the vanilla functions, and different methods of doing the same functions as vanilla. It's just confusing because I don't know what's actually possible, and what the limitations are. I'll have to get used to it. This is the current state of the quest script: https://pastebin.com/VqeifQW6 Don't mind the sloppiness for now, I was just testing out a bunch of methods to see if I could get the logic working, before trying to clean it up. I tried to comment on the new parts I added, but I don't know how I can best describe the context of the perk, so that you can see what's actually going on. To reiterate, the crashing only seems to happen if the perk entry script that is set to run immediately is invoked. Due to this, I haven't been able to actually see if the rest of my logic holds up.