Separate names with a comma.
Discussion in 'Fallout General Modding' started by killap, Dec 23, 2013.
All saves work perfectly, no crash and Kaga behaves correctly. Thank you for the fixes.
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
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.
@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...
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...
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.
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.
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.
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.
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?
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.