Fallout 2 mod FO2 Engine Tweaks (Sfall)

[Timeslip]

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...

I didn't mean hookscripting. I meant adding an 'if pc_stat(level) > whatever then set_critter_extra_stat(partymember, ...); display_float(level up message);' style block in the critters script. There's not really anything involved in levelling up that you can't do manually, and I'm not a fan of hacking at things when there's existing ways to do them. (Unless the existing way is messy or hard to do, and could be made significantly cleaner with very little effort.)

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.

Not many people add things to there alas. It's been around for a while, and I've tried a few times to encourage people to post there. Maybe cleaning it up will help a bit.

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.

Heh, completely missed that one. Will add it to the changelog.

 

[Popcorn Eyeglasses]

I'm having an issue with too many random encounters on the world map, I've tried a few things, but nothing works, any help?

 

[Josan12]

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.

Excellent work, Haen. And I care about the 6th level of NPC's - if you can bring it back into the game that would be awesome.

 

[Haenlomal]

And I care about the 6th level of NPC's - if you can bring it back into the game that would be awesome.

Well, like Timeslip wrote, this can be done with a bit of simple scripting for each party member with a Stage 6 PID. That said, changing the engine directly is also much simpler than it first seemed, and may be much easier and quicker to boot.

I had initially wrote that access to the internally generated party member table would be all over the place in the engine -- it was a reasonable assumption, after all, given the optimized nature of the assembly code. As a matter of fact, however, I was wrong. There are indeed many functions which need information from the table, but they call the same sub-routine (partyMemberGetAIOptions) to retrieve the offset of individual records within the table. In other words, there's only ONE place where adjustments would need to be made!

As such, the fix is simply to increase the size of the individual records to accommodate the Stage 6 PID, increase the corresponding malloc call accordingly, and finally adjust partyMemberGetAIOptions to return the proper offset with the assumption of 204-byte records instead of 200-bytes records. Technically speaking, I should also ensure that the free memory command is working with the updated table size, but since this happens only on game exit, and the O/S will free up all memory used by Fallout 2 on program termination, I've not touched that part.

I've implemented the fix locally on my machine, and have verified that both Sulik and Vic can reach Stage 6, and that no other settings of theirs have been messed up. As soon as I can verify it has no impact on party members without Stage 6 PIDs, I can submit the fix, RL issues permitting.

Still, this is the last time I'll be patching something that can otherwise be simply scripted. So consider yourselves lucky, or something

 

[smilodom]

Any bid helps...Master "Haenlomal"...
Best regards..

 

[Haenlomal]

Ok, I've checked in a fix for the NPC Stage 6 issue. It does increase your memory usage slightly, so I've defaulted it off. Check sfall's website if you're interested in the technical details.

To set it on, find the line NPCStage6Fix=0 and change it to NPCStage6Fix=1.

-- The Haen.

 

[NovaRain]

Ok, I've checked in a fix for the NPC Stage 6 issue. It does increase your memory usage slightly, so I've defaulted it off. Check sfall's website if you're interested in the technical details.

a dumb question, what if I set the fix on, get my NPCs level up to Stage 6 and save the game, then turn it off and load the save? Will the save be unable to load or NPCs back to Stage 5?

 

[Haenlomal]

Ok, I've checked in a fix for the NPC Stage 6 issue. It does increase your memory usage slightly, so I've defaulted it off. Check sfall's website if you're interested in the technical details.

a dumb question, what if I set the fix on, get my NPCs level up to Stage 6 and save the game, then turn it off and load the save? Will the save be unable to load or NPCs back to Stage 5?

In that case, the NPCs will still be on Stage 6. This is because internally, the engine copies the stats found in the Stage 6 PID and overwrites the stats found in the copy of the Base PID found in your save files. In fact, it does this for all other stages. So even if you turn off the fix after you've leveled up, the overwritten values will remain.

There is a check for max level, which is defined as the number of stages. The engine will skip the NPC level-up process if the NPC's current level is greater than or equal to the max level. With the fix on, those with Stage 6 PIDs will obviously have a max level of 6. Once it is turned off, it will revert back to 5, but fortunately, a current level of 6 is still greater than or equal to max level of 5, so it shouldn't "level up" to Stage 5 stats.

-- The Haen.

 

[Timeslip]

Ok, I've checked in a fix for the NPC Stage 6 issue. It does increase your memory usage slightly, so I've defaulted it off. Check sfall's website if you're interested in the technical details.

Looks good to me.

I don't think you need to worry about memory usage; anything running winxp is already so far above fallouts minimum requirements that that's hardly an issue. (Besides, other parts of sfall already use far more extra memory than that.)

It should still stay defaulting to off though, on account of being a new feature rather than a bug fix.

 

[Haenlomal]

It should still stay defaulting to off though, on account of being a new feature rather than a bug fix.

AFAIK, this is a bug, and not a new feature. According to the Fallout Bible, Stage-6 NPCs were supposed to be part of the game. So presumably the fact that the player couldn't reach Stage-6 should be interpreted as a bug.

 

[Timeslip]

AFAIK, this is a bug, and not a new feature. According to the Fallout Bible, Stage-6 NPCs were supposed to be part of the game. So presumably the fact that the player couldn't reach Stage-6 should be interpreted as a bug.

There's no bug in the code that accidentally prevents npcs from getting their last level. It's a deliberately cut feature, and for some npc's, the 6'th level proto was never created in the first place, so it's not a last minute cut either.

Just because something was originally intended doesn't make its absence a bug, or the whole RP should be merged into the unofficial patch. (Of course, killap might want to have it default on for the RP, for exactly that reason.)

 

[NVShacker]

Any idea what the best way to detect side mouse button presses with Sfall would be? I'm playing with the idea of patching KeyDown to return mouse state from 0x100+ (sort of like what Oblivion Script Extender does) but I don't know what the best way of reading that mouse state would be, I don't believe this version of directinput can be coaxed into providing mouse state with 8 buttons, at the very least my cursory attempt at getting DIMOUSESTATE2 to work failed. I honestly don't know what my best bet for getting mouse state outside of that would be, GetAsynchKeyState seems to rely on the mouse not otherwise being captured, maybe something with window events? Suggestions would be welcome.

EDIT-
As it turns out I can do what I want with DirectInput, I just needed to lock down SetDataFormat, F2 was setting it after I was. I'll post a diff when I have it working for my purposes, if anyone's interested in merging it in.

 

[agris]

Timeslip-

I'm playing the RP 2.1.1 with the control party members feature turned on. For the first time, I'm experiencing the cloning of my main character- is this a bug you're familiar with / due to the party control feature?

 

[NVShacker]

Well, my thing works which I'm happy about, though I'm not familiar enough with assembly to make KeyDown take a non-BYTE argument so I just hijacked 0x70 - 0x77 in the directx scan code range, could easily be adapted otherwise though. I've chucked the diff and an example script in, I'd honestly drop the native SFall support for middle mouse -> button code and let scripts handle that for flexibility though I guess you don't want to drop a feature.

Diff / Example script @ http://nick.pojpo.com/mouse_keydown.zip

Also, building myself seems to cause movies to crash with a memory read violation, even when building from the revision that's on sourceforge, which leads me to believe I'm doing something wrong, Hael/Timeslip either of you familiar with this issue with building it?

 

[Timeslip]

I'm playing the RP 2.1.1 with the control party members feature turned on. For the first time, I'm experiencing the cloning of my main character- is this a bug you're familiar with / due to the party control feature?

It's certainly possible that the party control option could cause that, although I've not seen it before. If it is due to the party control though, note that it will almost certainly not be fixed.

Diff / Example script @ http://nick.pojpo.com/mouse_keydown.zip

Looks good to me.

though I'm not familiar enough with assembly to make KeyDown take a non-BYTE argument so I just hijacked 0x70 - 0x77 in the directx scan code range

ok, I'll make that change then. I'll also need to do something about the dinput.h header... That's part of the old dx sdk, and not sfall, so licence-wise I shouldn't have it stored in sfall's svn repository at all, never mind making changes to it. The problem is that that header isn't included in the dx9 sdk that the rest of sfall needs, so it still needs to come from somewhere. Maybe I'll make a seperate build pack download that has that and the .obj files for the upscaling filters.

I'd honestly drop the native SFall support for middle mouse -> button code and let scripts handle that for flexibility though I guess you don't want to drop a feature.

No, I wouldn't want to drop that. There's nothing stopping people disabling it in ddraw.ini and using a script if they want though, so you get the best of both.

Also, building myself seems to cause movies to crash with a memory read violation, even when building from the revision that's on sourceforge, which leads me to believe I'm doing something wrong, Hael/Timeslip either of you familiar with this issue with building it?

Normal bik movies? I've not seen sfall cause that, but the obvious guess would be that it's something to do with the avi movie support. You can try and comment out sfall's attempt at loading 32 bit movies and see if that helps.

 

[Lexx]

Would it be possible to add a kind of placeholder signs in a dialogue / pro_item.msg file, which later in the game will be used for text replacements?

Example:

{100}{}{Hello, my name is @npcname@ whats up?}

@npcname@ =>
if variable x == 1, then "Hans"
else if variable x == 2, then "Peter"
...

?

Or adding variable item description: If variable x == y, item name "bottle" becomes "broken bottle" and description "looks like a bottle" becomes "damn, it IS a bottle!".

I know, the item name and description thingy could be done with adding new items with this name and description, but I have a list with nearly 40 possible names and never will I add an item 40 times with always only changed name and description.

The normal text stuff can be done scripted as well, even though it's a bit inconvenient. So it's not really that important to me. But I really would like to change item name and descriptions ingame. Right now, this is not possible, as far as I know.

 

[Timeslip]

Would it be possible to add a kind of placeholder signs in a dialogue / pro_item.msg file, which later in the game will be used for text replacements?

Things like @pcname@ and @date@ and other global values could be replaced at the point where the message is read from the file with no problem. Something like @npcname@ is a lot harder. The code that reads data from a message file doesn't know what npc is being referred to, so there's no way you could make the substitution there, and messages are used in so many places that patching them all at a point lower down the call stack where I could find out what messages were being talked about would be impractical.

I could add an msg_expand script function that does more complicated substitution using the object the script is attached to, but at any point where you're reading a message in from a script you could do what you like with it anyway. (<s>dialogue should come under this heading anyway, so what's the problem there?</s> Edit: Ah, you already said it could be scripted. I should have read more carefully.)

 

[Lexx]

First I thought, it might be possible to change item name and description via script attached to that item. The procedure would be then like with normal npcs:

procedure description_p_proc begin
   script_overrides;
   display_msg(mstr(102));
end

But sadly, this had no effect on the item. In fact, the item description then has been empty in the game. No error message or something else shown.

 

[NVShacker]

ok, I'll make that change then. I'll also need to do something about the dinput.h header... That's part of the old dx sdk, and not sfall, so licence-wise I shouldn't have it stored in sfall's svn repository at all, never mind making changes to it. The problem is that that header isn't included in the dx9 sdk that the rest of sfall needs, so it still needs to come from somewhere. Maybe I'll make a seperate build pack download that has that and the .obj files for the upscaling filters.

The DX9 SDK from March 2009 has a version of it that seems to work fine, I assume it was dropped after that?

I'd honestly drop the native SFall support for middle mouse -> button code and let scripts handle that for flexibility though I guess you don't want to drop a feature.

No, I wouldn't want to drop that. There's nothing stopping people disabling it in ddraw.ini and using a script if they want though, so you get the best of both.

Makes sense.

Also, building myself seems to cause movies to crash with a memory read violation, even when building from the revision that's on sourceforge, which leads me to believe I'm doing something wrong, Hael/Timeslip either of you familiar with this issue with building it?

Normal bik movies? I've not seen sfall cause that, but the obvious guess would be that it's something to do with the avi movie support. You can try and comment out sfall's attempt at loading 32 bit movies and see if that helps.

Bizarrely, killing all of the movie hook code seems to have no effect, I can't even find sfall in the stack trace trying to debug it. *shrug* I'll continue to play with it.

 

[DForge]

Heanlomal: AWESOME. I've been waiting for level 6 fix for years. Each time I started a new fallout session, this stupid issue was annoying me. it's like using a race car on a race track and never being able to shift to last gear.

For those who don't care: well, actually there is a huge gap between level 5 and level 6 NPC in terms of power. This may mean +2 APs and +10% critical chance, for instance. Which may mean another shot with a carried weapon, or, if you prefer, another aimed shot with, say, a gauss rifle if you're controlling party members manually. Which pretty much doubles damage per turn. And NPCs are all about damage per turn.

For those who completely don't care about NPCs: well actually, despite lame AI controlling them, they are worth more than any perk because of the damage they do. Level 6 Sulik with a HK 90c is pretty much OHKO for every enemy there is if you set him to charge, for instance. Recruiting him (which possibly means rising your CH by 2) equals to, say, getting 2 more shots with gauss pistol with better criticals. Who wouldn't want such a perk?

And that is JUST for 2 CH points & will benefit you through ALL the game, unlike Sniper perk and whatever you have.

The problem with this game is that it is too easy to make use of that. yeah, save 9-man enclave patrols, you are untouchable as long as you take proper positioning. The casino fights in New Reno are a good example: the enemies will run into ol' Big J Mordino's room and get slaughtered one by one by you and your team at relatively low levels/bad gear. This isn't possible without a party, afaik, unless you want to exploit bugs or simply farm exploits which shouldn't be there aka San Fran speedrun.

There's no bug in the code that accidentally prevents npcs from getting their last level. It's a deliberately cut feature, and for some npc's, the 6'th level proto was never created in the first place, so it's not a last minute cut either.

For some there is no Stage 5 either - Cassidy, for instance. Does it mean anything other that he wasn't intended to have more levels than 4 - contrary to other NPCs?

I can barely see it as feature, seeing that everything is left in place, save the issue Heanlomal described. It doesn't even make any sense for the game creators to deliberately cut such a "feature" after implementing EVERYTHING in the game. And if they wanted to, wouldn't it be better to simply erase the PID and proto files with one click rather than making a buggy check in the engine? What for?

Just because something was originally intended doesn't make its absence a bug, or the whole RP should be merged into the unofficial patch. (Of course, killap might want to have it default on for the RP, for exactly that reason.)

The problem here is that pretty much EVERYTHING seems to imply it is some sort of underlooked development rather than deliberate planning. I'm pretty sure it would look different otherwise. Unless you want to call it something else than a bug, maybe lame design or something else. Still, bugs aren't limited to misplaced variables or typos in code if you ask me. Something like a formula that isn't optimized to work properly, like the case of level 6 issue, is also a bug imho.