Fallout 2 mod FO2 Engine Tweaks (Sfall)

zlykiss said:
Josan12 said:
Darek said:
Timeslip, have you done something to the jinxed trait, or something that may have an effect on it?

I also have noticed this issue Darek describes with the jinxed trait.

so, jinxed trait is broken? Its a pity really because ive waited so much on RP 2.1 with jinxed build in the mind and i think its the only build that i havent used in my numerous playthroughs.

:eagerly waiting for Timeslips reply:

I'm not Timeslip, but I was looking into this issue after hearing reports of it from various players. I was busy tackling the Jet Antidote problem, so I've not fully devoted my attention to it. Now that the Jet Antidote issue is fixed (at least I hope it's fixed -- crosses fingers), I've taken a closer look.

Thanks to Darek, who did regression testing on my behalf, we've narrowed down the problem to code introduced for sfall 2.3 -- apparently, Jinxed trait and perk behaves normally for sfall 2.2, but behaves oddly afterward.

At a preliminary glance, it looks like some hookscripts may be the culprit, but I'll have to take a longer and deeper look to be certain. It may take me a while though due to RL stuff. It'll also be a good idea for me to PM Timeslip once his RL stuff dies down, since he undoubtedly will have a much better idea exactly what to look for.

-- The Haen.
 
Haenlomal said:
I'll have to take a longer and deeper look to be certain. It may take me a while though due to RL stuff. It'll also be a good idea for me to PM Timeslip once his RL stuff dies down, since he undoubtedly will have a much better idea exactly what to look for.

You're awesome, Haen :ok:
I eagerly await the fix.
 
Haenlomal said:
At a preliminary glance, it looks like some hookscripts may be the culprit
To be more specific, I think it's AfterHitRollHook. The 'cmp ebx, 1;' and 'hookend' lines are the wrong way around.

You might still want to double check though. You know how well it went the last time I tried to poke at a bit of asm with only 10 minutes to spare. :P (Plus I see no reason why that particular bug would only affect the jinxed trait. It should pretty much screw up all combat if it's doing what I thought it was. :?)

Edit: ah, now I can see why it would have fun with the jinxed trait. The behaviour is slightly different if you don't have a hookscript attached, so I missed it because I had a script attached for testing. By default the jinxed check should only run for misses, but with that bug it's being run for hits too, and half of all hits end up getting downgraded to critical misses.
 
Timeslip said:
To be more specific, I think it's AfterHitRollHook. The 'cmp ebx, 1;' and 'hookend' lines are the wrong way around.

You might still want to double check though. You know how well it went the last time I tried to poke at a bit of asm with only 10 minutes to spare. :P (Plus I see no reason why that particular bug would only affect the jinxed trait. It should pretty much screw up all combat if it's doing what I thought it was. :?)

Edit: ah, now I can see why it would have fun with the jinxed trait. The behaviour is slightly different if you don't have a hookscript attached, so I missed it because I had a script attached for testing. By default the jinxed check should only run for misses, but with that bug it's being run for hits too, and half of all hits end up getting downgraded to critical misses.

Well, and that takes care of that. :) Glad to see you dropping in, Timeslip. Hope RL stuff is less busy for you now.

I guess it's onto the next item on the to-do list for me.

-- The Haen.
 
Timeslip said:
Luigibacsi said:
Hi Timeslip!
Would it be possible to fix the "sound or endings problem" with your patch?
The usual fix is to turn sound hardware acceleration off, but I'm not aware of any way to do that from inside the application using sound.

I may have found a way. There are some registry entries that can be played with to change sound acceleration. The effect is instant and it seems to work without side effects (at least in XP, tested with dxdiag and F2), you'd only need to figure out a way to read the deviceid and the other subkeys.

The entries being changed are here:

Code:
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Hardware Profiles\Current\System\CurrentControlSet\Enum\[several device-related subkeys]\DirectSound\Device Presence]
"Emulated"=dword:0000000x
"VxD"=dword:0000000x
"WDM"=dword:0000000x
and
Code:
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Hardware Profiles\Current\System\CurrentControlSet\Enum\[same subkeys]\DirectSound\Mixer Defaults]
"Acceleration"=dword:0000000x

For me basic acceleration works best, so here would be an example, using a Realtek HD Audio card:

[spoiler:23ade49fd2]
Code:
REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Hardware Profiles\Current\System\CurrentControlSet\Enum\HDAUDIO\FUNC_01&VEN_10EC&DEV_0888&SUBSYS_14627519&REV_1000\4&320DE364&0&0001\DirectSound\Device Presence]
"Emulated"=dword:00000001
"VxD"=dword:00000001
"WDM"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Hardware Profiles\Current\System\CurrentControlSet\Enum\HDAUDIO\FUNC_01&VEN_10EC&DEV_0888&SUBSYS_14627519&REV_1000\4&320DE364&0&0001\DirectSound\Mixer Defaults]
"Acceleration"=dword:0000000f
[/spoiler:23ade49fd2]
The different values are as follows:

[spoiler:23ade49fd2]
Code:
[b]No acceleration:[/b]
Emulated=1
WDM=0
VxD=0
Acceleration=f (15)

[b]Basic acceleration:[/b]
Emulated=1
WDM=1
VxD=1
Acceleration=f (15)

[b]Standard acceleration:[/b]
Emulated=1
WDM=1
VxD=1
Acceleration=8

[b]Full acceleration:[/b]
Emulated=1
WDM=1
VxD=1
Acceleration=0
[/spoiler:23ade49fd2]

So, using this information it might be possible to change sound acceleration to basic and back with sfall, if you're interested to implement that. Even if not, this can be used for making a batch file, which benefits all games that have this problem! :D

credits
 
Hi everyone, please help me with "GlobalShaders" - they just don't work on my machine. "Software scalers" is too slow, and "texture filtering" is too blurry :( I've got C2D, Win7 x32, Nvidia ver.197.77. All functions of sfall working properly except that damn global.fx :( Tried MegaMod 2.42 and latest sfall from sourceforge, global.fx is placed in Data/Shaders. Setting "GlobalShaderMode" does nothing.

Thanks and sorry for bad english ;)

UPD: with Megamod 2.33 works well!
 
2.11 is up.

Code:
>Added an option to remove the critical hit/miss limits in the first few days of game time
>Added an option to use 32 bit images for talking heads
>Fixed the original engine issue that resulted in the jet antidote not being consumed (From Haenlomal)
>Fixed the original engine issues with the wield_obj_critter script function (From Haenlomal)
>Fixed the original engine issue that caused the critical hit bonuses from special unarmed attacks to not be applied correctly. (From Haenlomal)
>Fixed the sfall bug that made the jinxed trait rather more potent than it should have been
>Fixed an issue with the karma image override that caused it to leak out to other panels
>Fixed a hero appearance mod issue that caused the wrong frm to be displayed when opening a bag in the inventory (From Mash)
>Fixed a bug in Glovz's damage mod.
(Edit: Missed a credit)

afaik, the jet fix hasn't had any testing whatsoever, so is off by default. Add 'JetAntidoteFix=1' to the misc section of the ini to turn it on.

Using 32 bit head images currently requires a bit of hex editing of the original frms: Create a subfolder in data/art/heads, and put one image per frame into it named 0.png, 1.png, etc. (They don't actually have to be png's, they just have to have that extension.) At offset 0xc, write 0xbc, oxab, then the name of the folder interchanging every two letters. (silly big endian format files...) Anyone with the option turned on will see the new images, and anyone with it off or without sfall at all will see the original frm contents.

I'll add a tool to the modders pack to patch the frm's automatically if anyone actually wants to use it. (I expect it'll go the same way as avi movie/large tile/mp3 support, with no-one actually using it, but it was interesting to write, so all is good. :))

Windows 2000 support has apparently been broken since 2.7, when I switched over to visual studio 2010. For the benefit of anyone still using win2k, there's a new win2k file up on sourceforge built with vs2008. Eventually, it'll probably suffer the fate of the win9x version and bitrot away until I have to scrap it, but for now it should work.

Atombunker said:
I may have found a way. There are some registry entries that can be played with to change sound acceleration. The effect is instant and it seems to work without side effects (at least in XP, tested with dxdiag and F2), you'd only need to figure out a way to read the deviceid and the other subkeys.
Now that's pretty interesting. I'm not too comfortable poking about in the registry, so something like that will certainly never be a default-on fix, but I certainly make it an optional extra.

The only problem is that I don't actually have any problems with the ending credits, (I'm on windows 7, so no hardware acceleration for directsound whether I want it or not,) so I can't test if anything I do works. I'll try and include it in 2.12 anyway.
 
Timeslip said:
afaik, the jet fix hasn't had any testing whatsoever, so is off by default. Add 'JetAntidoteFix=1' to the misc section of the ini to turn it on.

Actually, since the modders' pack was released I've been doing quite a bit of testing on it, and it seems to be fine so far. Nonetheless, for those of you who have it enabled, please PM me if you know of any issues.

Now, onto the main purpose of this particular post.

I can't think of another place to put this issue, so consider this my general answer to both the posters who have posted publicly in this forum and to the many PMs I've received about the same issue:

The problem of Sulik, Vic, Goris, and Dogmeat not reaching Stage 6 isn't going to be fixed anytime soon, if at all. In order to better understand the issue, here's a brief description of what normally happens.

When you run Fallout 2, there is a function named partyMember_init that reads the party.txt file, and organizes the data it extracts from the file into a party member table. There is a record for each party member found in the file, and each record is 200 bytes long. Everything about your potential NPC allies is stored in this table, and afterward the engine will extract any information it needs directly from this table. This table is created before the initial Main Menu screen for Fallout 2 shows up.

The root of the problem lies in the fact that Stage 6 is really a misnomer - in fact, it should be considered Level 7 (Level 1 - Base PID, Level 2 - Stage 1 PID, Level 3 - Stage 2 PID, etc.). Apparently, for the original developers, they also made the conceptual error of really thinking that Stage 6 is Level 6, and they defined their data structure accordingly -- that is to say, there is only enough room for the PIDs of the first 5 stages.

Therefore, during game load, the engine reads the party.txt file, creates a data structure internally with the info, and thanks to boundary checking will only read the first 5 PIDs before hitting the end of the record. During level-up, the engine will consult the table it had made earlier, and will of course never been able to find the Stage 6 PID since it's not there.

Changing the party.txt initialization routine to increase the size of the structure to accommodate the Stage 6 PID is simple enough -- you only need to change two bytes -- but the problem is that the engine has been optimized with the size of each party member record in mind. Once I change the size of the record to 204 bytes to accommodate the Stage 6 PID, the optimized offsets that depend on the fact that party member records are 200 bytes long are all going to return, um, very interesting results. :P And as you may have guessed, the party members table is accessed all over the place in the engine. At least the problem is made somewhat "better" by the fact that level PIDs are the last thing stored in each record, so other information gleaned from party.txt would still be in the same location relative to each individual record's starting offset.

So, in order to fix this problem, I can do a few things:

  1. Go through the engine, and make the appropriate adjustments everywhere that the engine accesses the party member table. Is this doable? In theory, yes. Is it practical? No, for very obvious reasons. Will it be implemented? Based on my previous two answers, highly unlikely.
  2. Hook into the relevant party member code and write up new routines for sfall to totally handle party member level ups and other stuff related to the table. Is this doable? Yes. Is it practical? Well, probably more than Option 1. But it will be quite a massive piece of code. Will this be implemented? Depends on my free time, I guess. But I wouldn't hold my breath if I were you.
  3. Make a rough hack for Sulik, Vic, Goris, and Dogmeat. While this should be relatively simple to implement (well, still complicated, but simple compared to the first two options), it won't of course be a nice general solution for those mods with custom NPCs that goes beyond Stage 5, unless certain rules and restrictions are followed.

The bottom line is that those of you who have posted and PM'ed me about the problem should expect any quick fix. I'll think about it some more, and I'm sure Timeslip has much better ideas since he has been traipsing through the engine code much longer than me, but for now I'll move onto the next item on my to-do list.

Cheers,

-- The Haen.
 
Haenlomal said:
Actually, since the modders' pack was released I've been doing quite a bit of testing on it, and it seems to be fine so far. Nonetheless, for those of you who have it enabled, please PM me if you know of any issues.
Ah, sorry, you should have mentioned. I'll stick it back on in the next release then.

Haenlomal said:
and I'm sure Timeslip has much better ideas since he has been traipsing through the engine code much longer than me
I normally make a policy of never repeating something I've already said earlier in the thread, but given it must be a year or so by now that I delt with this one I guess it wont hurt: Hacking the engine to use the level 6 protos is far too much effort for something that can be scripted so trivially. (Edit: after thinking for myself how I'd go about scripting it, I guess I'd better take out the utterly. I'm leaving the trivial though.)

Why people are bombarding you with pm's just because they don't like, (or haven't been bothered to look for,) my answer I don't know. I suggest ignoring them. It's always worked for me. :P
 
I personally never cared for any of my party members level. So I am fine with them beeing able to only go to "level 5". Don't understand what's the big deal with the 6th level. :>
 
Timeslip said:
>Fixed the original engine issues with the wield_obj_critter script function (From Haenlomal)
>Fixed the sfall bug that made the jinxed trait rather more potent than it should have been

Haha! You the man/woman, Timeslip. :ok:

So, will the wield_obj_critter fix stop the dude from keeping the bonuses he gets in the Reno boxing ring? And if so, will this be included in the RP 2.1.1, Killap?
 
Timeslip the original 8bit loading screens (splash – colorRix Image) will not show up with the 16bit color function used by the resolution patch…is there a chance you can fix this in the next addition of Sfall so a normal 16bit BMP file format could be used in their place. Here is some information on the format. http://falloutmods.wikia.com/wiki/RIX_File_Format. Thanks.
 
Josan12 said:
So, will the wield_obj_critter fix stop the dude from keeping the bonuses he gets in the Reno boxing ring? And if so, will this be included in the RP 2.1.1, Killap?
Yes and yes.

.Pixote. said:
Timeslip the original 8bit loading screens (splash – colorRix Image) will not show up with the 16bit color function used by the resolution patch…is there a chance you can fix this in the next addition of Sfall so a normal 16bit BMP file format could be used in their place. Here is some information on the format. http://falloutmods.wikia.com/wiki/RIX_File_Format. Thanks.
The 16 bit mode isn't really anything to do with sfall, so that would need to be fixed in the res patch if anything: Anything that I did to let you use new graphics would require you to be using sfall's DX9 mode rather than the res patches 16 bit mode, and I assume that they show up in dx9 mode already. (At least, speed issues aside. On modern computers as long as you aren't vwait limited or something fallout tends to finish loading before the loading screens finish fading in. Actually, that may be the problem in 16 bit mode; fades are a lot slower, so it would probably still be mostly black by the time loading finishes.)
 
Explosives seem to be really buggy in Fallout 2. You can crash the game with them, they don't work if you exit the map, etc. Right now I saw that if you activate dynamite, place it on the ground, then save the game and reload, it's bugged as well.
 
Timeslip said:
2.11 is up.
Now that's pretty interesting. I'm not too comfortable poking about in the registry, so something like that will certainly never be a default-on fix, but I certainly make it an optional extra.

The only problem is that I don't actually have any problems with the ending credits, (I'm on windows 7, so no hardware acceleration for directsound whether I want it or not,) so I can't test if anything I do works. I'll try and include it in 2.12 anyway.

Nice! :) I'd gladly test it on XP and report back. Note that (as far as I know) different setups require different levels of sound acceleration, so for some "no acceleration" fixes the no sound problem but makes the music skip instead (read that somewhere here), while basic acceleration works well for them. Others might need the setting to be no acceleration or standard acceleration.
 
Timeslip said:
It's always worked for me. :P
For a given value of 'worked'. For people having trouble differentiating between what I can't do, won't do, plan to do or have forgotten about and require prodding for, I've started reformatting the sfall requests wiki page to give more information on the current status of requests. I suggest adding any new (or old and forgotten) requests there if you don't want them to drown in here.
 
If you don't mind Timelip, I am going to post in here and hope someone sees my post before it drowns as a way of warming up.

Firstly, LUA? I learned how to use it yesterday, and calling C Functions from a script is super dope.
 
Heh. Maybe I'll learn to ignore future requests in time. Perhaps I'm being a bit too nice about it. And on further digging it seems like the 6th proto problem isn't as complicated as it first looks regardless of engine change or hook scripting, so maybe there's some hope yet...

On a related note: that page about sfall requests on the wikia will sure be useful! I didn't know about it, or else would have looked at it a long time ago. Thanks for pointing it out and cleaning it up. :)

A quick comment on the changelog: I've also fixed the issue where the critical chance bonuses assigned to certain Special Unarmed Attacks weren't being processed due to a poorly structured series of it-then-else statements. They now process the critical chance properly, and Special Unarmed Attacks (especially the higher level ones) are quite scary now. ;)

-- The Haen.
 
Back
Top