Darek said:
Ah, ok, sorry then! I never experienced any problems with my own exploding pants adventures, so I assumed from the discussion that it only applied to leaving the map before the explosion.
Fallout 2 Restoration Project 2.2 - OPEN BETA (ie NOT FINAL)
- Thread starter killap
- Start date
- Status
Ah, ok, sorry then! I never experienced any problems with my own exploding pants adventures, so I assumed from the discussion that it only applied to leaving the map before the explosion.
Heh hehJimTheDinosaur said:
@killap: No worries. I copied Darek's code from a few pages back, and have been looking it over. I'm almost certain I can made a rudimentary version of it for Fallout 1 engine. It won't have to run every map load, just when returning to the map(s) where the pants were exploded at.
Also, in testing for this I noticed that Fallout's handling of Steal is absolute bullshit. Even at 200%, planting a dynamite failed at least half of the time. What a fucking joke.
That won't be enough, you'll only be 50% covered. Like killap and I discussed, there are different crash scenarios. To fix the insta-crash part you need to start combat before the explosion too. I checked and Fallout 1 is affected by that as well.Sduibek said:
At least you don't need to worry about searching for explosives on the ground as Fallout 1 don't auto drop dynamite from inventory slot.
Yeah I've never understood how it really works. Isn't it supposed to consider size of item and how many times in a row too. Wonder if it really works properly, should be more successful at higher skill levels.Sduibek said:
Cool, best of luck coming up with something. Since your hook scripts don't run when explosives go off, it's put a bit of a damper on my own workaround.Timeslip said:
Does sfall for Fallout 2 allow to override the 95% cap on success rates?
If you mean hit chance, yes. Normal skill checks... no idea.
Nope, Fallout 1 is my jobZeonII said:
Heh. I had considered it long ago but at that time TeamX was in charge. Now Sduibek has taken over. There's something addicting about Fallout modding, but I think it's time I move on.Sduibek said:Nope, Fallout 1 is my jobZeonII said:
@Darek
I think I have a combination of hook scripts that takes care of the explosives crashes, minus the insta-crash scenario. I'm not completely satisfied, since the hooks I wanted to use don't trigger for explosions, but what I have will do and should only trigger when the bug actually would manifest itself. Should be the least invasive possible.
Give it a try combined with Timeslip's test dll. Hopefully all situations are covered here. I haven't been able to produce a crash on my end with this.
Hopefully Timeslip comes up with something better as she gets her hands dirty with reverse engineering, but worst case I think we have something that can work. This assumes the fix in her test dll doesn't cause other problems down the road.
Grab the files here.
Or we just assassinate the president with Super Stimpaks instead of explosives (or have high Sneak and being skilled in Unarmed combat (Silent Kill, Slayer etc)). The engine do crash from multiple explosives at the (almost) same time, so refraining from using explosives as means of assassination of powerful characters might be a good idea if this cannot be fixed easily.
By the way, in Megamod this superstim exploit is handled in a cool way. It deletes your stims every time you use it on the healthy NPC.
NO CHEATERS ALLOWED!
NO CHEATERS ALLOWED!
Good name for a website.Drobovik said:
Oppen
FIXT n°1 fan
I don't know why you consider that cheating. In the worst case, you could say there's a missing check for stealing, since a character would probably not like someone poisoning him, but that's no cheat. IRL you can kill without violence, why would that be impossible in games?Drobovik said:
No, Oppen, I'm actually good with the exploit. I like break open the game's potential as much as the next guy. It's just nice when developers give us, the exploiters
, the finger. You can't just do all you want, Mr. Gamer. hahaha
But sometimes balance should be considered too, you know. That's all I'm saying.
Even if we patch up all the exploits, in Fallout some smart fella still will find another one. Beauty of this great game.
, the finger. You can't just do all you want, Mr. Gamer. hahahaBut sometimes balance should be considered too, you know. That's all I'm saying.
Even if we patch up all the exploits, in Fallout some smart fella still will find another one. Beauty of this great game.
Sduibek said:
Its fun to stay at the (Y)NCA!
Gods, now I got that song stuck in my head. WHY?
... MCA. Sorry, will stop now. Seriously though, doing another run in F2 and came across a small spelling error in the speech (Max in Broken Hill if I recall right) about a "minor's strike" being the cause for raised prices for uranium. I assume you meant "miners".
@ killap
Nice, well done!
I found one crash problem though.
Planting explosives on ground next to the scientists in the reactor room still crash the game if they notice you planting explosives and then you sneak and exit combat. glexplc1 is not fired. If you are not noticed it works. Need a change in dude script. If G_var770 is -1 you don't want to take any action.
Also, I just had a thought about your fix.
What happens if you blow someone up, leave the map, blow someone up there and then come back to the first map?
That is a possibility with first killing the President and then the scientists (or vice versa). It will cause a crash.
Same thing if you blow up someone in New Reno. Lets take Renesco as an example on the New Reno 3 map. You exit to New Reno 2, but don't go back for a while. You play around for a while (still not returning) and then go to to New Reno 4. There you get pissed of with Mr Wright and decides to blow him up as well. By doing that Renesco will no longer be protected from crashing.
Could do with a second global variable for whenever the first one is already in use. Or is that over the top?
Then again, never underestimate what players will attempt to do.
And as i saw someone mention supper stimming, there is another crash bug there. Could be related.
The use of this "tactic" is controversial so I haven't bothered looking into it.
I did try three times with the President, twice it crashed when I left the map before he had died. On the third time it didn't, maybe cause I had entered combat mode on that try. That's not enough testing to say anything really, could be a coincidence. But like I said, I'm not going to bother with this.
Nice, well done!
I found one crash problem though.
Planting explosives on ground next to the scientists in the reactor room still crash the game if they notice you planting explosives and then you sneak and exit combat. glexplc1 is not fired. If you are not noticed it works. Need a change in dude script. If G_var770 is -1 you don't want to take any action.
Code:
procedure combat_p_proc
begin
if (global_var(770) == -1) then begin
// set_global_var(770, 0);
endAlso, I just had a thought about your fix.
What happens if you blow someone up, leave the map, blow someone up there and then come back to the first map?
That is a possibility with first killing the President and then the scientists (or vice versa). It will cause a crash.
Same thing if you blow up someone in New Reno. Lets take Renesco as an example on the New Reno 3 map. You exit to New Reno 2, but don't go back for a while. You play around for a while (still not returning) and then go to to New Reno 4. There you get pissed of with Mr Wright and decides to blow him up as well. By doing that Renesco will no longer be protected from crashing.
Could do with a second global variable for whenever the first one is already in use. Or is that over the top?
Then again, never underestimate what players will attempt to do.
And as i saw someone mention supper stimming, there is another crash bug there. Could be related.
The use of this "tactic" is controversial so I haven't bothered looking into it.
I did try three times with the President, twice it crashed when I left the map before he had died. On the third time it didn't, maybe cause I had entered combat mode on that try. That's not enough testing to say anything really, could be a coincidence. But like I said, I'm not going to bother with this.
Attempted explosives fix mk2 is up. Same download link. There were indeed a few more fields which get zeroed out at the start of combat aside from the problem one. It also does something weird with scripts, but I'm not sure how important it is.
On the other hand, Darek's method of crashing with the scientists sounds like it'll still crash with my patch in place, since it already involves combat anyway. :/
On the other hand, Darek's method of crashing with the scientists sounds like it'll still crash with my patch in place, since it already involves combat anyway. :/
Didn't you guys say it's possible to crash right as the person dies from explosives? Do you know what causes that one?
I can fix the leave-map-come-back-crash issue in Fallout 1 but I don't know even what causes the instacrash (i.e. how to prevent it), that wasn't clear to me from the posts above.
I can fix the leave-map-come-back-crash issue in Fallout 1 but I don't know even what causes the instacrash (i.e. how to prevent it), that wasn't clear to me from the posts above.
Oops, funny you mention this. As I was falling asleep last night, I realized that bit of code was wrong to include. I was being overly conservative when the combat hack would trigger and I had assumed that just starting combat was enough and thus the hack should be voided in that case, but no, that's for a different crash scenario (where Timeslip's first test dll came into play).Darek said:
Or what if they do this on say 10 different maps. Yes, this occurred to me later on and my solution would be to fill an array of maps ids that need to run the combat hack on. I didn't realize until yesterday that sfall provided arrays to Fallout scripting. omg, why didn't I know about this when I was coding the repair bay stuff at the Sierra Army depot. I might actually revisit that code...Darek said:
Anyway, if I do these changes then I think my workaround is a pretty viable solution. However, Timeslip's new sfall dll is the winner. I couldn't reproduce a crash at all with various scenarios (normal explosive tests, stating combat at various times during it, doing explosive deaths across several maps, etc). All came out good. Great job, Timeslip! Cleanest solution.
Yeah, I've seen crashes with that too. And I can reproduce one consistently with the Enclave save game. Just super stim the vault girl by the reactor exit a good 10 times and try to leave the map - insta crash. Doesn't matter if you start combat, leave the map first and then super stim, etc. Only waiting around on the map (or sleeping) is the way to get the game to not crash when over stimming someone. Any thoughts here, Timeslip?Darek said:
At the very least, I think we're good with your latest test dll, Timeslip, at least in terms of explosives. Again, great work!
The only true clean way to fix the problem is via sfall. However, to fix the insta-crash problem (which we, well at least I, have no idea how it differs from the other explosive crash problems) you must start combat right after dropping an active explosive. So, Darek's script is the only viable solution for F1 until Timeslip makes a new dll for it.Sduibek said:
- Status