MazeMouse
First time out of the vault
And doing unaimed melee crits is doing me in right nowKanhef said:
So I'm gonna start a new game to try again
Fallout 2 mod Unofficial Fo2 patch thread - problems, reports, suggestions
- Thread starter Per
- Start date
First time out of the vault
So I'm gonna start a new game to try again
Getting Living Anatomy adds damage to all your hits (against non-robots) and prevents this bug.
MazeMouse
First time out of the vault
You sir, are my hero!Per said:
*makes a mental note to always get Living Anatomy from now on*
EDIT:
Recalling the hero statement for further testing
Unless the falche edited perk test doesn't work (IE: Living Anatomy added with falche doesn't provide the bonusses) living anatomy doesn't solve my problem. Gonna do a test where I get Living Anatomy the normal route to check this.
Uh, what does said rock tell you?Shiozaki said:
Something went wrong with the installation then. Script is missing, though I thought it would crash in this case... Either way something is not right.Shiozaki said:
alphadavenport
First time out of the vault
Hey, killap, I'm having a similar problem as the one addressed in this post regarding the restoration mod, although I'm only using your unofficial patch. Unfortunately, the given solution isn't working for me. I don't know if it's related to your patch or what, but I was wondering if you ever checked out that save and identified the problem.
Great work, by the way, it's awesome to see you providing such dedicated support to your project.
Great work, by the way, it's awesome to see you providing such dedicated support to your project.
Per said:
I'm not sure if that would be the original intent of the developers. Judging by the comments found in Merk's script, the developers definitely did not want to give the Dr. Henry Papers quest right away, though this can happen anyway due to poor scripting and the needlessly complicated overall design of Merk's script. Besides, should the same thing happen if the player killed Doofus before he meets Merk as well? At the same time, though, it wouldn't make much sense for Merk to tell the player to kill the Hubologist or Doofus, only to have the player tell him that he did the job right away: as a criminal mastermind, Merk would already know about that (see line 235), and would quite logically look for the player to kill someone else or do something else as proof.
I guess one other way this issue could be tackled is to have the player claim that he killed the Hubologist, much like how he can currently claim that he's a bad mofo. So the dialogue could look something like this:
Code:
Merk: Are you that stupid? You think I'm just gonna hire anybody? You work for me, you got to prove you're good for something.
Player: You heard about the death of the Hubologist? Let's just say that I am *very* familiar with that incident.
or
Player: Heard about the death of Doofus? I can assure you that he screamed like a little girl before the end.
Merk: (after either reply) Looks like we can do business, friend. Here's the deal - there's a loopy scientist in town - Dr. Henry. He's got some papers I'd like. I'll pay $1000 for them. Oh, and I don't want no harm to come to Dr Henry. He's useful alive. Interested?This would be a nice compromise position between our two views. What do you think, Per? Of course, the final decision is killap's, so in a way what we think is quite irrelevant...
On a totally different note, my fourth list of bugs is coming. I haven't even reached San Fran yet, but the SAD is proving to be a veritable hunting ground for bugs, with one verified crash bug, and one potential crash bug heading the list. I hope to be able to post everything later today.
-- The Haen.
Edit: And here it is! Unfortunately, I won't have time to submit anymore (I'm going away on an Alaskan cruise, and then heading back to School in September) so I guess any undiscovered bugs will have to wait for the next update of the patch.
The Den
1. A couple of minor typos in dcVic.msg for you to fix:
-> Line 1501: Extra comma right before the word "Boss".
-> Line 1800: "to far" should be "too far" instead.
Redding
1. Doc Johnson barters with the player through dialog, but his supply never replenishes. I understand that he does not refresh his supplies even in the vanilla game, but given that you can barter with him through dialog, I think he really should restock around once every week or so. A similar comment can be made for Lou, the bartender.
NCR
1. Random peasants in NCR Downtown can walk out the gates of NCR during daytime, rendering them visible yet inaccessible to the player, thanks to the exit grid. Similarly, critters can walk out the exit grid from the Downtown to the Council Area, and from the Council Area to Downtown, with the same results. A few strategically placed blocking hexes should do the trick.
2. Currently, when you are guarding Westin's brahmin herds, no time passes. This is obviously not quite right. Since Westin claims in his dialog that the attacks happen at night, I think that a realistic fix would be to set the time to 1800 when the player is first dumped in the fields (or whatever the time currently is if current time is later than but reasonably close to 1800), then increment 3 hours for every cutscene. This will make it about 0300 when the player finally has his encounter with the talking Deathclaws, which again fits with the idea of attacks in the middle of the night.
3. It is possible for Oswald's jail cell to be locked and yet opened. First, talk to Deputy Karl after you've heard about the prisoner from Tandi, and get him to open the door for you. Do whatever you want to Oswald. Walk back to Karl when you are done, and there's a very good chance that Karl won't be able to walk back to Oswald's cell to lock and close the door -- and you won't be able to talk to Karl either depending on the circumstances. If you leave the map now, and then return, Oswald's door will be opened but yet remain locked.
The root of the problem is actually a consequence of engine design. If a critter has been scripted to walk from one tile to another, and finds its most immediate path blocked, the engine is smart enough to find an alternate path to get the critter to the target tile. However, if no possible paths exist (most likely because other critters have blocked all available paths), the engine stops the critter dead in its tracks, and is not smart enough to wait until the obstruction clears before resuming.
In the case of Deputy Karl and Oswald's jail cell, the corridor is very narrow, so if the player has a large party (say, four or more), it is very easy for Karl's path to be blocked when the player walks back to Karl after interrogating the prisoner. So what essentially happens is that Karl is stopped wherever he is (most likely on his home tile), and tries to use the jail door from where he is. Of course, this does not happen (jail door is out of reach), and his script is stuck waiting for the "use" animation to finish when it'll never happen...
There's no easy fix for the issue, but a "quick and dirty" hack can be made in Karl's script. In critter_p_proc, detect if Karl isn't at either FRONT_OF_DOOR or HOME_POS, or if DoWalking is greater than 1, then process the DoWalking and openCloseDoor variables and force Karl to resume his journey to the front of the jail door or back to his home tile.
4. Grant, the gate guard to Westin's ranch, initially faces the gate when the player first enters NCR Downtown. However, after turning off the force field and returning to his home tile, Grant faces in a different direction.
To fix this, go to scWesGrd.ssl and modify procedure Walk (what a creative name
). Look for the two lines "animate_move_to_tile(starttile);" and add "animate_rotation(self_obj, startrot);" right underneath both of them.New Reno
1. The casino girls make most their random float messages in red. This should be neutral color instead. To fix this, change the define dice_floater in niDceGrl.ssl to:
Code:
#define dice_floater(x) float_msg(self_obj, dice_mstr(x), FLOAT_COLOR_NORMAL)2. The casino girls' floats for prizefighters and porn stars are reversed, due to a mix-up in procedure timed_event_p_proc in niDceGrl.ssl. The code currently is:
Code:
else if (dude_has_porn_star_rep) then call Node007;
else if (dude_is_prizefighter) then call Node009;It should be:
Code:
else if (dude_is_prizefighter) then call Node007;
else if (dude_has_porn_star_rep) then call Node009;3. Very minor typo in ncResear.msg, line 485: extra space between "to" and "come".
4. Majorie Reed shows up as "Researcher" if you click on the Review button during dialog or engage her in combat. To fix this, change line 542 in scrname.msg to "Majorie Reed" (or simply "Majorie").
5. In the Stables, the slaves fight on the same side as Mordino's Men. I think this is a bug, especially given that they are classified as "good" critters and the Mordinos are "evil" critters. They should really remain neutral in any fight.
6. The Enclave members present at the Salvatore secret exchange are called "Soldiers". While this is accurate collectively, individually they should probably be called "Soldier" instead. The relevant lines to change in scrname.msg are 1136 and 1137.
7. The two guards guarding the stairs to Bishop's room are called "Bodyguard". To be consistent with the naming convention given to other gang members, they should probably be called "Bishop's Bodyguard". The relevant line to change in scrname.msg is 519.
8. If you provoke a member of any family into attacking you while you are a made man for them -- you can do this by trying and failing to steal from one of them, for example -- you are still a made man for them until you return the attack and hit them back. This can create rather interesting scenarios. For example, if you unsuccessfully steal from one of Bishop's men, he'll attack you. If you let your companions kill him without retaliating, and retreat up or down some stairs once the offended guard is toast, you can return later and everyone will act as if nothing had happened! Or if you flee the Bishop's Shark Club and try to go to the Desperado or Salvatore's Bar, be prepared for a rude welcome because they certainly still think you're a made man for the family who just turned their guns on you.
The fix is to call attack_family(self_family) in Node998 of the appropriate scripts. The following scripts need this update:
* ncBarten.ssl
* ncBigJes.ssl
* ncBisGrd.ssl
* ncBisMen.ssl
* ncCasBou.ssl
* ncChrWri.ssl
* ncEthWri.ssl
* ncKeiWri.ssl
* ncLilJes.ssl
* ncMason.ssl
* ncMorMen.ssl
* ncOrvill.ssl
* ncRamire.ssl
* ncSalMen.ssl
* ncSalvat.ssl
* ncWriTee.ssl
Sierra Army Depot
1. When you set off the alarms in the SAD, the klaxons start to flash. However, when you deactivate the alarm (or have Skynet deactivate them for you), the klaxons continue to flash. The reason for this is simple enough: the script governing klaxon behaviour, wsKlaxon.ssl, simply does not have any code to revert back to non-flashing mode. Ideally, the klaxons should go off once security is off. At the same time, though, you do not want to be creating new instances flashing klaxons and silent klaxons everytime the player decides to mess up. So the code should look something like this:
Code:
procedure map_update_p_proc begin
variable Item;
if (global_var(GVAR_SIERRA_BASE_SECURITY) == SIERRA_SECURITY_ON) then begin
if (obj_pid(self_obj) == PID_NS_LIGHT) then begin
item:=create_object_sid(PID_NS_FLASHING_LIGHT,tile_num(self_obj),elevation(self_obj),SCRIPT_WSKLAXON);
destroy_object(self_obj);
end
else if (obj_pid(self_obj) == PID_EW_LIGHT) then begin
item:=create_object_sid(PID_EW_FLASHING_LIGHT,tile_num(self_obj),elevation(self_obj),SCRIPT_WSKLAXON);
destroy_object(self_obj);
end
end else if (global_var(GVAR_SIERRA_BASE_SECURITY) == SIERRA_SECURITY_OFF) then begin
if (obj_pid(self_obj) == PID_NS_FLASHING_LIGHT) then begin
item:=create_object_sid(PID_NS_LIGHT,tile_num(self_obj),elevation(self_obj),SCRIPT_WSKLAXON);
destroy_object(self_obj);
end
else if (obj_pid(self_obj) == PID_EW_FLASHING_LIGHT) then begin
item:=create_object_sid(PID_EW_LIGHT,tile_num(self_obj),elevation(self_obj),SCRIPT_WSKLAXON);
destroy_object(self_obj);
end
end
end2. If you get into combat on level 4, after you kill a few robots (3 or more, to be exact), you'll notice that you can no longer "repair" the emitters to either enable or disable the force fields on level 4. You might also notice some of the forcefields on level 4 seemingly become disabled and enabled by themselves during the middle of combat. Luckily, using explosives to totally destroy the emitter still works, so at least you can still potentially have access to any area of the Sierra Army Depot.
It took me a while to figure out the reason for this bug, but I finally nailed it. The problem arises because wcSecBot.ssl apparently uses the MVAR defines from both DepoLvA.h and DepoLvB.h. Unfortunately, some of these MVAR values overlap: the absolute values of MVARs that keep track of the state of the force fields on level 4 (located in file DepoLvB.h) happen to correspond to the absolute values of the MVARs that keep track of robots requesting repairs after being destroyed -- probably intended for use with the unimplemented automated repair feature. For example, MVAR_Repair_Request3 in DepoLvA.h and MVAR_Field_4a in DepoLvB.h both have the value of 3. Because the MVARs that keep track of robot repair requests are still modified on robot destruction (see procedure destroy_p_proc in wcSecBot.ssl), this gives the MVARs keeping track of force field states on level 4 unexpected values, which in turn results in nothing happening on repair and other oddities. In theory, this overlap of MVAR values would also adversely effect the map variable MVAR_Security_Level_4, though I have yet to see specific in-games examples of this.
There are several possible ways to get around this, but the simplest solution would be to give the MVARs in DepoLvB.h different values than those in DepoLvA.h, and recompile all scripts that includes the DepoLvB.h header file.
3. The security bots on level 4 are activated, and their corresponding hidden doors opened, if you set off the alert at any level, even if you haven't previously visited the level. This is because the security doors on Level 4 are opened if GVAR_SIERRA_BASE_ALERT is set to 1, which happens if you set off the alert on any level. I'm guessing that the more logical MVAR_Security_Level_4 isn't used in the conditional check because of the MVAR value overlap I described in the previous entry.
Therefore, the solution is twofold: 1) Assign different MVAR values to avoid conflicts between DepoLvA.h and DepoLvB.h, as per the suggestion I made in the previous entry. 2) In the script wiScrtDr.ssl, use the condition MVAR_Security_Level_4 instead of GVAR_SIERRA_BASE_ALERT as a condition to opening the doors, as thus:
Code:
if ((cur_map_index == MAP_SIERRA_4) and (map_var(MVAR_Security_Level_4) == 1)) then begin
animate_stand;
if (tile_contains_obj_pid(tile_num(self_obj),elevation(self_obj),WALL_BLOCKING_HEX)) then
destroy_object(tile_contains_pid_obj(tile_num(self_obj),elevation(self_obj),WALL_BLOCKING_HEX));
end4. The date in the evacuation holodisk currently reads June 9, 2077. However, given the information provided by Skynet and other holodisks in the SAD, this should probably read July 9, 2077 instead. The relevant line to correct is line 9000 in pipboy.msg
5. The October 2077 dates in the GNN Transcript is formatted differently from the rest of dates found in the holodisk. "October, 10 2077" (Line 11102 in pipboy.msg) should read "October 10, 2077" instead, and "October, 22, 2077" (Line 11114 in pipboy.msg) should read "October 22, 2077" instead.
6. Another minor grammatical error is found in the GNN holodisk. The last sentence of the last entry (October 22, 2077 entry) reads: "Crippled by lack of fuel, US forces have pushed the invaders back to their home capital of Beijing." This makes it sound like as if it were the US forces that have the lack of fuel, instead of the invaders. The sentence should probably read: "Crippled by lack of fuel, the invaders have been pushed back to their home capital of Beijing."
7. Minor typo in line 110 of wcDobbs.msg: "Bye," should be "Bye."
8. Yet another one of those "details" bug: There is a "Munitions Access Terminal" on level 2 of the Sierra Army Depot. One of the things you can do there is to read some e-mails. If you read the e-mail "Trade", then there is a reference to a "Chateau Lafayette 2155" in it. However, given that the e-mail was presumably sent in 2077, the vintage obviously doesn't make that much sense. The fix is simply to give the vintage a more reasonable year, say, 2055. The relevant line to correct is line 150 in wsTerm2b.msg.
9. On the Munitions Access Terminal located on the 2nd floor, you can try to disable the force fields on level 2 either by guessing the password or hacking the terminal. If you try and fail to guess the forcefield password, and then try and succeed in hacking the forcefields off, the forcefields are still enabled. These forcefields cannot be disabled using a tool or the repair skill, though using dynamite or plastic explosives still do the trick. In fact, you should still run into the same bug if you do this in reverse (i.e. fail to hack the terminal, but then correctly guess the password), but the presence of yet another bug prevents this (see next entry).
The reason for this bug lies on Node024. Apparently, the force fields on level 2 were suppose to come back on if the player fails to guess the password, and so Node024 tries to create the force fields. Unfortunately, there are several errors with this process.
a) The code makes no check to see if the force fields already exist before creating new force field objects, yet it makes use of the original pointers pointing to the force fields. Because of this, the pointers no longer point to the original fields, so when the player finally hacks the terminal, what ends up getting destroyed are the newly created force fields, not the original ones. These remain in place, despite the fact their associated MVARs say that they are gone. That is why using the tool or the repair skill no longer works after the bug occurs.
b) The code tries to place the newly created fields in hexes stored by several local variables (LVAR_Hex_Field2a, 2b, 2c, and 2d), but these local variables are never initialized. I can only assume that these fields are being created on hex 0 or even some random hex. Needless to say, this can potentially crash the game, though I haven't actually managed to crash it yet while investigating the problem.
c) The code creates a force field regardless of the power level in the Sierra Army Depot. It should probably create pain fields instead if the SAD is running on low power.
These are major problems, but the funny this is that they are actually quite irrelevant! Why? Because there is really no need to create any type of force field. Think about it: if the player is already in a position to wrongly guess the password, that must mean that the force fields on level 2 are already on and in place under most circumstances. In fact, there are only two reasons why a force field might not be active and in place: i) The player temporarily bypassed the force field using the repair skill or a tool on the emitter, and the force field had not come back on yet by the time the player accessed the Munitions Terminal. In this case, the timer event will automatically enable the force field in due time, so there is no need to do anything about it. ii) The player blew up the force field emitter using explosives. In this case, a force field should quite logically NOT be created at all!
So if we don't need to worry about creating force fields, we can take out all the code relating to that, and Node024 becomes much simpler, as thus:
Code:
procedure Node024 begin
set_map_var(MVAR_Level2_Fields,FIELD_ENABLED);
Reply(162);
NOption(163,Node001,004);
NOption(164,Node999,004);
end10. If you try to disable the forcefields on level 2 by hacking the Munitions Access Terminal, but fail in the attempt, the shock plates are enabled even if they were previously disabled (oops). This is because Node013a calls Node011, which is the same node called if the player fails to hack the terminal in an attempt to disable the shock plates. The fix is to call Node014 (which I assume you commented out) instead of Node011, but keep in mind that the code in Node014 contains the same bug described in the previous entry, and will need to be fixed in a similar fashion.
11. In the Sierra Depot Battlefield level, there are some landmines for the player to disarm (or walk into and set off if the player isn't perceptive enough). If the player attempts to disarm one of these, but experiences a critical failure, then the landmine disappears, and nothing else happens. The player is informed that the trap has been accidentallly set off, but the player will not see a triggered trap, nor will there be any damage inflicted.
It's a little bit mysterious to me why the bug is occuring. The code for creating a triggered floor trap object after a critical disarm failure is almost the same as the code for creating a triggered floor trap object after the player accidentally steps on it. In fact, the only difference the command used to create the triggered trap. In the disarm failure scenario, the command used is create_object_sid:
Code:
Trap:=create_object_sid(ART_TRAP_EXPLODED,tile_num(self_obj),elevation(self_obj),CUR_SCRIPT);In the stepped-on scenario, the command used is create_object:
Code:
Trap:=create_object(ART_TRAP_EXPLODED,tile_num(self_obj),elevation(self_obj));My best guess here is that CUR_SCRIPT, which points to SCRIPT_WTLNDMIN, is a spatial script, and trying to attach it to an object causes the script to crap out, not create the object, and stop processing the explosion, which comes right afterwards. If this is the case, then changing create_object_sid to create_object should fix the problem.
12. *** CRASH BUG ALERT *** Trying to destroy a previously destroyed emitter using explosives result in a crash. This is because in procedure damage_p_proc, the command is given to destroy the force field (destroy_object(Field_Ptr)) without checking whether or not the field actually exists. So, if you had already destroyed the field with a previous explosive, then the destroy_object command tries to destroy a non-existent object, which crashes the system.
The fix is to make sure that the field exists before processing the traps roll. If the field is already destroyed, then don't do any processing at all. Wrapping all the existing code with the outer conditional "if (map_var(FIELD_STATUS) != FIELD_DESTROYED) then begin" should do the trick. This fix will need to be applied to all SAD emitter scripts.
13. If you use a tool (or, thanks to your fixes, a super tool kit) to temporarily disable an emitter, a skill roll is made against your science skill. The roll should probably be made against your repair skill instead. Note that this is an "original bug" all the way from v1.02D of the scripts. All emitter scripts need to be corrected.
14. Using the super tool kit to disable emitters offers no bonus at all compared to using the tool, though at least the player can now use the super tool kits! Judging by the benefits given by other "extended" toolsets such as extended lockpicks, the bonus given to the super tool kit should be twice that of the tool. In other words, the bonus given to super tool kits should be a +40 compared to the tool's +20 modifier.
15. If you manage to make Skynet angry at you, most of the terminals in the SAD will lock you out and zap you if you try to access them. However, the alarm terminals on level 1 and level 2 gives the displays the message "Error". This is because both of them tries to reference the non-existent line 300 in SCRIPT_WSTERM1B. Making the reference point to SCRIPT_WSTERM1A should do the trick. The relevant scripts to update are wsTerm1b.ssl and wsTerm2b.ssl. Alternately, you can create a line 300 in wsTerm1b.msg "The computer seems to have some sort of defense mechanism.", and this will also fix the problem.
16. The security bots initially hidden behind the walls on levels 1 and 3 are invisible until the alarm is raised, at which point they become visible. However, the hidden security bots on level 4 are visible at all times, which is a bit inconsistent. In fact, there is no code to accomodate making the level 4 robots visible or invisible.
There is also another related problem: if the player somehow manages to reset the alarm after triggering it, and if these robots are somehow located in one of the hidden enclosures, then the script would make them invisible again. However, the script thinks that the hidden enclosures on level 1 quite a bit bigger than it actually is, so the robots turn invisible in unexpected places like the corridor in front of the elevator or the level 1 security room.
The fix is to check for the correct areas, and to insert code to process the level 4 robots. This can be done by changing the first section of procedure critter_p_proc in wcSecBot.ssl to something like the following:
Code:
procedure critter_p_proc begin
if (cur_map_index == MAP_SIERRA_123) then begin
if (tile_in_tile_rect(17910,17890,19110,19090,tile_num(self_obj)) or tile_in_tile_rect(20702,20693,22302,22293,tile_num(self_obj))) then begin
if ((elevation(self_obj) == LEVEL_ONE) and (map_var(MVAR_Security_Level_1) == 0)) then begin
set_obj_visibility(self_obj,1); // invis
end
else if (elevation(self_obj) == LEVEL_ONE) then begin
set_obj_visibility(self_obj,0); // vis
end
end
else if (tile_in_tile_rect(16280,16274,19880,19874,tile_num(self_obj))) then begin
if ((elevation(self_obj) == LEVEL_THREE) and (map_var(MVAR_Security_Level_3) == 0)) then begin
set_obj_visibility(self_obj,1); // invis
end
else if (elevation(self_obj) == LEVEL_THREE) then begin
set_obj_visibility(self_obj,0); // vis
end
end
else begin
set_obj_visibility(self_obj,0); // vis
end
end else if (cur_map_index == MAP_SIERRA_4) then begin
if (tile_in_tile_rect(20290,20274,21490,21474,tile_num(self_obj))) then begin
if (map_var(MVAR_Security_Level_4) == 0) then begin
set_obj_visibility(self_obj,1); // invis
else begin
set_obj_visibility(self_obj,0); // vis
end
end
else begin
set_obj_visibility(self_obj,0); // vis
end
endNote that the code above will only work if a) the MVAR defines in DepoLvB.h have been adjusted not to overlap with the MVAR defines in DepoLvA.h, and b) MVAR_Security_Level_4 is being correctly used in all circumstances, which is unfortunately not the case -- read on for more details.
17. There are several script inconsistencies found in procedure Security of wcSecBot.ssl, most of which seem to be efforts to get around problems caused by the MVAR value overlaps in DepoLvA.h and DepoLvB.h. I'll list them one by one.
a) There are several conditional checks that look like this:
Code:
if ((cur_map_index == MAP_SIERRA_4) and (global_var(GVAR_SIERRA_BASE_ALERT) == 1))These should be replaced with:
Code:
if ((cur_map_index == MAP_SIERRA_4) and (map_var(MVAR_Security_Level_4) == 1))(b) Given the fix in MVAR values, the line "set_map_var(MVAR_Security_Level_4,1);" is no longer necessary and should be removed/commented out.
(c) In two places, there is a check for cur_map_index == MAP_SIERRA_123 without checking for MAP_SIERRA_4. This causes some lines not to execute, because one of the conditionals checks for cur_map_index == MAP_SIERRA_4, but the only way to reach the check is for cur_map_index to be MAP_SIERRA_123. Hmm....
The fix here is to check for cur_map_index == MAP_SIERRA_123 or cur_map_index == MAP_SIERRA_4.
18. Judging by the code and the text messages in wcSecBot.ssl and wcSecBot.msg, any bot that has been successfully disabled by the player shouldn't be chasing him or her around. However, this is only partially true: the disabled robots will no longer actively chase the player when the alarm is raised, but they will still join into battle if their non-disabled comrades attack the player or if the player attacks them directly.
The reason this is the case is because all the robots are still on the same team, and the script does not check to see whether or not the bot has been disabled before allowing it to join in combat. Therefore, a very logical fix would be to take them out of the team once they are disabled. However, I think an easier way to fix this is to borrow a page out of wcDedBot.ssl and make use of the currently blank procedure combat_p_proc, as thus:
Code:
procedure combat_p_proc begin
if ((fixed_param == COMBAT_SUBTYPE_TURN) and (local_var(LVAR_Active) == 1)) then begin
script_overrides;
debug_msg("I am disabled and won't attack!");
end
endIn the same way, attacking a disabled robot probably shouldn't send an alert to other active robots (It's disabled, right? So how can it possibly ask for help or warn others?). So procedure damage_p_proc could look something like this instead:
Code:
procedure damage_p_proc begin
if (local_var(LVAR_Active) == 0) then begin
set_global_var(GVAR_SIERRA_BASE_SECURITY,SIERRA_SECURITY_ON);
if ((cur_map_index == MAP_SIERRA_123) or (cur_map_index == MAP_SIERRA_4)) then begin
if (elevation(self_obj) == LEVEL_ONE) then begin
set_map_var(MVAR_Security_Level_1,1);
end
else if (elevation(self_obj) == LEVEL_TWO) then begin
set_map_var(MVAR_Security_Level_2,1);
end
else if (elevation(self_obj) == LEVEL_THREE) then begin
set_map_var(MVAR_Security_Level_3,1);
end
else if (cur_map_index == MAP_SIERRA_4) then begin
set_map_var(MVAR_Security_Level_4,1);
end
end
end
end19. Speaking of disabling the bots, you can now use the super tool kit to help you in your efforts, which is a good thing. However, using the super tool kit does not offer any additional bonus over using the tool -- both offer a minus 20 modifier instead of the minus 40 modifier being applied when using the repair skill unaided. Using the super tool kit should probably remove the negative modifier outright.
20. Once you get Skynet (with the cybernetic brain version) working, it will disable each level's security. However, it does not do so for level 4, for the very simple reason that no such code/line exists. Moreover, the disabling of the security is only partially effective: the alert and security status of the overall base is reset, but the MVARs tracking the individual security levels are not.
To fix this, both DepoLvA.h and DepoLvB.h have to be included in wcBrnBot.ssl (if they are not being included already). Under procedure critter_p_proc, look for the call to Node024 and replace it with this:
Code:
if (((cur_map_index == MAP_SIERRA_123) and ((map_var(MVAR_Security_Level_1) == 1) or (map_var(MVAR_Security_Level_2) == 1) or (map_var(MVAR_Security_Level_3) == 1))) or (cur_map_index == MAP_SIERRA_4) and (map_var(MVAR_Security_Level_4) == 1) then begin
call Node024;
endNext, go to Node024 and change the code there to the following:
Code:
procedure Node024 begin
if (cur_map_index == MAP_SIERRA_123) then begin
if ((map_var(MVAR_Security_Level_1) == 1) and (elevation(self_obj) == 0)) then begin
set_global_var(GVAR_SIERRA_BASE_ALERT,0);
set_global_var(GVAR_SIERRA_BASE_SECURITY,0);
floater(204);
set_map_var(MVAR_Security_Level_1,0);
end
else if ((map_var(MVAR_Security_Level_2) == 1) and (elevation(self_obj) == 1)) then begin
set_global_var(GVAR_SIERRA_BASE_ALERT,0);
set_global_var(GVAR_SIERRA_BASE_SECURITY,0);
floater(205);
set_map_var(MVAR_Security_Level_2,0);
end
else if ((map_var(MVAR_Security_Level_3) == 1) and (elevation(self_obj) == 2)) then begin
set_global_var(GVAR_SIERRA_BASE_ALERT,0);
set_global_var(GVAR_SIERRA_BASE_SECURITY,0);
floater(206);
set_map_var(MVAR_Security_Level_3,0);
end
end
else if (cur_map_index == MAP_SIERRA_4) then begin
if (map_var(MVAR_Security_Level_4) == 1) then begin
set_global_var(GVAR_SIERRA_BASE_ALERT,0);
set_global_var(GVAR_SIERRA_BASE_SECURITY,0);
floater(207);
set_map_var(MVAR_Security_Level_4,0);
end
end
endLastly, go to wcBrnBot.msg and add line 207 to it. It should read: "Deactivating all Security - Level 4".
21. This may be stuff that's more appropriate for your Restoration Project, but I'll toss it out here and leave it up to you to see what you think about the situation.
Right now, if you use the repair skill on a robot, you either disable it and gain 200xp on a successful attempt, or you heal it completely and receive 75xp on a failed attempt. This may be what the developers intended, but to me, this is a design bug. Why? Because without the ability to break into the scripts (and most players won't have this ability), whether or not a robot is healed or disabled would seem like a random thing to the player. It would seem like that you are getting a random big reward or a random small reward on trying to repair the robots, and it may never occur to the player's mind that he or she actually failed a die roll.
How I would fix this design bug is based on a very simple game design principle: unless there is a very good and compelling reason or reasons, players should not be rewarded for failure, but instead should suffer the consequences. Therefore, a successful attempt should disable the robot, and a failed attempt should set it hostile. I can only guess that the ability to repair the robots was the remnants of some unimplemented plotline (like the repairing of the useless maintenance robots as mentioned in the EPA design docs), but right now, I'd be more inclined to throw it out altogether.
Vault 13
1. Judging by the dialog in line 139, Gordon, the Shrine Keeper, should also give the "Talk to Goris" quest. You can do this by changing Node006 in ocGordon.ssl to the following:
Code:
procedure Node006 begin
set_global_var(GVAR_V13_GORIS_QST, 1);
Reply(139);
NLowOption(140, Node003);
NLowOption(141, Node999);
NOption(142, Node003, 4);
BOption(143, Node009, 4);
GOption(144, Node003, 4);
end2. If you go to Vault 13 before ever going to Vault 15 (very easy to do if the player decides to follow the Deathclaws or buys Saltbeef's portrait from Doc Jubilee), fix the Vault 13 computer, receive the GECK from Gruthar as your reward, wait around for two weeks, leave Vault 13 and return, then everyone will be massacared. The funny thing is, there is a blood patch (and sometimes even a body) corresponding to where Dalia would be standing on Vault level 3, even though you never had the opportunity to send her to Vault 13 from Vault 15.
The reason this is happening is because of procedure start in ocDalia.ssl, which consists entirely of the code checking if the massacare has taken place, and if yes, to "kill" Dalia. Unfortunately, procedure start is run before anything else, so the procedure check_dalia_state is never called in map_enter_p_proc.
The fix is to check for Dalia's state in procedure start in the event of the massacare, and "silently" remove her using the destroy_object command rather than the more bloody kill_critter command, as thus:
Code:
procedure start begin
if (VAULT13_SEQ) then begin
if (not dalia_state(DALIA_ON_15)) then begin
destroy_object(self_obj);
end else begin
DO_KILL_SELF
end
end
endVault City
1. Minor detail: Lydia, the bartender, is facing the wrong way in her bar: instead of facing the counter, she's facing the wall. Turning her around 180 degrees should do the trick.
2. When you become a citizen, become the captain of the guard, or destroyed the enclave Sergeant Stark will greet you with the appropriate floats even if he can't see you. Similarly, if you have been kicked out of Vault City, the good Sergeant will give a suitably hostile float message, though he doesn't actually attack you unless he sees you. Stark also used to go hostile without seeing you (but not attack) if the you had either Lenny or Marcus in your party, but that seems to have been fixed in your script.
The problem is located in procedure timed_event_p_proc in vcStark.ssl -- all the floats referenced above are given without checking whether or not Stark can see the player. Therefore, a check needs to be made first to see if the Stark can see the player before making the appropriate floats. Taking account the already existing fix for Marcus and Lenny, the procedure timed_event_p_proc can be streamlined, as thus:
Code:
procedure timed_event_p_proc begin
if( fixed_param == 1 ) then begin
if( not( combat_is_initialized ) ) then begin
if( ( Fallout2_enclave_destroyed ) and
( self_can_see_dude ) ) then
call Node001;
else if( ( global_var( GVAR_VAULT_CITIZEN ) == CITIZEN_KICKED_OUT) and
( self_can_see_dude ) ) then
call Node004;
else if( ( day ) and
( global_var( GVAR_VAULT_CITIZEN ) == CITIZEN_CAPTAIN_GUARD ) ) and
( self_can_see_dude ) ) then
call Node002;
else if( ( day ) and
( Marcus_Ptr != 0 ) and
( obj_can_see_obj( self_obj, Marcus_Ptr ) ) then
call Node005;
else if( ( day ) and
( Lenny_Ptr != 0 ) and
( obj_can_see_obj( self_obj, Lenny_Ptr ) ) then
call Node006;
else if( ( day ) and
( global_var( GVAR_VAULT_CITIZEN ) == CITIZEN_REAL_CITIZEN ) and
( self_can_see_dude ) ) then
call Node003;
else if( day ) then
call Node007;
end
add_timer_event( self_obj, game_ticks( random( 20, 40 ) ), 1 );
end
end3. Both Vault Gate Guards (i.e. the two guards guarding the entrance to the Vault) are said to be carrying "a powerful shotgun", but in fact they are both carrying assault rifles. This can be fixed by slightly modifying line 100 in vcVltGrd.msg. Also, one of them has 85hp, while the other one has 70hp. Given how consistent the developers were in placing the more powerful 85hp critter model in sensitive areas (like the Vault Council building), I'm inclinded to think they accidentally used the wrong critter model for the weaker guard. This is admittedly a subjective interpretation, so if you feel that it is better to leave the weaker guard in place, by all means go for it.
4. In the Vault City council area, you can shoot through the wall near the corner closest to where the bartender is standing. This leads to some very interesting battles, in which a clever player can snipe at the guards standing outside the Council Building, and getting sniped right back by the irate guards. The Official Mapper shows some blocking hexes in place, but apparently, they only block movement, and not line of fire or line of sight.
5. Connar is one of the people found behind the force fields in the Servant Allocation Center. I don't know if this is from the original v1.02D maps or an accidental inclusion from your Restoration Project, but either way, he probably shouldn't be there.
Miscellaneous
---------------------------
1. Maybe it's just me, but I've noticed the vast majority of the times when I've been critically hit and the display window says that I've been knocked down (mostly line 6503 from combat.msg, and occasionally line 6513), my player character in fact remains standing and is able to continue the next turn without loss of AP, though he does suffer from the (sometimes massive) loss of hp that accompanies such criticals. As a result, my character rarely gets knocked down from anything short of an explosive attack.
Now, for testing purposes I've been running a character with 10 in every primary stat without the Gifted trait -- I used a hex editor to modify a GCD file for this purpose -- and this gives my character the maximum possible starting level for each skill at the beginning of the game, but the character has no other enhancements beyond that. He does not have the Stonewall or the Quick Recovery perks, so it can't be those either. I don't recall this being the case in the past, when I ran the same character against previous versions of the unofficial patch, so I don't know if this is an inadverdent side effect from one of Timeslip's engine tweaks, or something else.
2. Skynet has some rather awkward combat floats when an enemy shoots and misses it. The problem lies in lines 44560-44566 in combatai.msg. Apparently, whoever wrote Skynet's combat floats thought that Skynet says these messages when it misses the enemy, rather than the other way around. All of these lines will need to be re-written to something more appropriate. Here are my own suggestions, but I'm sure you can come up with better ones:
Code:
{44560}{}{Engaging evasive maneuvers.}
{44561}{}{Defensive protocol Beta initiated.}
{44562}{}{Enemy's targeting capability inferior. Reassessing threat level.}
{44563}{}{Enemy missed. Recalculating enemy's offensive capability.}
{44564}{}{Analysis: enemy effectiveness minimal.}
{44565}{}{Analysis: evasive maneuvers successful.}
{44566}{}{Unit is undamaged.}Read on for a list of errors found in combatai.msg.
3. Minor idiomatic errors found in combat.msg:
-> Lines 213, 263: "your weapon destroyed" should be "destroyed your weapon" or "broke your weapon" (the word "destroyed" sounds a bit awkward in this context (a critical miss), but maybe it's just me being too picky.)
-> Lines 214, 264: "your weapon dropped" should be "dropped your weapon".
-> Line 313: "his weapon destroyed" should be "destroyed his weapon" or "broke his weapon" (the word "destroyed" sounds a bit awkward in this context (a critical miss), but maybe it's just me being too picky.)
-> Line 314: "his weapon dropped" should be "dropped his weapon".
-> Line 413: "her weapon destroyed" should be "destroyed her weapon" or "broke her weapon" (the word "destroyed" sounds a bit awkward in this context (a critical miss), but maybe it's just me being too picky.)
-> Line 414: "her weapon dropped" should be "dropped her weapon".
4. Minor grammatical and idiomatic erros found in combatai.msg. I don't know if the file cmbatai2.msg is being used, but if yes, then the equivalents located there should be corrected too:
-> Line 1047: "Arrrgh, my spine." should be "Arrrgh, my spine!"
-> Line 1058: "Help me,eeeeellp meeeeee!" should be "Help me, eeeeellp meeeeee!"
-> Line 1076: "Bone, so white, pain so great...." should be "Bone, so white, pain, so great...."
-> Line 1155: "My insides are on the outside, that can't be good." should be "My insides are on the outside. That can't be good."
-> Line 1245: "Damn, you're better than you look, 'spose you'd hafta be." should be "Damn, you're better than you look. 'Spose you'd hafta be."
-> Line 1253: "I sure do have a lot of blood in me, well I used to anyway." should be "I sure do have a lot of blood in me. Well, I used to anyway."
-> Line 1298: "I think I need to sit down, for a while." should be "I think I need to sit down for a while."
-> Line 1352: "I hope that was your best shot, you won't get another." should be "I hope that was your best shot. You won't get another." or "I hope that was your best shot, cuz you won't get another."
-> Line 1372: "You broke my arm, but I'll break your neck!" should be "You broke my leg, but I'll break your neck!"
-> Line 1401: "Warning! CPU damage! Processing impaired!" should be ""Warning! CPU damaged! Processing impaired!"
-> Line 1491: "Regulator damage! Regulation impaired!" should be "Regulator damaged! Regulation impaired!"
-> Lines 1563, 1573: "You would cripple me, Coward!" should be "You would cripple me, coward!"
-> Line 1584: "Seeking to blind me? You Coward!" should be "Seeking to blind me? You coward!"
-> Line 1590: "I have too many young all ready." should be "I have too many young already."
-> Line 1688: "Aiyeee! Aiyeee! my eye!" should be "Aiyeee! Aiyeee! My eye!"
-> Line 2059: "I am, one bad-ass. You just better watch yourself." should be "I'm one bad-ass. You just better watch yourself."
-> Line 2308: "I'll be back, 'til then you can dream about me." should be "I'll be back. 'Til then you can dream about me."
-> Line 2460: "Your Mamma teach you that move?" should be "Your mama teach you that move?" (This will make the line consistent with 2444)
-> Lines 2600, 2606, 2660-2669: Strip off the leading space.
-> Line 3002: "Combat effective minimal. Retreat advised." should be "Combat effectiveness minimal. Retreat advised."
-> Line 3060: "Analysis. Defensive program success." should be "Analysis. Defensive program successful."
-> Line 3061: "Analysis. Target offense negligible." should be "Analysis. Target offensive abilities negligible."
-> Line 3100: "Gotta get outa here!" should be "Gotta get outta here!"
-> Line 3118: "I guess, you've learned your lesson, I'm outa here!" should be "I guess you've learned your lesson. I'm outta here!"
-> Line 3126: "More Brains...." should be "More brains...."
-> Line 3171: "Shame that your first time is gonna' be your last too." should be "Shame that your first time is gonna be your last too."
-> Line 10130: "Would you like cream with that Ma'am?" should be "Would you like cream with that ma'am?"
-> Line 10131: "Yes Sir, a Mr, Handy unit, Sir." should be "Yes sir, a Mr. Handy unit, sir."
-> Line 12043: "::I wanna be an airborn ranger...::" should be "::I wanna be an airborne ranger...::"
-> Line 32643: "...something for your sister...." should be "...something for your sister...." (removed the extra space between "for" and "your")
-> Line 36035: "Good shot. My turn" should be "Good shot. My turn."
-> Line 36204: "You and Kaga will meet again" should be "You and Kaga will meet again." (Yes, I know Kaga is not in the unofficial patch, but since we're here already...)
-> Lines 36249, 36348, 36449: "Scream for me" should be "Scream for me."
-> Lines 36300-36365: All these are combat floats for Kaga Area 3. The majority of them are missing ending puntuation -- either a period or an exclamation mark.
-> Line 36552: "Kaga will send you to next life!" should be "Kaga will send you to your next life!"
-> Line 36670: "Ahhhgh! My leg" should be "Ahhhgh! My leg!"
-> Line 36694: "I will hurt you for many hours" should be "I will hurt you for many hours!"
-> Line 36803: "The good guys are supposed to win/" should be "The good guys are supposed to win?"
-> Line 36826: "You're head is worth quite a bit." should be "Your head is worth quite a bit."
-> Line 40003: "That almost broke Grampy-bone" should be "That almost broke Grampy-bone."
-> Line 40024: "Uh, oh. Sulik not feel de fingers." should be "Uh oh. Sulik not feel de fingers."
-> Line 40042: "Hard to breath or us as if we be takin' de dragon-hit." should be "Hard to breath for us as if we be takin' de dragon-hit."
-> Line 40051: "We not want do red, red, wine come out." should be "We not want de red, red, wine come out."
-> Line 40070: "We not be movin and groovin' now, man." should be "We not be movin' and groovin' now, man."
-> Line 40142: "Grampy be lovin' de sound o' bone crunchin, man." should be "Grampy be lovin' de sound o' bone crunchin', man."
-> Line 40154: "We be wantin' de fresh meat, we be glad you here." should be "We be wantin' de fresh meat. We be glad you here."
-> Line 40175: "We tink think you should go back to hunting de mice until you be knowin' more." should be "We tink you should go back to huntin' de mice until you be knowin' more."
-> Line 40967: "Missed me by a few % points." should be "Missed me by a few percentage points." (took out the "%" symbol just to be on the safe side...)
-> Line 40979: "Looks like you need to lay off the sauce before getting' inta combat." should be "Looks like you need to lay off the sauce before gettin' inta combat."
-> Line 41209: "Uh, oh. I can't remember anything." should be "Uh oh. I can't remember anything."
-> Line 41220: "That's really going to effect my swing." should be "That's really going to affect my swing."
-> Line 41221: "Geepers that hurt!" should be "Jeepers that hurt!"
-> Line 41234: "Heh, heh, went right through me, didn't feel a thing." should be "Heh, heh...went right through me...didn't feel a thing."
-> Line 41236: "Uh, oh, that's a bad one." should be "Uh oh, that's a bad one."
-> Line 41272: "Thanks for taking care of that for me, it was gangrenous,." should be "Thanks for taking care of that for me, it was gangrenous."
-> Line 41284: "I've got my eye on you, uh, can I have it back now?" should be "I've got my eye on you! Uh, can I have it back now?"
-> Line 41300: "Uh, oh, my spidey-sense is tingling." should be "Uh oh, my spidey-sense is tingling."
-> Line 41303: "What, do you mean they're armed?" should be "What do you mean they're armed!?"
-> Line 41317: "Feets don't fail me now!" should be "Feet don't fail me now!"
-> Line 41319: "I'm makin' like a banana and splitttin'" should be "I'm makin' like a banana and splittin'"
-> Line 41371: "You sure talk *act* tough." should be "You sure *talk* tough."
-> Line 41375: "You can do better than *that.*" should be "You can do better than *that*."
-> Line 41657: ":: he wheezes::" should be "::wheezes::"
-> Line 41720: "I got a can of Sh! with your name on it." should be "I got a can of whoop-ass with your name on it." (I've no idea what "Sh!" was supposed to be, so I substituted what I thought would convey the same meaning.)
-> Line 41764: "bzzt! That's a miss!" should be "Bzzt! That's a miss!"
-> Lines 42010, 42020, 42030, 42060, 42070, 42090: Restore these lines to the way they were originally -- all lowercase, separated by one space, and no punctuation. This is a deliberate thematic structure that is being repeated over and over throughout Myron's combat floats (see lines 42094 and 42116 for other examples).
-> Lines 42068, 42078: "Aighh! There goes my leg. I'll have to crawl out of here using my lips." should be "Aighh! There goes my leg. I'll have to crawl out of here using my hips."
-> Line 42116: "Gotta get out of here gotta get out of here gotta get out of here" should be "gotta get out of here gotta get out of here gotta get out of here"
-> Line 42151: "Please die please die please die" should be "please die please die please die"
-> Line 42170: "Please attack someone else please attack someone else" should be "please attack someone else please attack someone else"
-> Line 44408: "Biogel pressure falling. Shut down eminent." should be "Biogel pressure falling. Shut down imminent."
-> Line 44423: "Repair systems reports damage to left retractor circuit." should be "Repair systems reports damage to right retractor circuit."
-> Line 44439: "Power conditioning unit damage. Operating at 75% capacity." should be "Power conditioning unit damaged. Operating at 75 percent capacity."
-> Line 44543: "Initiating attack sequence" should be "Initiating attack sequence."
-> Line 44547: "Resuming assault target" should be "Resuming assault on target."
-> Line 44838: "Oh the pain (yawn). Please don't hurt me any more." should be "Oh the pain (yawn). Please don't hurt me anymore."
-> Line 44845: "That didn't hurt at all" should be "That didn't hurt at all."
-> Line 44847: "As soon as I can move again, you've had it" should be "As soon as I can move again, you've had it!"
Nice to finally know what causes the SAD forcefields to become unusable. As for the knockdowns, I think that the game does an endurance check after that critical has been chosen, which is why your high-endurance character is unaffected. It's probably not possible to force a re-roll for the critical, so this may be unfixable.
Zacirus
Wasteland Lurker
Holy Jesus Haenlomal, thats a lot of things found, I'm impressed. I also found 4. for Vault City I just thought it was resolved already, guess not.
Zacirus said:
Well, a lot of these bugs are of the "minor details" variety, such as typos and awkward grammatical issues, which really doesn't affect gameplay. If you take a closer look at all 4 lists I made, you'll find that only a few of them are of a showstopper variety -- most of the bugs I listed have workarounds or can be safely ignored if you aren't really into the details.
@killap: Just a quick suggestion for your corrections.txt file: It may be useful for you to put a list of known bugs that a) you haven't yet fixed or b) you won't be planning fix. That'll prevent people like me from double reporting known issues...at least in theory.
-- The Haen.
Haenlomal said:
I can't say much without looking at the dialogue files and scripts, but it sounds OK.
Is this something that happens in 1.02 as well?
I think most traps in the game work like this, if they haven't been fixed already. From my guide: "If you fail critically while disarming a floor trap it will say that you accidentally set off the trap; this is not strictly true, as the trap often does not go off, but you can't attempt to disarm it again."
This is hard to verify as a bug.
And possibly consistencify with the number of periods in ellipses.
That looks fine to me.
And these don't look outright wrong either, possibly but not necessarily insert a comma after "well" in the second one.
These also look all right to me. CPU damage = damage in the CPU.
Also it should be "bad ass" instead of the attributive "bad-ass".
Looks fine (same as above etc.).
These look workable to me. A bit convoluted, but that's robots for you.
Again, I think the second comma works.
Preferably add a comma before "ma'am", too. Or was the player just served a ma'am?
Not to mention, in British typography at least "Mr" and "Dr" aren't followed by periods; I assume the basic rule is (as in Swedish) that you omit the period when the last letter of the abbreviation is also the last letter of the abbreviated word. This isn't consistent though, as for instance "Sr." (as in "Sr. Mordino") still has a period.
Should also have a space after the leading ellipsis. Plus ellipsiconsistency.
Or "the next life".
Maybe "breathe" too.
Preferably "red, red wine".
Fine to me etc.
No objection to the second and third commas, but I want to remove the first: "Heh heh, went right through me, didn't feel a thing."
Fine etc. etc. Alternatively: "I've got my eye on you - uh, can I have it back now?"
Possibly intended as "What do you mean, they're armed!?"
I have seen this expression (with "feets") elsewhere, so it should be as intended. Edit: it even has a Wikipedia entry.
Also add an exclamation mark.
I think this comes from a practice of writing "shit" as "sh!t", so it should be "can of shit".
You're probably right, but it won't be as funny...
Also "shutdown".
Also "report".
Think "damage" works (etc. etc.).
Is the yawn consistent with other dialogue actions? Or should it be "Oh(,) the pain. ::yawn:: Please don't hurt me anymore." or something? (Also, I hate "anymore". After we're done shooting everyone who writes "alot", we'll go after the "anymores". Maybe the "everytimes", too.)
Or a period.
Per said:
Nope. This was an unintended side effect introduced by the unofficial patch -- in v1.02D, only DepoLvA.h was included, so it did not collide with any MVARs found in DepoLvB.h. It was the inclusion of DepoLvB.h that really made the code more complicated. Not that I'm complaining, though -- including DepoLvB.h ultimately fixed more bugs than it introduced, so ironing out a few details is a small price to pay.
True. However, the intention was definitely for the player to get hurt and for the new graphic to be created on the same spot before the critical failure -- the code is in place and should work, being identical to the code that is run when the player steps on the trap. That's why I stated that it could be the create_object_side that is causing the script to crash and not execute the damage and new art creation code.
About the various commas: In general, I only replaced the comma with a period if there is a comma splice. That is to say, if the comma was used as a separator between two complete sentences. I know that many people do not really pay close attention to this rule, especially in American English, so it could just be the English tutor in me being overly picky. Fallout is written in American English on the most part, after all.
And I also agree with you about the ellipsis and the consistency between using "..." or "…" or "...." or any other variation out there. I think it'd be great if someone can go through and standardize the ellipsis, plus all the action separators. Needless to say, this would be a Herculean task.
-- The Haen.
Edit: I just noticed that for some reason, I accidentally forgot to copy and paste the Broken Hills part of my fourth bug list...not that there is much to it. Just some dialog errors for Marcus. So here is it, and sorry about that!
Broken Hills
1. What Michael Dorn (voice actor for Marcus) says and what the text in hcMarcus.msg says doesn't quite match up in a few spots. Here's the list as far as I can find.
-> Line 114: Change "a ugly mutant." to "an ugly mutant."
-> Line 138: Change "We tussled for a while – probably a day or two." to "Well, we tussled for a while… (chuckles) …probably a day or two."
-> Line 140: Change "We became friends." to "And then we became friends."
-> Line 142: Change "There ya go." to "There you go."
-> Line 156: Change "My undying gratitude. Right?" to "My undying gratitude. Right? (chuckles)"
-> Line 195: Change "Guess it’s not that surprising with the mines around. You’ll keep looking around for those folks, right?" to "Hmm… guess it’s not that surprising with the mines around. But you’ll keep looking around for those folks, right?"
-> Line 198: Change "Here’s your reward." to "Well, here’s your reward."
-> Line 203: Change "We'll be on the lookout." to "Well, we'll be on the lookout." (I'm not quite sure if we can actually reach this line in the game, but since we are here correcting stuff anyway...)
-> Line 219: Change "What a great mutant he would’ve been." to "Ah… what a great mutant he would’ve been."
-> Line 236: Change "Jacob heard the call and embraced it. So did the Vault Dweller." to "When Jacob heard the call and embraced it, so did the Vault Dweller." (I'm actually uncertain about this one...the latter is definitely what Michael Dorn said, but it does not quite make sense contextually speaking. On the other hand, what the text currently is makes a great deal of sense. The ideal solution to me would be to correct Michael Dorn's voice file to fit the text, but since we can't do that...)
-> Line 246: Change "Don't forget," to "But don't forget,"
-> Line 262: Change "My memories of being a human aren't as clear as they once were, but I remember pettiness, hatred, jealousy..." to "Well, my memories of being a human aren't as clear as they once were, but I remember pettiness, hatred, jealousy…"
-> Line 299: Change "You got anything to help?" to "Hey, got anything to help?"
-> Line 350: Change "Didn't your parents explain this to you?" to "Didn't your folks explain this to you?"
-> Line 353: Change "What? Where the hell did you hear that?" to "What? Where did you hear that?"
Change locations bug
Hi Killap
Sorry to disturb you, but I have send you my save game. Did you looked at it? I don't know if the problem I have was allready solved, so please help me. The problem is, that game (Fallout 2 with RP or not) crashes when I am changing locations (for example in the save I gave you: from 1st Street in New Reno to 2nd Street). Please help me, what is this bug?
Hi Killap
Sorry to disturb you, but I have send you my save game. Did you looked at it? I don't know if the problem I have was allready solved, so please help me. The problem is, that game (Fallout 2 with RP or not) crashes when I am changing locations (for example in the save I gave you: from 1st Street in New Reno to 2nd Street). Please help me, what is this bug?
Thanks again for postings these lists Haenlomal. I am up to your latest list of reports but I don't know when I will get to it. RL has been taking precedence recently and time for Fallout is becoming more limited with each passing day...
@Tabjohn
I did indeed get your e-mail and I apologize for not responding. I have run your savegame and I to get a crash when I try and go to another map. I have no idea what happened and it might be related to the too many items bug, but it didn't look like there were any severe culprits in your inventory. I am afraid this save and any other likes it are not salvageable.
@Tabjohn
I did indeed get your e-mail and I apologize for not responding. I have run your savegame and I to get a crash when I try and go to another map. I have no idea what happened and it might be related to the too many items bug, but it didn't look like there were any severe culprits in your inventory. I am afraid this save and any other likes it are not salvageable.
@Tabjohn
If you have this bug "every time" you start a new game, then maybe your installation is corrupted. I'd uninstall Fallout, delete the folder just to be on the safe side (defaults to "C:\Program Files\Black Isle\Fallout2"), reinstall, then reapply the unofficial patch.
@killap
You're welcome.
If your time is limited, then a viable option would be to do what you can so that at least you have the August release, then defer the rest for your next patch. Hopefully, by that time, I'll have my 5th list out and ready too, so you can work more efficiently.
-- The Haen.
If you have this bug "every time" you start a new game, then maybe your installation is corrupted. I'd uninstall Fallout, delete the folder just to be on the safe side (defaults to "C:\Program Files\Black Isle\Fallout2"), reinstall, then reapply the unofficial patch.
@killap
You're welcome.
If your time is limited, then a viable option would be to do what you can so that at least you have the August release, then defer the rest for your next patch. Hopefully, by that time, I'll have my 5th list out and ready too, so you can work more efficiently.
-- The Haen.
One thought on the combatai.msg changes: These are spoken exclamations for the most part, which don't have the same grammar as formally written language. In particular, the comma splices match how it's actually said better than full stop periods do. There isn't a single 'right' way to do it, so it's a matter of personal taste. If you don't like the way it is, you can edit your copy of the file.
BabisSougias
First time out of the vault
Hi i think i have come across a bug too. I will explain from the beginning.
I start a new game. I made a weird character so i needed some powerups first. I went to San Fransisco First and got a Power Armor then i went to Den, got the Fuel Cell Controller Quest from Smitty and then went straight to Gecko. Skeeter told me he needs a Super Tool Kit so i have to go to Vault City to get it. I also talked to Gordon and got the economic data holodisk. I didn't talk to any other ghoul, especially not Harold with whom i have the problem.
Now i go to Vault City and pick the Super Tool Kit, also i become i citizen by taking the test and i also speak to McClure about Gecko, and give him the economic holodisk and he tells me to go to the ammenities office to pick a Hydroelectric Magnetosphere Regulator. So i get it, but i haven't talked to Harold or gone inside the Nuclear Plant in Gecko yet.
Now that i have the Gecko, if i speak with Harold, there is that big dialogue option saying "Harold, I have the part needed and i am going to install it blah blah. Goodbye". So first of all that is a weird chat line for someone i speak to for the first time. Anyway...
Next i go to the plant. I need a yellow key to proceed.. I get one from the locker(this key card is named "Yellow Pass Key"). Then i go to Festus. Although again this is the first time i speak with him, i go straight to the dialogue about him installing the part and he says "Didn't i tell you i know all about nuclear blah blah blah". After he installs (or doesn't install) the part the dialogue that would have appeared if i talked to him for the first time and didn't have the Hydroelectric Magnetosphere appears.
And now the ACTUAL bug. If i fail the speech roll and he doesn't install the chip, and/or if i want to optimize the reactor i have to pass through the red door. The guard tells me that for the red key card i need to speak to Harold. However, there is NO dialogue option that has any relevance to keycards. I search Harold's bookcase and i find a yellow key card named "Yellow Reactor Keycard" which doesn't open yellow doors. And the red keycard is nowhere to be found.
Ok... Was that a total waste of time or am i onto something weird?
Please excuse me if i missed something profound.. :/
edit: according to Per Jorner's guide(which i am following ) the guard as the plant has both cards. 1) was it always like this?? 2) When i try to steal from the guard he only has a yellow card. o.O
I start a new game. I made a weird character so i needed some powerups first. I went to San Fransisco First and got a Power Armor then i went to Den, got the Fuel Cell Controller Quest from Smitty and then went straight to Gecko. Skeeter told me he needs a Super Tool Kit so i have to go to Vault City to get it. I also talked to Gordon and got the economic data holodisk. I didn't talk to any other ghoul, especially not Harold with whom i have the problem.
Now i go to Vault City and pick the Super Tool Kit, also i become i citizen by taking the test and i also speak to McClure about Gecko, and give him the economic holodisk and he tells me to go to the ammenities office to pick a Hydroelectric Magnetosphere Regulator. So i get it, but i haven't talked to Harold or gone inside the Nuclear Plant in Gecko yet.
Now that i have the Gecko, if i speak with Harold, there is that big dialogue option saying "Harold, I have the part needed and i am going to install it blah blah. Goodbye". So first of all that is a weird chat line for someone i speak to for the first time. Anyway...
Next i go to the plant. I need a yellow key to proceed.. I get one from the locker(this key card is named "Yellow Pass Key"). Then i go to Festus. Although again this is the first time i speak with him, i go straight to the dialogue about him installing the part and he says "Didn't i tell you i know all about nuclear blah blah blah". After he installs (or doesn't install) the part the dialogue that would have appeared if i talked to him for the first time and didn't have the Hydroelectric Magnetosphere appears.
And now the ACTUAL bug. If i fail the speech roll and he doesn't install the chip, and/or if i want to optimize the reactor i have to pass through the red door. The guard tells me that for the red key card i need to speak to Harold. However, there is NO dialogue option that has any relevance to keycards. I search Harold's bookcase and i find a yellow key card named "Yellow Reactor Keycard" which doesn't open yellow doors. And the red keycard is nowhere to be found.
Ok... Was that a total waste of time or am i onto something weird?
Please excuse me if i missed something profound.. :/
edit: according to Per Jorner's guide(which i am following
) the guard as the plant has both cards. 1) was it always like this?? 2) When i try to steal from the guard he only has a yellow card. o.O