Fallout 2 mod FO2 Engine Tweaks (Sfall)

Why exactly, Drobovik? Concerns the downloads wouldn't work right?



…Also, another thing to ask for with Sfall 3.7 is the possibility to barter with NPCs while moving any companion's inventory into dude_obj's one so I for example don't have to take the flamethrowers Marcus carries, when I also really cannot old onto them all. It should be as easy as moving store inventories from the trader to them when bartering:
Code:
if (Ian_in_party) then begin
move_obj_inven_to_obj(pid_ian,dude_obj)
…Too bad it'd result in either my character's entire inventory gets dumped into Ian's, or even vice versa.
 
Last edited by a moderator:
I have an Sfall question for all you talented modders. Personally, I usually play with speed somewhere between 108 and 120. However, this cuts off Ron Perlman's voiceovers in the endgame slideshow, due to how the game calculates wait time in such sequences.

Is it possible to modify Sfall to prevent this issue? Playing the game at 100 to me is intolerable but I can't set it higher than 100 for Fixt because of this issue.

I am not sure if @Timeslip or @Crafty or someone else has the answer. Maybe someone does :)

DDRAW.INI said:
;The initial speed at game startup
SpeedMultiInitial=120
 
Last edited by a moderator:
Yeah, big thanks for the new features. The display of rest weight, when looting containers is brilliant. I already thought about this. Same for PipBoy scrolling, top.

Perhaps i have an further idea for optimizing pipboy:

I looked into data/data/quests.txt and found these lines:

#####
# New Reno Quests
#####
# Find who killed Mr. Wright's son.
1507, 801, 286, 1, 2
# suspect: Jagged Jimmy J
# 1507, 802, 543, 1, 2
# suspect: Jules
# 1507, 803, 544, 1, 2
# suspect: Lil' Jesus Mordino
# 1507, 804, 545, 1, 2
# suspect: Renesco
# 1507, 805, 546, 1, 2

I think this was foreseen but not implemented. A multiline quest entry, which can be controlled by multiple global variables.

I already posted this idea as question (if possible and how) in FO General Modding forum. But here i post it as suggestion :)
 
But wouldn't it work if you simply uncomment the other variable lines? Quest text in the pipboy is sorted in that order, so setting the variables to their start / end state should do what you want, no?

/Edit: ok, I just read your post in that other thread.
 
Last edited:
I found out today that you can set the damage of the explosives through the SFall ini:
Dynamite_DmgMin=30
Dynamite_DmgMax=50
PlasticExplosive_DmgMin=40
PlasticExplosive_DmgMax=80
But those aren't in the ini by default, I had to go through Phobos' old Sfall commits and find out what they were called in main.cpp. Perhaps you could consider putting them in the ini?

Also, I noticed they're writing to memory addresses. I'd really like to be able to modify them programmatically, such as making the damage depend on your Traps skill.
Can I use sfall's write_int to write to those same addresses, if I turn Unsafe Scripting on?
 
I found out today that you can set the damage of the explosives through the SFall ini:
Dynamite_DmgMin=30
Dynamite_DmgMax=50
PlasticExplosive_DmgMin=40
PlasticExplosive_DmgMax=80
But those aren't in the ini by default, I had to go through Phobos' old Sfall commits and find out what they were called in main.cpp. Perhaps you could consider putting them in the ini?

Also, I noticed they're writing to memory addresses. I'd really like to be able to modify them programmatically, such as making the damage depend on your Traps skill.
Can I use sfall's write_int to write to those same addresses, if I turn Unsafe Scripting on?

This is indeed strange. Why would this be removed from the ini? It could just as easily be commented out by default. I've encountered this in the past several times, where still-functional and definitely-useful features are deleted from the ini. At the time, I could not locate any documentation of the removal, nor a justification of such. In my opinion this is kind of retarded and doesn't help any of the players. Why the lack of transparency?
 
I found out today that you can set the damage of the explosives through the SFall ini:
Dynamite_DmgMin=30
Dynamite_DmgMax=50
PlasticExplosive_DmgMin=40
PlasticExplosive_DmgMax=80
But those aren't in the ini by default, I had to go through Phobos' old Sfall commits and find out what they were called in main.cpp. Perhaps you could consider putting them in the ini?

Also, I noticed they're writing to memory addresses. I'd really like to be able to modify them programmatically, such as making the damage depend on your Traps skill.
Can I use sfall's write_int to write to those same addresses, if I turn Unsafe Scripting on?

This is indeed strange. Why would this be removed from the ini? It could just as easily be commented out by default. I've encountered this in the past several times, where still-functional and definitely-useful features are deleted from the ini. At the time, I could not locate any documentation of the removal, nor a justification of such. In my opinion this is kind of retarded and doesn't help any of the players. Why the lack of transparency?
Well, this particular one has been around since 3.4, but it wasn't in the 3.4 ini either. In the code it mentions that this is a quick hack job, so maybe they were planning on adding it to the default ini when they've tested it a bit more?

It is mentioned in the 3.4 changelog though.
 
This is indeed strange. Why would this be removed from the ini? It could just as easily be commented out by default. I've encountered this in the past several times, where still-functional and definitely-useful features are deleted from the ini. At the time, I could not locate any documentation of the removal, nor a justification of such. In my opinion this is kind of retarded and doesn't help any of the players. Why the lack of transparency?
Timeslip removed some still functional settings from sfall since 2.8.
If you want an INI with (nearly) full options, check the ddraw_adv.ini in modders pack.
 
@NovaRain Ah good, I'm glad to know there's documentation somewhere of the removals and an inclusive version of the ini. Maybe she had tons of bug reports in the past and it turned out was just from people mucking around with things they didn't understand? I suppose that's reasonable. I can't know her motivations and justifications for these removals.

However, I think a better solution to this...
Timeslip said:
Removed from ddraw.ini, but which will still be recognised if they're readded:
DialogueFix, GainStatPerkFix, BlackSkilldexFix, SaveInCombatFix, SingleCore
...would be to make ddraw.ini entries look like this:
Code:
[Deprecated]
;WARNING: NO LONGER SUPPORTED! IF YOU CHANGE THESE AND SOMETHING BREAKS, YOU ASSUME FULL RESPONSIBILITY.

;--BUG REPORTS REGARDING THESE SETTINGS WILL BE IGNORED--

;Prevent pressing "0" to exit dialogue.
;DialogueFix=

;GainStatPerkFix=

;BlackSkilldexFix=

;Prevent saving in combat.
;SaveInCombatFix=

;Force Fallout to only use one CPU core.
;SingleCore=

Specifically this is important for two reasons I can think of off the top of my head:

1) Pressing 0 to end dialog is something I use all the time during modding. I use it every time I am running a testing session. But I would want it disabled in all user installs, because it's a massive exploit. See the problem?

2) Prevention of saving during combat is really annoying. I save during combat in Fallout all the time. The lack of documentation and lack of ability to disable this (without doing some digging and manually adding it to the ini) is basically saying "I don't trust you to make the choice to disable a fix that could be understandably annoying and confusing to you" which is... questionable.

My example of code above is a good compromise. It clearly provides the settings, making them easy for power-users and modders to change, but also clearly warns the consequences of messing with them. It also communicates that you trust people to make their own choices :) I believe that more options is always better than less options. The assumption should be that your users are intelligent and responsible and unique, and thus will appreciate being able to personalize their experience.
 
Last edited by a moderator:
SaveInCombatFix is defaulted to 1, which you can still save in combat if you don't spend any AP yet.
 
@Crafty got new update. With a bit of luck and his great know-how he might have these bugs squashed soon:

CONFIRMED If you give a critter tons of super stims in hopes of killing it, and then leave the map, the game will crash when it tries to kill the critter. Engine issue. --FIXED
CONFIRMED NPCs hooked on jet becomes utterly useless — stuck with 1 AP. Jet antidote doesn't work on them. Engine issue. --FIXED
CONFIRMED Ability to gain too high stats from drug use — use drug twice, save and load and you can use drugs to raise your stats even more. Engine issue. --FIXED
CONFIRMED Drugs used on one critter will affect all critters of that same type (i.e. look the same). Engine issue.
CONFIRMED NPCs leveling up while under drug influence don't end up with correct stats — it checks the current stats and not base stats. Engine issue.
CONFIRMED A game saved in combat where one of your NPCs has died will become corrupted. Engine issue.

Also now text color under Health line in party member controls changes from green to red if he/she is addicted to any drug. If you use jet on them for example)

And F1 engine was treated with the same drug addiction fix as well

Links still are here (F2). And here (F1)

All hail, Crafty!!!
 
Last edited:
CONFIRMED Drugs used on one critter will affect all critters of that same type (i.e. look the same). Engine issue.

Just to be clear what he of course doesn't mean is FRMID, but PID. Everytime one "loser" in the Den takes Jet, all of them get affected (and get unaffected the moment you save/load or leave the area). The reason for this is that individual objects exist only in a relatively limited capacity in the engine: each critter has his own health (that's why one critter using a stimpak doesn't affect another one with his PID) but doesn't have his own SPECIAL stats (which is why, say, mentats do affect every critter with the same PID).

I don't think there's any realistic way of addressing this issue other than giving every individual critter SPECIAL stats through LVARS, and rewrite drugs to affect those rather than the PID's. Not really a realistic prospect tho.
 
What. I didn't even know this. :D

For my mod I did a simple workaround, though... (regarding the drugging of NPCs... that was a common tactic since ever) Wrote a macro that is includet into *any* critter which simply does not allow the player to use drugs on them. Trying to will just spawn a text message like "this does nothing" and cancles the use (so the item won't disappear) and that's it. Problem solved.

/Edit:
Code:
procedure use_obj_on_p_proc begin
/* npc will ignore, if player uses item x on him... */
   npc_no_alcohol
   npc_no_illegal_drugs
   npc_no_steroids
end

Code:
#define npc_no_alcohol                 npc_item_used:=obj_pid(obj_being_used_with);                \
                                       if ((npc_item_used == PID_BEER)                             \
                                          or (npc_item_used == PID_BOOZE)                          \
                                          or (npc_item_used == PID_GAMMA_GULP_BEER)                \
                                          or (npc_item_used == PID_ROENTGEN_RUM)) then begin       \
                                          script_overrides;                                        \
                                          display_msg(npc_item_used_mstr(10071));                  \
                                       end 
                                       
#define npc_no_illegal_drugs           npc_item_used:=obj_pid(obj_being_used_with);                \
                                       if ((npc_item_used == PID_JET)                              \
                                          or (npc_item_used == PID_RADAWAY)) then begin            \
                                          script_overrides;                                        \
                                          display_msg(npc_item_used_mstr(10072));                  \
                                       end

#define npc_no_steroids               npc_item_used:=obj_pid(obj_being_used_with);                 \
                                       if ((npc_item_used == PID_MENTATS)                          \
                                          or (npc_item_used == PID_BUFFOUT)                        \
                                          or (npc_item_used == PID_PSYCHO)                         \
                                          or (npc_item_used == PID_SUPER_STIMPAK)                  \
                                          or (npc_item_used == PID_HEALING_POWDER)) then begin     \
                                          script_overrides;                                        \
                                          display_msg(npc_item_used_mstr(10073));                  \
                                       end


This stuff actually reminds me about how much work I've put into my Fallout 2 mod... I've added a shitton of such details to the game (even multiple currencies are available - added NCR dollar and bottlecaps, *before* New Vegas was out). Fuck, I really need to pick it up again. :/

/Edit: Hehe. Just another thing: If you had a critical failure with a flamer and it exploded in your hands, you would get a "burned" status effect, which could only be removed by a doctor. I love this stuff, because it's such a tiny detail... I mean, how many of you ever had the flamer explode while using? It usually doesn't happen that often...
 
Last edited:
What. I didn't even know this. :D

In case anybody's interested in what is and what isn't registered by the game, check http://falloutmods.wikia.com/wiki/SAVE.DAT_File_Format and http://falloutmods.wikia.com/wiki/MAP_File_Format for a (partial) list.

The former file saves pretty much everything (so including SPECIAL stats) concerning party members and the dude, while the latter saves on a map by map basis (as .SAV, but in the same format as .MAP) only certain bits and pieces of information (such as ammo counts, current HP, and crippled statuses, which the above page omits for some reason).
 
I mean, how many of you ever had the flamer explode while using? It usually doesn't happen that often...
Fair enough, but it does happen more often if you set all weapon critical fail tables to higher than default values :wiggle: IIRC default for Flamer is 5, you can set to 6.

Playing with Jinxed is a dickshitload of fun. I'm surprised more people don't use it. Once you have >100% in weapon skills, critical failures are pretty minor even with that Trait, and in any case it makes combat no longer be "Guaranteed Wins Every Time With Decent Stats & Skills" so that's a big plus as well.
 
Last edited:
Back
Top