Fallout 2 mod FO2 Engine Tweaks (Sfall)

I'll try to reproduce when I have time.
Anyway, better to report bugs to github, if you don't want them to be forgotten. Forums are harder to keep track of.

 

sfall 4.3.4 and 3.8.34 are released on SourceForge, along with their respective modders packs.

Note: If anyone is interested in how the engine or some code in sfall works, you can download the IDA databases and check them (require IDA Pro 6.8+, comments are in Russian).

 

Hi,
sfall 4.3.4.7 and rpu v26
When i activate party control=2 after my companion's turn the picture of my weapon doesn`t change. Only after changing hands does the correct one appear.
I remember there was no problem with this in the older version Sfall

 

Try this script.

 

it works - Thank You !!

 

sfall 4.3.5 and 3.8.35 are released on SourceForge, along with their respective modders packs.

 

I found that there is a maximum number of party members I can have join me even though I have fallout2tweaks installed. Under unlimited party, it mentions that "All original game and RP NPCs are already included." How do I fix this?


Edit: on a different note, trying to use the sfall HRP makes my screen pulse whenever an animation plays, giving it an almost sand feel, like worms are moving beneath my screen.

 

sfall 4.3.6 and 3.8.36 are released on SourceForge, along with their respective modders packs.

 

Outdated (possibly)
When I use sfall 4.3.2, and load a save that is on the same map I'm currently on, it fails to play music.
Example, I start a new game, music plays, I save, load and no music. Enter temple, leave temple, music plays. Load save, no music.
So any load of the temple entrance map plays no music if I'm currently on the temple entrance map.
I do not have the problem when disabling sfall. Or when using 4.2.
[Not tested with new version though.]


Second (probably not outdated)
[Edit: Correction. The following assumes that the max DT/DR for EMP is 500/500%, however, it is 100/100%. This error caused the follow up misconception that the "bypass armour" effect does apply unequally, when in truth, it does not seem to apply to the DT/DR of EMP at all.]
I'm pretty sure that if the DT or DR value for EMP is 100 or more it disables the bypassing armour effect on the crit table. If below 100 it enables it.
However, I believe there are two bugs with this:
-First, it's switched. When EMP is 100 or more, bypassing armour effects are enabled. When below 100, bypassing armour effects are disabled.
-Secondly, when it enables bypassing armour effects it does that for all critical effects even those that don't have it.
This is something I got in 1.02d US w & w/o sfall (4.3.2), so it should be a basic engine bug.
Test examples (set-up):
I changed a 10mm Pistol to do 12-12 damage (for consistency) and changed the damage type to EMP.
Next, I gave my character a 100% crit chance, so every hit crits.
I then changed Anna (the ghost in the Den, proto 29) to have EMP resistances of 0/91%.
Test examples (in-game):
In the Den I then fired the 10mm (loaded with AP ammo) at an addict, aka loser model (who has EMP resistances of 0/500%). I expect to do damage of (0, 3, 3, 5).
However, the damage I got was
forceful: 3
piercing/blow: 3
ground: 3
slumps: 5
Which means the "forceful" crit got a bypassing armour effect (which is wrong).
I then shot at the ghost (Anna) who has 0/91% EMP resistances and expect: 4, 9, 12 & 18. What I got was:
forceful: 4
piercing/blow: 4
ground: 5
slumps: 7
Which is a resistance of 0/91% (DR=91-25) but without any bypassing armour effect (which is wrong).
This can be repeated with DT as well, behaves the same. [tested w/ 150/0 (which became 500/0, see following notes, with added bypassing armour effects to all hits) and 50/0 (which got no bypassing armour effects.]
Notes:
DT & DR do this separately. Example, if critting against 500/50% it will apply bypassing armour to DT (as it's above 99), but not to DR (as it's below 100).
And, the engine sets any resistance value for EMP that is above 99 and below 500 to 500. This seems to be an EMP special [other resistances have a max of 100/90%]. So a resistance of 150/0% would become 500/0% in-game.
I spend some time testing this (the above is just a quick summary of a number of tests) but I think I've reached a point that is correct now, that means applying the theory creates correct predictions and repeating the tests shows identical results and confirms the predictions, i.e. seems to be on point.

This is how I calculate damage:
CALCULATION (100% crit)
Damage:
=ROUNDDOWN((min damage+max damage)/2*(ammo modifier)*crit modifier/2;0)
ammo modifier for AP is 1/2, for JHP 2/1
Crit modifier is 3 for forceful & piercing, 4 for ground, 6 for slump
DT (if bypassing armour):
=ROUNDDOWN(DT/5;0)
DR (if bypassing armour):
=DR/5-ammo modifier
=DR/5+ammo modifier
Final Damage:
=(damage-modified DT)-ROUNDDOWN((damage-modified DT)*modified DR/100;0)
You can put these in a spreadsheet, insert the numbers and it will calculate it.

 

@_@

It's very nice to see that someone is willing to make tests such as these.

Make sure to report it here, on the issues tracker: https://github.com/sfall-team/sfall/issues

 

I didn't see special handling of EMP DR/DT for crits in the engine code dump (RE or CE for more readable source code) when the game calculates the damage in combat.
But Anna in RP has the "invulnerable" flag set in her proto, which sets the damage multiplier of critical hits to basic "x2", i.e. no bonus damage from crits. Maybe you should check if she has that flag set in your game, or maybe test the cases on the same critter but with different DR/DT combinations.
Can also use the combat damage hook to print out the details of an attack to check if the corresponding critical effect flags are set for your target.

 

No to all the above.
Except, the damage hook which is still too advanced for me, (art (all of it) & engine) is something I haven't even started to look into yet. [Do want to, but that's another mountain to climb.]

[Edit: Correction. The following assumes that the max DT/DR for EMP is 500/500%, however, it is 100/100%. This error caused the follow up misconception that the "bypass armour" effect does apply unequally, when in truth, it does not seem to apply to the DT/DR of EMP at all.]

However, I did a few more tests (just to be sure) and no change.

Tried Last Hope (1.082), US 1.02d (vanilla, not RP Mod, but w/ HRP & sfall) and GER 1.02d (HRP, no sfall). All behave the same: Crits against EMP resistances below 100 do not get a bypassing armour effect. Only if 100 or more does "bypassing armour" apply.

I even went through the pain of keeping editing to a minimum (i.e. no save editor): I only adjusted the Tough Thug proto (ID 30) to EMP resistance 0/99% and then placed the Tough Thug and 10 Pulse Grenades on the Desert1 map (so it should be pretty default). Picked a character, played through the temple, entered default desert map and lobbed grenades until I got a crit. Which did 5 points of damage (which is multiplied damage, without it I only did 2 damage), but it is too low for a bypassing armour crit against 0/99%, i.e. when a 100-150 damage pulse grenade gets a bypassing armour effect against 0/99% (99/5=19%) it should be about 200 points of damage or more.

I then tested it against robots.
Used Robobrain (proto 75) set him to 0/90% and a Floating Eye (proto 76) (no edit, so it has the default 0/0%).
Again with Pulse Grenades and a 100% crit chance.
Against the Robobrain I did 18 to 24 damage (which is 90% DR, so again the crits got the damage multiplier but not the bypassing armour effect) and against the floating eye I did about 240 damage (which is a crit multiplier and „probably“ without bypassing armour, but a DT of 0/5=0, so bad example).

Keeps confirming itself.
Idk, what else I could change or test atm. It's so universal at my end that anyone emulating the tests should get the same results I'm getting.
-shrug-

 

OK, I overlooked the code. There is a check for EMP when the game calculates the combat damage:

Code:

if ((*flagsPtr & DAM_BYPASS) != 0 && damageType != DAMAGE_TYPE_EMP) {
    damageThreshold = 20 * damageThreshold / 100;
    damageResistance = 20 * damageResistance / 100;
}

The bypass armor critical effect only works when the damage type is not EMP.

 

I made an interpretation error.

I assumed that an EMP resistance above 99 would be set to 500 and then bypassing armour applies (500/5=100), however, it seems that any EMP resistance above 100 is set to 100 (100=100) and that bypassing armour never applies to EMP resistances. [apparently confirmed by code, see above]

That was always a possibility (as in-game it would appear identical, both is 100 before ammo modifier), however, I somehow thought that I checked that possibility, but apparently my tests got muddled (not unusual when still trying to find a pattern), and I thought wrong.
I think I got also mislead by every proto using 500% for EMP, so I assumed it does mean something (500/5 is still 100% even after bypass armour so it did make sense to me), but apparently it's actually pointless to set a proto to anything above 100/100% (or 100/90% in the other cases).

Anyway, I did the tests again (this time also checking "non-crits") and the max for EMP resistances must be 100/100%, not 500/500%. [i.e. if a non-crit can do damage it can't be 500%, but must be 100% minus ammo modifier, which the tests confirmed.]
And in addition the "bypass armour" effect never applies to the DT/DR of EMP.
Penetrate does however.

That should be correct now...

Which means there really is no engine bug [-.-]... it's just a rule (EMP does not bypass armour).

[I edited the posts above with a quick disclaimer pointing out what I got wrong.]

The thing to take away from this is that setting proto files to values above 100/90% or 100/100% is apparently pointless, and that there is no EMP immunity (0/500% is an illusion). It only works because Pulse Grenades have no DR modifier and because of "the engine" blocking bypassing armour effects. That makes 0/500% immune to EMP. However, if you would add an EMP weapon with an ammo that has a DR modifier all "humans" would lose their EMP immunity. [example, 500% becomes 100% and then gets modified 100-25=75%.]
It is probably also not a good idea to give robots EMP DT/DR (as it's immune to bypass armour). Or to be at least aware of it.

My false interpretation may actually be a better rule (if below 100 bypassing armour applies, if above 99 it is set to 500 and bypassing armour does not apply). That would be EMP immunity, except versus weapons with something outlandish like a -401 or more DR modifier. While robots could have some protection against it without becoming borderline immune (as a crit could still break it). Only counter-argument could be that EMP isn't supposed to bypass armour, however, it does allow penetrate.
Idk.
Anyway, this absolute block of the "bypass armour" effect is not a bug, just odd.

P.S. I also did test "invulnerable" and it seems as if it's actually "disabling crits" (entirely; damage multiplier and bypass armour effect) but not actual invulnerability to damage. If I set Anna to 0/0% I can hurt her, and when I use a 10mm pistol w/ AP and a damage of 202-202, I also do 1 point of damage as I can blow through her max of 100/90% even without a crit. However, that's an outlier. Still, that flag should probably be called "immune to crits".

 

sfall 4.3.7 and 3.8.37 are released on SourceForge, along with their respective modders packs.

About dropping support for pre-SSE processors, the affected old processors are:

• Intel - Pentium II, older Celeron (Covington/Mendocino, anything lower than Celeron 533A)
• AMD - older K7 (Athlon Classic/Thunderbird)

I don't know if there are people still playing FO2+sfall on these old machines. I do want to keep a wider hardware compatibility, but to be honest it's not really that practical running the game with sfall on them, especially considering using DX9 modes.
One of the reasons is I don't want to keep my PII potato server running anymore as spare parts are sparse, but I still have three working PIII machines (one Coppermine, two Tualatin) and getting their parts is much easier for me.

 

The following is something I stumbled upon. And I did a few tests on it.

I don't think I'll follow up on this as it doesn't seem overly important. It may hint at a calculation glitch (possibly), but even if, it doesn't seem that relevant, tbh. Still, there may be an engine glitch... see end of notes (i.e. there may be a failing min/max check when calculating HP).

These are my full test notes from start to finish, not a summary.

Conclusion: the above assumes that HP fails to take the min/max for SPECIAL into account.

That's it "so far", not as crisp and developed (i.e. normally I sleep over it, sometimes for months, see if I can think of something), but as said I don't think I'll follow up on this [I lied, added a P.S.S.], and my backlog is growing too much. I think I should push stuff out more even if it's not "finished" as in truth it probably never will.


Then,
there's Something (almost) completely different:
Another "detail" [using 1.02d US w/ sfall 4.3.6]:
When I checked a XP gain of -1.000.000 on a critter, it got reset to 0 XP and skipped the "you gain XP" message. Detail but apparently 0 XP (or a negative amount... both tested), skips over it, rather than displaying "You gain 0 XP for killing Bob". I guess that could be fixed (on a slow day...), especially as it seems to skip 0 XP. [i.e. a negative amount would be fringe zone, but setting a proto to 0 XP is almost within the realm of something someone might do.]


And last, one that is a bit more out there (not sure how I feel about it):
"If I give a critter drugs (that change SPECIAL) then save and load, it will remember the change to SPECIAL, but not to the secondary stats." Example; using booze reduces PE from 5 to 4 and Sequence from 10 to 8. When I then save & load, the critter has PE 4 and Sequence 10.

Code:

procedure look_at_p_proc begin
display_msg("I have " + get_critter_stat(self_obj, 1) + " Perception!");
display_msg("I have " + get_critter_stat(self_obj, 13) + " Sequence!");
end

This is similar to a "map_enter", i.e. critters do reset their proto back to default on every map_enter. When doing so the engine does not recalculate secondary stats, but just uses base+bonus (ignoring SPECIAL). The only thing, as far as I can tell, that causes a recalculation of the derived stats (taking SPECIAL into account), is a change to SPECIAL (as, for example, drugs-use does).
However, I'm not sure if messing with this is a good idea.
Although adding a recalculation of secondary stats on loading a game could make sense. At least that shouldn't cause any follow up issues (as SPECIAL already is reduced in the load, it just doesn't reflect on the derived stats).
However, adding the same recalculation to map_enter [which I think the engine actually should also do] would cause compatibility issues with old mods that set up their proto files incorrectly (i.e. editing the base of secondary stats or failing to edit secondary stats after editing SPECIAL). Those mods already are buggy (due to the nature of the faulty proto files), but would become even more unstable in some cases if map_enter would recalculate the base of secondary stats. [i.e. it would overwrite all the "edited" values [example; 999 base HP] with the "correct" ones [example; 34 base HP, according to ST 7 & EN 6.] This is not as concerning during loading a save, as that base HP [example; of 999] is already glitched by the drug-use [changes to SPECIAL do reset max HP (tested), it just ignores any extra/bonus to SPECIAL]. Then again, loading the save [just as a map enter] would reset the critter back to default [in this case back to the proto's 999 HP]. So...?
Anyway, the current behaviour is that feeding a critter booze, then save & load, will keep PE down (as well as Skills, as they do get recalculated, probably as they have no base [tested w/ Buffout]*) but not secondary stats like Sequence (those reset).
*Tbh, I don't know why secondary stats even have a base value. Basically they should function like Skills which are always (SPECIAL + Skill bonus).
Used the following w/ Buffout (should show that skills & ST stay the same after a load, only 11 & 12 reset):

Code:

procedure look_at_p_proc begin
display_msg("I have " + get_critter_stat(self_obj, 0) + " Strength!");
display_msg("I have " + get_critter_stat(self_obj, 7) + " max HP!");
display_msg("I have " + get_critter_stat(self_obj, 11) + " Melee Damage!");
display_msg("I have " + get_critter_stat(self_obj, 12) + " Carry Weight!");
display_msg("I have " + has_skill(self_obj, 3) + " Unarmed!");
display_msg("I have " + has_skill(self_obj, 4) + " Melee Weapon!");
end

P.S. This behaviour does not apply to the dude or Fo2 companions. Only generic critters. And in Fo1 it doesn't even remember the change to SPECIAL (resets both PE & Sequence etc.).
Not sure what can be done about this, or if anything should be done about it...

 

Since my issue on sfall's github page was closed claiming that .mp4 h.264 support is built in if proper codecs are present...
Can I at least get a list of Compatible codec packs?

I know for certain that "Combined Comunity Codeck Pack x64" or CCCP as its nicknamed is not working for sfall, does anybody tried to run a direct show video with sfall and it worked? if so what codecs were you using...

If it actually works I'm going to toy around with existing fallout videos ( originals and mods) in FHD res using machine learned AI for upscaling videos, some of them cough Resurrection cough would really benefit from this.

 

What happened to the project? All the latest builds are removed from SourceForge

 

Probably SourceForge rollbacked the database by some accident. Now there are only versions up to 4.3.0.2.

 

For SFALL? Works fine on GitHub - https://github.com/sfall-team/sfall/releases

Oh, I see what you mean. For a build, it uses SourceForge and it gives up with an "Unable to find any mirror information for the "/sfall/sfall_4.3.7.7z" file. Please select another file." error.

It looks like downloading the newest release doesn't work, but you can still download it (at least I presume it is it) manually via this link https://sourceforge.net/projects/sfall/files/sfall/sfall_4.3.7z/download

It almost looks like the releases on sourceforge have an additional ".7" in their names.