Fallout 2 mod FO2 Engine Tweaks (Sfall)

... or simply begin to use F2Explorer, not only a savegame editor but a powerful all around tool ^^"

 

OK: "There's no error. F12se just can't read sfallgv.sav correctly."

Sorry, I didn't pick that up from the text. My bad.

Something else:
Was experimenting with SPECIAL, killap's hintbook script and "stuff" in WM2 (using Sfall 4.3.7) and the second Dermal upgrade reduced CH by -2. I disabled sfall and it was only -1.
Only difference I can tell is that sfall now adds a rank after the Dermal (2), maybe a side effect...?
Same applies for the other one, the Phoenix one. Same thing. -2 w/ sfall, -1 w/o
...
Should be an error, unless this is on purpose, but I checked the sfall readme and I found nothing. And I think, a balance fix like this would be mentioned.

 

I tried adding the perks with save editor or doing the surgeries in-game in RPU, each of the "enhancement" combat implant reduces CH by 1 as they should.

 

@Nova i think the Bug that Muttie wrote about is related to Wasteland Merc mod only. Since wasteland Merc was designed b4 any sfall saw daylight, i think it has it's own way to handle the oprations, a.k.a by scripts, and sfall does this by engine, and hence when one applies sfall to wasteland merc you get double -1 CHA penalty, hence the -2 for a single enhacment operation. It houldn't be a big deal though, one can have up to 10 operations per special stat in Wasteland Merc mod. the only limiting factorsa for them is getting ahold of the correct chip module, and having enaugh caps.

 

@NovaRain Thanks for checking.

Had another look and apparently it is a script bug that gets enabled by sfall.

This is the code

critter_rm_trait(dude_obj, 0, 76, 1);
critter_add_trait(dude_obj, 0, 77, 2);​

And the error is to set the added trait to rank 2 (should be 1).

However, this does work out fine with the original engine (i.e. sfall disabled) but not with sfall (which adds a rank (2) to the perk name and reduces CH twice, but still only gives +10% DR (because hardcoded?)).

It's never easy, is it? I thought once disabling/enabling sfall it's clear cut.

Anyway, it needs to fix the script, but considering that sfall enables the bug, maybe there is room to handle it better? (especially considering that it seems the rank influences CH decrease, but not the DR increase). But that's as it may be, the issue is with the script (eventually), but the original scripter didn't do anything wrong really as it must have worked when they did it. Can't blame them for not spotting that.

 

critter_add_trait(who, trait_type, trait, amount)
Before 4.2.1, calling "critter_add_trait(dude_obj, 0, 77, 2)" is the same as "critter_add_trait(dude_obj, 0, 77, 1)", which only add one rank of the perk.
And yes, the DR bonus is hardcoded in the engine, which only checks if player has the perk.

 

Here is another weird one:

WM2 sets the Alien Warlord to have a base HP of 50.000.
In game this gets reduced to the max of 999.

However, the current HP stays at 50.000 when using sfall (4.3.7) but gets reduced to the max of 999 when disabling sfall.

This is sfall hitting the warlord for 2584 damage, which only reduces it down to 999/999 (however, that's vanilla behaviour):


This is w/o sfall hitting the warlord for 60 damage. So it truly is set to the max of 999 and not just a visual bug.


So it seems sfall enables current HP to be above the max (if the proto is set as such), while the vanilla engine does not.


If you need a quick test, here is the WM2 game I was using: https://easyupload.io/bh3o8h
(full game, I only removed critter.dat and master.dat, the save is 09 (called DoubleChecking; ready to go to the Lair) another is under 02 (called Test; just about to face the Warlord; which was loaded w/o sfall so it has 999/999 HP)). Both saves were made w/o sfall.
There is also a Dev Room which allows to get to any point in the game, but I'm not sure how easy that is w/o knowing how WM2 works... anyway, you can quickly check the HP by just toggling sfall, load either save (2 or 9), exit map, enter Lair and check the silver alien. Should adjust as above.

Special Note: The build is currently using the original proto files, which adjust base HP, so you can make them glitch by giving the Warlord beer (resets HP to 999/43). That's how I tested if vanilla behaves the same as sfall, and it does (any damage > 0 and it drops to 43/43), so it seems, the only difference is the disabled max check for current HP.

Anyway, not sure if there is a reason or anything, I was just surprised that the 50k HP is a sfall thing. While vanilla seems to cap it correctly...

 

I bashed my had against this for the past four days.
These are my notes, maybe something is interesting.

[transfer_pid_between_objs]
[transfer_all_pid_between_objs]
[remove_pid_qty]
-can detect all items (inventory, handslot, worn).
-but only move what they can find in inventory and ignore the rest (handslot & worn) (bug).
-if nothing is in inventory it will remove a single item instead. The order to select this item is: handslot item1, handslot item2, worn. And last: (oddity: picked up items*). If this happens it (may) remove the item incorrectly (bug). That means it may not clean up animation (weapon & armour; minor bug) and may not reset DT/DR (armour; bug).

*ODDITY: an item (or items) dropped to the ground and picked up again, are not part of the inventory until opening/closing inventory. So in the case of the bug the engine will check handslots and worn first, and the picked up items last. [note: only if the picked up items do not already exist in inventory. If they do, the picked up items get added to that stack and removed with it. But if it's a new stack, the whole stack of items is in “limbo”. Until opening/closing inventory.]
**ODDITY II: This is more vague, but it's possible that an item moved from handslot to inventory via [inven_unwield] will enter the same limbo state as the picked up item.
I did run [inven_unwield] before [remove_pid_qty] and it would put the item in limbo, but when I used [rm_obj_from_inven plus add_obj_to_inven] instead [inven_unwield], it didn't. May have been bad scripting on my part. Used this:

if (critter_inven_obj(dude_obj, 2) or critter_inven_obj(dude_obj, 1)) then begin
metarule(43, dude_obj);
end​

which does unwield but may not do it correctly... not sure. Anyway, [inven_unwield] may be another potential case.​

Btw, I also tested this w/ [rm_mult_objs_from_inven] only, see AcMorlis.int (node007). She wants three Healing Powder and you can hide two on your handslots.
[You can also test the pick up limbo with her: Put one powder on handslot and drop the other two. Then pick the two up again. And deliver. And it will only remove the one from handslot.]

Tests done w/ sfall 4.3.7. And confirmed w/o it. This should all be vanilla behaviour.

Fixes:
-The first [incorrect removal] can be fixed by adding a "proper" [remove_armor] and [inven_unwield] check into the code.
[Notes: The transfer command misses it entirely. The check in [remove_pid_qty] uses self_obj for [critter_inven_obj] (instead of who_obj) so it does not adjust to dude_obj. This creates a bug w/ [remove_armor], i.e. it removes the armour but does not reset DT/DR or clean up animation.]

Note: may also use [rm_obj_from_inven] or [move_obj_inven_to_obj] which do this [i.e. unequip] correctly, and w/o any addition to the code.​

-The second [ignoring items on handslot and armour]... I only managed to fix with this:
#define remove_pid_qty_proper(who_obj, the_pid, pid_qty)

counter := 0; \
while (counter < pid_qty) do begin \
restock_obj := obj_carrying_pid_obj(who_obj, the_pid); \
rm_obj_from_inven(dude_obj, restock_obj); \
destroy_object(restock_obj); \
counter := (counter + 1); \
end​

And

remove_pid_qty_proper(dude_obj, PID_COMBAT_ARMOR, 5)
scr_return(1);​

Which seems to work so far.

-The limbo thing is beyond my scope.
[Notes on behaviour: when using the loop it only results in unnecessary stripping (i.e. it removes handslot & worn first and “limbo” item last). With [rm_mult_objs_from_inven] it results in removing only a single item again (i.e. it can't find an item in inventory). Example, I can have 5 combat armour, put one on handslot, drop the other 4, pick them up again, deliver and only lose the one on handslot. However, using the loop can fix this.]

Should this be fixed yes/no?
I'm not really sure... [rm_mult_objs_from_inven] allows to transfer items from one NPC to another w/o wiping their equipped gear. Which could be useful. [Of course if wanting to move all it would need a workaround then...]
However, regarding the dude I can't think of a case where the equipment should be untouched. In most cases that results in buggy behaviour (like the old "dropping items from barter" trick).
A technical issue is that hiding items on handslot & worn has a range of X + 3. Example; I need to deliver 5 Combat Armours. I can put 2 in inventory, one on each handslot and wear the 5th.
That said, maybe [rm_mult_objs_from_inven] could get an extension of:
if dude then, if items on dude => qty and < qty +3 then, loop to remove items one by one... not sure if this makes sense (or just loop always?), but in theory that would not create wrong behaviour i.e. strip the player unnecessarily [unless there is a limbo item].
Idk, may be a starting point.

Personally, I'm not sure yet, I don't think LH (for example) should replace any check with the loop, I'd rather have sfall fix that. But for WM2 I may consider to use it, as I like that the mod works w/o sfall and I'd like to maintain that (if possible), but it would mean to rebuild every single request script.

Anyway, [summary]
-[rm_mult_objs_from_inven] not removing armor & weapons correctly, script error. [i.e. use correct unwield and/or the correct [rm_obj_from_inven].]
-[rm_mult_objs_from_inven] not touching equipped gear, engine error. (esp. for the dude) [loop can fix it]
-Unable to find items in limbo (Object Pointer?), engine error, probably. (allows to reduce any "hand in" quest to a single item if it runs [rm_mult_objs_from_inven] w/o loop fix.)

The easiest to confirm this is w/ AcMorlis, should work in 1.02d and RP 2.3.3.
Using 1.02d has the benefit of toggling sfall. Almost anything else nowadays stops working the moment you disable sfall.

That's all. The tests on the last day had become very consistent and predictable. So, I think I'm done with this... then again... idk, there is always something.

 

You could create issues on github for each of things you find. It's hard to discuss when you dumped a lot of various issues as one pile.

Personally I used a lot of the inventory opcodes without much trouble. You need to understand how inventory in the game works, some things are not intuitive. If something doesn't work as you want it to, there's always some workarounds you can script. If there's really something that can't be done with scripts, then by all means - post an issue, or maybe try to contribute some fix.

 

sfall 4.4 and 3.8.40 are released on SourceForge, along with their respective modders packs.

Important changes in 4.4:

1. The newly implemented mods_order.txt replaces previous .dat autoloading mechanism.
   (PatchFileXX options in ddraw.ini's [ExtraPatches] section are still honored.)
   If you only update sfall for your current RPU/TCs decked out with mods, nothing will change. Because if the txt doesn't exist, sfall will try to initialize a new one with your current mods setup. The catch is when you want to install a new mod after that, you have to add the mod to mods_order.txt. Currently EcCo and EtTu beta/development versions have already utilized mods_order.txt.
   
2. The two basic script mods, gl_highlighting.int and gl_partycontrol.int, are now packed into sfall.dat, and their config file sfall-mods.ini is moved to the "mods" folder. If you update sfall for your games, make sure to remove sfall's old gl_highlighting.int and gl_partycontrol.int from your data\scripts\ folder, and migrate your settings to the new sfall-mods.ini in the "mods" folder.

 

I think backwards compatibility on this one is broken? At least I tried to run it on xpsp3.

Edit: that said, maybe I just need to install a newer msvc redist. I'll try that later

 

Thanks for the report. Yes, 4.4 crashes on startup on XP/2003, there will be a hotfix release later.

 

sfall 4.4.0.1 and 3.8.40.1 are released on SourceForge. They are hotfix releases for the previous version.

I got lazy and didn't check 4.4 builds on XP/2003. Sorry if anyone got the crash on older Windows.

 

I tried Fallout 2 modding.
Compiled some simple INT file. How do I integrate it into game now? There is no /Data/scripts folder in my GOG version of the game. I have read multitude instructions on the internet and tried them all but nothing makes my compiled script recognized by the engine.

Is there a way to plugin INI file into installed sFall?

 

Did you try this guide? https://f3mic.github.io/

You can create data/scripts folder if it doesn't exist. But the more "modern" approach is to create a subfolder in mods/ folder like mods/mymod.dat and place scripts folder inside it. Then, if you use sfall 4.4 or higher, add it to mods_order.txt.

What do you mean exactly?

 

That is a good idea. Thank you.

I tried the guide you mentioned and this one and others but none tells how to properly deploy/install them onto the game and not within the modding environment only.

When you tell about create directory do you mean structure like mods/mymod.dat/scripts/ACKLINT.int ?
(I am trying to modify a simplest script by this manual).
I tried your technique and it didn't pick it up. Should I probably convert INT into DAT?

 

Yes, the path is correct. But make sure that it's actually loaded by whichever sfall you're using. If you use the one that comes with EcCo 0.9, you need to add "mymod.dat" to mods/mods_order.txt file.

No, script should be picked up if it's in scripts folder. Try "<fallout_dir>/data/scripts/acklint.int". Also make sure data_patches path in fallout2.cfg points to a data folder.

 

Hello. I am using the sfall to achieve some stuff and I've come across issues which I don't know how to solve. I would appreciate any help on these:
1) While traveling on worldmap, the outdoorsman skill can give you option to avoid the random encounter. Is there any hook to modify this? Or completely cancel it? Simply force player to visit the random encounter?

2) Can I change the AP cost when using some misc item? Stealth Boy for example, but that way that the new cost appears on the interface correctly?

3) Can I somehow stop player or NPC from moving during fight? I tried changing the AP cost through movecost hook but it doesn't work. The player moves despite it shows he can't.

Thanks for any help.

 

1. try HOOK_ENCOUNTER.
2. HOOK_CALCAPCOST, for those toggleable items you need to check both normal and "active" PIDs.

 

Thanks, HOOK_CALCAPCOST actually works, I didn't even try it coz the documentation says that "Runs whenever Fallout is calculating the AP cost of using the weapon (or unarmed attack). Doesn’t run for using other item types or moving."

The HOOK_ENCOUNTER doesn't really do what I need. Or maybe I don't know how to use it. I tried it in combination with force_encounter() but that just makes me appear on empty map. I guess there is no way to force a player to enter random encounter.