About the custom sfall
Moderators: Ratman, Seto, Saruman, feťák8, valcik, NovaRain
About the custom sfall
FoRes uses a custom sfall 3.1a, and I'd like to compile a new sfall based on the newest sfall code (3.7c) to use with the mod. Can devs explain in detail what changes you made to the source code?
Judging from ddraw.ini it seems at least you always enable AllowUnsafeScripting and remove TimeLimit, PipBoyAvailableAtGameStart, and DisableHorrigan from the INI, but what else get changed?
BTW, does FoRes use any sfall array in scripts?
Judging from ddraw.ini it seems at least you always enable AllowUnsafeScripting and remove TimeLimit, PipBoyAvailableAtGameStart, and DisableHorrigan from the INI, but what else get changed?
BTW, does FoRes use any sfall array in scripts?
Re: About the custom sfall
"Can devs explain in detail what changes you made to the source code?"
That's what I have to figure out. It's been quite a long time since I was compiling it.
From what I remember:
- sfall credits were moved to credits in DAT file so we could easily prepend ours.
- allowUnsafeScripting is enabled because of few perks
- paths to global scripts are modified according to the directory structure (resdata/scripts/gl*.int)
And probably something more but I can't access the source code because the PC it was compiled on few years ago is broken. I will try to fix/solve it somehow soon and let you know.
- maybe some path/filename but maybe not
These are not set by sfall at all (but by fores.exe), they are probably overriden when changed by sfall:
- starting map,
- pipboy at start
- city patch
- start appearence
- patch name
- CFG name
- starting year
- starting month
- starting day
- MOD name
- world highlight X
- world highlight X
- world highlight Y
- world highlight Y
- disabled armor and trade buttons
- 10 years limit
- horrigan encounter
- disabled dreams
- perks
OFC it would be possible to remove some configuration from fores executable and set it insine ddraw.ini.
- elevators (using f2elev + binary diff)
- high resolution patch (using high resolution patcher + binary diff) - i think the patcher was not updated so it is probably possible just to update the corresponding dll but it was maybe hexaedited so it would be better to check it using some diff tool
These are set by fores.exe because of historical reasons - the fores executable is older than sfall.
That's what I have to figure out. It's been quite a long time since I was compiling it.
From what I remember:
- sfall credits were moved to credits in DAT file so we could easily prepend ours.
- allowUnsafeScripting is enabled because of few perks
- paths to global scripts are modified according to the directory structure (resdata/scripts/gl*.int)
And probably something more but I can't access the source code because the PC it was compiled on few years ago is broken. I will try to fix/solve it somehow soon and let you know.
- maybe some path/filename but maybe not
These are not set by sfall at all (but by fores.exe), they are probably overriden when changed by sfall:
- starting map,
- pipboy at start
- city patch
- start appearence
- patch name
- CFG name
- starting year
- starting month
- starting day
- MOD name
- world highlight X
- world highlight X
- world highlight Y
- world highlight Y
- disabled armor and trade buttons
- 10 years limit
- horrigan encounter
- disabled dreams
- perks
OFC it would be possible to remove some configuration from fores executable and set it insine ddraw.ini.
- elevators (using f2elev + binary diff)
- high resolution patch (using high resolution patcher + binary diff) - i think the patcher was not updated so it is probably possible just to update the corresponding dll but it was maybe hexaedited so it would be better to check it using some diff tool
These are set by fores.exe because of historical reasons - the fores executable is older than sfall.
Re: About the custom sfall
Yes, many of the settings/changes/features can be done with newer sfall. Especially after 3.7 phobos2077 and I merged both normal and debug versions of DLLs, now you only need to enable debug mode and set AllowUnsafeScripting=1 in new INI.maryo wrote:"Can devs explain in detail what changes you made to the source code?"
That's what I have to figure out. It's been quite a long time since I was compiling it.
(snip)
OFC it would be possible to remove some configuration from fores executable and set it insine ddraw.ini.
It would be great if you can retrieve the source code for detailed changes, or consider to utilize more sfall feaures.
I just replaced the included f2_res.dll with 4.1.8 one, don't encounter any issues so far.maryo wrote:- high resolution patch (using high resolution patcher + binary diff) - i think the patcher was not updated so it is probably possible just to update the corresponding dll but it was maybe hexaedited so it would be better to check it using some diff tool
These are set by fores.exe because of historical reasons - the fores executable is older than sfall.
Re: About the custom sfall
So I've recovered the data and the changes are realy just those I've already mentioned.
sfall 3.1a
Microsoft DirectX SDK %28June 2010%29
- ScriptExtender.cpp - removed conditions for AllowUnsafeScripting in void ScriptExtenderSetup()
bool AllowUnsafeScripting=true;
- Credits.cpp - commented out HookCalls in void CreditsInit(), the credits were moved to DAT
//HookCall(0x480C49, &ShowCreditsHook);
//HookCall(0x43F881, &ShowCreditsHook);
//HookCall(0x42CB49, &CreditsNextLineHook);
- global scripts are loaded from resdata\scripts\gl*.int instead of data\scripts\gl*.int (this was changed using hexaeditor but it probably doesn't matter)
So if it is now possible to enable AllowUnsafeScripting (looks like it is) then it should work properly after the path to the global scripts is changed.
I don't know what about the credits. We wanted to have our credits before sfall credits. So an option how to achieve this would be great. Or if you could just compile the new version for us without the credits that would also be awesome, I don't have the environment running anymore.
BTW the only place where AllowUnsafeScripting is used is for 2 perks which alter skill levels. I gues it is probably possible in sfall now since i was requesting this feature few years ago and I think Timeslip implemented it. But i already implemented it using AllowUnsafeScripting lke this and it was working well so i left it untouched.
I can send you the source code of fores.exe (quite awful peace of code) if interested. I think that every single feature could be now implemented using sfall except disabling armor/trade buttons. It is done using this snippet. Someone on TeamX forum helped me to find the first offset
sfall 3.1a
Microsoft DirectX SDK %28June 2010%29
- ScriptExtender.cpp - removed conditions for AllowUnsafeScripting in void ScriptExtenderSetup()
bool AllowUnsafeScripting=true;
- Credits.cpp - commented out HookCalls in void CreditsInit(), the credits were moved to DAT
//HookCall(0x480C49, &ShowCreditsHook);
//HookCall(0x43F881, &ShowCreditsHook);
//HookCall(0x42CB49, &CreditsNextLineHook);
- global scripts are loaded from resdata\scripts\gl*.int instead of data\scripts\gl*.int (this was changed using hexaeditor but it probably doesn't matter)
So if it is now possible to enable AllowUnsafeScripting (looks like it is) then it should work properly after the path to the global scripts is changed.
I don't know what about the credits. We wanted to have our credits before sfall credits. So an option how to achieve this would be great. Or if you could just compile the new version for us without the credits that would also be awesome, I don't have the environment running anymore.
BTW the only place where AllowUnsafeScripting is used is for 2 perks which alter skill levels. I gues it is probably possible in sfall now since i was requesting this feature few years ago and I think Timeslip implemented it. But i already implemented it using AllowUnsafeScripting lke this and it was working well so i left it untouched.
Code: Select all
#define OFFSET_DUDE_SKILL 0x51C4AC
#define calc_dude_skill_offset(skill)\
(OFFSET_DUDE_SKILL + 4 * (skill))
#define get_dude_extra_skill(skill)\
read_int(calc_dude_skill_offset(skill))
#define set_dude_extra_skill(skill, value)\
write_int(calc_dude_skill_offset(skill), value)
#define mod_dude_extra_skill(skill, amount)\
set_dude_extra_skill(skill, get_dude_extra_skill(skill) + div(amount, is_skill_tagged(skill) + 1))
#define get_dude_skill(skill)\
critter_skill_level(dude_obj, skill)
#define mod_dude_extra_skills(amount)\
global_temp := SKILL_SMALL_GUNS;\
while (global_temp <= SKILL_OUTDOORSMAN) do begin\
mod_dude_extra_skill(global_temp, amount);\
global_temp += 1;\
end nop
procedure div(variable value, variable factor) begin
if (0 > value) then begin
return -(-value / factor);
end
return value / factor;
end
Code: Select all
/* Armor button height */ WriteProcessMemory(processInfo.hProcess, (void*)0x44898D, "\x00", 1, &bytesWritten);
/* Trade button height */ WriteProcessMemory(processInfo.hProcess, (void*)0x44A7AA, "\x00", 1, &bytesWritten);
/* CTrade button width */ WriteProcessMemory(processInfo.hProcess, (void*)0x4488BF, "\x00", 1, &bytesWritten);
I think it does not.BTW, does FoRes use any sfall array in scripts?
Re: About the custom sfall
I can add an option in debugging section (just like AllowUnsafeScripting) to let modders disable sfall internal credits.maryo wrote:So if it is now possible to enable AllowUnsafeScripting (looks like it is) then it should work properly after the path to the global scripts is changed.
I don't know what about the credits. We wanted to have our credits before sfall credits. So an option how to achieve this would be great. Or if you could just compile the new version for us without the credits that would also be awesome, I don't have the environment running anymore.
Looks like the only thing that need to change in the source code is the custom path for global scripts. I'm curious why you chose to use a custom data folder (resdata), to prevent mod data getting mixed with FO2 itself (the main data folder) before Lexx posted his mod installation method?
Yes, Timeslip has already implemented skill related functions in 3.0:maryo wrote:BTW the only place where AllowUnsafeScripting is used is for 2 perks which alter skill levels. I gues it is probably possible in sfall now since i was requesting this feature few years ago and I think Timeslip implemented it. But i already implemented it using AllowUnsafeScripting lke this and it was working well so i left it untouched.
- >Added get/set_critter_skill_points, get/set_available_skill_points, mod_skill_points_per_level, set_perk_freq, get_last_attacker, get_last_target and block_combat script functions
- get/set_critter_skill_points will get/set the number of additional points a critter has in a skill, on top of whatever they have from their stats and other bonuses. Note that skill points are part of the proto, so calling set_skill_points on a critter will affect all critters that share the same proto.
Sure, I'd like to check the source code, thanks.maryo wrote:I can send you the source code of fores.exe (quite awful peace of code) if interested. I think that every single feature could be now implemented using sfall except disabling armor/trade buttons. It is done using this snippet. Someone on TeamX forum helped me to find the first offset
BTW, talked about the source code, would you consider releasing the script sources of Resurrection like Restoration Project? I don't mean releasing them now but maybe after some time when you don't plan to maintain/fix the mod any further?
Re: About the custom sfall
That would be great. I hope devs won't be disabling sfall credits just for funI can add an option in debugging section (just like AllowUnsafeScripting) to let modders disable sfall internal credits.
Yes. I've been considering it and I wanted to do it. But i was lazy to test it all again since it was tested and working properly I decided to leave it as it is - I was also not sure if sfall handles it the same way .You might want to consider using those "safer" functions instead of direct memory manipulation.
Exactly. The mod was not living in it's own directory few years ago and sfall/high resolution patch were not mandatory dependencies. Now they are so it was then moved to Resurrection folder (prior to Lexx recipe).I'm curious why you chose to use a custom data folder (resdata), to prevent mod data getting mixed with FO2 itself (the main data folder) before Lexx posted his mod installation method?
It could probably be renamed back.
Will send you the source through PM.
Sure. I think so. It would be a pitty to not do it.would you consider releasing the script sources of Resurrection like Restoration Project?
Re: About the custom sfall
OK, today I got an old rack server with Win2000 Server SP4 and VC6 SP6 installed. I replaced all "resdata" with "DATA" in the source .c file, commented out memory patches that can be handled with official sfall 3.7.x, and compiled a new loader exe. But it seems I f**ked up because strcmp is case-sensitive. Got no global scripts extracted and have to unpack them manually. BTW, I'd suggest to update zlib to 1.2.8, 1.1.2 is a bit too old.
In game testing shows while some basic things work, like disabled UI buttons and smaller world map, some don't work as they should, like my leveled party members lost their HP/AP bonuses. Weird thing is the game still creates a resdata folder in the main data folder. When I enabled the logging function in sfall and loaded a save in data\savegame, it shows "Loading save game: resdata\\savegame\slot70\sfallgv.sav" in the log. Saving the game will have error message about failed to create sfallgv.sav. Maybe that's why party members lost their bonuses? Not sure if there's still any "resdata" reference in the loader/mod that effect sfall.
I'll try something else tomorrow, maybe just completely remove the DAT extraction, put sfall global scripts inside the scripts folder, and strip the code for hi-res patch (I think the same can be done with renaming a pre-patched fallout2.exe to fallout2). To be honest the whole DAT extraction stuff seems rather unnecessary for me, too much hassle for merely two global scripts. Still planning to make Resurrection use standard directory structure as other ordinary TC mods and work with official sfall binary.
EDIT: Stripped off the code of DAT extraction and hi-res patch, and extract everything from fores.dat. It seems most of the problems are gone. Now the issues I'm still having are party members lost their bonuses after loading saves and Leader perk not working. Not sure how Resurrection handles party member leveling.
One of the benefit of code stripping is now the exe compiled in VS2008 Express (used to win2k compatibility) doesn't crash upon exiting the game.
In game testing shows while some basic things work, like disabled UI buttons and smaller world map, some don't work as they should, like my leveled party members lost their HP/AP bonuses. Weird thing is the game still creates a resdata folder in the main data folder. When I enabled the logging function in sfall and loaded a save in data\savegame, it shows "Loading save game: resdata\\savegame\slot70\sfallgv.sav" in the log. Saving the game will have error message about failed to create sfallgv.sav. Maybe that's why party members lost their bonuses? Not sure if there's still any "resdata" reference in the loader/mod that effect sfall.
I'll try something else tomorrow, maybe just completely remove the DAT extraction, put sfall global scripts inside the scripts folder, and strip the code for hi-res patch (I think the same can be done with renaming a pre-patched fallout2.exe to fallout2). To be honest the whole DAT extraction stuff seems rather unnecessary for me, too much hassle for merely two global scripts. Still planning to make Resurrection use standard directory structure as other ordinary TC mods and work with official sfall binary.
EDIT: Stripped off the code of DAT extraction and hi-res patch, and extract everything from fores.dat. It seems most of the problems are gone. Now the issues I'm still having are party members lost their bonuses after loading saves and Leader perk not working. Not sure how Resurrection handles party member leveling.
One of the benefit of code stripping is now the exe compiled in VS2008 Express (used to win2k compatibility) doesn't crash upon exiting the game.
Re: About the custom sfall
I don't know why but the DAT extraction works only when it's compiled in Visual Studio Debug environment. It had it's reason... there were only two files - fores.exe and fores.dat 10 years ago . No extra directory . So it's pretty
unnecessary now.
"my leveled party members lost their HP/AP bonuses"
Are you sure it's caused by your changes? I've read somewhere on this forum that it happened to other players too but they mentioned drug usage. It could possibly be a bug of Resurrection itself but I'm not sure.
Or couldn't it be caused by sfall version incompatibility if there is?
"I'd suggest to update zlib to 1.2.8, 1.1.2 is a bit too old."
If that helpes with the debug mode... Zlib is there just because of the DAT extraction. So not really needed if you removed the extraction code.
"Weird thing is the game still creates a resdata folder in the main data folder."
Have you removed
? I guess so. There are also references in fores.cfg and f2_res.ini and in the custom sfall.
"strip the code for hi-res patch (I think the same can be done with renaming a pre-patched fallout2.exe to fallout2)."
The copy of fallout2.exe and the Resurrection directory was not there originaly. So yes, it would be probably better to do it the way you mentioned now.
"Leader perk not working."
Really? That' strange. I guess Leader perk uses the unsafe scripting way. Is it properly enabled?
Have you copied the global scripts to data (OR resdata folder)? The path depends on sfall OFC but you know it .
You can try to enable resurrection debug to see if global script works.
ddraw.ini
But all it enables is just a few messages like "Game loaded.". If you see this message after enabling debug mode than global scripts are loaded. If leader perk does not still work then there is a problem with the unsafe scripting.
BTW We've noticed your post about keyboard shortcuts and how to bypass the disabled barter and armor button. Don't you know if there is a possibility to disable these two keyboard shortcuts? I was checking how DialogueFix in sfall is done
Someone apparently found a memory offset of this. But I'm not exactly sure how to find these two. I could try to disassemble it but I'm not very good at ASM and it's painful work. I guess I won't be lucky this time .
unnecessary now.
"my leveled party members lost their HP/AP bonuses"
Are you sure it's caused by your changes? I've read somewhere on this forum that it happened to other players too but they mentioned drug usage. It could possibly be a bug of Resurrection itself but I'm not sure.
Or couldn't it be caused by sfall version incompatibility if there is?
"I'd suggest to update zlib to 1.2.8, 1.1.2 is a bit too old."
If that helpes with the debug mode... Zlib is there just because of the DAT extraction. So not really needed if you removed the extraction code.
"Weird thing is the game still creates a resdata folder in the main data folder."
Have you removed
Code: Select all
mkdir("resdata");
mkdir("resdata\\scripts");
"strip the code for hi-res patch (I think the same can be done with renaming a pre-patched fallout2.exe to fallout2)."
The copy of fallout2.exe and the Resurrection directory was not there originaly. So yes, it would be probably better to do it the way you mentioned now.
"Leader perk not working."
Really? That' strange. I guess Leader perk uses the unsafe scripting way. Is it properly enabled?
Have you copied the global scripts to data (OR resdata folder)? The path depends on sfall OFC but you know it .
You can try to enable resurrection debug to see if global script works.
ddraw.ini
Code: Select all
[Resurrection]
Debug=1
BTW We've noticed your post about keyboard shortcuts and how to bypass the disabled barter and armor button. Don't you know if there is a possibility to disable these two keyboard shortcuts? I was checking how DialogueFix in sfall is done
Code: Select all
if(GetPrivateProfileIntA("Misc", "DialogueFix", 1, ini)) {
dlog("Applying dialogue patch.", DL_INIT);
SafeWrite8(0x00446848, 0x31);
dlogr(" Done", DL_INIT);
}
Re: About the custom sfall
I tested with my end game saves. In current Resurrection Keri has HP 121/121 (level 4), loaded in my "new" Resurrection setup it becomes 121/81. No drug usage.maryo wrote:"my leveled party members lost their HP/AP bonuses"
Are you sure it's caused by your changes? I've read somewhere on this forum that it happened to other players too but they mentioned drug usage. It could possibly be a bug of Resurrection itself but I'm not sure.
Or couldn't it be caused by sfall version incompatibility if there is?
AFAIK the only incompatibility in newer sfall is the scripting array. That's why I asked if Resurrection uses any sfall array in scripts. But also it's possible during sfall update and code refactoring something has been changed.
From sfall logging it's enabled.maryo wrote:"Leader perk not working."
Really? That' strange. I guess Leader perk uses the unsafe scripting way. Is it properly enabled?
Yes, global scrips are loaded. Another interesting thing is loading my end game save in new setup (Keri is wearing power armor), telling her change armor would cause stats loss.maryo wrote:You can try to enable resurrection debug to see if global script works.
ddraw.iniBut all it enables is just a few messages like "Game loaded.". If you see this message after enabling debug mode than global scripts are loaded. If leader perk does not still work then there is a problem with the unsafe scripting.Code: Select all
[Resurrection] Debug=1
Guess I should also build a custom sfall similar to the current one for Resurrection, with no structure changes, no new loader, and working like a simple update to Resurrection's. See if those issues only due to new sfall.
I'd suggest using new hook scripts to prevent NPCs from wearing (wielding) armors they don't like instead of more asm hacks.maryo wrote:BTW We've noticed your post about keyboard shortcuts and how to bypass the disabled barter and armor button. Don't you know if there is a possibility to disable these two keyboard shortcuts?
And here's my default ddraw.ini for new sfall and new Resurrection setup if you're interested:
http://pastebin.com/8sE5ib8s
Re: About the custom sfall
Actually Leader perk does not use unsafe scripting. It's Loner perk who needs the unsafe scripting.
Changing the stats of the companions is inside their scripts (keri.ssl/int and partyact.h, i know you don't have the sources) and it is done using simple mod_critter_extra_stat.
Where memberToken is "Keri/Lystra/Gabriel/Vorech/Slinta" and switchToken is "On"/"Off"
"AFAIK the only incompatibility in newer sfall is the scripting array"
I'm quite sure we don't use arrays but the main global script (global.ssl/int) uses SFALL global variable as seen in the code snippet. Couldn't this be the problem?
"here's my default ddraw.ini"
"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.
I haven't checked everything. What about
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.
"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.
Changing the stats of the companions is inside their scripts (keri.ssl/int and partyact.h, i know you don't have the sources) and it is done using simple mod_critter_extra_stat.
Code: Select all
set_gvar_bit_##switchToken(GVAR_PERK_LEADER_PARTY, bit_##memberToken);\
mod_critter_extra_stat(memberToken##_Ptr, STAT_max_move_points, PERK_LEADER_MULTIPLIER_##switchToken);\
"AFAIK the only incompatibility in newer sfall is the scripting array"
I'm quite sure we don't use arrays but the main global script (global.ssl/int) uses SFALL global variable as seen in the code snippet. Couldn't this be the problem?
Code: Select all
#define SFALL_GVAR_PERK_ENABLED 1000
"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.
I haven't checked everything. What about
Code: Select all
StartXPos=-1
StartYPos=-1
ViewXPos=-1
ViewYPos=-1
"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.
Re: About the custom sfall
Well, I set it because in your fmp.c the loader treats fores.dat as a patch file: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.
Code: Select all
/* Patch name */ WriteProcessMemory(processInfo.hProcess, (void*)0x5023C8, "fores", 5, &bytesWritten);
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.
Ah yes, StartXPos and StartYPos can replace the memory patches in fores.exe. Well, more lines got commented out in fmp.c.maryo wrote:I haven't checked everything. What aboutNot sure if it's the same as World Highlight X / Y inside fores.exe though. I guess it has something to do with it.Code: Select all
StartXPos=-1 StartYPos=-1 ViewXPos=-1 ViewYPos=-1
And maybe perk changes could be replaced with Perks.ini. I'll check them later.
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: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.
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.
Last edited by NovaRain on Mon Aug 01, 2016 2:30 am, edited 1 time in total.
Re: About the custom sfall
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);
And there is no foresXXX.dat file so this change is actually not used. It's there because of patches. And now when it lives in it's own directory it could be better actualy to get rid of it. patchXXX.dat (vanilla) can now be used again as a patch name.
So in Resurrection the fores.dat file is really loaded using High Resolution Patch only. It's kind of a hack but it works and it solves the mentioned priority.
Good tip. Is it really needed to set it from a global script?. I guess it could be set using merchants' scripts too or not?. Probably not a big difference than changing it straight in the PROTO but it could be safer at least. One proto can be shared by more critters.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));
Yes. We were discussing the directory structure change and we are still not considered primarily because of this. There may be some changes in GLOBAL VARs making the old saves incompatible in future patches though so we will see.Guess if you need to consider the compatibility of old saves, changing the directory structure is probably not a good idea. D:
But all I changed in the custom sfall bundled with resurrection is really just the credits thing and then the path to global scripts was simly changed using hexaediting one string. So It's really strange you need to change more things to make it work. Making it configurable would be better than maintaining two sources/branches but yes.BTW, I just made a custom sfall with only replacing all "data\\" with "resdata\\"...
Code: Select all
And maybe perk changes could be replaced with Perks.ini. I'll check them later.
Great . And is also the original sfall with the updated credits option available compiled somewhere? I don't see it there https://github.com/phobos2077/sfall/releasesI 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 could try if just hexaediting the one string is really not a solution now or if it is caused by something else.
BTW If also REPUTATION GVARs and elevators were decoded and moved to sfall then fores.exe could be almost removed. All what would left is just removing the buttons (which could be added to sfall as a feature or it could just be done by unsafe scripting from global script). Maybe it could solve the problem that some antiviruses see Resurrection as a threat
Re: About the custom sfall
Interesting, I'll change the INI then. Thanks.maryo wrote:It's confusing but it replaces just the first 5 bytes . So the result is actualy patch%03d.dat -> fores%03d.dat
And there is no foresXXX.dat file so this change is actually not used. It's there because of patches. And now when it lives in it's own directory it could be better actualy to get rid of it. patchXXX.dat (vanilla) can now be used again as a patch name.
So in Resurrection the fores.dat file is really loaded using High Resolution Patch only. It's kind of a hack but it works and it solves the mentioned priority.
Changing the path to global scripts is already enough for current Resurrection, but if you're going to use hook scripts you also need to change the path to them. The rest of changes are only for the sake of completeness.maryo wrote:But all I changed in the custom sfall bundled with resurrection is really just the credits thing and then the path to global scripts was simly changed using hexaediting one string. So It's really strange you need to change more things to make it work. Making it configurable would be better than maintaining two sources/branches but yes.BTW, I just made a custom sfall with only replacing all "data\\" with "resdata\\"...
The binary for the newest code is not available in public. I do keep a private collection of my personal test builds for nearly each commit.maryo wrote:Great . And is also the original sfall with the updated credits option available compiled somewhere? I don't see it there https://github.com/phobos2077/sfall/releasesI 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.
You could check the develop branch for newest code (it's 3.7.3 now). We only merge the code to the master branch when releasing an official release.
Re: About the custom sfall
Oh I see. That's great.Changing the path to global scripts is already enough for current Resurrection. Changing the path to global scripts is already enough for current Resurrection, but if you're going to use hook scripts you also need to change the path to them. The rest of changes are only for the sake of completeness.
I could compile it myself from the develop branch but i don't have the environment installed (Like DirectX SDK etc) so if its not a problem for you then I'd better use your buildsThe binary for the newest code is not available in public. You could check the develop branch for newest code..