Fallout 2 Restoration Project 2.3 (Unofficial Expansion)
- Thread starter killap
- Start date
- Status
First time out of the vault
All saves work perfectly, no crash and Kaga behaves correctly. Thank you for the fixes.
Last edited:
According to my observations, San Francisco boxing crashes occur when i make a hit on a knocked-out target (kicking and punching him while he is on the ground). The crash not occurs immediately, only after the next some round. My temporary solution was to end turns till my opponent regains his consciousness and gets up from the floor. Maybe it was all about luck but it worked. Even killing the opponents did not caused me trouble. I did not experienced this in New Reno boxing, however i always knocked out the target + ended combat, which won the fight.
Interesting, reason is the general availablity of multiprocessor systems? I was thinking the Fallout engine is completely synchronous and deterministic and therefore resistant against race conditions. Could be more race conditions hidden in the game and would it therefore make sense to pin the game to a single core?
AFAIK, RP is already forced to use a single core by sfall.
After disabling the patch and setting Mode=4 in ddraw.ini, now the game doesn't load at all. On launch, it gives me an error message stating:
The instruction at 10026e20 referenced memory at 00000000
The memory could not be read from
merenbach
First time out of the vault
Where at the SAD are the savegames that are corrupted? Are these saves made during combat?
Well, it's certainly multi threaded and that's all it takes for a race condition to crop up.
So, here's the situation with Kaga. Now initially I pinpointed the first set of crashes down to a function call in the procedure run when the map loads that had to do with Kaga's cronies facing you when you arrive. Oddly enough, it was just one of the cronies that would cause the crash -- the last one. Process of elimination found that it. This was the case for all the kaga files, except for the 5th encounter. Initially I was confused why that function would cause a crash in the first place, but once I saw that it didn't always happen and specifically didn't happen for the 5th encounter, I knew something deeper was at play. So I wrapped everything in the map procedure to run only if "is_map_loaded". That check returns true/false. No crashes after this for any of the encounters, even after reverting to their original state (calling the code to face the player). At this point I was like, ah, surely a race condition since the map was not truly loaded at this point but it was calling code that assumed the map was loaded. But this is where I get confused...
Another problem though is that, well, the map load procedure is called once and what if "is_map_loaded" is false at that point. You won't ever get the code wrapped inside it to run then. Buuut, if it was the case that the map was not loaded and hence causing the crashing, then how on earth does the code get run now. Shouldn't have "is_map_loaded" returned false? Is the engine doing something special with that check and actually treats that code as a callback? Impossible. I'd have to say no, because I had fixed a few issues awhile back that things enclosed in "is_map_loaded" were never ever run and thus some scripts were broken on map loading until I actually removed the "is_map_loaded" check.
So yeah, I don't know, but hey, at least Kaga is happy now. And apparently this also fixed empty Kaga encounters too! At least that is what I believe one user was telling me.
Last edited:
merenbach
First time out of the vault
@killap, without knowledge of the scripts here I'm more or less stabbing in the dark. Is it possible that the check for is_map_loaded has the side effect of ensuring the map gets loaded, or maybe setting some other variables, in the case of the Kaga encounter? Since you say you do software development it may have occurred to you already, but I thought I'd ask.
EDIT: Whoops, I totally edited your message by mistake...
EDIT: Whoops, I totally edited your message by mistake...
Last edited by a moderator:
No a map will always load without that check. I'm assuming they just added it because of asynchronousness. In the case of map loading you would totally code in a call back function to run once the loading finished. I don't see any callbacks and this check certainly isn't one, so I don't see why it would help. But it does here...merenbach said:
And I do believe things were being run too early for Kaga because when the map loads I hear the critters arming themselves before everything is actually displayed on the screen (it's all still black). With the check in place, I hear no noises until after everything is drawn on the screen.
merenbach
First time out of the vault
To me (again, operating in a vacuum here) that almost sounds as though the relevant script is being called twice. The first time it's ignored with your fix because the map's not yet ready, and the second time it's loading like any other map.
What about other graphic modes in sfall? Have you looked at the WINE/Mac instructions here: http://falloutmods.wikia.com/wiki/F2RP_Technical_Info
The point is that the map procedure is only run once. I tested with printing something out and it only prints once, with or without the loading check. Now perhaps the game encounters that check and then waits to call everything wrapped inside until loading is truly complete. Some sort of quasi-callback. I never heard of something structured like that, but sure. The problem there though is that why did I find cases previously where stuff wrapped in that check would never get run on map load. Our map "callback" doesn't always get run? *head explodes*. It's all very strange. There is just a lot of inconsistencies here.
Last edited:
You gotta love the Fallout engine.
I remember when I had a "dude object" pointer crash the game, and had to use "self object" instead to get it to work. The object in question was the dude, and the pointer ends up being the same anyway, except one way crashed and the other did not. A bit head-scratching this engine is.
And damned time difference, I missed all the action yesterday.
I remember when I had a "dude object" pointer crash the game, and had to use "self object" instead to get it to work. The object in question was the dude, and the pointer ends up being the same anyway, except one way crashed and the other did not. A bit head-scratching this engine is.
And damned time difference, I missed all the action yesterday.
Schezza
First time out of the vault
How many APs and HPs does Kitsune have on max level? mine has 9-120 atm, but seeing that others have 10-13 and 128-146 I assume there's atleast one more level
Yes Kitsune has one more level. She starts out with 80 HP and ends up with 130 HP and her AP will always be the 9 she starts with.
Schezza
First time out of the vault
thanks.
Killap's unofficial patch gets around this by a simple solution: killing Dr. Schreber in Navarro saves the deathclaws if the player can kill him before the attack (two weeks after first entering V13).
Can someone confirm this, please? Played F2 before and he's always dead long time before I enter V13. Last thing I read only way to prevent deathclaws being killed is by doing Enclave before the raid.
Killap's unofficial patch gets around this by a simple solution: killing Dr. Schreber in Navarro saves the deathclaws if the player can kill him before the attack (two weeks after first entering V13).
Can someone confirm this, please? Played F2 before and he's always dead long time before I enter V13. Last thing I read only way to prevent deathclaws being killed is by doing Enclave before the raid.
That should work, but only in the RP. I don't think the unofficial patch does that anymore. It's strictly bug fixes. Is the raid still happening for you in the RP?
RolandDeschain79
Android Adventurer
Kudos to you as well for making it work on Android!
So I don't know how you have things setup, but have you tried manually setting it through the f2_res.ini file? You don't have to change these setting through the game itself.
Hey Killap,
Well after a lot of tweaking and bashing my head against the table I believe I've found the problem. I'm not sure if this is also related to the black screen issues that people have been reporting but it might be something for those folks to test as well.
First I attempted to modify the f2_res.ini but no matter what I did the changes would stick unless it was set to Direct draw 7 mode, which was so lagged it made the game unplayable.
So I ate a box of Mentats and proceeded to modify things by mixing new and old files; which is how we have this running on Android in the first place with DX9C
After replacing Mash's current High resolution patch with the older 3.06 version, the problems have disappeared and performance in Direct draw 7 mode is back to normal.
This replaces the current settings GUI with the older one, which wasn't working properly on my old emulated setup.
I don't understand why this works or what the issue is but it does seem to indicate a problem with Mash's latest version of the patch and your RP versions 2.2-2.3.
I made a link for the older version and I want to add that to my forum info to get people playing with the RP2.3 instead of 2.1.2b. Do you think there would be any problem playing F2RP2.3 with this modification? I don't have saved games for 2.3 yet so I will actually have to start testing this out with a new game. If anyone would be kind enough to upload their RP2.3 saves so that I can load them and look for issues I would be very grateful
Here is the older patch if anyone would like to test it on their PC and see if that fixes the reported issues with RP2.3
I should note that this works only for the DosBox Turbo version of the Mod I may need to try older version of the RP for the QEMU version. Do you happen to have a link to an archive for your older RP versions Please and thank you.
Download Fallout2_High_Resolution_Patch_3.06
Last edited:
Interesting find, RolandDeschain79. I've seen people report the same thing about the high-res patch. There shouldn't be any problems using it, though I can't say for certain...
I do have older versions. You can find them all here: http://killap.net/fallout2/expansion/old/
@iLikeDirt, it might be worth reverting you changes to ddraw.ini and then downloading the high-res patch v3.06 and use that instead. I'm curious if that works for you.
I do have older versions. You can find them all here: http://killap.net/fallout2/expansion/old/
@iLikeDirt, it might be worth reverting you changes to ddraw.ini and then downloading the high-res patch v3.06 and use that instead. I'm curious if that works for you.
Last edited:
- Status