No, the latest release is 4.3.7.
It's SourceForge rollbacked the download section.
EDIT: https://sourceforge.net/p/forge/site-support/
Yup, sfall isn't the only one having the issue.
EDIT 2: The files are back now.
Last edited:
Fallout 2 mod FO2 Engine Tweaks (Sfall)
- Thread starter Dude101
- Start date
It's SourceForge rollbacked the download section.
EDIT: https://sourceforge.net/p/forge/site-support/
Yup, sfall isn't the only one having the issue.
EDIT 2: The files are back now.
sfall 4.3.8 and 3.8.38 are released on SourceForge, along with their respective modders packs.
Changelog said:
I still don't know anything about the exe but here is a mad idea:
When sfall detects an animation that is mid-way in map_exit, can't it try to cancel it and force it into a single frame animation?
For testing:
The crash: Take desert1 and put any critter on it, give it a script (EcBandit; or preferably something not hostile on LoS) and give that critter:
procedure map_exit_p_proc begin
in map_exit. This should force a crash every time. [edit: it crashes the next time you try to enter a map, probably as desert1 isn't saved, when I had this on a different map (that is saved), it crashed immediately.]
The fix: However, if you force the critter into a single frame animation first, example (add the following to EcBandit):
procedure map_update_p_proc begin
it does not crash on map exit. [edit: because it blocks the animation, I guess.]
...
If the engine could somehow twist these animations into a SF (in map_exit), maybe it could fix these crashes (example: a critter explodes during map_exit).
...
Here's the folder of the files I put together to test if the above is correct in essence: https://easyupload.io/u9owru
...
Idk, if this is useful or feasible, but it's a script stunt to make [critter_dmg(self_obj, 119, 256);] in map_exit work. Pointless, maybe... but you do get the scream on map_exit (for a cinematic walk off, for example) [edit: or play an sfx...]... which you don't get with kill_critter or Dmg_NoAnimate.
Anyway, I guess it all depends if the SF can be shoehorned in before map_exit fully executes and then doesn't know what to do with the critter in mid-animation.
...
P.S. This works too:
procedure map_exit_p_proc begin
critter_dmg(self_obj, 119, 256);
anim(self_obj, 48, -1);end
Maybe I'm dumb, but when I can fix it in script, no reason why sfall shouldn't be able too, right? Then again, I don't know how to detect if a critter is in mid-animation...
Anyway, just an idea of a (crash) fix that does work in script.
[edit: don't do this, it was a glitch.]
[Glitch (explained): In 4.3.6 & 4.3.7 I can put the above in EcBandit. When I then leave the map, it plays the scream and I crash when I enter the next map. However, when I save on the map, then load that save and try the same, I skip the crash in 90%* of all times (*a fresh start needed two or three tries before it became consistent). But it seems the EcBandit is not set to dead in those cases. When I empty the music folder, it fails the skip entirely (no idea why). This was fairly consistent at my end. It also only works with sfall, w/o it I crashed every time I tried.]
When sfall detects an animation that is mid-way in map_exit, can't it try to cancel it and force it into a single frame animation?
For testing:
The crash: Take desert1 and put any critter on it, give it a script (EcBandit; or preferably something not hostile on LoS) and give that critter:
procedure map_exit_p_proc begin
critter_dmg(self_obj, 119, 256);
endin map_exit. This should force a crash every time. [edit: it crashes the next time you try to enter a map, probably as desert1 isn't saved, when I had this on a different map (that is saved), it crashed immediately.]
The fix: However, if you force the critter into a single frame animation first, example (add the following to EcBandit):
procedure map_update_p_proc begin
anim(self_obj, 48, -1);
critter_injure(self_obj, 8);
endcritter_injure(self_obj, 8);
it does not crash on map exit. [edit: because it blocks the animation, I guess.]
...
If the engine could somehow twist these animations into a SF (in map_exit), maybe it could fix these crashes (example: a critter explodes during map_exit).
...
Here's the folder of the files I put together to test if the above is correct in essence: https://easyupload.io/u9owru
...
Idk, if this is useful or feasible, but it's a script stunt to make [critter_dmg(self_obj, 119, 256);] in map_exit work. Pointless, maybe... but you do get the scream on map_exit (for a cinematic walk off, for example) [edit: or play an sfx...]... which you don't get with kill_critter or Dmg_NoAnimate.
Anyway, I guess it all depends if the SF can be shoehorned in before map_exit fully executes and then doesn't know what to do with the critter in mid-animation.
...
anim(self_obj, 48, -1);
Anyway, just an idea of a (crash) fix that does work in script.
[edit: don't do this, it was a glitch.]
[Glitch (explained): In 4.3.6 & 4.3.7 I can put the above in EcBandit. When I then leave the map, it plays the scream and I crash when I enter the next map. However, when I save on the map, then load that save and try the same, I skip the crash in 90%* of all times (*a fresh start needed two or three tries before it became consistent). But it seems the EcBandit is not set to dead in those cases. When I empty the music folder, it fails the skip entirely (no idea why). This was fairly consistent at my end. It also only works with sfall, w/o it I crashed every time I tried.]
Last edited:
Why not play the death sfx directly then kill_critter or DMG_NOANIMATE? It seems to me you don't really need the animation itself (don't see a point for map exit), only need the screaming.
Code:
play_sfx("HMXXXXBF");
critter_dmg(self_obj, 999, DMG_normal_dam bwor DMG_BYPASS_ARMOR bwor DMG_NOANIMATE);Absolutely. The same (using sfx) occurred to me over the day. This whole map_exit is dumb anyway, what mainly triggered this was “critters exploding outside of combat” which can happen and hitting exit at the same time should crash.
I thought the above could be an angle, but it isn't... I was too rash.
Addition:
It's noteworthy that any explosion seems to trigger an UI-disable, however, I don't think that stops animation, so if already running it should still take me to the exit... however, I never had this happening (!), it's just something I have in the back of my head as something that "could" happen. And when I was told someone crashed on exit my first diagnosis was "must have hit an explosion mid-way on exit"... however, I may have been wrong actually... too rash, as said.
Addition II:
Actually, a UI disable may block an exit from map (never tested), but I do know that you can break a UI disable by taking damage (like an explosion) or starting combat.
I thought the above could be an angle, but it isn't... I was too rash.
Addition:
It's noteworthy that any explosion seems to trigger an UI-disable, however, I don't think that stops animation, so if already running it should still take me to the exit... however, I never had this happening (!), it's just something I have in the back of my head as something that "could" happen. And when I was told someone crashed on exit my first diagnosis was "must have hit an explosion mid-way on exit"... however, I may have been wrong actually... too rash, as said.
Addition II:
Actually, a UI disable may block an exit from map (never tested), but I do know that you can break a UI disable by taking damage (like an explosion) or starting combat.
Last edited:
NineCoronas
First time out of the vault
I just wanted to say that the option to control your party members during combat has been a complete gamechanger to the way the game is played. thank you!
I'm pretty sure this is well known, but here is another example of it:
...
Dialogue options
It happens that the option lines fit perfectly, but the highlighting assumes that the line is different in size than it actually is. As a result, options (or line-breaks) can be cropped off or even disappear.
This is something I can fix by adding (pointless) spaces to the option line (i.e. force the line to be longer than it is) so the engine displays it correctly.
...
Example 1 (Fo2 default):
{157}{}{I am so happy to see you again. What can I do for you today?}
{158}{}{Hi, I didn't expect some kind of Spanish inquisition, there are three weapons at our disposal ruthless... some other stuff...}
This will cut off "stuff" when highlighting (158). It also fails to highlight "stuff" as if the engine doesn't realize there is a line break. [This happens regardless of NumbersInDialogue.]
And it's purely length related. This fails too:
{158}{}{Hi, I didn't expect some kind of Spanish inquisition, there are three weapons at our disposal ruthless... some other stuff t}
But add anything after the "t" and it's fine (i.e. highlighting recognizes the line-break).
...
Example 2 (using NumbersInDialogue & default (see edit)):
{157}{}{I am so happy to see you again. What can I do for you today?}
{158}{}{Uh, I didn't actually try to use them but I think they can be used to disable the front laser gate and... some other stuff...}
{159}{}{I'm there, now I'm gone, now I'm there, now I'm...}
In this case, the second option line (159) disappears entirely when highlighting (158) and only hovering over (159) makes it appear again.
(Note: It must be option 1 & 2 for this to happen AND ddraw must be set to "NumbersInDialogue=1"). This is a rather rare bug I just happened to hit on the head. Example 1 is more common.
This is also purely length related. This fails:
{158}{}{Uh, I didn't actually try to use them but I think they can be used to disable the front laser gate and... some other stuff t}
While this works [creates a line break]:
{158}{}{Uh, I didn't actually try to use them but I think they can be used to disable the front laser gate and... some other stuff t.}
Edit: If NOT using NumbersInDialogue then this line creates the same behaviour:
{158}{}{Uh, I didn't actually try to use them but I think they can be used to disable the front laser gate and... some other stuff....}
Just needed a full stop more to compensate for the shorter bulletin.
...
Not sure if the highlighting being different length than the text can be fixed. More a QoL thing anyway. As I can always add spaces to artificially increase the line-length. It's just a bit tedious and messy to do.
Then again maybe something can be done along these lines? When I checked example 1, it almost looks as if the bulletin (at the start of each option) isn't accounted for (or accounted for incorrectly). That's about the space it is off. Not sure what is happening in example 2 [seems almost as if it's the same thing just inverted], in any case, it is length related, too. Still, probably tricky regardless, considering that each line in the dialogue window has a steadily increasing indent (see example 2 which needs to be in position 1 & 2, else it doesn't trigger, it's very specific). Wouldn't be surprised if this is difficult to fix.
...
TEST:
For confirmation I used DcTubby.msg (1.02d) and replaced the lines (second time talking) as shown above. Both examples should be reproducible. (I used 4.3.6 & 4.3.7)
P.S.S. I cannot have the game in windowed mode and adjust msg files on the fly, who would have thought. Need to load a save before it registers... :amazed & surprised:
...
Dialogue options
It happens that the option lines fit perfectly, but the highlighting assumes that the line is different in size than it actually is. As a result, options (or line-breaks) can be cropped off or even disappear.
This is something I can fix by adding (pointless) spaces to the option line (i.e. force the line to be longer than it is) so the engine displays it correctly.
...
Example 1 (Fo2 default):
{157}{}{I am so happy to see you again. What can I do for you today?}
{158}{}{Hi, I didn't expect some kind of Spanish inquisition, there are three weapons at our disposal ruthless... some other stuff...}
This will cut off "stuff" when highlighting (158). It also fails to highlight "stuff" as if the engine doesn't realize there is a line break. [This happens regardless of NumbersInDialogue.]
And it's purely length related. This fails too:
{158}{}{Hi, I didn't expect some kind of Spanish inquisition, there are three weapons at our disposal ruthless... some other stuff t}
But add anything after the "t" and it's fine (i.e. highlighting recognizes the line-break).
...
Example 2 (using NumbersInDialogue & default (see edit)):
{157}{}{I am so happy to see you again. What can I do for you today?}
{158}{}{Uh, I didn't actually try to use them but I think they can be used to disable the front laser gate and... some other stuff...}
{159}{}{I'm there, now I'm gone, now I'm there, now I'm...}
In this case, the second option line (159) disappears entirely when highlighting (158) and only hovering over (159) makes it appear again.
(Note: It must be option 1 & 2 for this to happen AND ddraw must be set to "NumbersInDialogue=1"). This is a rather rare bug I just happened to hit on the head. Example 1 is more common.
This is also purely length related. This fails:
{158}{}{Uh, I didn't actually try to use them but I think they can be used to disable the front laser gate and... some other stuff t}
While this works [creates a line break]:
{158}{}{Uh, I didn't actually try to use them but I think they can be used to disable the front laser gate and... some other stuff t.}
Edit: If NOT using NumbersInDialogue then this line creates the same behaviour:
{158}{}{Uh, I didn't actually try to use them but I think they can be used to disable the front laser gate and... some other stuff....}
Just needed a full stop more to compensate for the shorter bulletin.
...
Not sure if the highlighting being different length than the text can be fixed. More a QoL thing anyway. As I can always add spaces to artificially increase the line-length. It's just a bit tedious and messy to do.
Then again maybe something can be done along these lines? When I checked example 1, it almost looks as if the bulletin (at the start of each option) isn't accounted for (or accounted for incorrectly). That's about the space it is off. Not sure what is happening in example 2 [seems almost as if it's the same thing just inverted], in any case, it is length related, too. Still, probably tricky regardless, considering that each line in the dialogue window has a steadily increasing indent (see example 2 which needs to be in position 1 & 2, else it doesn't trigger, it's very specific). Wouldn't be surprised if this is difficult to fix.
...
TEST:
For confirmation I used DcTubby.msg (1.02d) and replaced the lines (second time talking) as shown above. Both examples should be reproducible. (I used 4.3.6 & 4.3.7)
P.S.S. I cannot have the game in windowed mode and adjust msg files on the fly, who would have thought. Need to load a save before it registers... :amazed & surprised:
It's normal. You can try to compile the same source twice on your system, and the two DLLs won't even have the same checksum.
I didnt know about that. Interesting. So if im not changing anything in the source and if its succesfully compiles, i will have an equal file to released version of sfall from github, right?
Yes, you should have a binary with the same functionality.
Ok. Thx for answer. But can you tell me why is that? Compiler adds some random bytes or what? How it works?
Some info about "deterministic builds":
https://blog.conan.io/2019/09/02/Deterministic-builds-with-C-C++.html
https://stackoverflow.com/questions/1180852/deterministic-builds-under-windows
https://blog.conan.io/2019/09/02/Deterministic-builds-with-C-C++.html
https://stackoverflow.com/questions/1180852/deterministic-builds-under-windows
Where i can read about HookCalls is there some documentation about sfall source code? I mean when i can and cannot use them? For example tried to replace _credits func, wrote a func with __asm and hook it like this - HookCalls(myHookFunc, {addrOfCreditsFunc}). It is always a crash on the certain address. _credits in addr 0x42C860, crashes on addr 0x42C869 if i understand it right (error below). its even not depends on code in __asm{}, i tried to let it empty for test - same error. Just cant realize where to look to understand what am i doing wrong.
Last edited:
I have no idea what you tried to do or what your function is. Check SafeWrite.cpp/.h to see how those memory hack functions work.
I'd like to hear more opinions about this issue: https://github.com/sfall-team/sfall/discussions/450
I think the current approach with mods folder is way better than before when we had to dump everything into data folder, but it still has issues:
Burn will say that "we need to strive for mods having no conflicts" and then load orders won't matter. This is simply not how modding is done in general. It's some purist pipe-dream from the world of enterprise development. Mods override files from other mods, that's what the concept of modding is all about. I change a pro file, other mod change it. I want to make sure it has a priority. Example - EcCo and RPU. RPU is a mod that contains a lot of prototype files. My mod is based on that but it changes them. It's important that it is loaded after or nothing will work. How do you achieve "no conflicts"?
Let's say we are in a perfect future where we don't use proto files but some advanced json/yaml-based runtime patching system. No conflicts, right? Wrong. Mod A made by one guy, changes 100 items, most of the changes are good, but other guy thinks some of them needs to be corrected. He makes mod B that changes the same values of the same items but only a subset. His mod has to be in the correct load order, so that this patching applies changes correctly.
Load orders will never go away.
I think the current approach with mods folder is way better than before when we had to dump everything into data folder, but it still has issues:
- Having to fiddle with names to achieve proper load order. This is insane, I have very rarely seen such nonsense (if ever) in my entire modding "career".
- Having to temporarily move/delete/rename files/folders from the mods folder to disable them.
Burn will say that "we need to strive for mods having no conflicts" and then load orders won't matter. This is simply not how modding is done in general. It's some purist pipe-dream from the world of enterprise development. Mods override files from other mods, that's what the concept of modding is all about. I change a pro file, other mod change it. I want to make sure it has a priority. Example - EcCo and RPU. RPU is a mod that contains a lot of prototype files. My mod is based on that but it changes them. It's important that it is loaded after or nothing will work. How do you achieve "no conflicts"?
Let's say we are in a perfect future where we don't use proto files but some advanced json/yaml-based runtime patching system. No conflicts, right? Wrong. Mod A made by one guy, changes 100 items, most of the changes are good, but other guy thinks some of them needs to be corrected. He makes mod B that changes the same values of the same items but only a subset. His mod has to be in the correct load order, so that this patching applies changes correctly.
Load orders will never go away.
Last edited:
As I already mentioned it in passing:
I found an engine bug w/ WM 2:
In WM 2 the enemies destroy their inventory in destroy proc and in pick up proc (both works).
However,
When I stack corpses and then knock an enemy unconscious on top of that stack, and then use the arrow buttons to cycle through the corpses, then the unconscious critter's inventory was not destroyed when I reached it.
So it seems the arrow buttons fail to call pick_up_p_proc. [sfall used was 4.2 (bit old maybe...)]
...
However, I just confirmed it again today [using sfall 4.3.7]. And I'm positive it failed to call pick up proc. Not a big deal, but it's an engine bug.
And I get this in F12se:
09:57:00.705 WARNING File: C:\Games\WM2_v1.0a\data\SAVEGAME\SLOT01\sfallgv.sav was loaded with errors. Position 32/36
Any idea what position 32/36 is?
Maybe I can fix this.
I found an engine bug w/ WM 2:
In WM 2 the enemies destroy their inventory in destroy proc and in pick up proc (both works).
However,
When I stack corpses and then knock an enemy unconscious on top of that stack, and then use the arrow buttons to cycle through the corpses, then the unconscious critter's inventory was not destroyed when I reached it.
So it seems the arrow buttons fail to call pick_up_p_proc. [sfall used was 4.2 (bit old maybe...)]
...
However, I just confirmed it again today [using sfall 4.3.7]. And I'm positive it failed to call pick up proc. Not a big deal, but it's an engine bug.
And I get this in F12se:
09:57:00.705 WARNING File: C:\Games\WM2_v1.0a\data\SAVEGAME\SLOT01\sfallgv.sav was loaded with errors. Position 32/36
Any idea what position 32/36 is?
Maybe I can fix this.
@Muttie
The F12se sfallgv.sav not an sfall bug..
this was an f12se bug. it only screwed your savegae if you've decided to overwrite sfalgv.sav ( normally this file would not get overwritten during saving with f12se.
Lately though someone did help Vad with sfallgv.sav file structure, and Vad made it work in latest build. However the latest build triggers antiviruses, and Vad is currently unable to go arount that problem, the versions that don't trigger antiviruses, have no source code anymore ( it got lost/overwritten according to Vad), so Vad is unable to craft fixed version of that.
I think the person that heled Vad was Phobos2077, or so i remembered.
Anyways @Muttie if you don't specifically press a button to save sfallgv.sav within F12se. you should be ok.
I have no problem in-game.
It just triggers for any save game of WM2, and "normally" F12se points out issues, so I thought maybe there's something I can fix. I just didn't what it could be... but nvm. All fine.
It just triggers for any save game of WM2, and "normally" F12se points out issues, so I thought maybe there's something I can fix. I just didn't what it could be... but nvm. All fine.
What I ment to say is: this bug with sfallgv.sav is present in about any Fo2 and or conversion there is. that's why Vad made a separate button to save sfallgv.sav file. it doesn't get saved, normally when you save all the other stuff. Nothing to worry about.
Though as I said Phobos2077 helped Vad solving the sfallgv.sv problem in the latest F12se builds. So it's an issue of older F12se buids only. and if You don't want to mess with antivirus warnings, You should stick to whatever version of F12se you have currently.