NVSE Extender

[jaam]

Well 3beta2 is a *double* beta. It is marked "beta version" on the page' date=' while 2beta12 is marked "latest version".. but uh yeah.. you want the *actual* latest version, which is not called "latest version", but "beta version."

I'll just shut up now and thank Ian for getting our patches in there at all, no matter what he named it.

[/quote']

Well FOSE and OBSE did reach the "release" status, though there's always an active beta for both.

[KainsChylde]

Looks like we need to ignore "beta" and just stick with "Get the LATEST version of NVSE".

[prideslayer]

Looks like we need to ignore "beta" and just stick with "Get the LATEST version of NVSE".

This is the problem. If you download the one that on the page says "latest version"' date=' you'll get the [i']old, wrong version (2beta12).

I will add an NVSE version check to sexout, though that will still crash the game if NVSE isn't present at all.

[KainsChylde]

The largest then? Yeesh, NVSE can be confusing.

[jaam]

Looks like we need to ignore "beta" and just stick with "Get the LATEST version of NVSE".

This is the problem. If you download the one that on the page says "latest version"' date=' you'll get the [i']old, wrong version (2beta12).

I will add an NVSE version check to sexout, though that will still crash the game if NVSE isn't present at all.

There is a mod/script on nexus to allow detecting NVSE without crashing: http://newvegas.nexusmods.com/mods/36600

It might help ?

[prideslayer]

Interesting. Will check it out.

[prideslayer]

Updated some out of date things in the OP (there may be more). There are a few things I'm working on in NX that I hope to have available in v12, whenever that happens.

- Check for v3+ of NVSE on load, or abort. (done)

- Functions to check the "can equip / can unequip" flag on equipped items.

- Texture swapping stuff.

- Cleanup of old NX savefiles. They currently just "build up" in the directory even when old saves are deleted or saved over. Don't sweat it, they're small.

- NX_IsInList list recursion.

- NX_IsSwimming / IsInWater for Halstrom. This one is proving to be a real pain.

- Animation swapping. Crawling in an ESM alone is being a real pain. I will investigate changing the animation files used for locomotion animations (which cannot be assigned in the geck, as they are not 'idle' animations) "in memory" for a particular actor.

[DoctaSax]

I was wondering if this could be made possible too:

for the next clothing eval, I was hoping to make it so that pressing a hotkey while hovering over a clothing item in your inventory detects the item in question. So that clothing eval is pretty much set in motion in the same way repair and weapon mod fires up, instead of making the player equip the item first.

I just tried to do this with GetCrossHairRef, but failed. Whether that is because GetCrossHairRef only works in GameMode, or whether it's a ref/base form thing, I don't know.

This is just a little try-out/what-if script of course, but it's how I'd like to set it up:

scn DSSCESSelectionScpt ; quest script

ref DSClothing

Begin MenuMode 1002 ; ie: inventory-only

if 1 == IsKeyPressed 18 ; just picked E as a hotkey for now
	set DSClothing to GetCrossHairRef
	printc "selected: %n" DSClothing
endif

End

The printc doesn't return a name, so nothing gets detected so far.

[prideslayer]

I believe it only works in game mode. When you mouse over things, before you click, they 'highlight' though right? There might be a way to tell what's highlighted..

[DoctaSax]

Yeah, they do. It's probably something in the inventory_menu.xml, but damifiknow what

I've looked at the code in it that kicks the repair menu into gear if you hover + press the repair button, but I have still no idea how they detect the form that's gonna be repaired.

Of course, geck code is all I know, which is sad. Also, if there's no way of doing this without altering the xml itself, I'd rather not do it at all due to all the possible UI incompatibilities.

[astymma]

Yeah' date=' they do. It's probably something in the inventory_menu.xml, but damifiknow what

I've looked at the code in it that kicks the repair menu into gear if you hover + press the repair button, but I have still no idea how they detect the form that's gonna be repaired.

Of course, geck code is all I know, which is sad. Also, if there's no way of doing this without altering the xml itself, I'd rather not do it at all due to all the possible UI incompatibilities.

[/quote']

Have you tried GetBaseObject on the ref before attempting printc on its name? Wouldn't surprise me if non base references don't have names, only their parent base objects...

[DoctaSax]

Have you tried GetBaseObject on the ref before attempting printc on its name? Wouldn't surprise me if non base references don't have names' date=' only their parent base objects...

[/quote']

Just tried to, but PowerUp gives me a warning that GBO needs a "specific reference in a quest script" & won't compile.

So, instead of returning the name with %n to figure out if the form is detected, I went with %i instead, to return a formid. All I got was 00000000, so it has to be the GetCrossHairRef function that's not working in menumode. (And just in case the %i parameter is bugged, which might well be the case, I made sure with equipitem & removeitem commands: nothing going on.)

Good thought though.

[astymma]

Odd would think it would be valid to have:

ref refTarget
ref refBase

set refTarget to GetCrosshairRef
if refTarget
    set refBase to refTarget.GetBaseObject
endif

if refBase
    printc "selected: %n" refBase
endif

[Halstrom]

NX_IsSwimming / IsInWater for Halstrom. This one is proving to be a real pain.

Don't sweat too much over it, it sounds like there was some reasoning behind why it wasn't an easy fix when they broke it

[DoctaSax]

Odd would think it would be valid to have:

Tried that too, figuring I messed up with the syntax using "GetBaseObject DSClothing" instead of "DSClothing.GetBaseObject" but still a no go.

[prideslayer]

I'm pretty sure it doesn't work in menumode guys. Being an NVSE function, can take a look at the source and maybe figure out why / create a replacement that does work in menu mode though.

[DoctaSax]

That would be great, pride

Having a slick interface for the system, now that all slots are up for eval, would make a big difference.

[prideslayer]

What exactly prevents you from doing something like a 'fake' terminal? Can terminal menus not be created dynamically? I've always wondered about that, and why MCM doesn't use them. Just as a fallback plan.. it may be easier for me to create functions to modify terminal contents via a script than to mess around with the inventory UI.

[DoctaSax]

What exactly prevents you from doing something like a 'fake' terminal? Can terminal menus not be created dynamically? I've always wondered about that' date=' and why MCM doesn't use them. Just as a fallback plan.. it may be easier for me to create functions to modify terminal contents via a script than to mess around with the inventory UI.

[/quote']

I don't think they can be. Some choices in a terminal can depend on conditions, but that's about it far as I can tell.

I could always follow sen4mi's example in doing the whole thing in MCM, but that too has you go out of the game & press a bunch of buttons (Equip the item/Esc/MCM/MCM sidebar/dropdown to pick the thing) just to get started first. Which isn't much simpler than equip/hotkey/2-3 messagebox menus to pick the thing. Just different.

Just "mouseover + hotkey straight from inventory" would be a lot more slick if you intend to process a bunch of items: no equipping, no picking anything from a list. The actual system itself might benefit from a terminal interface, but for the picking of the item you'd still have you go through a list of equipped items first.

Of course, if it's not doable, I'll have to go with one of the above. Just wishing & hoping it just might be (made) possible.

[prideslayer]

I don't think doing it in MCM is a terrible idea, except for all the clicking as you mentioned. However I do kind of like an MCM or Terminal system solely because it lets you manage the lists without having to have the stuff in your inventory.

I will look into the options and see what I can do, I want to do the terminal thing anyway for other reasons. On the one hand, I think in the geck that terminals can only display 'messages' and 'notes', but on the other, they can obviously be controlled by the engine with dynamic content as they are when hacking.

Secretly, I'd love to ditch MCM in favor of a terminal interface.

[prideslayer]

Well no real love on the GetCrosshairRef front unfortunately. It's just an internal engine call that NVSE is exposing, not an actual function within NVSE that I can examine. It's part of the "InterfaceManager" class which itself has some other potentially useful things that haven't yet been debugged/decoded by silverlock..

- FOPipboyManager

- activeTile

- cursor

- debugSelection

- A buttload of values of unknown purpose, as usual

There may be something there. I will investigate some of these values and see if anything reasonably obvious pops up when the mouse is hovered over different items in the inventory.

[DoctaSax]

Well, the advantage of just going from inventory is that it doesn't matter what esp/esm a clothing item comes from. No need for buildrefs or anything.

Terminals are tricky in terms of layout: you either pass a note, which can be as long as you want but has no buttons, or have a short welcome text with buttons. Especially the latter is very annoying to get right: buttons just disappear if the welcome text is too long. And a welcome text can persist to a subterminal, so the sub has to have its own or some of its buttons will disappear if it has more than its, ehm, dom. It's really rather restricted. Also, to go from one level to another, you basically pick a brand new terminal from a drop-down menu in the geck. To get dynamic stuff going would take some doing.

There may be something there.

Fingers crossed!

[prideslayer]

Oh I had no intention of building the menu in the GECK in the terminal, I know that's just as annoying as the damn books or MCM are to begin with. I was thinking more along the lines of some custom NX commands to add/remove/read/write terminal data dynamically, coupled with a menumode script to issue those commands. In this context your inventory would still be available, but you would also get access to things not in your inventory, no buildrefs required.

I'm really just trying to find a way "out from under" MCM because the general fragility of geck scripts coupled with the script size limit irritates the hell out of me. I've personally made four or five releases in the past where minor typos in scripts for MCM have completely boned MCM for every other mod, and I'm not alone there.

I really want a way to dynamically create menus with basic UI functionality for adding and removing items and subpages, and getting and setting values.

[DoctaSax]

Well, MCM is fragile indeed. If I read you right, you're generally looking for some sort of TerminalEX combined with a reliable form of creating, storing & retrieving strings & other data? Would be pretty powerful stuff.

[prideslayer]

Strings can already be stored in messages. It's not ideal/perfect, but at least it gets them out of the (limited) space available to a given script and allows reuse. So what I'm thinking of is something like this, which is a very rough sketch..

refTerminal1.NX_TermClear

refTerminal2 = refTerminal1.NX_TermAddSubmenu
refTerminal3 = refTerminal1.NX_TermAddSubmenu
refTerminal4 = refTerminal1.NX_TermAddSubmenu
refTerminal5 = refTerminal1.NX_TermAddSubmenu

refTerminal2.NX_TermAddItem (string, or message ref ID) (value)

Now I haven't thought deeply about this.. at all. It may make more sense to just define the terminal and all it's submenus and so on in an XML file or something like that and have an NX command to load it and build the menu. I'm really not clear on how I'd want to handle that TermAddItem thing. It needs to toss up a string/label that gets 'persistently' associated with a variable of some kind (NX var, quest var, something).

When the terminal is closed, somehow, all the settings inside it would then be applied.

Again.. really sort of brainstorming here, I have no idea how I'd actually implement this last bit. I do really like the idea of different 'pages' simply being other terminals, to allow basically infinite nesting and whatnot.