NVSE Extender

[zippy57]

Unless something has changed quite recently, that's not correct. I have made FOMM archives containing DLL files multiple times in the past and they have installed fine.

[annika]

At least with NMM dll files seem to install correctly. I tried with New Vegas Stutter Remover, and it's dll installed and uninstalled correctly.

[KainsChylde]

NVSE updated to 2.1 today. Dunno if that will change how this works or not, testing now.

[ashmedai]

I'm getting a CTD on calling NX_IsUsingSkeleton. It is because of the 'dummy' argument passed to strtok_s. I can submit a subversion patch , if you prefer.

[prideslayer]

Hmmm.. the function worked for me in the past, it's been a while since I tried it. Are you sure it's not due to some other issue?

 

Can submit via svn or just copy me here with a patch (in a spoiler/code block).

[prideslayer]

Unless something has changed quite recently' date=' that's not correct. I have made FOMM archives containing DLL files multiple times in the past and they have installed fine.

[/quote']

 

FOMM has always ignored files not in its 'authorized' files list, and specifically prohibits .dll, .exe, and .com files from the 'fomod ready' zip installer. If you specifically copy those files with a real fomod .cs script, I think it will work though I haven't tested.

 

Quickedit: I might have been mistaken about this, I don't see it in the source now, but I was pretty positive it was there. I'll stuff the extender into sexouts fomod and see if it installs correctly or not; I seem to remember those file types and some others being ignored..

[prideslayer]

Actually, sorry, I take that back. It's installing outside the data directory that FOMM can't do -- so it can't install NVSE itself since that needs to go in the directory with the .exe.

 

I stuffed the .dll in the right place in the core fomod and it installs fine, so it'll be in the next release and marked as 'included' in the requirements section.

[ashmedai]

Hmmm.. the function worked for me in the past' date=' it's been a while since I tried it. Are you sure it's not due to some other issue?

 

Can submit via svn or just copy me here with a patch (in a spoiler/code block).

[/quote']

 

I double checked, and it crashes every time I enter player.Nx_IsUsingSkeleton "_male" on the console. Once I apply the patch, it works fine. Here is the patch in the spoiler block. Basically, just changed dummy from ptr-to-ptr to ref-to-ptr

 

 

 

Index: nvse_extender.cpp

===================================================================

--- nvse_extender.cpp (revision 8)

+++ nvse_extender.cpp (working copy)

@@ -76,7 +76,7 @@

char skelName[512];

char actorModel[512];

char *pch = NULL;

- char **dummy = NULL;

+ char *dummy = NULL;

char **parts = NULL;

int cnt = 0;

int idx;

@@ -91,13 +91,13 @@

if (pActor)

{

strcpy_s(actorModel, 512, pActor->model.GetPath());

- pch = strtok_s(actorModel, "/\\", dummy);

+ pch = strtok_s(actorModel, "/\\", &dummy);

while (NULL != pch)

{

parts = (char **) realloc(parts, (cnt + 1) * (sizeof(char*)));

parts[cnt] = pch;

cnt++;

- pch = strtok_s(NULL, "/\\", dummy);

+ pch = strtok_s(NULL, "/\\", &dummy);

}

 

for (idx = 0; idx < cnt; idx++)

 

 

[prideslayer]

Hmm that's odd, thanks for the patch though. I'll build and test and if it's ok, new release will be forthcoming.

[prideslayer]

V6 in OP with ashmedai's patch. Tested out fine.

 

Ashmedai, how would you feel about digging into the NVSE source itself a bit?

[ashmedai]

V6 in OP with ashmedai's patch. Tested out fine.

 

Ashmedai' date=' how would you feel about digging into the NVSE source itself a bit?

[/quote']

 

Actually, I was just reading some of the NVSE source. I'm getting sexout to work on FO3, and I'm looking at what is in NVSE that is not in FOSE, and if it is needed, looking at what it takes to add it to FOSE.

[prideslayer]

Ahh well there are things in OBSE that aren't in FOSE or NVSE, so look there too. I am particularly interested in getting the saveload hooks working in NVSE somehow. Ideally if this could be done entirely in the extender (by patching whatever in the exe that nvse itself patches) that would be perfect.. but if it can't be done except in nvse itself, I'm about to give up waiting for the silverlock team to do it.

 

So, if you're bored.. saveload hooks in NVSE would be monumental. I don't care about the stupid save/load in the normal savegame format like obse does, I just want notified when a new game, save, or load happens -- and if it's a save or load, which file.

[ashmedai]

sure, I'll take a look as I rummage through the source. So just the name of the file, nothing about the contents?

[prideslayer]

yeah, that would be enough for me to save a coincident file of my own with current state, load it back up, and know when I need to clear.

[ashmedai]

yeah' date=' that would be enough for me to save a coincident file of my own with current state, load it back up, and know when I need to clear.

[/quote']

 

I see. You want to replicate the OBSE plugin listener, it just happens you want the LoadGame event, you don't care about the serialization callbacks, because you want to implement your own. That makes it far simpler to implement.

 

It looks like the silverlock guys did the hard part already (finding the load/save game call and return addresses, the asm to inject), and it seems to be working. I have a few spare man-hours over the next few days to build a prototype of the dispatcher. I'll put the code on github.

[ashmedai]

yeah' date=' that would be enough for me to save a coincident file of my own with current state, load it back up, and know when I need to clear.

[/quote']

 

I see. You want to replicate the OBSE plugin listener, it just happens you want the LoadGame event. You don't care about the serialization callbacks, because you want to implement your own. That makes it far simpler to implement.

 

It looks like the silverlock guys did the hard part already (finding the load/save game call and return addresses, the asm to inject). The hook works. What is missing is the listener registration and message dispatching.

 

I have a few spare man-hours over the next few days to build a prototype to test with. I'll try to override the hook from the plugin, as it is faster to implement. I'll put the code on github.

[Halstrom]

NVSE updated to 2.1 today. Dunno if that will change how this works or not' date=' testing now.[/quote']

Where did you find that? I can only find NVSE 2beta12 which has been around a while I think.

[KainsChylde]

Just double checked and you're right. I must have misread something. I don't even remember posting that.

[ashmedai]

yeah' date=' that would be enough for me to save a coincident file of my own with current state, load it back up, and know when I need to clear.

[/quote']

 

I see. You want to replicate the OBSE plugin listener, it just happens you want the LoadGame event. You don't care about the serialization callbacks, because you want to implement your own. That makes it far simpler to implement.

 

It looks like the silverlock guys did the hard part already (finding the load/save game call and return addresses, the asm to inject). The hook works. What is missing is the listener registration and message dispatching.

 

I have a few spare man-hours over the next few days to build a prototype to test with. I'll try to override the hook from the plugin, as it is faster to implement. I'll put the code on github.

 

Actually, doing it on the plugin will not work: NVSE patches the hook AFTER the plugins are initialized.

 

Only way is to do it in nvse, and add the missing logic to register listeners and dispatch messages.

[prideslayer]

Eternal gratitude ashmedai if you can work something out, and of course double extra bonus points if it can be done without changing the NVSE source. I don't really care if the extender has to hook FONV itself. The silverlock guys released source (obviously) but it has no license and they specifically ask that nobody release binaries so I'd like to avoid doing so if at all possible.

[ashmedai]

The plugin can't override the hook. Plugin initialization is done before nvse patches the load save game hook.

 

I don't think there is a way around changing nvse. Either remove the hook or at least it move it under _DEBUG like the other ones, or add the registration/dispatching logic.

 

nvse has no license (they use the legal disclaimer from the MIT license, but they don't use it?), and their readme is not clear about contributions.

 

We can probably:

 

- ask them to remove the unimplemented hook from nvse, at least until they implement message dispatching. That way the hook can be patched in the plugin.

 

- ask them if they would take a contribution that implements the message dispatching

 

In the meantime we can make the changes to the nvse source, and make a new nvse_1_4.dll available for testing the functionality you want to implement.

 

Silverlock are probably busy with skyrim, I would think they would be open to contributions for fallout, particularly if tested by a number of people.

[prideslayer]

Well patching for the dispatching would probably be acceptable to them. When I started work on the extender I had to get ahold of them for an opcode range, and while it took some time, Ian did eventually respond and get me what I needed; he indicated some interest in incorporating some of the extender features into the NVSE core.

 

I asked him about the saveload hooks and he said they were unimplemented due to lack of demand/interest, and said it wouldn't be too difficult but as you said, they were busy with skyrim. So since it's been out a while now I contacted him again a week or so ago and, as yet, have not heard back.

 

So if it's the only way, a modified NVSE is fine by me. Can just test it amongst ourselves, submit the patch to them, and give them some time to make a new release.

[ashmedai]

np, I'll start adding the registration/dispatching. It would not be too difficult to do. I'll put a repo on github with the modified nvse and a sample plugin that registers for load game events.

[jaam]

The plugin can't override the hook. Plugin initialization is done before nvse patches the load save game hook.

 

I don't think there is a way around changing nvse. Either remove the hook or at least it move it under _DEBUG like the other ones' date=' or add the registration/dispatching logic.

 

nvse has no license (they use the legal disclaimer from the MIT license, but they don't use it?), and their readme is not clear about contributions.

 

We can probably:

 

- ask them to remove the unimplemented hook from nvse, at least until they implement message dispatching. That way the hook can be patched in the plugin.

 

- ask them if they would take a contribution that implements the message dispatching

 

In the meantime we can make the changes to the nvse source, and make a new nvse_1_4.dll available for testing the functionality you want to implement.

 

Silverlock are probably busy with skyrim, I would think they would be open to contributions for fallout, particularly if tested by a number of people.

[/quote']

 

If you can provide them with proper contribution they won't hesitate to take it, given ianpatt has the time to incorporate and publish. Just don't forget NVSE supports nogore version now and getting offsets for that version is pretty dificult.

[ashmedai]

Fortunately, the addresses for load, save, etc. are already in nvse for the ng version. The changes should work for ng, in theory.

 

BTW this will only work for the latest FNV version: 1.4.0.525.