[Disclaimer: Bug fixing is hard... the following may include errors.]
I looked into the dialogue issue in Colly and it's bad.
It seems “something” has been added between 2.47.4.1 and 2.47.6 that does not allow critter_proc to call dialogue anymore.
Test Notes:
-Joining the Lumpen (kill Rafael, not Tony, it's faster). This starts in dialogue with Humphrey, then it ends dialogue, which sets a local, the local calls critter_proc, and critter_proc calls dialogue again. (Colly does this a lot).
-Critter_proc then tries to call dialogue, the dialogue window comes up, but it's transparent (can click on stuff behind it) and I'm outside dialogue (I can move around, talk to people etc.) When I talk to someone else I can also partially remove the dialogue window (but dialogue itself is bugged at this point). [Note: it helps to have companions with you, as you can walk to the edge of the screen, press R to summon them and talk to them. That's the easiest way to get out of it.]
-Oddly enough the [Done] option (#1) on the bugged window screen toggles “sneak mode” (even when clicked with mouse only). So apparently, clicking option 1 registers as pressing 1, which then triggers sneak as the player is considered to be outside of dialogue.
[Note: I tried the 2.47.6 Humphrey script with 2.47.4.1 and it works, so it's not the script. I also tried to replace 2.47.6 sfall with the one from 2.47.4.1, but no difference. I tried to toggle any option in sfall that seemed related to dialogue, but zippo. No idea what else it could be.]
Fixes:
[Notes: First I tried a few things, like critter proc only calls Node071 (crashes), remove the “in_dialog” temp (no change), switched 1 & 0 around (crash), set the same for the “else” option (no change). So it seems that critter_proc cannot start dialogue anymore as it used to in 2.47.4.1. Not sure if I missed something...]
What did work was: I took the whole “call Node071a” and moved it from critter_proc to the node that triggered critter_proc.
Like the following (don't mind the locals... variables):
Code:
procedure Node071 begin
set_local_var(9, local_var(9) bwor 65536);
if (((local_var(9) bwand 65536) != 0) and (((local_var(9) bwand 131072) != 0) == 0)) then begin
gfade_out(1);
game_time_advance((24 * (60 * (60 * 10)) * (game_time_hour > 2300)) + (((2300 / 100) - (game_time_hour / 100)) * (60 * (60 * 10))) + (((2300 % 100) - (game_time_hour % 100)) * (60 * 10)));
gfade_in(1);
set_local_var(9, local_var(9) bwor 131072);
if (in_dialog == 0) then begin
in_dialog := 1;
start_gdialog(1306, self_obj, 4, -1, -1);
gsay_start;
call Node071a();
gsay_end;
end_dialogue;
in_dialog := 0;
end
else begin
call Node071a();
end
end
end
And that fixes it...
However,
Leyla.int uses the same thing twice too. Should also bug out now...
So does Grizzly (3 in one check)
And Berk (1 time)....
Stopped looking at this point... we're fucked.
Colly really loves calling dialogue from critter_proc. There are probably some in Timmy and maybe Tony, Pard, Rafael and Rusty.
The whole location should be unplayable now. Not sure what you want to do... [edit: actually I have not tested any, just assume they would behave like Humphrey does.]
-You could do the same as above, find the nodes that trigger the ones in critter_proc and move them over... but you know how complicated Colly scripts are, really not looking forward to that.
-You could use [
dialogue_system_enter;] that seems still to work but that would probably call talk_proc and good luck finding the right position in there, those are already pretty long in most cases. That's probably even worse than the previous option.
-If at all possible it should be much better to find whatever is preventing critter_proc from calling dialogue and have that fixed. As you said yourself, Colly scripts are really complicated. It took me two weeks of studying and research to figure them out and find all the bugs. I don't want to do that again. Especially, as the scripts should be working (they did in 2.47.4.1 (with all bugs fixed*)).
(*except the final crash I couldn't figure it (possibly related to looting), not checked if you found a fix, but it seemed fairly stable regardless, if remembering to pick up Humphrey's knife). I really thought we had it all fixed and it's all beautiful, radiated splendour in cannibalism now.
Of all the places that could break it had to be Colly. The HcDoc script is much nicer to look at...
The Slavers' Camp should be a different issue. As mentioned:
The door (slvco2.int) can't be opened other than with the key. Any open attempt (hand icon and lockpick) calls a dialogue window to deal with that.
The problem is the patrolling guard (slvcc5.int) who forces dialogue upon seeing the player. As slvcc5.int continues patrolling while the “door dialogue box” is open, it is possible that he forces dialogue while a dialogue window is already open. When that happens it freezes the game.
Can be avoided by having that “forced dialogue” first (as the guard will trigger only once). Or with better timing. Combat should overwrite his forced dialogue (probably in critter_proc which can't trigger in combat). But if the player gets out of combat the patrolling guard may still force this “initial” dialogue if not triggered yet, which can be inappropriate.
In the RP Mod, the door is not locked, and the patrolling guard only reacts to a player “handling the door while in sight”, but not on sight alone. However, MM can find its own solution. Not sure what though? Perhaps, the slavers' hostility check (I think there is a map variable that does that?) could prevent the forced dialogue and the door could replace the dialogue window with display messages. However, I haven't looked into this, may be talking bananas.
Some small fixes (for 2.47.6):
This one I found after all the Colly fixes. It's a small copy & paste error in Josie.int:
Talk proc starts with a check if the player “is a dweeb”, which in general disables dialogue with the Lumpen gang.
Code:
procedure talk_p_proc begin
variable LVar0 := 0;
if ((global_var(830) bwand 8) != 0) then begin
call Node001();
end
This seems to work, but Node001 (of Josie.int) has a copy & paste error and needs to be:
Code:
procedure Node001 begin
float_msg(self_obj, message_str(219, random(200, 202)), 8);
end
Without the fix Josie would fail to respond after the player set 830 (8) to 1.
However, this is a rather minor detail. These floats only occur in the obscure case of the gang considering the player a dweeb and not talking to him anymore (which is very rare and requires very precise manoeuvring of Humphrey's dialogue). However, fixing this is probably for the best as it supplies some feedback when trying to do the book quest. [Although that could be improved... I just don't know how yet (either Berk won't give the quest or the quest overrides Josie's animosity)... the first is boring, while contingencies make the second one tricky. Not sure yet. Maybe return to this later.]
rayze.msg:
{124}{}{Would the Fools be ready for an attack?}
{125}{}{No. Still, I don't think it would be wise to attack them just yet.} to 128
{126}{}{Yes. They are vulnerable.} to 129
{127}{}{I need to scout some more.} to exit (eventually)
{128}{}{It doesn't matter. Nothing will stop them from feeling the cold of death! They die now!}
{129}{}{Excellent. We will catch them unprepared. They die now!}
If using the above version it probably needs to be
{125}{}{Yes. Still, I don't think it would be wise to attack them just yet.} to 128
{125}{}{No. And I don't think it would be wise to attack them just yet.} to 128
{125}{}{Yes. But I don't think it would be wise to attack them just yet.} to 128
or as suggested the originally, but with a “No” instead of a “Yes”.
{125}{}{No. It might not be wise to attack them yet.} to 128 (and Rayze ignores it)
Although it made sense what you did, as it was probably meant to be that way that both 125 & 126 are affirmative, just 125 is cautious like:
{125}{}{Yes. But it may not be wise to attack them just yet.} to 128 (and then Rayze ignores it)
Which may be the best version maybe...
[Btw additional space after Excellent in 129, and after death! In 128, probably both superfluous...]
And another small one I found: RP Mod fixed the map name for the second New Reno map to
# 55: New Reno 2 newr2.MAP
{365}{}{2nd Street}
{366}{}{Shark Club 2nd Floor}
{367}{}{Shark Club 3rd Floor}
However, the second elevation is used by the Shark Club AND the Salvatore Club. So it probably needs to be:
# 55: New Reno 2 newr2.MAP
{365}{}{2nd Street}
{366}{}{2nd Street, 2nd Floor}
{367}{}{Shark Club 3rd Floor}
Or similar, otherwise the Salvatore Club 2nd floor is referred to as the Shark Club.
The original msg only called it
{366}{}{2nd Floor}
Which is not really helpful as a description, so it makes sense to add the location name “New Reno 2nd Street (that's the name), 2nd Floor”, it just can't be Shark Club.
And another small one. The fix for [Encounter: DNRV_Den_Caravan] (in worldmap.txt) also requires to change the guard scripts from 259 to 508. Else the fight against the Vault City Caravan will still bug out (same team-number on both sides). Otherwise that is the fix to go with I think. I had another thought about it but I still don't see a better way. It's a trader encounter that is hostile to all but Slavers. Best to think of it as a hostile encounter accompanied by a slave trader, and the special option to trade only unlocks if the player happens to be a slaver. The “normal” trader is [Encounter: DMRV_Caravan].
I think that's it. Basically, an exact copy of the original 1.02d worldmap.txt, just that the Den Caravan trader needed his own script to go with his slaver guards.
And the FoTactics frms
-haenroAN.frm (this is still getting “hit” needs to be replaced with “big dodge” aka the previous AP)
[You could take “haenroDE.frm” copy it and name the copy “haenroAN.frm”.]
And the following is on me (I skipped the “new animations” for some reason... perhaps I was looking through the RP frms, not that that makes any sense but what can you say, I'm a strange guy. (quote by Mike from the young ones)
-haenroPE.frm (is still “getting hit” and needs to be “small dodge” aka the previous AO)
[You could take “haenroJE.frm” copy it and name the copy “haenroPE.frm”.]