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.
Changelog said:
v4.3.4
>HRP: Fixed a few issues with the main menu
>HRP: Added support for LocalMapXLimit/LocalMapYLimit options in ddraw.ini
>Removed FadeBackgroundMusic option because the fix in 4.3.3 doesn't work reliably in all cases
>Added a fix for being unable to plant items on non-biped critters with the 'Barter' flag set (e.g. Skynet and Goris)
>Updated the ammo ini loader mod in the modders pack
Click to expand...
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).
 
Last edited:
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
 
sfall 4.3.5 and 3.8.35 are released on SourceForge, along with their respective modders packs.
Changelog said:
v4.3.5
>HRP: Fixed movie subtitles not showing up when setting MOVIE_SIZE=1 with certain combinations of screen and movie aspect ratios
>HRP: Disabled IFACE_BAR_WIDTH and SCALE_BUTTONS_AND_TEXT_MENU for a modified fallout2.exe with Chinese/Japanese support to prevent garbled text
>HRP: Added support for SPLASH_SCRN_TIME option in f2_res.ini
>Fixed the handling of obsolete script functions that are still recognized by script compiler and decompiler
>Fixed NPC combat control mod not redrawing the interface bar properly when it's the player's turn again
>Improved the fix for updating the HP stats of critters on the map when loaded for the first time
>Removed DivisionOperatorFix from ddraw.ini because there is little reason to turn it off
>Removed ComputeSprayMod from ddraw.ini. Now ComputeSpray_* options no longer require a master switch
>Added a fix for a crash when the player equips a weapon overloaded with ammo
>Added a fix for being able to use the 'Push' action on members of the player's team in combat when they are knocked down
>Added missing sounds for the markers on the world map interface (similar to Fallout 1, from Ghosthack)
Click to expand...
 
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.
 
Last edited:
sfall 4.3.6 and 3.8.36 are released on SourceForge, along with their respective modders packs.
Changelog said:
v4.3.6
>Minor code fixes and improvements to sfall and engine functions
>Fixed UseWalkDistance having no effect when trying to use a ladder
>Fixed float_msg script function not setting the purple or black text color correctly
>Changed the mode 1 of NPC combat control mod to require sfall debugging mode to control all critters in combat
>Added a fix for NPC stuck in a loop of reloading the solar scorcher when out of ammo
>Added an option to NPC combat control mod to allow the player to gain a positive reputation while controlling other critters
>Added a boundary check to set_terrain_name script function
>New script function: get_terrain_name
Click to expand...
 
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.
 
Last edited:
Muttie said:
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.
Click to expand...

@_@

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.
 
NovaRain said:
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.
Click to expand...
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-

P.S. she said:
Another thing I did test w/ Anna was if her resistances for other damage types (normal, electric etc.) are really 500/500% or if they get reduced to the max of 100/90% (something you can see in mapper when you open her inventory, there all her resistances are displayed as 100/90%). And according to the numbers I've got in-game, that seems to be correct. With the exception of EMP (as mentioned above) which I've checked by calling her stats via script „example: display_msg("I have " + (get_critter_stat(self_obj, 22)) + " EMP DT!");“ and it claims to be 100/100% but it actually seems to be 500/500%. [Test: I checked her by using a 101-101 10mm pistol (w/ AP ammo) & EMP damage, while having a 100% crit chance, against EMP resistances of 105/0%. When I get a "slump" crit (i.e. a damage multiplier of 3) I got 51 points of damage [damage is 101/2 (AP)*3 (crit)=151,5 (rounded down) to 151] which means she has a DT of (500/5=100) and not a DT of 105 or 105/5=21, so it seems to adjust her DT of 105 to 500). DR does the same.]
I also tested this with the proto from RP mod (2.3.3, which does not have the invulnerable flag set, btw) which has set her to 999/999% to see how that changes, and there all her resistances became 100/90%, except EMP which remained at 999/999%.
Click to expand...
 
Last edited:
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.
Changelog said:
v4.3.7
>Dropped support for older pre-SSE processors in favor of more optimized code. Now sfall requires a processor with SSE support
>Fixed a bug that could prevent loading files from the art\<language>\ directory
>Fixed REMOVEINVENOBJ hook to match the values of RMOBJ_* constants correctly
>Fixed NPC combat control mod not setting the lighting of controlled critters correctly in some cases
>Expanded set_pipboy_available script function to match PipBoyAvailableAtGameStart option
>Expanded message_str_game script function to support editor.msg file
>Increased the default number of sound buffers available for sound effects from 4 to 8
>Changed the way AllowDShowSound works. Now mode 2 is combined with mode 1
>Removed MoreTiles from ddraw.ini. Now the maximum number of tile FRMs is always 16383
Click to expand...
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.
I used 1.02d US w/ sfall 4.3.6 [edit: and w/o, so it's not sfall] and started a new game w/ Narg.
He has 44 HP=15+ST (9)+(2*EN (10)).
Then I open F12se and adjust his base ST to 100.
Back into game, I open the character screen (causes a recalculation of secondary stats) and Narg has a max HP of 136.
Isn't this wrong?
Even weirder, why does it adjust to 136? Even when it skips the SPECIAL max of 10 it should be 135=15+ST (100)+(2*EN (10))? Why 136?
[edit: (speculation) could be: HP (44)+100-ST (9-1 for Gifted)=136... sounds strange but adds up. Gifted is weird though... but apparently it isn't added to the base stat, see below.]
...
I checked again (same thing, just disabled Gifted).
Then Narg had 41 HP=15+ST (8)+(2*EN (9)) and 133 after editing (i.e. setting base ST to 100).
[edit: could be: HP (41)+100-ST (8)=133.]
...Did a third attempt (non-Gifted again) but this time edited EN to 100, and he ended up with 223 HP.
So Narg had 41 HP=15+ST (8)+(2*EN (9)) and 223 after editing (i.e. setting base EN to 100).
[edit: could be: HP (41)+(2*100)-(2*EN (9))=223.]
...
Btw, when I adjust "bonus" ST etc. it behaves fine, caps at the max of 10 and max HP does not adjust, which is correct (i.e. HP is the one secondary stat that does not adjust with Drugs or Power Armour; aka it does ignore any bonus/extra to ST or EN).
...
Did another clean check:
Took a new character, set LK to 10 and picked the bottom three skills.
Then created 4 saves and set base/bonus of ST & EN to 100.
It all seemed correct (melee, carry weight, HR, poison/rad resistances & skills; all used the max of 10 for SPECIAL). However, HP is (15+ST (5)+(2*EN (5))=30 and changed to:
100STBase: 125 (so +95) --- HP+100-5 (ST)?
100STBonus: 30 (correct; bonus shouldn't influence HP)
100ENBase: 220 (so +190) --- HP+(100*2)-10 (EN*2)?
100ENBonus: 30 (correct; bonus shouldn't influence HP)
...
And another
Took a new character, set LK to 8, ST & EN to 6 and picked the bottom three skills.
Then created 4 saves and set base/bonus of ST & EN to 225.
It all seemed correct (melee, carry weight, HR, poison/rad resistances & skills; all used the max of 10 for SPECIAL). However, HP is (15+ST (6)+(2*EN (6))=33 and changed to:
100STBase: 252 (so +219) --- HP+225-6 (ST)?
100STBonus: 33 (correct; bonus shouldn't influence HP)
100ENBase: 471 (so +438) --- HP+(225*2)-12 (EN*2)?
100ENBonus: 33 (correct; bonus shouldn't influence HP)
...
Makes no sense, really.
Seems as if the engine takes current max HP, adds the new base value (multiplied by 2 in case of EN) and then subtracts the "old" base value from it... Seems strange. Adds up, but I'm not sure this can be right.
Still, why doesn't it just reduce the new base stat (i.e. ST/EN of 100 or 225) to the max of 10? Anything else (melee, carry weight, HR, poison/rad resistances, skills) seems to.
HP is special though (i.e. not influenced by drugs etc.). Maybe there is a glitch in how it's calculated.
Which could be as simple as a max check that is missing or not working correctly (i.e. if above 10, treat as 10), anything else (as said) seems to do that. [Note: even when I save the game, the base continues to be 100 or 225, but all the secondary stats treat it as 10, except HP).]
Could be... maybe it's supposed to be:
HP+(new ST: 225 IF > 10 THEN 10 ELSE 225)-(old ST)
And
HP+(new EN: 225 IF > 10 THEN 10*2 ELSE 225*2)-(old EN*2)
Does that make sense?
Still seems strange, but it would add up.
...
P.S.
The only question mark is Gifted in the first example. Not sure what to make of it. Did a quick test with the same numbers (repetition is crossed out):
Took a new character, set LK to 10 and picked the bottom three skills. THEN I took Gifted, reduced ST & EN [and LK] by one and added it to CH.
Then created 4 saves and set base/bonus of ST & EN to 100.
It all seemed correct (melee, carry weight, HR, poison/rad resistances & skills; all used the max of 10 for SPECIAL). However, HP is (15+ST (4+1)+(2*EN (4+1))=30 and changed to:
100STBase: 126 (so +96) --- HP+100-4 (ST)?
100STBonus: 30 (correct; bonus shouldn't influence HP)
100ENBase: 222 (so +192) --- HP+(100*2)-8 (EN*2)?
100ENBonus: 30 (correct; bonus shouldn't influence HP)
?
Summary (from the two tests above):
100STBase: 125 (so +95) --- 30 HP+100-5 (ST)? : this is Non-Gifted (ST 5 & EN 5)
100STBase: 126 (so +96) --- 30 HP+100-4 (ST)? : this is Gifted (ST 5 & EN 5)
Seems as if Gifted is not added to the base stats, and consequently, gets somehow skipped in all this...? 1 HP more... Which means assuming the above is true:
HP+(new ST: 225 IF > 10 THEN 10 ELSE 225)-(old ST)
And
HP+(new EN: 225 IF > 10 THEN 10*2 ELSE 225*2)-(old EN*2)
it would create a +1 glitch for Gifted. Or it needs to be 9 if Gifted...
HP+(new ST: 225 IF > 10 THEN IF Gifted THEN 9 ELSE 10 ; ELSE 225)-(old ST)
And
HP+(new EN: 225 IF > 10 THEN IF Gifted THEN 9*2 ELSE 10*2 ; ELSE 225*2)-(old EN*2)
...
Next (Same w/ Endurance):
100ENBase: 220 (so +190) --- 30 HP+(100*2)-10 (EN*2)? : this is Non-Gifted (ST 5 & EN 5)
100ENBase: 222 (so +192) --- 30 HP+(100*2)-8 (EN*2)? : this is Gifted (ST 5 & EN 5)
...
Adds up, but...?
Also does it matter? I mean can this ever happen outside using F12se? Maybe if adding to base ST via script...? Uhu... [yep, well, at least it does adjust max HP. Not checked adding an amount that takes it above the max of 10 though. But that should start to glitch... in theory.]
Anything else besides Gifted...? Lifegiver (part of current max HP, I guess)...
How do the other secondary stats handle this? Shouldn't it be enough to check those and then copy & paste whatever they do right (regarding the max of SPECIAL & Gifted), and which HP isn't? Assuming it is a failing max check... should be, though. I mean what else, right?
…
P.S.S.
Did a quick check w/ -100 base values and it also glitched. Did set me to 0 HP (death*) although I should have some HP (even w/ both ST & EN reduced to their minimum of 1). Gifted made no difference (also 0 HP), but that's probably as the total HP was negative and got reset to its minimum of 0. If interested one can experiment with setting a character to -100 base ST or EN and bonus HP to 999 (the max) that seems to create some interesting numbers (in one case I had 930 HP... so it does add/subtract something). Anyway, same as above, adjusting base ST & EN to -100 glitches HP, while the other secondary stats (carry weight, heal rate etc.) handle it fine (get reduced to a value that is based on the minimum of SPECIAL, i.e. carry weight drops to 50 (ST 1) and heal rate to 1 (EN 1), and not to 0 (the actual minimum of carry weight & HR), so they treat -100 ST as ST 1, just as HP should, I think).
*death: this doesn't kill instantly. You need to toggle C [character screen] a bit before it triggers. Note: toggling C triggers a recalculation of secondary stats (HP, carry weight etc.) which then adjusts the HP on the interface, values on the inventory screen and eventually death. Once being set to 0 HP, it also knocks out the script (dude_obj), i.e. looking at myself stops working and also looking at anything else (no display message), bit messy by the nature of 33/0 HP being a peculiar state and the engine adjusting to it gradually). Btw, all tests were made w/ a new character at the Temple of Trial entrance.
Note: Reducing a SPECIAL stat to 0 during radiation sickness is death... but I guess "radiation" is special, while the above is the standard (i.e. things like drugs, script (?) or F12se "accidents" (etc.) can't reduce SPECIAL below its minimum of 1)... I think?
There is probably a lot more one could check (like NPC critters)... but, worth it?
Click to expand...
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.
 
Jumbo1682 said:
What happened to the project? All the latest builds are removed from SourceForge
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top