Fallout 2 mod FO2 Engine Tweaks (Sfall)

In response to questions sent via PM:

Sduibek said:
1.) How do I build the "debugging" version instead of / in addition to the normal version, of ddraw.dll?

2.) More importantly, why isn't the debugging stuff just integrated so all builds of ddraw.dll always have the ability to do debug stuff? That makes more sense to me. I don't see the point of having two versions of ddraw.dll for every single release. The options "DebugMode=0" to disable debugging in the .ini file should be enough, yes?

3.) Is it possible for the "IgnoreCRC" line to have multiple values? Long story short, this would help me a lot if it were possible. (e.g. "ExtraCRC=0xf43d208c,0xf0fd4d53")

4.) Init=1 doesn't seem to add anything to the debug.log for me, is it broken?

Thank you :grin:
1) Currently you need to uncomment this line in Logging.h
Code:
//#define TRACE
then compile.

2) I see your point. My thoughts about the reason behind this decision:
  1. Performance. There are some places in sfall code which may be executed very often (like calling global scripts from the main game loop) and some debugging actions (like logging) may eat some portion of processor time, resulting in FPS drop on slow machines. That's in theory.
  2. Crash safety. Debugging section contains option to enable unsafe scripting - which is basically raw engine hacks built into normal game scripts. Imagine you downloaded some bad-ass mod compilation pack, and one of the mods contain some left-over testing code (or worse - intentional hacks) which changes game engine code and mod installer may simple enable the setting in ddraw.ini because "it says so in mod readme". Sfall authors cannot be held responsible for any crashes in this case, but it will be very hard to trace such bugs. In case a modder needs some advance scripting he must either build his own ddraw.dll, ask others to add some features to sfall or study existing functions more carefully, they often contain required functionality that people try to repeat in other ways.

I think we need more thought and discussion on this.

3) Currently not, but it can be added I guess. Can you explain a use case when you need several values at once?

4) Sfall doesn't write anything to debug.log directly, it uses it's own sfall-log.txt for sfall-related messages.
 
Excellent, thank you. Is the current rendition of Sfall (with changes from Crafty etc etc) on GitHub? If not, I'll gladly create a repo for it. I already have a couple minor changes to commit.

We should have a public repo for this new era of Sfall codebase to increase collaboration and so we don't ever lose it. :nod:

Sourceforge is not advised as they've been engaging in questionable business practices (junkware, adware, malware) for a while now.
 
Last edited:
Crafty's answer to Sduibek's questions:

[TABLE="width: 95%, align: center"]
[TR]
[TD][/TD]
[/TR]
[TR]
[TD="bgcolor: #2A2A2A"]2.) More importantly, why isn't the debugging stuff just integrated so all builds of ddraw.dll always have the ability to do debug stuff? That makes more sense to me. I don't see the point of having two versions of ddraw.dll for every single release. The options "DebugMode=0" to disable debugging in the .ini file should be enough, yes?[/TD]
[/TR]
[/TABLE]
In Falloutw.exe the debug mode has a debug mode which can be turned on by DebugMode. In sfall there is a debug mode of its own, but in F1 version is very limited (just a few messages during sfall initialization compared to F2 version.
Either way, I agree there's no sense in having DebugMode tied to trace/debug version of sfall, hence DebugMode is available in release version as well.

[TABLE="width: 95%, align: center"]
[TR]
[TD][/TD]
[/TR]
[TR]
[TD="bgcolor: #2A2A2A"]3.) Is it possible for the "IgnoreCRC" line to have multiple values? Long story short, this would help me a lot if it were possible. (e.g. "ExtraCRC=0xf43d208c,0xf0fd4d53")[/TD]
[/TR]
[/TABLE]
DONE ;)
 
Crafty's answer to Sduibek's questions:

[TABLE="width: 95%, align: center"]
[TR]
[TD][/TD]
[/TR]
[TR]
[TD="bgcolor: #2A2A2A"]2.) More importantly, why isn't the debugging stuff just integrated so all builds of ddraw.dll always have the ability to do debug stuff? That makes more sense to me. I don't see the point of having two versions of ddraw.dll for every single release. The options "DebugMode=0" to disable debugging in the .ini file should be enough, yes?[/TD]
[/TR]
[/TABLE]
In Falloutw.exe the debug mode has a debug mode which can be turned on by DebugMode. In sfall there is a debug mode of its own, but in F1 version is very limited (just a few messages during sfall initialization compared to F2 version.
Either way, I agree there's no sense in having DebugMode tied to trace/debug version of sfall, hence DebugMode is available in release version as well.

[TABLE="width: 95%, align: center"]
[TR]
[TD][/TD]
[/TR]
[TR]
[TD="bgcolor: #2A2A2A"]3.) Is it possible for the "IgnoreCRC" line to have multiple values? Long story short, this would help me a lot if it were possible. (e.g. "ExtraCRC=0xf43d208c,0xf0fd4d53")[/TD]
[/TR]
[/TABLE]
DONE ;)
@Crafty Marry me!
:revolution:
So how are the three of you (Drobovik / phobos2077 / Crafty) connected anyhow? It says phobos2077 is in/from Russia so presumably active on the same Russian forum/site as Crafty, what's your story though Drobovik? I know where you live and it ain't Russia :P
 
Last edited by a moderator:
@Sduibek
Drobovik means shotgun in russian;) Need any other hints? "We're everywhere. We waiter your tables, we fix your meals, deliver your mail...(fixing your engine bugs, translate your mods) So do not fuck with us..." Fight Club.:grin:
 
Last edited:
Here comes a new request:

Would it be possible to add a switch that allows me to enable / disable the player access to his inventory?

It would be kind of a workaround for my real problem- I am temporarily changing the artfid of the player character, but as soon as I open the inventory, he switches back to default, which sucks.

/Edit: Or is there a different way to change the look of dude_obj, without "art_change_fid_num"?
 
Last edited:
Excellent, thank you. Is the current rendition of Sfall (with changes from Crafty etc etc) on GitHub? If not, I'll gladly create a repo for it. I already have a couple minor changes to commit.

We should have a public repo for this new era of Sfall codebase to increase collaboration and so we don't ever lose it. :nod:

Sourceforge is not advised as they've been engaging in questionable business practices (junkware, adware, malware) for a while now.

Here it is:
https://github.com/phobos2077/sfall

I'm yet to integrate Crafty's work into our "main" branch (that's me and NovaRain). We don't like some of his changes, so ideally I expect him to fork the repo for all his work. And then either we will migrate features manually or (ideally) he will make merge-pull requests (though I doubt it will happen..).
Also when we're working with engine hacks, we can't blindly pull his changes, because you can never understand how the code works without first thoroughly studying the engine code in disassembler, and then figuring out what the hack does and how. Then think if it's a good solution, what possible problems may be caused by it, and so on. Not to mention that some people don't follow coding style of the project they're modifying.

So our current plan is to pull features slowly one-by-one, making sure we don't break anything. Sfall introduced too much crashes in the past due to bad code, so we should be extra careful. Meanwhile, I think Crafty's version will live it's life.


Here comes a new request:

Would it be possible to add a switch that allows me to enable / disable the player access to his inventory?

It would be kind of a workaround for my real problem- I am temporarily changing the artfid of the player character, but as soon as I open the inventory, he switches back to default, which sucks.

/Edit: Or is there a different way to change the look of dude_obj, without "art_change_fid_num"?
I think the game checks which armor you're wearing when you close the inventory screen and adjust your art FID. However, it only changes the armor portion of the FID. For example, if you switch from male to a female character, it should theoretically make you a female indefinitely.

I think you can make a very dirty workaround:
  1. add some hook or just a code in the main loop, that checks if inventory is opened
  2. as soon as inventory screen is opened, close it using "tap_key"
  3. change art FID again
 
Last edited:
I think you can make a very dirty workaround:
  1. add some hook or just a code in the main loop, that checks if inventory is opened
  2. as soon as inventory screen is opened, close it using "tap_key"
  3. change art FID again

Or just block out the "I" key and a release click over the UI area where the inventory button is with disable_ui for a short period (exactly how short you have to try out yourself, it's hard for me to figure out exactly). That way you don't have to change the FID back as the inventory never fires.
 
I'm yet to integrate Crafty's work into our "main" branch (that's me and NovaRain). We don't like some of his changes,
Whether what criterion for definition deserves change of honor to be added?
RU:Каков критерий для определения заслуживает ли изменение чести быть добавленным?

so ideally I expect him to fork the repo for all his work. And then either we will migrate features manually or (ideally) he will make merge-pull requests (though I doubt it will happen..).
To what me sense to make merge-pull requests (and whether it will unclear deserve chance of addition) if all the same has to be engaged in my version?
RU:Какой мне смысл делать merge-pull requests (и непонятно заслужит ли он шанса на добавление) если всё равно должен заниматься своей версией?

Also when we're working with engine hacks, we can't blindly pull his changes, because you can never understand how the code works without first thoroughly studying the engine code in disassembler, and then figuring out what the hack does and how. Then think if it's a good solution, what possible problems may be caused by it, and so on. Not to mention that some people don't follow coding style of the project they're modifying.
The many people took part in creation of sfall, nearly every second file of sources has "the style". About which "style" the speech?
RU:В создании sfall принимало участие множество людей, чуть ли не каждый второй файл исходников имеет "свой стиль". О каком именно "стиле" речь?

Meanwhile, I think Crafty's version will live it's life.
Aha, now are given a free hands :-p
RU:Ага, руки теперь развязаны :-p
 
@Crafty,

Good to finally see you here! Welcome to the forums!

I'm yet to integrate Crafty's work into our "main" branch (that's me and NovaRain). We don't like some of his changes,
Whether what criterion for definition deserves change of honor to be added?
RU:Каков критерий для определения заслуживает ли изменение чести быть добавленным?
There is no honor, only practical considerations. To be honest, I only closely studied the first changes. There were some UI stuff that wasn't optional and it looked like something one player thought would be cool to have for his game. Sfall aimed to add stuff that will be useful for most people. Because tastes are very different, and there are many views of how "perfect fallout" should look like and work. So the best approach in my opinion is to just move as many hard-coded stuff as possible to scripting and/or config files, and not just hard-code complete features in C++. Though, as I said, some of the more small and practical changes may be good.

so ideally I expect him to fork the repo for all his work. And then either we will migrate features manually or (ideally) he will make merge-pull requests (though I doubt it will happen..).
To what me sense to make merge-pull requests (and whether it will unclear deserve chance of addition) if all the same has to be engaged in my version?
RU:Какой мне смысл делать merge-pull requests (и непонятно заслужит ли он шанса на добавление) если всё равно должен заниматься своей версией?
Well ideally, working with forks have several benefits. First, you can integrate stuff from the default branch more easily. Also, a second pair of eyes is always good in my opinion. When other people review your code to integrate into their branch, they basically help you to isolate bugs, and some bad design decisions. Given that you are open to constructive criticism :)

Also when we're working with engine hacks, we can't blindly pull his changes, because you can never understand how the code works without first thoroughly studying the engine code in disassembler, and then figuring out what the hack does and how. Then think if it's a good solution, what possible problems may be caused by it, and so on. Not to mention that some people don't follow coding style of the project they're modifying.
The many people took part in creation of sfall, nearly every second file of sources has "the style". About which "style" the speech?
RU:В создании sfall принимало участие множество людей, чуть ли не каждый второй файл исходников имеет "свой стиль". О каком именно "стиле" речь?
As far as I remember, there was a problem with indentation (we have common indentation style in all source files, if I'm not mistaken). Also, when there are no spaces between operators like if(){, (a>=0) and so on, it's difficult to read the code.

Meanwhile, I think Crafty's version will live it's life.
Aha, now are given a free hands :-p
RU:Ага, руки теперь развязаны :-p

I would love to work together to make perfect sfall version. But the reality is that we live in open-source era. Everyone can do anything with the code. It's a shame when projects like this split into different pieces though.
 
Good to finally see you here! Welcome to the forums!
Thanks a lot :)

There is no honor, only practical considerations.
It can and to the best, don't refuse you to me with my "changes" and probably there would be no my version.
RU:Может оно и к лучшему, не откажи ты мне с моими "изменениями" и наверное не было бы моей версии.
 
@phobos2077 @NovaRain @Crafty @JimTheDinosaur I don't know if this is possible, but what about a setting that centers the screen on each critter during combat? I've always disliked how Fallout doesn't center the screen. For example in the huge fight in Adytum, half the time you might not even know what the hell is going on because it's stretched across about 3 screens. Is there some kind of center_screen_on_obj(self_obj) we can do for each combat action?

The current way it functions is just clumsy and frustrating, and feels "old". (i.e. a proper engine would foresee and avoid such issues)
 
Last edited by a moderator:
Haven't tried controlling other characters yet, it was buggy for me and caused confusing behavior.
 
Guys, I have updated my repo with some small stuff, like config files, etc. Github has an awesome and very easy to use feature called "Issues". If you wanted anything added/changed in sfall and hesitated to ask, or found some bug, feel free to create some issues. It's much better to manage than current "wiki system", as we can quickly discuss stuff, tag it, push to various milestones, etc.
 
Finished translated Crafty's changelog for his sfall versions. If somebody wants to know what he changed links are in my signature.
 
I tried to trigger the 'NPC turns into a container' bug in the game with official sfall 3.6. I use a custom CriticalOverrides.ini to make all critical hit effects for 'men' critters be knockouts.
My test character is an all-10 cheater with both Slayer and Sniper perks. I knocked out Sulik, Vic, and Cassidy, and accessed their inventory while they're unconscious, plus moving to another map quickly before they woke up.
But I can still interact with them normally. Does anyone know if there's any other requirement to trigger the bug, [strike]maybe the knockout has to be done by other critters[/strike]?

EDIT: Nope, I made some super Brahmin and provoked them to attack/knock my NPCs out, but still can't trigger the bug. Now I wonder if the bug still exists in the current 1.02d exe.
 
Last edited:
I tried to trigger the 'NPC turns into a container' bug in the game with official sfall 3.6. I use a custom CriticalOverrides.ini to make all critical hit effects for 'men' critters be knockouts.
My test character is an all-10 cheater with both Slayer and Sniper perks. I knocked out Sulik, Vic, and Cassidy, and accessed their inventory while they're unconscious, plus moving to another map quickly before they woke up.
But I can still interact with them normally. Does anyone know if there's any other requirement to trigger the bug, [strike]maybe the knockout has to be done by other critters[/strike]?

EDIT: Nope, I made some super Brahmin and provoked them to attack/knock my NPCs out, but still can't trigger the bug. Now I wonder if the bug still exists in the current 1.02d exe.
It massively does, I've had it with both vic and goris.
I was playing with the Jinxed trait for the first time when it happened, and I hadn't encountered the bug before that.
Could it be related to critical failures?
 
Last edited:
Back
Top