Adding compatibility between two sorting mods

[FriedStephen]

Okay, so I've been working slowly on the mod for a few days now, trying to learn as much as I can in my spare time, but the Geck is frustratingly unintuitive at times, and it doesn't help that NVSE adds the the confusion. Anyway, the mod itself reached my initial goal of simply making MAS more compatible with UIS, but now that I have permission to release the full mod with my alterations, I feel I should take it a step further and make a few more QoL tweaks.

 

My goal for release is to add the option to dump your entire inventory on activate, but only on the main sorting container, and also to add the ability to remove any sorting categories from a container. To accomplish this, I've tried to make a script that will check any container on activation to see if it is one of the "assigned containers". If not, then the option to assign a category should show as normal. If the activated container does already one or more assigned categories, then the option to "remove category" will instead be available. Similarly, if the activated container is detected to be the main sorting container, then the option to "dump inventory" should show.

 

The scripts I've tried so far have resulted in crashing whenever I try to activate a container. The original mod, and my current work, uses perk entries and conditions to run scripts that change variables in the quest script (I guess that's standard procedure), but I seem to be having trouble specifically with the entry that is set to "run immediately". Is there perhaps a known bug with this option? I have noticed that upon restarting the Geck and checking the entry, the "run immediately" option is unchecked again.

 

I would very much love if someone could review what I have already and point out where my issue is, because I simply don't know where to start. One thing I should mention is that, at least for this version, I'd like these additions to be free of NVSE scripts, as I'd like this version to be backwards compatible with vanilla. If this version works out, the following version will remove backwards compatibility and utilise UIS to add many more categories, and hopefully NVSE optimised code.

[EPDGaffney]

Glad to see you doing your best. No better way to learn than getting right into it.

 

Trouble with your request is that UIS requires JIP LN, which requires NVSE, and everything I added to the MAS script requires NVSE or JIP LN as well.

 

How is NVSE adding to the confusion?

 

Are you using GECK PowerUp? For scripting, you need it. Get the fork:

https://www.nexusmods.com/newvegas/mods/41642

 

Let me see your scripts, ideally with some idea of what calls each one and what you want it to do. For formatting, PasteBin is preferred.

[FriedStephen]

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.

[EPDGaffney]

What happens when the box isn't ticked? People do seem to get crashes with that. I'm after testing a simple perk script that allows me add 500 Legion ears any time I open a container and it works. But I didn't tick that box.

 

I understand a little better what you meant about NVSE. Frankly, everyone that uses any mods should be using JIP LN for its fixes, and anyone playing this game should get NVAC, which requires NVSE. Besides that, I find using NVSE and its plug-ins less confusing because I know that any function I find documentation for on the wiki will be usable for me. The only other thing left is the 'different way of doing things' you mentioned. Do you mean Let? That's a choice. It isn't needed, but it's better, because when it fails, it prints an error in the console. And it's faster:

Set iTreasureFound to iTreasureFound + 1

VS

Let iTreasureFound += 1

You can keep using Set if you want, though, for the majority of functions anyhow.

 

You can set that variable in the console if you like, just to test, if the perk still doesn't work.

[FriedStephen]

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?

[EPDGaffney]

I don't completely understand the system and how all these scripts interact with each other. All I know is that everyone uses GameMode scripts for this type of thing and it doesn't seem logical to me. It seems as if there should be an event-based system and that it should be feasible to implement one, so the whole GameMode-based system is a little foreign to me.

 

Is this script running at all times?

 

What is its quest delay?

 

What are all the things that are meant to happen immediately when you activate a container?

 

How many scripts communicate with each other for this to work and what are they?

 

Your approach to a solution by delaying certain functions until others have run is conventional and may be the solution, but I need you to answer the previous questions for me to give a more definitive answer.

 

The other thing that occurred to me is that the quest delay here may simply be too long.

 

When I made my test perk, it absolutely ran immediately despite not setting that flag. Are other things using that flag? Perhaps having several things share that flag causes crashes and perhaps that flag delays Entry Point Activate perks that don't use the flag unless unless no other Entry Point Activate perks exist with the same conditions.

 

Most of the newer functions added by NVSE and its plug-ins that seem similar to vanilla functions are just improvements, so you can still use the vanilla ones and if you find yourself thinking, I really wish this function accounted for this other thing that seems obvious, you can check the function list I linked earlier in hopes that the function has been updated in the past eight years.

 

I don't think perks can check arrays but I'm not positive. I would leave it as is if it's already working.

 

Right, yeah, to set a variable in a quest via console (I hope you're sitting down for this), you need to put quotes round the quest form ID. For example, say MyQuest has a form ID of 01008f72, and it has a variable called bDoOnce that you wish to flip, you would enter:

Set "01008f72".bDoOnce to 1

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?

Not all functions will return printed results in the console. Can't remember does GetSelf do it or not. But you can use SQV with your quest forms and SV with anything that has an object script.

 

The other way to check any variable is to add a Print check in your script, so for example:

Let contMain := GetSelf
Print "contMain: " + $contMain

[FriedStephen]

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.

Edited May 5, 2018 by FriedStephen

[FriedStephen]

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.

Edited May 5, 2018 by FriedStephen

[EPDGaffney]

So, to clarify, everything works as you wish it to do right now, but it doesn't happen quickly enough?

 

OnActivate in what way? An event handler? You could do that, but I think the best way would be to have the entire mod's worth of scripting (or nearly the entire mod's worth) contained in a fast-running quest script that runs only during the sorting, as in, it's activated by the perk entry point menu option and then when it's done with what it needs to do, it stops itself.

 

The perk entry point is working perfectly for me, so we need to see what's happening with your specific arrangement.

 

What were the results of your testing?

 

With the quest delay set to .1, try testing this and immediately after pressing the button from the perk, check the quest variables to see is the problem with them not being set quickly enough or is it something after that.

 

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 confused about that. Could you describe for me exactly what is supposed to be happening? These scripts aren't supposed to run unless you click the button that runs them, or at least, that's my understanding (I've never needed to use this type of perk before, so I know only what I've read over the years).

 

I'll need to do research about creating menus, though they seem quite difficult for such a small feature of the mod.

You mean these message box menus? They're actually a lot of fun in my opinion. Use MessageBoxExAlt for the easiest time of it (and by far the best performance):

https://geckwiki.com/index.php/MessageBoxExAlt

 

GetActionRef refers to the thing doing the activating, in most cases the player. OnActivate is a blocktype that is bugged in that 'OnActivate Player' does not limit the script to running only when the calling reference is activated by the player, but will instead run when anyone activates it, so we just use:

Begin OnActivate
    If GetActionRef == Player
    ; Destroy the world, &c.
    EndIf
End

I tend to change out that line for If IsActionRef Player but they are equivalent (IsActionRef returns 1 or 0, and GetActionRef returns the actual reference).

 

GetSelf does work in an OnActivate block, but you can't add that to every single container; you'd need to use an event handler. It should work there as well, though.

[FriedStephen]

 

I'm confused about that. Could you describe for me exactly what is supposed to be happening? These scripts aren't supposed to run unless you click the button that runs them, or at least, that's my understanding (I've never needed to use this type of perk before, so I know only what I've read over the years).

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!