Endocore said:
I was going through the RP 1.2 kcsulik.int script for reasons of my own and found a few things that may need attention.
Alright, just got around to this. Since I'm in a fairly good mood and don't feel like working on the terrifying about of work I have to do for next week, I'll give you some detailed answers.
Endocore said:
1) There's an obviously bad line in Node054:
Code:
if (op_global_var(233)) then
begin
end
If global_var(233), er, is...? I'm guessing it should be "==1," based on a few lines line in Global.h, but I couldn't find the exact info on how this variable tracks the stages of the GECK quest while writing these notes.
The full bit of code you are looking at is:
Code:
if (dude_found_geck) then begin
end
else begin
NOption(799,Node056,004);
end
From the start, this is bad coding style (it should be not(fude_found_gecko) and then the dialog option), but then again I'm assuming they might have intended to put something in that empty if block. In any event, to answer your question that macro "dude_found_geck" expands to if (op_global_var(233)). Having an if statement like this is perfectly fine. However, you should only do this if you are checking a statement in terms of true or false (ie boolean). As long as global_var 233 isn't 0, then that statement is true. That's all we actually care about anyway in that check.
Endocore said:
2) Shouldn't the section:
Code:
procedure description_p_proc
begin
op_script_overrides();
op_display_msg(op_msg_string(383, 101));
end
instead be:
Code:
procedure description_p_proc
begin
op_script_overrides();
op_display_msg(op_msg_string(383, 102));
end
?
Nice catch. Seems like an oversight on their part.
Endocore said:
3) The first/biggest issue here looks like it starts right after the Sex Appeal check. Reaction is adjusted if self_obj is an evil critter (which Sulik isn't, but that's probably beside the point if it's all in a header file), and then in a separate subsection reaction is adjusted if self_obj is a good critter. The way I'm reading these two sections, the "Karma Beacon" perk is only considered if self_obj is a good critter, and is completely ignored if self_obj would happen to be an evil critter. If all this is the case, then it's obviously a problem. Either the Karma Beacon consideration should also be added into the evil critter subsection, or else moved to after both the good and evil critter subsections have done their respective thing.
This was an unused perk I implemented for the RP. You're correct, the karma beacon code is indeed only considered for good critters. Not sure why I did this. It's been way too long to recall what I was thinking at the time... I'll address this.
Endocore said:
The second issue is probably just an illusion based on my lack of understanding, but perhaps someone could explain it to me. In the lines dealing with the Karma Beacon modifiers check, the purpose of the phrase
isn't clear to me. Wouldn't each of the lines in the Karma Beacon calculations be more concisely written as:
Code:
if ((op_global_var(37) ==1) or (karma_tmp >= 1000)) then
for the various values (karma_tmp >= 750, etc)?
Yeah, I'm not sure why I wrote it that way. I'll have to go over this.
Endocore said:
The third issue (if, again, I'm reading the script properly) is that it doesn't look like the effects of the Presence perk are being calculated properly. According to the game description:
You command attention by just walking into a room. The initial reaction of another person is improved by 10% for each level of this Perk.
I can't recall ever taking the Presence perk in a game, and therefore can't really say whether multiple levels are even possible as indicated in the perk description. However even if only one level of Presence can be taken, it doesn't look to me as if the calculation used in the script:
Code:
Static_Reaction := Static_Reaction + (10 * op_has_trait(0, op_dude_obj(), 10));
could possibly be right. It looks like it adds ten
points (per level of perk) to the reaction calculation, which could be either considerably more or considerably less than ten
percent of the overall value. Wouldn't a correct evaluation of the effects of Presence be something like:
Code:
if op_has_trait(0, op_dude_obj(), 10) then
Static_Reaction := Static_Reaction + floor((Static_Reaction * ((level of perk) / 100)))
?
You're correct. They original devs are indeed just multiplying by 10. This isn't right. Also, there is no check for the number of levels of this perk, so having more than one wouldn't do anything extra. Perhaps something is hardcoded to handle this. I'll have to poke Timeslip and see what we come up with. You're solution seems fine if we could indeed check the number of levels taken for a perk.
EDIT:Actually, all is well here. has_trait returns the number of levels for a perk (did not know that before) and multiplying by 10 is actually correct. if you look at the macros, reaction_top is defined as 100, so presence does indeed move you 10% closer.
Endocore said:
4) There are half a dozen spots in the script where Sulik abandons the player if the player is doing bad things, and in each of these cases he fires off a float message. In each case, though, the float message color is yellow--shouldn't the color be red, since Sulik is upset with the player in these cases?
Yeah, seems like an oversight. Basically, the developers used floater(#) for all floats in his script. This uses the default color of yellow and if any other color needs to be used, then float_msg(....) should be used instead.
Endocore said:
5) In Node1100, in the subsection where Sulik abandons the party due to a bad reputation in Klamath shouldn't the dialogue line called be 1025 ("You be causing trouble in Klamath. We're gone") rather than the confusingly generic line 921 ("You got a lot of problems with people. We'll go until you be figuring that one out")?
Makes sense. Seems like another oversight.
Endocore said:
6) This is fairly trivial, but the procedures "Check_Next_Third_Of_Areas" and "Check_Second_Third_Of_Areas" both set a background for Sulik's talking head in the Primitive Tribe area. The code in "Check_Second_Third_Of_Areas" will never be called on as the background will always be set (if appropriate) in "Check_Next_Third_Of_Areas," and since it's redundant it seems pointless to have it in there (although, if the script was compiled with a header containing these sections it's understandable why it would be present, just like all the pointless checks to update the player's marital status).
Oops, my bad. Yeah, this doesn't cause any problems but it is unused code sitting there. Plus, the second Primitive Tribe check is out of date anyway and the first one is actually the correct one.
Endocore said:
7) At the beginning of the script a local variable is declared,
Code:
variable Charisma_Roll := 0;
that doesn't seem to ever be used or referred to again. If it is supposed to refer to something in kcsulik.int (rather than something from a general-purpose header file), then there must be a problem.
This was a variable used by a few procedures that were commented out by the original devs. Seems like they just forgot to comment out this variable in the end.
Endocore said:
8) There are about 150 unused lines of dialogue in kcsulik.msg. Although many of these are duplicates of other lines or seem to have no easily discernible referent, lines 490-492 seem to pretty clearly (or at least, pretty clearly for Grampy Bone-speak) refer to the EPA. Shouldn't a clause using these lines be inserted into Sulik's "Grampy Bone says..." responses in Node027 to take advantage of the RP's additional content?
Can you compile a list of all these unused lines? It seems like a few of them might not have voice files attached to them (ie missing the slk#### tag on the message lines).
Endocore said:
9) There's an inconsequential error in Node027, due a small bit of confusion in Maps.h. The line:
Code:
else if ((op_cur_map_index() == 42) or (op_cur_map_index() == 43) or (op_cur_map_index() == 44) or (op_cur_map_index() == 45) or (op_cur_map_index() == 46) or (op_cur_map_index() == 43)) then
in the script obviously doesn't need the second reference to the NCR Council map.
Yep, seems like a mistake on the part of the devs. Doesn't cause any problems, but shouldn't be there.
Endocore said:
10) Right below this in Node027 Sulik's spirit-talk comments are set for Vault 15, but his stipulated responses have nothing at all to do with anything going on at Vault 15 as far as I can recall. Although his first comment from line 530 of his .msg initially seems appropriate, on deeper consideration I don't think "those that rest" could really have much to do with the squatters. Should some other lines of his dialogue (perhaps some of the unused lines) be used here instead? Note as well that lines 530-532 of kcsulik.msg are fairly apt descriptions of Navarro, which is dealt with in the very next line of the script (further suggesting the whole thing is a mistake/bug).
Well, I'm not entirely sure what is intended here. Maybe we can get some feedback from others here. My thoughts are:
Here are the lines used for Vault 15:
Code:
{530}{slk27sa}{An empty shell rests below those that rest.}
To me this would refer to the Vault below the squatters.
Code:
{531}{slk27sb}{Talons of death are close.}
While this sounds like a reference to the verti
birds, it might actually be a subtle hint about Darion's dog. Then again, talons are for birds...
Code:
{532}{slk27sc}{Small death will follow you.}
No idea about this reference.
here are the lines used for Navarro:
Code:
{540}{slk27ta}{The voice is louder than the sound of any gun.}
This makes sense since you should talk down Chris rather than blasting him away. However, it could also refer to everyone at the squat. Rather than blowing them all away, you should help them.
Code:
{541}{slk27tb}{Evil hops here.}
Not really sure.
Code:
{542}{slk27tc}{The pathway of evil is laid clear here.}
This really seems to refer to the minefield you have to pass through.
Endocore said:
11) Could someone briefly explain to me the purpose of the small subsection:
Code:
if ((op_cur_map_index() == 19) or (op_cur_map_index() == 37) or (op_cur_map_index() == 38)) then
begin
if ((op_elevation(op_self_obj()) != op_elevation(op_dude_obj())) and (op_local_var(11) != 0)) then
op_move_to(op_self_obj(), op_tile_num(op_self_obj()), op_elevation(op_dude_obj()));
end
found in "procedure map_enter_p_proc" for every single recruitable npc? Apparently it's intended to correct a possible elevation mismatch between the npcs and the pc on the northern Modoc, "Squat A," and "Squat B" maps, but I don't understand the point of it and am wondering if there are any situations where it ever does anything.
This is a special case that have to be considered for Modoc and Vault 15 (the squat section of the map). Consider an NPC left waiting at the squat. If you helped the people there and NCR is expanding the area, then when you enter the map the elevation has changed (to display the expanded Squat). Any npc that was waiting on the original level is now lost forever if you don't move them to the new elevation of the map that the player is on. The same is with Modoc and blowing up the outhouse.
Endocore said:
**************************************************
Unrelated to Sulik, there's a very old outstanding bug in all versions of FO2 (
cite) where Billy in the Den stops hiring a female pc for sex after the first few transactions. In looking at Billy's script and his behavior in the game, I believe this is because his destination tile (13742 on the east Den map) after leaving the bar to go home for the night is either set incorrectly (it's off the playable portion of the map) or set so that the exit grid is somehow interfering with his path; he therefore gets "stuck" trying to reach an unreachable destination, and never resets to proceed back inside the bar. I've set his script to use a new destination tile inside the playable portion of the map, but I haven't had an opportunity to try my revised script over time in a real game. Does anyone have an opinion of whether or not I'm on the right track with that solution? If so, that's an additional issue that could be fixed by the RP.
I came across this is some time ago. You are correct in your approach to fixing it, as it is essentially what I did. It's been some time since I looked into this, but I do believe it is the result of the hex being off the map (and blocked by invisible blockers). However, I've run into many issues before with the critter walk commands, where they would get stuck if you had them walk to a location too far away, etc. I've never come to an acceptable understanding of this yet...
EDIT:
kungfujoe said:
Does this suggest that if there's a 2.1 version (or 2.01 or whatever), that we'll be able to continue saved games from 2.0?.
I plan to ensure that RP 2.0 saves will work just fine with future versions. You might have to load an earlier save to get around a bug, but saves should be compatible.
earthdude said:
Has the buggy nature of the caravans been fixed for 2.0?
Maybe... I thought I had addressed all issues I personally came across. Missing drivers at the destination was one such issue. All I ask is that if you do come across these issues in RP 2.0, you provide a save game for me to test.
earthdude said:
An unrelated bug that may not be a bug is: if you are wearing power armor, it seems that the weight of the power armor is credited against the amount you can carry, which seems illogical since it is powered. Just carrying it in your inventory, of course, should affect the amount you can carrry.
Interesting. Never noticed this before nor do I know what I could do about it.
mavi85bmn said:
Hey, I'm glad to hear that food system is planned to be implemented.
Yes, but no promises.
mavi85bmn said:
This just gives me another reason to wait for the next version, aside from the bug fixes.
Yeah, seeing how long it took to get 2.0 out (and it still isn't out as of writing this), I'd HIGHLY suggest playing 2.0.x series. 2.0.x will be bug fix releases and the first will surely come out with 1-2 weeks of release. 2.1 will be long way away.
mavi85bmn said:
I hope you are planning to add sleep system as well,
A sleep system has been considered. Again, no promises.
mavi85bmn said:
along with the bags as a requirement to carry more than a couple of pounds stuff around.
Bags are gone forever. They can be exploited (are buggy) and just confuse players too damn much.