Wolfmark

Modify the RestoreHealthStimpak magic effect, attach a script and add the perk to player inside OnEffectStart event handler. Or you can add a new magic effect to Stimpak with a huge duration that adds the perk (see the Perk to Apply combo box). But I don't know if this works with Fire and Forget casting type.

Extra Item Info? https://www.nexusmods.com/fallout4/mods/32435

I don't think is possible to disable loot respawn and keep NPCs respawn. It is possible to disable both, but this requires a F4SE extension. The idea is that the respawn happens when a cell is reset. Theoretically you can increase the time between resets using iHoursToRespawnCell and iHoursToRespawnCellCleared settings. Setting these to ridiculously high values will disable most resets. Some locations will still be reset from some (radiant) quest scripts. The problem is that some locations (like Thicket Excavations or Mass Pike Interchange) are always reset due to a bug. This can't be fixed without a F4SE extension. A Cell belongs to a Location. Each Location has an Encounter Zone (you can find them in CK, the World Data section). Each Encounter Zone has a "Never Reset" flag, but also 2 properties: last load time and last unload time. For some locations the last unload time is not updated when the player leaves the location on foot. Strange, it is updated if the player leaves the location using a loading screen (fast travel, interior cell, player.moveto player etc...). Because of this bug such locations will be always reset when loaded. Note that setting the Never Reset flag to false for all Encounter Zones is not a solution. This will break some radiant quests because the LocationAllowsReset condition function will always return false => the quests won't start.

Follow my first 2-3 posts on this thread to setup Visual Studio and the F4SE solution. By default F4SE is build as a shared library (the result is a DLL) and for creating extensions it must be build as a static library (the result being a LIB file). Then add an existing extension for which you can find the source code and the Visual Studio project. There are few: Clipboard Resurrection, Extended Dialogue Interface, Active Effects on HUD, MCM etc... See if you can build it. Clipboard Resurrection requires changes to F4SE code, so you may skip it. Then remove all the code and keep only the F4SEPlugin_Query and F4SEPlugin_Load functions. These are the ones called by F4SE when it loads an extension. Each F4SE extension must export these 2 functions. Then start from here. There's no documentation, so download the source code for any F4SE extension you can find. Even SKSE source code (the project and existing extensions) is useful. Compiling an extension is easy, you don't need programming skills. Writing one is a different thing.

Some things about crosshair are hard-coded in HUDMenu.swf file. For example the default tick radius, which is 19 and there's no setting to change it...

The IPrefix.h from F4SE 0.6.17 version contains #include <string>. The IPrefix.h from F4SE 0.6.16 version doesn't contain the #include <string>. This is why you compiled without changes 0.6.17. Probably in Visual Studio 2012 (the one used by F4SE team) the <string> header is already included by other headers. And this is not true in Visual Studio 2019 (the version you're using) anymore. For older F4SE versions you have to add #include <xmmintrin.h> to BSSkin.h, but they fixed this in 0.6.14. Also you had to add #include <algorithm> to PapyrusObjects.h.

You're welcome :)

You can download Steamless binaries (see the Releases page). No need to compile that project :smile: The addresses from source code are actually offsets. The base address is detected at run-time to compute the real address in memory (base + offset). In IDA the base address for Fallout 4 executable is 0x140000000. This means that for 0x0040D970 offset the address in IDA is 0x14040D970, while for 0x058CEE98 offset the address is 0x1458CEE98. You can use the calculator to sum hex numbers, but is easier to remove a 0 from offset and to add 14 at the start. Some tips: 1. Use Text View. If you're using Graph View then right click somewhere in the window and choose Text View. 2. Go to Options => General and there's an option to set the number of opcode bytes. By default is 0, change this to 10, so you'll see the bytes for each instruction. 3. By default the functions are named sub_XXXXXXXXX, where XXXXXXXXX is their address. If you know what a function does you can rename it (right click on the name) so will be easier to recognize. For example I've renamed all the functions used by Clipboard to wmk_cp_Enable_Native, wmk_cp_Disable_Native, wmk_cp_EffectShaderPlay etc... 4. Use Jump => Jump to Address (G key) to jump to an address. 5. Use X while a symbol is selected to see from where it is referenced. You can download from here the executable from Fallout 1.10.98. And you should have one folder for each exe version. Create an IDA project for each and open both projects in the same time. Jump to same address in both and then compare the bytes / instructions. In this way you'll see if an address has changed. For example to find the new address for qword_145907F18 variable (the one that we had to change): 1. First change the name for all 5-6 functions in both projects (their address has not changed). 2. Go to 145907F18 address in the project for 1.10.98. You know that this is the address of that variable. 3. You'll find the symbol, rename it to wmk_cp_qword_145907F18 (or whatever). 4. Right click, Jump to xref to operand (or use X key) and you'll see that is used from Enable_Native (a function you renamed at step #1). 5. Go to that address (from where is used). 6. Then go to Enable_Natives in the project for 1.10.138. 7. Find the section of the code that looks like in 1.10.98 and you'll see the new variable => so you'll get the new address.

I don't know any tutorials. You don't really need to understand the assembler to verify that an address hasn't change (or to find the new address). I can give you more details, but this if you already unpacked the executable and created the IDA Project. It takes a lot of time to parse a 60MB executable. Is better to copy the EXE first in a separate folder, so all other files created by IDA will be placed there. Also is a smart idea to save the current F4 executable, so you can compare it with the new one (if the game will be updated again). But think if this is worth it, because it takes time, you don't know if the game will be updated again, maybe the signatures won't change etc...

Finally :smile: Ignore that warning, has nothing to do with Clipboard extension. Probably the code that generates that warning is not even included in the final DLL. Ask Struckur to make you admin on existing project, so you can upload new files. Or ask permission to upload a patch that contains only the updated DLL, so the users will have to download first the original mod. Remember to always release the source code too. When Fallout 4 updates you don't need to do again all the changes: 1. First you must compile the new F4SE as a static library (see my first message in this thread). 2. Then you must update the GameReferences.h file from the new F4SE to include the changes required by clipboard extension. Don't copy the old file, edit the new one, because it may contain other changes, modified addresses etc... 3. Then copy the clipboard project from old F4SE to the new F4SE (you don't have to create it again). Copy the folder, but only with vcxproj files + main.cpp and then use Add => Existing Project option to add the project (the copy, not the one from old F4SE) to the new solution. 4. Build the project. You also have to verify the addresses, but for this you'll need: 1. A tool named Steamless to remove the changes made by Steam to Fallout 4 executable. 2. The IDA Disassembler to disassemble the unpacked executable.

Looks good. Now all you have to do is to fix the code that verifies the run-time version (starting from line 3237): if (f4se->runtimeVersion != RUNTIME_VERSION_1_10_98) { UInt32 runtimeVersion = RUNTIME_VERSION_1_10_98; char buf[512]; sprintf_s(buf, "Clipboard\nExpected Version: %d.%d.%d.%d\nFound Version: %d.%d.%d.%d", GET_EXE_VERSION_MAJOR(runtimeVersion), GET_EXE_VERSION_MINOR(runtimeVersion), GET_EXE_VERSION_BUILD(runtimeVersion), GET_EXE_VERSION_SUB(runtimeVersion), GET_EXE_VERSION_MAJOR(f4se->runtimeVersion), GET_EXE_VERSION_MINOR(f4se->runtimeVersion), GET_EXE_VERSION_BUILD(f4se->runtimeVersion), GET_EXE_VERSION_SUB(f4se->runtimeVersion)); MessageBox(NULL, buf, "Game Version Error", MB_OK | MB_ICONEXCLAMATION); _FATALERROR("unsupported runtime version %08X", f4se->runtimeVersion); return false; } Replace RUNTIME_VERSION_1_10_98 (2 occurrences) with CURRENT_RELEASE_RUNTIME (which in F4SE 0.6.17 is RUNTIME_VERSION_1_10_138). Compile and test again. Should work (if the original version used to work).

Starting from your files (the clipboard-cpp-files.zip archive): 1. The C/C++ => Preprocessor => Preprocessor Definitions is invalid. I said "Add _CRT_SECURE_NO_WARNINGS to the list with preprocessor definitions", but you instead replaced the default ones with _CRT_SECURE_NO_WARNINGS. For Debug the setting should be: _DEBUG;CLIPBOARD_EXPORTS;_WINDOWS;_USRDLL;%(PreprocessorDefinitions);_CRT_SECURE_NO_WARNINGS For Release this setting should be: NDEBUG;CLIPBOARD_EXPORTS;_WINDOWS;_USRDLL;%(PreprocessorDefinitions);_CRT_SECURE_NO_WARNINGS 2. The C/C++ => Advanced => Forced Include File should be "common/IPrefix.h", not "common/IPrefix.h;%(ForcedIncludeFiles)" (without quotes). Or maybe Visual Studio 2019 adds the last part automatically. 3. Fix the bug in line 73. This is the line that causes the error 1114. Replace UInt32 nullHandle = *g_invalidRefHandle;with UInt32 nullHandle; // = *g_invalidRefHandle;and then edit F4SEPlugin_Query and change: // ### do not do anything else in this callback // ### only fill out PluginInfo and return true/false // supported runtime version with // ### do not do anything else in this callback // ### only fill out PluginInfo and return true/false nullHandle = *g_invalidRefHandle; // WMK // supported runtime version 4. The F4SEPlugin_Query and F4SEPlugin_Load are not exported by default (probably Struckur used a DEF file that was not uploaded on GitHub), so their signature must be fixed. Add __declspec(dllexport) at the start of the line: __declspec(dllexport) bool F4SEPlugin_Query(const F4SEInterface * f4se, PluginInfo * info) { // WMK __declspec(dllexport) bool F4SEPlugin_Load(const F4SEInterface * f4se){ // WMK That's all for now. Do the changes and then test the resulted DLL. Should complain about invalid Fallout 4 version. Then create another zip with the project's files (everything in project's folder + GameReferences.h file) and give me the link to verify that everything is ok. https://imgur.com/a/r0Xpyng

The addresses are OK, I've verified them. The code has a bug (line 73): a global variable from main.cpp (nullHandle) is initialized using the value of a global variable from another unit (g_invalidRefHandle). UInt32 nullHandle = *g_invalidRefHandle; The standard doesn't specify the order of initialization, so this depends on compiler (the version, the settings etc...). So it seems that nullHandle is initialized before g_invalidRefHandle => an exception occurs => the DLL cannot be loaded. Probably Struckur compiled with different settings or with a different Visual Studio version.

OK, I'm trying to find what is the problem...

Yes, that's the error. But I don't know the cause. The idea is that LoadLibrary call fails. And the error code is 1114, which means ERROR_DLL_INIT_FAILED. Is the original file (for 1.10.98), or the one you've built (for 1.10.138)? If is your file, try the original one, see if that can be loaded successfully (it still should fail, but with another error, because the F4 run-time is not the expected one). If is the original file then try your file.

Everything looks OK, except one little thing: the plugin verifies the game version and if is different than 1.10.98 then it displays "Game Version Error" message box and fails to load. So this must be changed. But the question is: why did you say that "No complaints about version or other error messages though." when this should actually be the first thing the plugin does (see line 3237 from main.cpp)? I assume the plugin is not enabled / loaded for some reason. Note that you don't need to repackage the entire thing whenever you compile the DLL. You only have to copy the new DLL in Data\F4SE\Plugins folder. And make sure that the old one is removed or doesn't have the DLL extension. So: 1. Install again the latest "official" release (the one for version 1.10.98). 2. Start the game and you should see "Game Version Error" message box. 3. Replace the old DLL with the new one. 4. Start the game again and you should still see "Game Version Error" message box. Currently it seems that the game simply doesn't load the DLL (for some reason). Maybe F4SE is not installed correctly ... I don't know. Verify My Games\Fallout4\F4SE for error messages. Upload the folder and post a link, so I can take a look. Then you'll need to fix the code that verifies the run-time version.

Upload all the files you changed (everything in project's folder + GameReferences.h file) somewhere and give me the link, so I can compare them with mine. Also try with the Debug version. The original author released the Debug version, so is possible that he/she never tested the Release version. If the code has bugs sometimes the Debug version still works. LE: I have the impression you didn't updated the address for qword_145907F18 variable. In your DLL I can find 18 7F 90 05 bytes, which is the old address (0x05907F18), instead finding 98 EE 8C 05 bytes (0x058CEE98), which is the new address. See this: https://forums.nexusmods.com/index.php?/topic/7759433-help-needed-compile-a-cpp-file-into-a-dll/?p=71250908

You can have multiple configurations for a project. By default there are 2: Debug and Release. The current configuration used when building the project is selected from a combo-box from toolbar. Most settings are the same for both configurations, but some (like Preprocessor Definitions and Runtime Library) are different. So you can't change their value while having All Configurations selected (there's a combo box in the settings page from which you select for which configuration the settings are displayed). And you have All Configurations selected because <different options> is displayed. If you already changed Preprocessor Definitions while having All Configurations selected then you have to start again. https://imgur.com/a/ju1HT3h

Hmm, probably you have a newer Visual Studio. Select the last one: Dynamic-Link Library (DLL).

Regarding Regen's trick, in f4se_versions you'll find this: #define MAKE_EXE_VERSION_EX(major, minor, build, sub) ((((major) & 0xFF) << 24) | (((minor) & 0xFF) << 16) | (((build) & 0xFFF) << 4) | ((sub) & 0xF)) #define MAKE_EXE_VERSION(major, minor, build) MAKE_EXE_VERSION_EX(major, minor, build, 0) So 1.10.98 is (1 << 24) | (10 < 16) | (98 << 4) => 0x10A0620 1 << 24 = 16777216 = 0x1000000 10 << 16 = 655360 = 0xA0000 98 << 4 = 1568 = 0x620 And 1.10.120 is 0x10A0780

I don't think it will work. F4SE is shipped as a dynamic library (a DLL file), but for extensions it must be built as a static library (a LIB file). Now I see that you tricked me, because when F4SE is compiled as a static library the result is f4se_1_10_138.lib, not f4se_1_10_138.dll. So you didn't change Configuration Type from Dynamic Library to Static Library as instructed. Because the F4SE extensions are statically linked against F4SE => some code from F4SE (the parts used by the extension) is actually included in extension.dll file. This is why usually most of the extensions must be updated whenever F4SE is updated. And the code from F4SE comes with many hard-coded addresses. So is not only about the hard-coded addresses from extension's main.cpp file, but also about the ones from F4SE itself. Some authors created F4SE extensions that are version independent. What they did was to use signatures to scan the memory at run-time to find the addresses, instead having them hard-coded. They did this for their own addresses, but they also had to do this for the ones from F4SE. Now if you check the f4se_versions.h file you'll find this: #define RUNTIME_VERSION_1_10_98 MAKE_EXE_VERSION(1, 10, 98) // 0x010A0620 creation club update 9 #define RUNTIME_VERSION_1_10_106 MAKE_EXE_VERSION(1, 10, 106) // 0x010A06A0 creation club update 10 (no addresses changed) #define RUNTIME_VERSION_1_10_111 MAKE_EXE_VERSION(1, 10, 111) // 0x010A06F0 creation club update 11 (no addresses changed) #define RUNTIME_VERSION_1_10_114 MAKE_EXE_VERSION(1, 10, 114) // 0x010A0720 creation club update 12 (no addresses changed) #define RUNTIME_VERSION_1_10_120 MAKE_EXE_VERSION(1, 10, 120) // 0x010A0780 creation club update 13 (no addresses changed) #define RUNTIME_VERSION_1_10_130 MAKE_EXE_VERSION(1, 10, 130) // 0x010A0820 creation club update 14 #define RUNTIME_VERSION_1_10_138 MAKE_EXE_VERSION(1, 10, 138) // 0x010A08A0 creation club update 15 So Regren's trick was possible because no addresses changed between 1.10.98 and 1.10.120. This is not true between 1.10.120 and 1.10.138.

F4SE has almost the best documentation available: is open source.Most of the F4SE extension I've seen require a much higher skill than reading F4SE source code. Anyway, it seems that only one address has changed: RelocPtr <void*> qword_145907F18(0x05907F18); must be changed to RelocPtr <void*> qword_145907F18(0x058CEE98); // updated for 1.10.138 All the other addresses seems to be the same in 1.10.98 (the version for which the clipboard mod was released) and 1.10.138. DEFINE_MEMBER_FN(SetScale, void, 0x003F8490, float scale); RelocAddr <_Enable_Native> Enable_Native(0x0040D970); RelocAddr <_Disable_Native> Disable_Native(0x004E4300); RelocAddr <_EffectShaderPlay> EffectShaderPlay(0x00422060); RelocAddr <_EffectShaderStop> EffectShaderStop(0x00F0DF40);

Nope :smile: Use Google for this...

The best documentation I've found is the source code of existing plugins. Some authors (registrator2000, kassent, Neanka etc...) released the source code for their mods... Probably this thread is the best documentation about what you need to compile an extension :smile: How do you find them? Cheat Engine? With a disassembler. From what I know Cheat Engine can be used for finding addresses in memory, not in the executable.

For debug build the DLL I've obtained has 5.65MB. The latest released version has 5.31MB, so is close enough. I assume that Struckur released the debug version. For release build the DLL has 297KB, which is OK (the extensions from my F4SE\Plugins folder have between 250KB and 560KB). I'm surprised that the mod used to work with the buggy GetLogFilePath, GetSettingFilePath, GetDefaultSettingFilePath functions. Returning the address of a local variable is something that may cause crashes... Probably Struckur used an old compiler and this is why it didn't catch the bug from TransmitPowerInSelectionLatent function. Anyway, you can find here everything I've done: https://drive.google.com/file/d/1qkc7g6KNJYSzoAglAvNgbXlxuJAs3ZM-/view?usp=sharing The project, the modified source code and the resulted DLLs. I assume you named your project clipboard-dll, mine is named clipboard, so you can load both in f4se solution to compare them. LE: read the message written by MaybeSomeone on clipboard's forum; you'll probably need the new addresses; I can find them, but I need the new EXE (I'm not playing F4 anymore)