Fallout 2 mod FO2 Engine Tweaks (Sfall)

sfall 4.4.3.1 and 3.8.43.1 are released on SourceForge. They are hotfix releases for the previous version.
Changelog said:
v4.4.3.1
>Fixed a possible hang or crash introduced in 4.4.1 when running certain script sequences
The most prominent issue seems to be the freeze/crash in Klamath, especially when Duntons run away in Torr's brahmin quest (either scaring them off or simply killing all radscorpions). But it's kinda random on different systems.
 
Some minor things

-The "lock jammed" effect blocks ALL Skill use, not just Lockpick.

I thought about it and it makes no sense to me. Either the skill should be usable, or, it should be up to the script to block it.

Skills in question:
-Lockpick: should be blocked by engine.
-Steal: has its own block mechanic (container is open/closed) and doesn't need to be blocked by jam. Besides, you can unlock a container with items (despite jam), then open it via the "hand icon", but when you use Steal on it, it blocks it and says "container is jammed". Which is just silly.
-Traps: Works on closed & locked containers. - And jammed isn't different to locked.
-Repair: May get blocked when container is locked/closed/jammed, but should be up to script, imo.
-Science: Could get a special "container is jammed" message if used on a jammed container. That may reflect the idea of science (to learn the state of an object), but Science is pretty vague - as a skill. Not sure if or if not it should react to jam.
That are all skills that work on a container. Door is the same but blocks Steal.

Sfall used (4.3.7), same on 1.02d US engine w/ HRP.

-Trying to open a locked container.

When I use "magic hands low" while holding something (hammer, pistol etc.) it bugs out when the container (grave, red shirt, pot, chest, footlocker etc.) is locked or trapped (i.e. when action cancelled). First it just freezes the animation but when I command to move somewhere (before the freeze resolves), it becomes very glitchy (and the "magic hands low" animation triggers up to four times, or more on occasion). It works fine if the hands are empty or when the container is not locked/trapped. Also "magic hands middle" works fine. Only "the cancel of magic hands low while holding something" glitches like this.

Sfall used (4.3.7), same on 1.02d US engine w/ HRP.

Test: a container (w/ action cancel) is in RP Mod : Hakunin's Chest. Only one (?) chance before combat though. Anyway, wield a spear and access. Animation usually freezes. When moving (fairly) quickly (i.e. while freeze is still on), the pick up action loops a few times. One time even indefinitely (dude was slowly jigging sideways out of the tent; which was funny). If I don't move away quickly, but wait (while frozen), and then move (i.e. freeze resolved), it doesn't happen.
That said, maybe it just needs a regain animation? Or even simpler, work the same as w/ hands empty (which seems to regain animation much better than when wielding). Also magic hands middle seems to handle it better (when wielding), i.e. it seem this is just missing something... ?
 
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.

I just tested with 4.4.3 and the above does not seem to be fixed.
Of all the feedback this was kind of important (major exploit).

I said I can fix it in script but by my experience fixing engine errors in script can backfire when switching engine. (i.e. the fix can become a bug). I'd rather not do it, if possible.

Anyway, if you're still looking into it, it may be interesting that this:
item_caps_adjust(dude_obj, -50000);
works perfectly fine.

While this:
remove_pid_qty(dude_obj, PID_BOTTLE_CAPS, 50000)
can be made to bug out (with full exploit I'll only lose $1*).

*full exploit: move one bottle cap onto handslot, drop the rest on the ground, pick it up again, then deliver w/o opening inventory. If done, it only removes the single bottle cap from handslot.

Maybe the way "item_caps_adjust" handles it can help with a fix for this exploit (i.e. for items other than money).
 
Addition to yesterday:
I gave it another try just in case I messed up, so I used the following (full decompiled macro of "remove_pid_qty") with the wielding part commented out:
Code:
removed_qty := obj_is_carrying_obj_pid(dude_obj, 17);
   if (5 < removed_qty) then begin
      removed_qty := 5;
   end
   if (removed_qty > 0) then begin
      restock_obj := obj_carrying_pid_obj(dude_obj, 17);
      /* Gets Stuck On : START */
      //if (obj_type(self_obj) == 1) then begin
         //restock_obj := obj_carrying_pid_obj(dude_obj, 17);
         //if (critter_inven_obj(dude_obj, 0) == restock_obj) then begin
            //if (obj_item_subtype(critter_inven_obj(dude_obj, 0)) == 0) then begin
               //restock_obj := critter_inven_obj(dude_obj, 0);
               //debug_msg("armour pid == " + obj_pid(restock_obj));
               //rm_obj_from_inven(dude_obj, restock_obj);
               //add_obj_to_inven(dude_obj, restock_obj);
            //end
         //end
         //else begin
            //if ((critter_inven_obj(dude_obj, 2) == restock_obj) or (critter_inven_obj(dude_obj, 1) == restock_obj)) then begin
               //metarule(43, dude_obj);
            //end
         //end
      //end
      /* Gets Stuck On : END */
      restock_amt := rm_mult_objs_from_inven(dude_obj, restock_obj, removed_qty);
      destroy_object(restock_obj);
   end
   restock_obj := 0;
   restock_amt := 0;
and it changed nothing. At this point the only thing used here is "rm_mult_objs_from_inven" which is just not able to remove from the different areas ["inventory, handslot & worn"] at the same time, but only from one of the three.

If I loop "rm_obj_from_inven" (i.e. use script return) it works and "item_caps_adjust" works, too (just a slight glitch on clearing active handslot, which is similar to using "transfer_pid_between_objs", if I remember correctly (i.e. missing unwield check).).

Anyway, I don't think this is anything at my end, or anything I can do about, except trying a workaround (i.e. loop the single rm_obj X times).

P.S. Maybe it's not THAT big of a deal, after all the player can use a save editor... so why bother about an exploit (player's choice)... but [rm_mult_objs_from_inven] not properly working feels wrong.
 
A preview of something I've been working on.

(images removed, see next post for updated designs)

PS: Ignore Inventory Filter panel - for those who don't know it's a separate mod from Mr. Stalin (needs some tweaks to support this feature though).

So as some of you know, Stalin's fork had this extended inventory feature for a long time and I thought how I could put something like this into sfall with as little effort as possible (without rewriting a whole bunch of UI code). Come up with a series of small hacks to extend inventory windows vertically. Turns out, if you extend window's height (but not width..) and not move elements around too much, code changes required are minimal.

Tried making those windows transparent (as shown on some images where windows are not rectangular) - but stumbled upon nasty bugs that I gave up trying to fix.

What's left to do before it can be merged into sfall:
- Need a proper rectangular art (maybe move some buttons down, etc).
- Figure out some kind of restriction on minimum game window height (I play with 960x540, vanilla 640x480 won't fit extended barter window).
- Test some more, refine ini settings, etc.
 

Attachments

  • upload_2024-5-4_23-59-55.png
    upload_2024-5-4_23-59-55.png
    240 KB · Views: 311
  • upload_2024-5-5_0-0-8.png
    upload_2024-5-5_0-0-8.png
    155 KB · Views: 306
  • upload_2024-5-5_0-0-23.png
    upload_2024-5-5_0-0-23.png
    263.7 KB · Views: 306
  • upload_2024-5-5_0-0-52.png
    upload_2024-5-5_0-0-52.png
    319.2 KB · Views: 307
Last edited:
@Oracle

You sure you're posting in the right thread? i initially thought you'd want to complain in Yesterday's thread..
Don't worry hexer is keeping the quality videos as a separate download.
 
Finally figured out how to make internal debug window bigger. You will be able to set desired width, height and font.
upload_2024-5-11_13-52-14.png
 

Attachments

  • upload_2024-5-11_13-51-3.png
    upload_2024-5-11_13-51-3.png
    53.6 KB · Views: 73
After a series of fixes and tweaks, extended inventory was merged and will come in the next sfall release. Here is the current design:

einv1b.png


einv2.png


einv4-crop.png
 

Attachments

  • einv1b.png
    einv1b.png
    207 KB · Views: 86
After a series of fixes and tweaks, extended inventory was merged and will come in the next sfall release. Here is the current design:

Looks good! That I think I could adjust to. That first concept with just the 'too-long' side pane would have blown up my brain. xD

Guessing it'll be optional for the absolute purists (hey, I'm nearly, but not quite one lol) and also... what mod(s) are you running? See several items up in those shots (bear trap? 8 I have no idea what, 3 some other thing, etc) that I've never seen before. Mind you, I've been away quite some time, so it's no shock I'm entirely out of the loop, but couldn't help be curious. ^_^
 
New sfall feature: auto-balancing caps amount in Move Items window when bartering. Taken from this PR for Fallout CE by y0lo.

YouTube video from the original, it works the same here:
 
Hey @phobos2077

Could You also throw in auto run to target when HtH, party-npc take of weapons and armor by double click use best weapon/armor, and use party skills?

or is the last thing going to work by default in official branch?

I'm asking since in sonora thread ppl are complaining that antivirus software is deleting sfall5's ddraw.dll, now given the current situation worldwide i don't recommend them to make an exception in their AV software, which potentially could be suicide.. instead I vowed to prepare ddraw.ini from vanilla branch that is compatible with Sonora.
 
what i meant by: last thigng working by default in official branch, was a mind shortcut, as lots of stuff Stalin made was working due to global scripts, namely the party npc skill utilization. it only had a minor addition to sfall-mods.ini in form of plain text, and it had a dedicated global script so i guess the ddraw.dll didn't do much in terms of functioning, will do a playthrough of Sonora with sfall switched to vanilla branch ( as I already prepared a ddraw.ini for this), due to antivirus triggers. I'll try to report here what works and what doesn't..

in the meantime the most practical feature would be the one i already requested on github. where ingame in character sheet there is dude's icon like in hero apperance mod ( but it would be there even without it) ant there would be left and right arrows underneeth the icon. when player clicks left or right arrows the character sheet switches to a party member character sheet, previous ( left arrow) or next ( right arrow) in the line, according to the order they would apear in combat in control combat. it is a neat little feature to sneakpeak party member character sheets, without the nessecity to enter combat or having [control combat] mode=2 enabled. I have no idea how that's implemented in Fo:Sonora however it would be cool to have this..
 
You can create feature requests on github, but I only implement things I find very useful for my own play and that are interesting/fun to do. Unless you're willing to do some of the work required for these features to be included, I recommend not bombarding others with feature requests. If you want someone to do something, make some effort to convince them to want that feature for themself but better do some of the work yourself (like researching - what sfall does, what scripts do, what sfall features allow those scripts to do those things, how they work, etc.). I'm not using closed source forks, so I don't care what features they have. And not all features are worth porting over and often there are much easier, better way to solve the original problem.
 
sfall 4.4.4 and 3.8.44 are released on SourceForge, along with their respective modders packs.
Changelog said:
v4.4.4
>Fixed a bug in NPCsTryToSpendExtraAP that caused NPCs to still be able to move in their combat turn after they killed themselves
>Fixed a bug in PlayIdleAnimOnReload that could cause critters to lose highlights after reloading weapons in combat
>Fixed a crash bug in interface_art_draw script function when drawing beyond window bounds
>Fixed the missing hotkeys for additional elevators derived from the original elevator types
>Fixed and improved the syntax parsing in script compiler (compile.exe in the modders pack)
>Improved the fix for using 'English' as the fallback language directory for msg files to work on a per-line basis
>Improved the fix for saving/loading party member protos to include the car trunk
>Improved the performance of draw_image, draw_image_scaled, and interface_art_draw script functions
>Expanded show/hide_iface_tag script functions to work with the tag value 0 (sneak)
>Changed the expanded world map interface to be compatible with older versions of the hi-res patch
>Changed the expanded action points bar to require fewer resources and be compatible with older versions of the hi-res patch
>Changed AIDrugUsePerfFix to be enabled by default
>Tweaked the behavior of NPCAutoLevel option and renamed it to PartyMemberNonRandomLevelUp to better match its behavior
>Removed the unnecessary error message about sndlist.lst when AutoSearchSFX is enabled
>Added a fix for the time interval for healing during world map travel being tied to the system timer instead of game time
>Added a fix for the interface bar obscuring the barter/trade interface when using the hi-res patch
>Added a tweak to prevent the 'forever' type of animation on objects from stopping when entering combat
>Added an option to use the expanded barter/trade interface (4 item slots per table instead of 3)
>Added an option to use the expanded inventory/loot screens (8 vertical slots instead of 6)
>Added an option to pre-fill the 'Move Items' window with the correct balancing amount when moving money/caps in the barter screen
>Added an option to set up a key to let you move items between inventory lists by simply clicking on them
>Added debug options to adjust the size and text font for the internal debug window
>Added an option for tweaking Cautious Nature perk to the perks ini file
>Added a new attribute type value to get_window_attribute script function
>Added PAUSEWIN flag to the game mode functions (when pausing the game using Ctrl+P)
>Added 2 new arguments to HOOK_ENCOUNTER hook script
>Added a healing skills example script to the example mods in the modders pack
>New script function: signal_close_game, art_frame_data, set_worldmap_heal_time

The expanded inventory/loot screens (8 vertical slots instead of 6):
expinven.png


The expanded barter/trade interface (4 item slots per table instead of 3):
expbarter.png


For the demo of the caps auto-balancing in the barter screen, see phobos2077's post above.

Note 1: We changed the default keys setup in ddraw.ini a bit. Now holding left Ctrl will let you move items between inventory lists by simply clicking on them (i.e. no need to drag and drop, see this). The key for the "move an entire stack of items at once w/o counter" is changed to left Shift. You don't need to worry about the key changes if you're using your existing ddraw.ini file.

Note 2: If you're using the inventory filter mod, make sure to update the new 2.0.4 so you can move the position of the swap panel when using the expanded barter/trade interface. Some recommended settings:

1. SwapBarterYOffset=48 (simply moving the swap panel down)
invfbarex1.png


2. SwapBarterOffset=-295, SwapBarterYOffset=-226 (moving the swap panel to above the player's portrait):
invfbarex2.png
 
@NovaRain I found small issue related to text position using ShowLootWeight mod. Also build-in inventory filter weight indicator has also wrong possition.
 

Attachments

  • scr00000.png
    scr00000.png
    850.4 KB · Views: 73
  • scr00001.png
    scr00001.png
    841.6 KB · Views: 69
You can use my settings if you wish to use InventoryFilter with both Expanded sfall options:
Code:
;The offset value of the position of the switch panel with party members along the X-axis
SwapBarterOffset=-294
SwapLootOffset=12

;The offset value of the position of the switch panel with party members along the Y-axis
SwapBarterYOffset=-226
SwapLootYOffset=188

;The offset value of the position of the "weight" label in the player's inventory along the Y-axis
WeightWinShift=93

I think InventoryFilter needs visual update: party member swap buttons are ugly AF, they need to use the existing arrows that appear when searching through files of corpses. Why invent custom UI (which is ugly and doesn't even match the original style) when there's already something appropriate in the game?
 
Back
Top