Fallout 2 mod FO2 Engine Tweaks (Sfall)

NovaRain said:
killap said:
And thanks, NovaRain. I'm still including the latest version of sfall for each version of Windows in my mods. I guess I'll use yours for Win 2k then.
If Timeslip doesn't change PartyControl.cpp in SVN except setting ControlCombat default to 0, my win2k build with r252 source should be functionally the same as the official 3.2.
There are indeed no other changes.

But that reminds me why I never added the line to the ini. Was going to change the syntax slightly to remove the need for the ControlCombatPIDCount line. Oh well, will do it some other time.
 
Timeslip said:
There are indeed no other changes.
But that reminds me why I never added the line to the ini. Was going to change the syntax slightly to remove the need for the ControlCombatPIDCount line. Oh well, will do it some other time.
Sounds great, since the count line seems redundant. Does that means we can control all PIDs as long as they're in CombatControlPIDList?
One more thing, may I post SVN builds in the thread if there's any new/significant update, for some people who might be interested in testing? :oops:
 
NovaRain said:
Sounds great, since the count line seems redundant. Does that means we can control all PIDs as long as they're in CombatControlPIDList?
Yup. Although don't blame me if controlling a non party member and shooting at your own party turns the whole world hostile or something. :p

NovaRain said:
One more thing, may I post SVN builds in the thread if there's any new/significant update, for some people who might be interested in testing? :oops:
Feel free.
 
Timeslip, sorry to bury you in requests (which I'm well aware will probably almost universally not be filled :)), but here's one that I think is either extremely easy to implement or virtually impossible: could you add an option to override the process that leads to compute_spray when animation type is 2E (burst)? I'd really love to be able to do all the bursting myself with my own simulated burst cone, but compute_spray gets in the way and all.
 
Hi. I've updated http://falloutmods.wikia.com/wiki/Sfall_Requests#New_Requests

It would be fantastic to fix them. The first one seems most problematic but also makes the most pain :/.
If you think it is impossible to do, feel free to remove it.
Thanks

EDIT:
Maybe it's needed to click on edit to see those new requests.
Copy-pasted version

From Fallout Resurrection team: A game saved in combat where one of your NPC's has died will become corrupted. Engine issue. http://falloutmods.wikia.com/wiki/Restoration_Project_bug_reports#Misc._bugs

From Fallout Resurrection team: Dynamite/Explosive exploit. If you place an explosive to the critter's inventory, leave the map and return back after a while, even if the critter is hurt, it is still friendly and if it dies, destroy_p_proc is not called

From Fallout Resurrection team: Option to disable the ability to change game map by pressing the map number key before entering the city map.
 
BTW. Have someone ever encountered an issue when more critters than defined are generated by the worldmap (looks like they're multiplied) ?

I can't find a mistake in our WORLDMAP.TXT and we are experiencing this issue only on some machines. For instance it does not happen to me even if i place the problematic encounter with FORCED probability and then i'm travelling there for hours.


And another question. What do you think is the best way to "solve" multi core processors?

SingleCore=1
ProcessorIdle
or CPU_USAGE_FIX in HiRes patch?
 
Mario_Dweller said:
And another question. What do you think is the best way to "solve" multi core processors?

SingleCore=1
ProcessorIdle
or CPU_USAGE_FIX in HiRes patch?
Depends what you mean by 'solve'

SingleCore pegs fallout to a single core, but does nothing to cut cpu usage. I don't think it actually helps fallout at all, but I include it with practically every old game patch I write because it's 3 lines of code and so many games suffer from multithreading bugs that go away (or at least happen far more rarely) when the process is locked to one core.

ProcessorIdle=x causes fallout to sleep for x milliseconds each frame. It's a way to stop fallout eating up 100% cpu time on one core. It doesn't fix any bugs, it just cuts down cpu usage while playing fallout, with the knock on effects on fan speed/power usage. (With no downside either, because not many monitors are capable of several thousand fps.)

CPU_USAGE_FIX is the res patches version of ProcessorIdle. They both do a similar thing, with the added advantage that the res patch supports more than just fallout 2.
 
Is there any kind of way to make companion drop down to the ground and play dead and then make them get up again? Is it possible through sfall scripting?

Thanks for the answer, Timeslip
 
Drobovik said:
Is there any kind of way to make companion drop down to the ground and play dead and then make them get up again? Is it possible through sfall scripting?

Thanks for the answer, Timeslip
This should be doable with the normal animation script functions. Unless you mean you specifically just want to do it with Sfall :P
 
Timeslip:
"it just cuts down cpu usage while playing fallout, with the knock on effects on fan speed/power usage"

Thanks for the clarification. I see the question was unclear. That's exactly what we want.
 
Sorry for asking again, but it'd be really cool if you could let me know if it's possible to to have the burst (and flame) animations not call compute_spray but simply calculate as regular hits so I can use my own burst cone. If it's impossible (or near impossible) then I just have to go the less interesting route and assemble the damage formula I made; otherwise I can do everything with hookscripts.

If it's possible (and even easy, which I think it should be, but I'm probably wrong in this), but you don't have the time to address it in the foreseeable future, do you think it's conceivable that I could do so myself with the help of something like the .exe function architecture Kanhef made (whose links are unfortunately dead but I'm sure someone has them lying around somewhere)?
 
JimTheDinosaur said:
Sorry for asking again, but it'd be really cool if you could let me know if it's possible to to have the burst (and flame) animations not call compute_spray but simply calculate as regular hits so I can use my own burst cone. If it's impossible (or near impossible) then I just have to go the less interesting route and assemble the damage formula I made; otherwise I can do everything with hookscripts.

If it's possible (and even easy, which I think it should be, but I'm probably wrong in this), but you don't have the time to address it in the foreseeable future, do you think it's conceivable that I could do so myself with the help of something like the .exe function architecture Kanhef made (whose links are unfortunately dead but I'm sure someone has them lying around somewhere)?
I don't know the answer off the top of my head. compute_spray is at offset 0x423488. Adding SafeWrite32(0x423488 , 0x0004c2); somewhere at sfall startup will block it from being called. I have no idea what effects that will have.
 
JimTheDinosaur, do you want to externalize compute_spray, so that you can replace it with your own algorithm that takes the same inputs and generates the same class of outputs, but is a different function?
 
Well, I put it in LoadGameHook.ccp, like this:

Code:
void LoadGameHookInit() {
	SaveInCombatFix=GetPrivateProfileInt("Misc", "SaveInCombatFix", 1, ini);
	if(SaveInCombatFix>2) SaveInCombatFix=0;
	if(SaveInCombatFix) {
		GetPrivateProfileString("sfall", "SaveInCombat", "Cannot save at this time", SaveFailMsg, 128, translationIni);
	}
	SafeWrite32(0x423488 , 0x0004c2); 
	HookCall(0x480AB3, NewGame);

etc.

Not sure if it was the right place, but it definitely had an effect: all weapons (including spears) can no longer be used at all. Is it maybe because compute_spray has simply been blocked, instead of being replaced by a call for the regular damage formula?

edit: I only have very brief comments by Atom in this to go by, where he says that "compute_spray is called if and only if weapon's animation type is 2E or 2F (burst attack and flame attack, respectively). Check for single shot/melee/etc. attacks is made elsewhere." So I guess you'd need to replace the compute_spray call with that single shot call "made elsewhere"? Or am I wide off the mark?

edit2: or does the fact that all weapons have stopped functioning mean that Kanhef was right after that "The function compute_attack is in charge of most of the process. Early on it makes a call to compute_spray; treating a single shot as a burst of 1 simplifies the code."? I've followed Atom in his interpretation, but no idea what's actually the case.

JimTheDinosaur, do you want to externalize compute_spray, so that you can replace it with your own algorithm that takes the same inputs and generates the same class of outputs, but is a different function?

Um, don't think so. I just want bursts to behave in the exact same way as a single shot would, except with the burst animation. If it behaves like that I can overwrite the ordinary burst behavior with my own simulated burst behavior (I can now make bursts for single fire weapons, but without the correct animation there isn't much of a point). In case you're interested, you can see some screens of the cone here.
 
The RP has had this issue since way back and I thought I'd look at it again but alas, I'm still stumped.

I have a spatial script registered as script #1451. If I use something like

Code:
float_msg(dude_obj, message_str(1451, 100), FLOAT_MSG_YELLOW);
or
Code:
display_msg(message_str(1451, 100));

Then I get an "Error" displayed. If I use scripts #1450 or #1452 instead (i.e. replace 1451 in the code above with either of these), I still get an "Error". However, if I go less than 1450 or greater than 1452 then it properly displays the text at line 100 in the msg file that I'm linking to. And yes, all these files have at least line 100 in them.

Any ideas? I only ask because sfall allowed for extending beyond 1450 scripts and this is perhaps an edge case?
 
killap said:
The RP has had this issue since way back and I thought I'd look at it again but alas, I'm still stumped.

I have a spatial script registered as script #1451. If I use something like

Code:
float_msg(dude_obj, message_str(1451, 100), FLOAT_MSG_YELLOW);
or
Code:
display_msg(message_str(1451, 100));

Then I get an "Error" displayed. If I use scripts #1450 or #1452 instead (i.e. replace 1451 in the code above with either of these), I still get an "Error". However, if I go less than 1450 or greater than 1452 then it properly displays the text at line 100 in the msg file that I'm linking to. And yes, all these files have at least line 100 in them.

Any ideas? I only ask because sfall allowed for extending beyond 1450 scripts and this is perhaps an edge case?
.
killap are you sure it's not something like the issue I encountered in VAULT13.GAM of lines being too long? [Or an invalid character in the line, etc etc.] I'd doublecheck SCRIPTS.LST to make sure it's not something like that. Also make sure the script name on those three lines is typed correctly and has a MSG file named the same name ;)

Basics I know but sometimes it's easy to miss something and not realize it :shrug:

EDIT: Sounds more like an issue with Sfall, maybe the setting isn't applying properly, but I'd still check basic stuff one more time to be sure.
 
My compiles of SVN r254: (removed due to newer versions)
(The dll in "trace" folder is equal to the "debugging" one in modder's pack.)

There's a bug in previous sfall versions since 2.15a about enabling custom skills config. If you enable SkillsFile setting, sfall built-in default doesn't count Strength attribute in for Melee and Unarmed skills. That means the original formulas for both skills:
Code:
Melee = 20+[2*(AG+ST)]
Unarmed = 30+[2*(AG+ST)]
will become:
Code:
Melee = 20+(2*AG)
Unarmed = 30+(2*AG)
For old versions, if you want to use custom skills config (skills.ini) but don't plan to change skill/stat relationship, you will need to add these two lines as a quick fix for Melee & Unarmed formulas:
Code:
Skill3=s2|a2 ;Unarmed formula fix
Skill4=s2|a2 ;Melee formula fix
 
Last edited:
I seem to have found a bug in the set_perk_freq() function. When set to 0, you get perks every three levels, as usual (I guess that's intentional). When you set it to 1, you get a perk every single time you level up. If you set it to anything greater than 1, you stop getting perks at all. Tested it on a range of numbers > 1, and it's always the same. I went up to about level 20 and no perks :(

I'm running set_perk_freq() from a global script; it didn't seem to work from a normal script (obj_dude.int).

Also, another request - would it be possible to make the function play_sfall_sound playback sounds with the loudness set in the options menu? I guess there would need to be some sort of get_sound_settings function which would enable me to pick whether I want the music slider, or the sfx slider, and adjust the play_sfall_sound loudness accordingly.

Thanks in advance for everything! :)
 
Timeslip, could you possibly add my new damage formula to sfall? It compiles fine for me and works as intended (as far as I can tell). It's very compact because a lot of elements I didn't need (crit, difficulty multipliers, etc.) are cut out.

edit: sorry, made a mistake. Will upload the proper version in a bit.

edit2: here it is:

edit3: never mind, I only just realized that I've ended up doing the exact same thing as Haen only in a more contrived way.
 
Last edited:
Back
Top