Timeslip said:
afaik, the jet fix hasn't had any testing whatsoever, so is off by default. Add 'JetAntidoteFix=1' to the misc section of the ini to turn it on.
Actually, since the modders' pack was released I've been doing quite a bit of testing on it, and it seems to be fine so far. Nonetheless, for those of you who have it enabled, please PM me if you know of any issues.
Now, onto the main purpose of this particular post.
I can't think of another place to put this issue, so consider this my general answer to both the posters who have posted publicly in this forum and to the many PMs I've received about the same issue:
The problem of Sulik, Vic, Goris, and Dogmeat not reaching Stage 6 isn't going to be fixed anytime soon, if at all. In order to better understand the issue, here's a brief description of what normally happens.
When you run Fallout 2, there is a function named partyMember_init that reads the party.txt file, and organizes the data it extracts from the file into a party member table. There is a record for each party member found in the file, and each record is 200 bytes long. Everything about your potential NPC allies is stored in this table, and afterward the engine will extract any information it needs directly from this table. This table is created before the initial Main Menu screen for Fallout 2 shows up.
The root of the problem lies in the fact that Stage 6 is really a misnomer - in fact, it should be considered Level 7 (Level 1 - Base PID, Level 2 - Stage 1 PID, Level 3 - Stage 2 PID, etc.). Apparently, for the original developers, they also made the conceptual error of really thinking that Stage 6 is Level 6, and they defined their data structure accordingly -- that is to say, there is only enough room for the PIDs of the first 5 stages.
Therefore, during game load, the engine reads the party.txt file, creates a data structure internally with the info, and thanks to boundary checking will only read the first 5 PIDs before hitting the end of the record. During level-up, the engine will consult the table it had made earlier, and will of course never been able to find the Stage 6 PID since it's not there.
Changing the party.txt initialization routine to increase the size of the structure to accommodate the Stage 6 PID is simple enough -- you only need to change two bytes -- but the problem is that the engine has been optimized with the size of each party member record in mind. Once I change the size of the record to 204 bytes to accommodate the Stage 6 PID, the optimized offsets that depend on the fact that party member records are 200 bytes long are all going to return, um, very interesting results.
And as you may have guessed, the party members table is accessed all over the place in the engine. At least the problem is made somewhat "better" by the fact that level PIDs are the last thing stored in each record, so other information gleaned from party.txt would still be in the same location relative to each individual record's starting offset.
So, in order to fix this problem, I can do a few things:
- Go through the engine, and make the appropriate adjustments everywhere that the engine accesses the party member table. Is this doable? In theory, yes. Is it practical? No, for very obvious reasons. Will it be implemented? Based on my previous two answers, highly unlikely.
- Hook into the relevant party member code and write up new routines for sfall to totally handle party member level ups and other stuff related to the table. Is this doable? Yes. Is it practical? Well, probably more than Option 1. But it will be quite a massive piece of code. Will this be implemented? Depends on my free time, I guess. But I wouldn't hold my breath if I were you.
- Make a rough hack for Sulik, Vic, Goris, and Dogmeat. While this should be relatively simple to implement (well, still complicated, but simple compared to the first two options), it won't of course be a nice general solution for those mods with custom NPCs that goes beyond Stage 5, unless certain rules and restrictions are followed.
The bottom line is that those of you who have posted and PM'ed me about the problem should expect any quick fix. I'll think about it some more, and I'm sure Timeslip has much better ideas since he has been traipsing through the engine code much longer than me, but for now I'll move onto the next item on my to-do list.
Cheers,
-- The Haen.