FiftyTifty

The reason it isn't compatible with TTW, is due to the ENB using an ancient binary. The latest versions don't have that issue, and haven't for several years now. An ENB preset will of course look different when a different lighting mod is used. You'll have to find one yourself. There aren't many, so you may have to compromise and find one that looks good enough, then tweak it so it actually suits your mods.

It's what the original GetRefs function had, so I'm stripping out the unnecessary stuff. There's no documentation, so I'm not sure on what can be removed, what needs to be added, and what is a requirement for interfacing with NVSE. So COMMAND_ARGS is unnecessary. Good, good. I'll continue to poke around then.

It's done through leveled lists, which are used as random selectors. So it works like this: 1. NPC record created with no data except face 2. NPC record added to base leveled list, used as random selector 3. NPC record with the data (level, stats, factions, inventory, script, perks, etc) uses the base leveled list as a template actor 4. NPC record added to a specific leveled list, used as random selector and/or enemy tier selector 5. NPC record uses the specific leveled list as template for all settings 6. NPC record is placed in the game To put it another way: NPC record with face data -> Added to base leveled list -> NPC record with rest of data uses base leveled list as template for face -> NPC record with data added to specific leveled list -> Barebones NPC record that uses specific leveled list to determine which actor to spawn -> Barebones NPC placed in game.

I'm attempting to make an NVSE script that, when the player presses a hotkey, all items present in a cell are put into an array and then iterated through, replacing each item with a static version. But I hit a wee snag with GetRefs(), as it couldn't be called via an NVSE script through CMD_GetRefs_Execute(), as far as I could tell. So I made a stripped down copy-paste, which is tailored to my specific usage: ArrayID GetItemsInCell(COMMAND_ARGS) { // returns an array of references formID in the specified cell(s) ArrayID arrayItemsFound = g_ArrayMap.Create(kDataType_Numeric, true, scriptObj->GetModIndex()); UInt8 formType = 0; UInt8 cellDepth = 0; bool includeTakenRefs = false; double uGrid = 0; double arrIndex = 0.0; cellDepth = 0; CellScanInfo info(cellDepth, formType, bIncludeTakenRefs, cellPlayerIsIn); info.FirstCell(); while (info.curCell) { const TESObjectCELL::RefList& refList = info.curCell->objectList; for (TESObjectCELL::RefList::Iterator iter = refList.Begin(); !iter.End(); ++iter) { TESObjectREFR* pRefr = iter.Get(); if (pRefr) switch (formType) { case 201: if (refrIsItem(pRefr)) { g_ArrayMap.SetElementFormID(arrayItemsInCellFormIDs, arrIndex, pRefr->refID); arrIndex += 1.0; } break; } } info.NextCell(); } return arrayItemsFound; } The problem is that I couldn't really discern what COMMAND_ARGS does. It has something to do with what is passed from a GECK script to the function itself, but the arguments aren't 1:1, so I'm at a loss. Moreover, it's scriptObj->GetModIndex(); that throws an error when I remove COMMAND_ARGS. I can tell that scriptObj is a child of COMMAND_ARGS, but that's about it. Since I'm going to be calling this function inside a plugin, with no functions being called via a GECK script, nothing will be passed to COMMAND_ARGS. How do I rectify this?

If you do need to use Fallout 3 assets, do remember that there is always the Tale of Two Wastelands mod.

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.

Righty, noob question time. After trying to create a script which failed, that replaced all valid items in a cell with static variants, due to a bizarre bug where the scripting engine would suddenly stop moving and rotating the spawned statics, I figured I'd try doing it all within a single NVSE function that is called via a single line in a script. But I can't wrap my head around how to call GetRefs from within my own NVSE plugin. Here's what I've got so far: std::map<std::string, UInt32> mapFormTypes; void FillmapFormTypes() { mapFormTypes.insert(std::make_pair("Armor", 24)); mapFormTypes.insert(std::make_pair("Book", 25)); mapFormTypes.insert(std::make_pair("Ingredient", 29)); mapFormTypes.insert(std::make_pair("Misc", 31)); mapFormTypes.insert(std::make_pair("Weapon", 40)); mapFormTypes.insert(std::make_pair("Ammo", 41)); mapFormTypes.insert(std::make_pair("Ingestible", 47)); mapFormTypes.insert(std::make_pair("Note", 49)); mapFormTypes.insert(std::make_pair("WeaponMods", 103)); mapFormTypes.insert(std::make_pair("CasinoChip", 108)); mapFormTypes.insert(std::make_pair("FactionCurrency", 116)); } void MultipleGetRefCalls() { TESObjectREFR* refArmor[] = Cmd_GetRefs_Execute(mapFormTypes["Armor"], 1, false); } It doesn't seem to be called the same way you'd call any other public function. The following errors are thrown: Error (active) E0165 too few arguments in function call aaafyty_items_to_statics 44 Error (active) E0520 initialization with '{...}' expected for aggregate object aaafyty_items_to_statics 44 Error (active) E0167 argument of type "UInt32" is incompatible with parameter of type "ParamInfo *" aaafyty_items_to_staticp 44 Error (active) E0167 argument of type "int" is incompatible with parameter of type "void *" aaafyty_items_to_statics 44 The function, when exposed to New Vegas' scripting engine, just requires three arguments; integer, integer, boolean. https://geckwiki.com/index.php?title=GetRefs So why does passing three arguments to it throw an error?

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.

In performance, I meant that having the instructions which call the imagespace modifier skipped could bring about noticeable performance improvements in combat. And even after patching the executable directly, rather than waiting for any NVSE hooks, the instructions are completely ignored. Used IDA Pro 5.0 to find them. Loaded up FalloutNV.exe, found GetHit in the string list, found the instructions that use it, patched them, but no change in behaviour. Screenshot to demonstrate: https://i.imgur.com/NSNP04Y.png That's the only result I find for it. So the code that handles applying that imagespace modifier when the player takes damage must be elsewhere, and not as easy to locate. Good to know about the deferred initialization though.

They will need to shift from OpenGL to a rendering API that has actually decent performance. Even if the functionality is there, performance would just crater, as we've seen even in just the interior scenes of early-doors rendering of Fallout 3 and Skyrim. Best hope the devs shift to implementing VulkanSceneGraph when it's ready for release.

Oh my, I forgot to report back. So I patched the instructions of FalloutNV.exe directly, but that didn't make any difference whatsoever. So the instructions that actually apply the GetHit IMAD aren't readily available with IDA nor CheatEngine. I settled for just setting the duration of the imagespace modifier to 0, but I'd much rather have it never be called in the first place. That's a possible performance gain that we're missing out on.

My Creative SoundBlaster X-Fi Titanium Fatal1ty Pro has similar software, where it can replace DirectSound with OpenAL, simulate 3D positioning, normalize volume, and a feature called crystalizer to make audio just sound way better. Never had any problem like this, but then I am on Windows 7.

Initially, I just wanted to patch the values for the GetHit imagespace modifier. Which I'm able to do, so there's no screen blurring when getting hit. Now, I want to skip the instructions that actually call that imagespace modifier. I found them in IDA, but NVSE won't let me patch them early enough in execution, so by the time they're changed, the engine has already done something with the instructions, so changing them this late in execution does nothing. Looked at iStewieAI's tweaks plugin, and I noticed that he uses several things. One, is that his early execution functions have the prefix __fastcall. Another, is that he uses a custom function called addDeferredInitHandler(). Lastly, he uses two other functions instead of SafeWrite(), which are WriteRelCall() and WriteRelJump(). But there's no documentation on how to use those. Here's the NVSEPlugin_Load() function: bool NVSEPlugin_Load(const NVSEInterface * nvse) { _MESSAGE("load"); g_pluginHandle = nvse->GetPluginHandle(); // save the NVSEinterface in cas we need it later SaveNVSE = (NVSEInterface *)nvse; // register to receive messages from NVSE NVSEMessagingInterface* msgIntfc = (NVSEMessagingInterface*)nvse->QueryInterface(kInterface_Messaging); msgIntfc->RegisterListener(g_pluginHandle, "NVSE", MessageHandler); g_msg = msgIntfc; g_script = (NVSEScriptInterface*)nvse->QueryInterface(kInterface_Script); //Begin addDeferredInitHandler(); PatchGetHitIMAD(); //End return true; } Here's my plugin's function: void __fastcall PatchGetHitIMAD() { //This function must be called at PreLoadGame() _MESSAGE("Starting"); addDeferredInitHandler(); //Address of near JNZ = 0046D7A4 SafeWrite8(0x46D7A4, 0xE9); SafeWrite8(0x46D7A5, 0xB6); SafeWrite8(0x46D7A6, 0x00); SafeWrite8(0x46D7A9, 0x90); } Original bytes: 0F 85 B5 00 00 00 New bytes: E9 B6 00 00 90 What those new instructions do, is they change the JNZ (a two byte opcode) into JMP (one byte opcode) by replacing the first opcode, and changing the second byte into the offset. The third byte, the original offset, is turned into 00. And the last byte is changed into a NOP for good measure. While the instructions are patched in memory, after the engine's been started, they're no longer used so changing them does nothing to the game itself. Even with __fastcall and addDeferredInitHandler() being called in NVSEPlugin_Load(). The bytes changed, but the instructions are no longer referenced by the game engine. So how do I go about doing this?

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.

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?

BSAOpt is broken, and has been since the day it was released. Never use it. Use BSArch.

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?

Righty, finally got round to doing this. I've downloaded the NVSE source code along with the example plugin, and opened the solution with VS Community 2019. It threw three errors saying that the .vc9project files need to be migrated. Clicked yes and all that, now it opens up in Visual Studio. But there's errors abound: https://i.imgur.com/0be31ht.png There any reason for that? I assume it's because the NVSE source code was built with VS 2010, so there's incompatibilities with the newer IDEs. Edit: Figured it out. For some reason, the dependency structure breaks convention, with the project relying on .cpp files in a different folder rather than in a subfolder. Re-downloaded NVSE's source, kept the same structure, and now there's no errors at first glance.

I remember there being a workaround for fixing Moira used by the devs of TTW, and that was to create a new actor that has a new FormID, but the same EditorID.

Can't it be done? IIRC, In Fallout 3, there is that Outcasts outpost where you trade technology for gear. It was replicated in TTW, so it isn't impossible. Now, if it's possible to do without tearing your hair out and spending a s#*&#33; ton of time, that's different.

What happens if you call Player.UnequipItem and then Player.EquipItem for the pipboy?

FormIDs are the hexadecimal value given to every record, with the first byte being the load order position of the mod the record is contained in if it's a unique record, or the FormID of the owning file of the record it overwrites. EditorID's are a holdover from Morrowind, and should be unique.

You have to regenerate all the LOD, unfortunately.

I'm guessing the FF at the end is the alpha value. What happens when it's set to 00?

Disable heap replacement, and light critical sections hooking in NVSR's ini. Also, increase the heap to 400MB in NVSE.ini