Patching base form in memory via NVSE plugin?

[FiftyTifty]

Got the example plugin loading up fine in VS 2019, so I've been trying to find a way to access a form in memory, with it's FormID and EDID already being known. What I've got in mind, is the GetHit ImageSpaceModifier. But as far as I can tell, there's no readily available function that allows that. Is there any way to get a pointer to a record, or am I simply out of luck and have to patch memory addresses manually with offsets for every possible FalloutNV.exe version?

Edited August 30, 2019 by FiftyTifty

[Purr4me]

Got the example plugin loading up fine in VS 2019, so I've been trying to find a way to access a form in memory, with it's FormID and EDID already being known. What I've got in mind, is the GetHit ImageSpaceModifier. But as far as I can tell, there's no readily available function that allows that. Is there any way to get a pointer to a record, or am I simply out of luck and have to patch memory addresses manually with offsets for every possible FalloutNV.exe version?

the only thing that comes to mind is not the games assets ID's but the executable assets internally.

 

"NoZone"

[lStewieAl]

You can use LookupFormByID, thereâs an example of it in the JIP LN NVSE source.

 

Only one FalloutNV.exe version is supported by most NVSE plugins, the non-noGore 1.4.0.525

[FiftyTifty]

You can use LookupFormByID, thereâs an example of it in the JIP LN NVSE source.

 

Only one FalloutNV.exe version is supported by most NVSE plugins, the non-noGore 1.4.0.525

 

Ah, that looks like it should be perfect. And it's good that it NVSE only cares about the release versions, and can work with executables modified by the FNV4GB patcher. Good, good.

 

Now I tried to build my rudimentary plugin that just outputs a message. It compiles fine, but the external code doesn't; it throws a huge number of errors: https://pastebin.com/raw/xgJUAPjP

 

All I've done, is opened the .sln file with Visual Studio 2019, which updated the project files, and tried to compile. Thought it might be a problem with my barebones .cpp file, so I tried compiling the unmodified example plugin. Nada, it throws the exact same errors. Any idea how I get around this?

[lStewieAl]

> which updated the project files, and tried to compile.

 

You need the 2008 toolset to compile the example, if you upgrade it youâll need to fix those errors yourself - string used to be a member of std namespace but was changed not to be in later toolsets.

[FiftyTifty]

> which updated the project files, and tried to compile.

 

You need the 2008 toolset to compile the example, if you upgrade it youâll need to fix those errors yourself - string used to be a member of std namespace but was changed not to be in later toolsets.

 

Aye, I tried to use the 2019 toolset, but the errors are a complete mess. A few of them are easily fixed, but the others just throw the same error even when fixed by following the instructions of the more seasoned C++ programmers: https://social.msdn.microsoft.com/Forums/vstudio/en-US/89091139-8df5-4176-bc51-d5a5dac94c04/opening-vs-2008-solution-with-vs-2019-breaks-project39s-libraries?forum=visualstudiogeneral

 

The 2013 toolset, the one you use for your plugins, doesn't throw any errors like that. It just throws a single error (https://pastebin.com/raw/Q6s4rk58), which is due to the destination path being local rather than absolute. Need to figure out why that's happening.

[lStewieAl]

My project has a post build event that copies the dll to the nvse plugins folder, you can edit or remove it in the Build Events option of Solution properties.

[FiftyTifty]

My project has a post build event that copies the dll to the nvse plugins folder, you can edit or remove it in the Build Events option of Solution properties.

 

Aye it turns out that it does copy successfully, it just throws that error for some odd reason. The error history doesn't take me to the part of the project that's the problem, but the source files of VC++ itself. So I can't seem to fix that.

[c6dev]

You got the second path wrong, it should be complete with C:\Program Files\.. etc.

Edited September 8, 2019 by TrueCourierSix

[FiftyTifty]

You got the second path wrong, it should be complete with C:\Program Files\.. etc.

 

There is no option for that to be changed. Changing the build directory works fine, but that second path is called somewhere for no reason, and is unchangeable, as far as I can tell.