maryo wrote:"PatchFile=fores.dat"
We don't use fores.dat as a patchfile (Even i suggested to solve the cheater issues this way) because I think patch files have higher priority over data/resdata directory. So when someone copies some files to data/resdata then it is overriden by the files from patch file (if they are present). This is solved by loading fores.dat using Hi Resolution patch INI file (f2_res.ini).
So I suggest to change it to the original "patch%d.dat" or to "fores%d.dat" so it behaves like patch DAT.
Well, I set it because in your fmp.c the loader treats fores.dat as a patch file:
Code: Select all
/* Patch name */ WriteProcessMemory(processInfo.hProcess, (void*)0x5023C8, "fores", 5, &bytesWritten);
I'm not sure if loading fores.dat in f2_res.ini will make the game load other files as well, or if it works differently from loading the DAT as a patch file in the game engine.
As much as I understand using a single DAT makes file management a lot more easier, I prefer using separated files in folders myself because of the issues caused by the priority you mentioned.
maryo wrote:I haven't checked everything. What about
Code: Select all
StartXPos=-1
StartYPos=-1
ViewXPos=-1
ViewYPos=-1
Not sure if it's the same as World Highlight X / Y inside fores.exe though. I guess it has something to do with it.
Ah yes, StartXPos and StartYPos can replace the memory patches in fores.exe. Well, more lines got commented out in fmp.c.
And maybe perk changes could be replaced with Perks.ini. I'll check them later.
maryo wrote:"I'd suggest using new hook scripts to prevent NPCs from wearing (wielding) armors they don't like instead of more asm hacks."
You mean "HOOK_INVENWIELD". That could work. I didn't know (or I just forgot) about this hook script.
The barter think is probably doable using prototype flag which is quite a lot of changing. Maybe if it was possible to turn off the bartering (the proto flag) using scripts then it would be better... But still doable.
If you want to set the proto flags for critters without editing .pro files one by one, you can use set_proto_data in a global script. For example in my
lootable turrets mod:
set_proto_data(PID_AUTO_GAT_GUN, PROTO_CR_ACTION_FLAGS, (CFLG_NODROP + CFLG_NOLIMBS + CFLG_NOAGES + CFLG_NOHEAL + CFLG_FLATTN + CFLG_NOKNOCKDOWN));
The downside is there will be A LOT (maybe hundreds) of similar lines in the global script to cover all original NPCs that can be bartered with the UI button. Not the most elegant solution to be honest, but at least you only need to maintain one script.
BTW, I just made a custom sfall with only replacing all "data\\" with "resdata\\" (not only in ScriptExtender.cpp) and dropped in the original Resurrection. Didn't have the said party members & Leader perk issues if loading old saves.
Guess if you need to consider the compatibility of old saves, changing the directory structure is probably not a good idea. D:
EDIT: No, I'm wrong. The problem is because I use the "patch file" method to load fores.dat. Old saves work fine in my current "data" structure setup.
I can upload the updated sfall with modified source code files if you're interested. At least if you don't plan to change the directory structure and the loader in later versions, it can be used as an updated component for current Resurrection setup.
I'll start a new game and play through Resurrection in my new setup ("data" folder + official sfall + custom INI + stripped loader) with completely following my previous playthrough. See if I'll encounter any of the said issues.