About the custom sfall

General discussion about Resurrection without spoilers. If you have questions about the game not concerning its content, or problems with running the game, this is the place to ask.

Moderators: Ratman, Seto, Saruman, feťák8, valcik, NovaRain

Post Reply
User avatar
NovaRain
Liked
Posts: 73
Joined: Fri Jul 15, 2016 5:40 pm

About the custom sfall

Post by NovaRain »

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?
User avatar
maryo
Resurrection team member
Posts: 23
Joined: Fri Dec 14, 2007 9:59 pm
Contact:

Re: About the custom sfall

Post by maryo »

"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.
User avatar
NovaRain
Liked
Posts: 73
Joined: Fri Jul 15, 2016 5:40 pm

Re: About the custom sfall

Post by NovaRain »

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.
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.
It would be great if you can retrieve the source code for detailed changes, or consider to utilize more sfall feaures. :D
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.
I just replaced the included f2_res.dll with 4.1.8 one, don't encounter any issues so far.
User avatar
maryo
Resurrection team member
Posts: 23
Joined: Fri Dec 14, 2007 9:59 pm
Contact:

Re: About the custom sfall

Post by maryo »

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.

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
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 :)

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);
BTW, does FoRes use any sfall array in scripts?
I think it does not.
User avatar
NovaRain
Liked
Posts: 73
Joined: Fri Jul 15, 2016 5:40 pm

Re: About the custom sfall

Post by NovaRain »

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.
I can add an option in debugging section (just like AllowUnsafeScripting) to let modders disable sfall internal credits.
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?
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.
Yes, Timeslip has already implemented skill related functions in 3.0:
  • >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.
You might want to consider using those "safer" functions instead of direct memory manipulation. :)
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 :)
Sure, I'd like to check the source code, thanks. :D
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?
User avatar
maryo
Resurrection team member
Posts: 23
Joined: Fri Dec 14, 2007 9:59 pm
Contact:

Re: About the custom sfall

Post by maryo »

I can add an option in debugging section (just like AllowUnsafeScripting) to let modders disable sfall internal credits.
That would be great. I hope devs won't be disabling sfall credits just for fun :)
You might want to consider using those "safer" functions instead of direct memory manipulation. :)
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 :oops:.
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?
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).
It could probably be renamed back.

Will send you the source through PM.
would you consider releasing the script sources of Resurrection like Restoration Project?
Sure. I think so. It would be a pitty to not do it.
User avatar
NovaRain
Liked
Posts: 73
Joined: Fri Jul 15, 2016 5:40 pm

Re: About the custom sfall

Post by NovaRain »

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. :twisted:

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.
User avatar
maryo
Resurrection team member
Posts: 23
Joined: Fri Dec 14, 2007 9:59 pm
Contact:

Re: About the custom sfall

Post by maryo »

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 :D. 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

Code: Select all

mkdir("resdata");
mkdir("resdata\\scripts");
? 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

Code: Select all

[Resurrection]
Debug=1
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

Code: Select all

    if(GetPrivateProfileIntA("Misc", "DialogueFix", 1, ini)) {
        dlog("Applying dialogue patch.", DL_INIT);
        SafeWrite8(0x00446848, 0x31);
        dlogr(" Done", DL_INIT);
    }
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 :).
User avatar
NovaRain
Liked
Posts: 73
Joined: Fri Jul 15, 2016 5:40 pm

Re: About the custom sfall

Post by NovaRain »

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?
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.
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.
maryo wrote:"Leader perk not working."
Really? That' strange. I guess Leader perk uses the unsafe scripting way. Is it properly enabled?
From sfall logging it's enabled.
maryo wrote:You can try to enable resurrection debug to see if global script works.
ddraw.ini

Code: Select all

[Resurrection]
Debug=1
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.
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.
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. :?
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?
I'd suggest using new hook scripts to prevent NPCs from wearing (wielding) armors they don't like instead of more asm hacks.

And here's my default ddraw.ini for new sfall and new Resurrection setup if you're interested:
http://pastebin.com/8sE5ib8s
User avatar
maryo
Resurrection team member
Posts: 23
Joined: Fri Dec 14, 2007 9:59 pm
Contact:

Re: About the custom sfall

Post by maryo »

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.

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);\
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?

Code: Select all

#define SFALL_GVAR_PERK_ENABLED 1000
"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

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.


"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.
User avatar
NovaRain
Liked
Posts: 73
Joined: Fri Jul 15, 2016 5:40 pm

Re: About the custom sfall

Post by NovaRain »

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. :P
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.
Last edited by NovaRain on Mon Aug 01, 2016 2:30 am, edited 1 time in total.
User avatar
maryo
Resurrection team member
Posts: 23
Joined: Fri Dec 14, 2007 9:59 pm
Contact:

Re: About the custom sfall

Post by maryo »

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);
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.
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));
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.
Guess if you need to consider the compatibility of old saves, changing the directory structure is probably not a good idea. D:
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.
BTW, I just made a custom sfall with only replacing all "data\\" with "resdata\\"...
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.

Code: Select all

And maybe perk changes could be replaced with Perks.ini. I'll check them later.
Probably all of them but it's possible that few new perks replace some old removed perks and they expect the effects of the removed ones. But maybe not. I'm actually not sure. I'll need to recheck it.[/code]
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.
Great :wink:. 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/releases
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 :)
User avatar
NovaRain
Liked
Posts: 73
Joined: Fri Jul 15, 2016 5:40 pm

Re: About the custom sfall

Post by NovaRain »

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.
Interesting, I'll change the INI then. Thanks.
maryo wrote:
BTW, I just made a custom sfall with only replacing all "data\\" with "resdata\\"...
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.
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. :P
maryo wrote:
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.
Great :wink:. 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/releases
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.
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.
User avatar
maryo
Resurrection team member
Posts: 23
Joined: Fri Dec 14, 2007 9:59 pm
Contact:

Re: About the custom sfall

Post by maryo »

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. :P
Oh I see. That's great.
The binary for the newest code is not available in public. You could check the develop branch for newest code..
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 builds :)
Post Reply