Fallout 2 mod FO2 Engine Tweaks (Sfall)

I haven't gotten the paint job for the car yet, but it still will not work for me on the regular car. I have no idea why not, though. I don't really understand how exactly sfall works. But, is it possible that some changes/fixes will only work on a properly installed game? I haven't installed Fallout 2 in such a long time on any of my computers. I just run/mod the game from an external hard drive. Could that make any difference? Or, is there another setting within ddraw that I may have set which could overwrite the car charging fix?
 
No, there's no other setting to do with the car charging fix. Have you tried 3.6? If 3.6 still doesn't work on your game, the car charging fix probably isn't the cause.
 
Haven't tried 3.6. The last version in the MM was around 2.12 or something like that. I'll get 3.6 and test it out, though. Thanks.
 
@MIB88
My Fallout is not "properly" installed either. I just did the basic update... took the ddraw.dll from sfall 3.7b and put it in the megamod folder, and then added
Code: 
;Set to 1 to fix the issue with being able to charge the car by using cells on other scenary/critters
CarChargingFix=0
at the bottom of your ddraw.ini.

This may sound stupid, but did you double check that you updated the sfall files to the correct folder? I mean it could happen if you have several installs and are a bit tired.:shrug:

Also, feel free to upload your ddraw.ini if you want me to test it on my system.
 
Are you kidding me?! I totally misread that, even after @NovaRain asked if it was set to 0! I thought I needed to set the fix to 1 in order to use it on other protos. No, it's all good. Works fine.

Now, where is that facepalm emoji...?

Thanks, guys.
 
Last edited:
I tested sfall builds on both UP and RP, with no other overhaul mods. Most of my testing environments are real OSes installed on different machines ranging from normal desktops to IBM/HP rack & blade servers (yes, I also tested sfall on Windows Server series). The only exception is Win10, which runs in VMware Player.
 
All right... so I was testing and and testing, and in the end it turns out to have to do with HRP.
I set PipboyTimeAnimDelay to 0.
On vanilla fallout, sleeping is instant.
With RP, too - if you use "basic" or "directdraw 7" graphics modes.
If swicthed to "DirectX 9", sleeping is faster but not instant anymore. That's on 640x480x8. If you start to increase resolution and/or color depth, sleeping slows down further. On 1280x800x32, no speedup is noticable.
Unfortunately, DirectX 9 mode is the only one which runs properly otherwise on my system.
 
I installed the GOG version of Fallout 2 in a new 32-bit Wine prefix. It works out of the box, but I had to tell Wine to use the native version of ddraw in order for the changes I made to ddraw.ini to have any effect.

The problem I'm experiencing now is the game becomes so slow in Trapper Town that it's almost unplayable. It only happens when I'm in the northern part of town, I assume because there are so many creatures on the screen. I was under the impression that sfall could fix this somewhat, but I'm unsure what settings I need to change. I know how to change the speed in-game using the numpad, but that doesn't really help.

I read somewhere that the 8 to 32-bit color conversion that has to take place is slow unless performed on the GPU, but this functionality is only available in graphics modes 4 or 5. However, when I try using either of those modes the game crashes on startup with the following error:

Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x10026e20).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:10026e20 ESP:0032f3d4 EBP:00000016 EFLAGS:00010246( R- -- I Z- -P- )
EAX:00000000 EBX:00010001 ECX:00fa11c0 EDX:7c08656a
ESI:0032f3f0 EDI:00000280
Stack dump:
0x0032f3d4: 1004f788 00000280 0001004c 0032f5d8
0x0032f3e4: 0001004c 00c5090d a8210400 00000280
0x0032f3f4: 000001e0 00000016 00000001 00000000
0x0032f404: 00000000 00000001 0001004c 00000001
0x0032f414: 00000000 00000000 00000000 00000000
0x0032f424: 80000000 00000000 a8210400 00110000
Backtrace:
=>0 0x10026e20 in ddraw (+0x26e20) (0x00000016)
0x10026e20: movl 0x0(%eax),%ecx
Modules:
Module Address Debug info Name (91 modules)
PE 400000- 6f0000 Deferred fallout2
PE da0000- f9f000 Deferred d3dx9_43
PE 10000000-10093000 Export ddraw
ELF 7933e000-7a800000 Deferred libllvm-3.5.so
ELF 7a800000-7a946000 Deferred opengl32<elf>
\-PE 7a820000-7a946000 \ opengl32
ELF 7b400000-7b7e7000 Deferred kernel32<elf>
\-PE 7b410000-7b7e7000 \ kernel32
ELF 7bc00000-7bcf8000 Deferred ntdll<elf>
\-PE 7bc10000-7bcf8000 \ ntdll
ELF 7bebb000-7bf00000 Deferred usp10<elf>
\-PE 7bec0000-7bf00000 \ usp10
ELF 7c000000-7c004000 Deferred <wine-loader>
ELF 7c03f000-7c100000 Deferred msvcrt<elf>
\-PE 7c060000-7c100000 \ msvcrt
ELF 7ce13000-7d6bf000 Deferred r600_dri.so
ELF 7d804000-7d80a000 Deferred libtxc_dxtn.so
ELF 7d80a000-7d813000 Deferred libffi.so.6
ELF 7d813000-7d82f000 Deferred libgcc_s.so.1
ELF 7d82f000-7d83d000 Deferred libdrm_radeon.so.1
ELF 7d83d000-7d866000 Deferred libudev.so.1
ELF 7d866000-7d877000 Deferred libdrm.so.2
ELF 7d877000-7d87a000 Deferred libxshmfence.so.1
ELF 7d87a000-7d882000 Deferred libxcb-sync.so.1
ELF 7d882000-7d887000 Deferred libxcb-shape.so.0
ELF 7d887000-7d892000 Deferred libxcb-render.so.0
ELF 7d892000-7d8a2000 Deferred libxcb-randr.so.0
ELF 7d8a2000-7d94f000 Deferred libgl.so.1
ELF 7d94f000-7da9a000 Deferred wined3d<elf>
\-PE 7d960000-7da9a000 \ wined3d
ELF 7e2e9000-7e2f2000 Deferred libxcb-xfixes.so.0
ELF 7e2f2000-7e2f6000 Deferred libxcb-present.so.0
ELF 7e2f6000-7e2fa000 Deferred libxcb-dri3.so.0
ELF 7e2fa000-7e300000 Deferred libxcb-dri2.so.0
ELF 7e300000-7e31b000 Deferred libxcb-glx.so.0
ELF 7e31b000-7e31e000 Deferred libx11-xcb.so.1
ELF 7e31e000-7e322000 Deferred libxdamage.so.1
ELF 7e322000-7e33e000 Deferred libglapi.so.0
ELF 7e33e000-7e37d000 Deferred d3d9<elf>
\-PE 7e340000-7e37d000 \ d3d9
ELF 7e37d000-7e3c9000 Deferred dsound<elf>
\-PE 7e380000-7e3c9000 \ dsound
ELF 7e3c9000-7e3d0000 Deferred libxfixes.so.3
ELF 7e3d0000-7e3dc000 Deferred libxcursor.so.1
ELF 7e3dc000-7e3ee000 Deferred libxi.so.6
ELF 7e3ee000-7e3f2000 Deferred libxcomposite.so.1
ELF 7e3f2000-7e3fe000 Deferred libxrandr.so.2
ELF 7e3fe000-7e409000 Deferred libxrender.so.1
ELF 7e409000-7e410000 Deferred libxxf86vm.so.1
ELF 7e410000-7e417000 Deferred libxdmcp.so.6
ELF 7e417000-7e43d000 Deferred libxcb.so.1
ELF 7e43d000-7e57b000 Deferred libx11.so.6
ELF 7e57b000-7e58e000 Deferred libxext.so.6
ELF 7e59f000-7e62f000 Deferred winex11<elf>
\-PE 7e5b0000-7e62f000 \ winex11
ELF 7e62f000-7e653000 Deferred imm32<elf>
\-PE 7e640000-7e653000 \ imm32
ELF 7e65b000-7e684000 Deferred libexpat.so.1
ELF 7e684000-7e6c2000 Deferred libfontconfig.so.1
ELF 7e6c2000-7e6d4000 Deferred libbz2.so.1
ELF 7e6d4000-7e6ec000 Deferred libz.so.1
ELF 7e6ec000-7e7a6000 Deferred libfreetype.so.6
ELF 7e7a6000-7e7f4000 Deferred libncurses.so.5
ELF 7e7f4000-7e81e000 Deferred msacm32<elf>
\-PE 7e800000-7e81e000 \ msacm32
ELF 7e81e000-7e8a0000 Deferred rpcrt4<elf>
\-PE 7e830000-7e8a0000 \ rpcrt4
ELF 7e8a0000-7e9dc000 Deferred ole32<elf>
\-PE 7e8c0000-7e9dc000 \ ole32
ELF 7e9dc000-7ea95000 Deferred winmm<elf>
\-PE 7e9e0000-7ea95000 \ winmm
ELF 7ea95000-7eaaf000 Deferred version<elf>
\-PE 7eaa0000-7eaaf000 \ version
ELF 7eaaf000-7ec23000 Deferred user32<elf>
\-PE 7eac0000-7ec23000 \ user32
ELF 7ec23000-7ec9d000 Deferred advapi32<elf>
\-PE 7ec30000-7ec9d000 \ advapi32
ELF 7ec9d000-7edba000 Deferred gdi32<elf>
\-PE 7ecb0000-7edba000 \ gdi32
ELF 7ef88000-7ef94000 Deferred libnss_files.so.2
ELF 7ef94000-7efa0000 Deferred libnss_nis.so.2
ELF 7efa0000-7efb9000 Deferred libnsl.so.1
ELF 7efb9000-7f000000 Deferred libm.so.6
ELF f7422000-f7426000 Deferred libxau.so.6
ELF f7426000-f742f000 Deferred libnss_compat.so.2
ELF f7431000-f7436000 Deferred libdl.so.2
ELF f7436000-f75d8000 Deferred libc.so.6
ELF f75d8000-f75f4000 Deferred libpthread.so.0
ELF f7605000-f77be000 Dwarf libwine.so.1
ELF f77bf000-f77e3000 Deferred ld-linux.so.2
ELF f77e5000-f77e6000 Deferred [vdso].so
Threads:
process tid prio (all id:s are in hex)
00000008 (D) C:\GOG Games\Fallout 2\fallout2.exe
00000009 0 <==
0000000e services.exe
0000001f 0
0000001e 0
00000016 0
00000010 0
0000000f 0
00000012 winedevice.exe
0000001b 0
0000001a 0
00000013 0
00000014 explorer.exe
00000024 0
00000023 0
00000022 0
00000015 0
0000001c plugplay.exe
00000021 0
00000020 0
0000001d 0
System information:
Wine build: wine-1.9.8
Platform: i386
Version: Windows XP
Host system: Linux
Host version: 4.4.6-gentoo

I tried installing d3dx9 with Winetricks but it still crashes.
 
IYouI said:
FALLOUT2.EXE crashed, when I went The Den and some old junkie attacked my character.

Windows 7 x64, RP 2.3.3

Code: 
---------------------------
Application Error: C:\F2\FALLOUT2.EXE
---------------------------
The instruction at 004c5d09 referenced memory at 0cba8970
The memory could not be read from


Click on OK to terminate the application
---------------------------
OK  
---------------------------
Click to expand...

This is happening to me as well, It happens when I travel from the Den Residential District to the entrance of the Den, Can Reproduce it each time.

I only use the RP 2.3.3 like IYouI and I did transfer all the settings RP had set, This also only happens on Sfall 3.7 and onwards, I do not get this crash with SFall 3.6.

I also use the GOG version.
 
Daemonjax said:
Verified 3.7b crashes fallout2.exe everytime transitioning from Den Residential to main Den area.
Click to expand...
It doesn't happen on my RP 2.3.3 game. What did you do in the Den before the crash, or the game crashed even you just rush to the residential area right after entering in the town?
 
Last edited:
NovaRain said:
It doesn't happen on my RP 2.3.3 game.
Click to expand...

That's strange, right?

I verified that the latest sfall .dll that works for me to transition without crashing in the Den is 3.6.

The ddraw.dll from 3.7, 3.7a, and 3.7b all crash at that transition... for me, anyways.

Changing the .dll to the one from 3.6 resolves the issue. I'm also using RP 2.3.3.

I'll use winmerge to see if it's a particular 3.7+ ddraw.ini setting that I have set that doesn't exist in 3.6.

EDIT:

These are the options I have set in my ddraw.ini from 3.7b which aren't present in the 3.6 ini:

SaveInCombatFix=2
GainStatPerkFix=1
FastShotFix=1
InventoryApCost=4
QuickPocketsApCostReduction=2
ObjCanSeeObj_ShootThru_Fix=1
arraysBehavior=1
StackEmptyWeapons=1
ReloadReserve=0
DialogOptions9Lines=1
EnableMusicInDialogue=1
CanSellUsedGeiger=1
CarChargingFix=1
InstantWeaponEquip=0

I tried flipping them, but it still crashes at the same transition. Same on a new installation, and same for a newly started game. The only thing that fixes it (for me) is to use the ddraw.dll from 3.6.

GOG version, if that matters.

EDIT2: "What did you do in the Den before the crash, or the game crashed even you just rush to the residential area right after entering in the town?"

No matter what I do or don't do before transitioning, the crash occurs with 3.7+ ddraw.dll's. During one test run, it crashed upon entering the den for the first time, but that crash was not reproducible so whatever.

Also (and this may or not be related), no matter what I do, sfall does not think my video card supports sm3.0 -- but it does since it's an amd 7990. I discovered this when trying to get a hardware shader working. I don't know if it works with the 3.6 dll or not.

I'm tempted to just use 3.6 while in the Den, and then switch back to 3.7b when I leave and see how it goes. Up until the Den, I had 0 issues with 3.7b (other than the hardware shader thing, but I don't really care about that). But if it turns out I just have to use 3.6, I can live with that. ;) There's a good chance it's just the Den.

I haven't tested without also running f2res (version 4.18, with and without zoom), because that would be a deal breaker for me.
 
Last edited:
I'm not sure if this is the right place to ask, but is there anyway to control the distance of NPC's being knocked back from explosions and whatnot? They have a tendency to go sliding from one end of the map to the other and it would be good if that could be shortened a little bit, if possible.

Cheers,
CPL
 
Daemonjax said:
That's strange, right?
I verified that the latest sfall .dll that works for me to transition without crashing in the Den is 3.6.
The ddraw.dll from 3.7, 3.7a, and 3.7b all crash at that transition... for me, anyways.
Changing the .dll to the one from 3.6 resolves the issue. I'm also using RP 2.3.3.
Click to expand...
Sorry for my rushed reply above. Yes, sfall 3.7 does cause the crash when leaving the Den Residential in a save you haven't entered it yet.
It seems using a save that you've been in the Den might not crash, but I only got a save before entering the Den and a save I've already done all quests in the Den (ready to leave) so I can't be sure.

The cause is the bug fix for "Unlimited Ammo" exploit (weird, I know). Currently you can download my temporary build which fixed the crash. and add the line UnlimitedAmmoFix=0 in [Misc] section in your ddraw.ini. This will disable the fix to prevent the crash.

EDIT: I uploaded a new fixed build. Now you don't need to add the line to disable the fix.
 
Last edited:
NovaRain said:
Sorry for my rushed reply above. Yes, sfall 3.7 does cause the crash when leaving the Den Residential in a save you haven't entered it yet.
It seems using a save that you've been in the Den might not crash, but I only got a save before entering the Den and a save I've already done all quests in the Den (ready to leave) so I can't be sure.

The cause is the bug fix for "Unlimited Ammo" exploit (weird, I know). Currently you can download my temporary build and add the line UnlimitedAmmoFix=0 in [Misc] section in your ddraw.ini. This will disable the fix to prevent the crash.
Click to expand...

Awesome!

Also, I just had Sulik turn into a container while using the 3.7b dll. I thought that bug was fixed?

Furthermore, I thought it required an area transition while a npc was knocked out? An npc was knocked out, but I never left the area. I have a save from just before the battle, so no harm done.

EDIT: Confirmed the 3.7c dll with UnlimitedAmmoFix=0 in the [Misc] section resolved the crashes in the Den.

EDIT2: Is there any way to turn companion-turned-container into a feature? Like, it would be cool if when you hold down shift and click on any companion, he acted like a container. And then when you let go of shift, he's turned back into a normal companion (outside of combat of course). If that's doable, that should also fix the issue if it ever came up again (just tap shift, and voila -- problem solved). Or something like that. A fix and feature rolled into one, kinda. Just an idea... no idea if that would be possible. Nevermind, I think something similar enough can be done using sfall's hookscripts.
 
Last edited:
Daemonjax said:
Awesome!
Also, I just had Sulik turn into a container while using the 3.7b dll. I thought that bug was fixed?
Furthermore, I thought it required an area transition while a npc was knocked out? An npc was knocked out, but I never left the area. I have a save from just before the battle, so no harm done.
Click to expand...
The bug happens when NPCs lost their next turn and you leave the map.
A save or some description on what happened in combat would be helpful.
 
NovaRain said:
The bug happens when NPCs lost their next turn and you leave the map.
A save or some description on what happened in combat would be helpful.
Click to expand...

Right, which is why it's strange: It occurred without leaving the map. I'm aware of the bug so I don't do area transitions when npcs are on the ground.

"NPC receives DAM_LOSE_TURN + player leaving map = 'NPC turns into a container'"... but it happened without leaving the map (it was a random encounter... bandits).

It only happened once. I couldn't reproduce it. I don't know whether sulik was knocked down during the fight -- I don't remember it happening, but it's possible. After the fight I noticed he wasn't following, and all I could do was open him as a container (which was kinda cool at first, until I realized what happened). I just reloaded. I always save before fighting (out of combat)/traveling.
 
Last edited:
You must log in or register to reply here.
Back
Top