Unfixed problems?

Merry Christmas everyone!

I analyzed the code for the priests a bit more, and more importantly, looked at some code which generates new characters on-screen, such as Zuggtmoy. I've come to the conclusion that Romag is not teleported in the first place, and that the talk_romag/hedrack stuff seems to be left over code and the dialog wasn't updated for it.

So now, there's a few possibilities:

a) put in code to spawn Romag and make him disappear after the conversation
b) alter the existing conversations to match
c) no idea really.. any ideas?

EDIT: Okay, I'm making some progress on how to fix up this dialog, but I would like to fix the rest of Hedrack's dialogs too. So, I'm wondering what's the difference between san_heartbeat and san_first_heartbeat..?

 

@Raaagh:
Sorry for the late reply. I was caught up with work and getting the 2nd list of fixes ready for Steve Moret.

I've looked into the Romag issue as well and basically agree with your observations.
Trying the conversation as is with Romag, sometimes leads to line 10 where Hedrack doesn't even acknowledge that Romag brought you down. That problem lies with the acknowledgement of completion of the 3rd quest not being properly recorded in some lines: game.quests[45].state = qs_completed
This has been corrected as the first list of fixes that I've sent to Steve.

After applying the fix, Hedrack now acknowledges that Romag escorted you, but as you've stated, the core problem here is:

Romag simply does not spawn!

Therefore after going to line 20 in Hedrack's dlg file and having you turn to Romag, the dialog now skips to line 520:

{520}{Very well then. [He waves his hand absently at the missing Romag.] I will just have one final test for you, then, before allowing you to join the Greater Temple!}{Very well then. [He waves his hand absently at the missing Romag.] I will just have one final test for you, then, before allowing you to join the Greater Temple!}{}{}{}{}
{521}{Actually, I am just here to kill you! [attack]}{}{8}{}{0}{npc.attack(pc)}
{522}{Me want to kill you! [attack]}{}{-7}{}{0}{npc.attack(pc)}
{523}{What is this final test?}{}{8}{}{210}{}
{524}{What be test?}{}{-7}{}{210}{}

The scenario can still proceed normally at this point since the options to take up Hedrack's quest or attack are given.

However it's really weird not to have Romag spawning in the first place.


To address this issue, the spawning function appears to be coded by the following lines in Romag's .py file:
(which is the last routine called when you agree to be blindfolded)

def escort_below( attachee, triggerer ):
game.global_flags[144] = 1
attachee.standpoint_set( STANDPOINT_DAY, 267 )
attachee.standpoint_set( STANDPOINT_NIGHT, 267 )
game.fade_and_teleport(0,0,0,5080,478,451)
return RUN_DEFAULT

Not exactly sure what is wrong here. Any ideas?
If there is an example of spawning that actually works in the game, we can refer to that as a guide to correct the routine above.

I hope if we can make Romag spawn correctly, the rest of the dialogue will be able to proceed normally.

 

Zhuge:

I've found some examples for monster creation, namely in Zuggy's py. I remember I found another one the other day, but I can't seem to find it right now.

However, the problem with monster spawning is that the function to create monsters requires a number of some sort which is tied to the monster. I don't know how the number relates to the monster, ie. which number links to which monster, so is there some kind of reference I can look at? Perhaps it's related to the protos.tab file and the row number...

Speaking of which, I just had another insight the other day about the four high priests and their quest completions. Let's say you completed each priest's high quest, but -didn't- kill them. The logic would therefore be messed up because, so far, we concluded that we needed some kind of flag to check whether or not the priest was still alive. I thought about checking to see if there were any spare flags we can use for each high priest escort when it hit me -- we could just set the 144 escort flag to values other than 1 to indicate which priest escorted the party! I'm not entirely sure whether or not flags can be set to values other than 1 and 0, so any insights on this?

EDIT: Concerning monster spawning, the game seems to use game.obj_create( [monster number], location). Also, I dug through the protos.tab file and made some startling discoveries. Column 22 is the monster numbers (referenced from other npc dialogs, such as Otis/Elmo) The monster references in talk_Hedrack, talk_Romag and talk_Iuz are totally wrong! Romag is 8045, Hedrack is 8032 (confirmed from Iuz's Hedrack resurrection), and Iuz is 8042! Can anyone confirm this with me?

 

Yep, that's an idea. I tried with Romag's snake problem a while ago but those tests gave me the impression that a 2 for "flag" variables doesn't seem to work. Troika may have coded these as Boolean type where it only accepts a True or False state (or on other words 1 or 0). The "vars" variables do seem to accept a wider range though.
In short, I doubt it will work, but if you have extra time you can try. Just don't get your hopes up too high.

Hmm... seems so. In Romag's .py file:
def talk_Hedrack( attachee, triggerer, line):
npc = find_npc_near(attachee,8046)
I suppose this should be 8032 (for Hedrack) as you mentioned.
Nice find! However I doubt if this will make Romag spawn correctly.

Does that command work?:
game.obj_create( [monster number], location)

Any clue on what to type for location?
If game.fade_and_teleport(0,0,0,5080,478,451) teleports the party but not Romag then trying a game.obj_create( [monster number], location) might work. In any case, knowing how to spawn monsters on a given map is an important step in making future mods so this line of thought is definitely worth pursuing.

 

Well, for the location parameters, I came across a neat little thing in the summon Iuz function that involved something like atachee.location -4, which meant it used some kind of relative location.

Hrm. I wonder if there's a debug command built into the game that shows cursor position like in the IE engine.

 

Well, there seems to be a third option that we can use that can solve a big chunk of our problems. Digging through the files, I found gamequestlog.mes and it gives a list of the quest titles and descriptions. This is just the description list, so does anyone know where the actual quest list (with the CRs and everything) are stored?

EDIT: Ooops. Found it.

 

Almost fixed!

Whee! I've almost done the fix for the high priests. This includes checking to see who escorted you and spawning of Romag!

So far, it involves adding some additional quests into the quest files. In retrospect, should I have just used the reputation file? Hmm.

 

Re: Almost fixed!

Glad to hear of it.
I've been really buried in work lately and could hardly test anything. I'm not too sure what you mean by needing to add extra quests though. Could you please clarify.

So Romag and Hedrack can now have a proper conversation before Romag fades away?

Regarding the attachee location-4 or location-3 any idea where the NPC in question ends up. We might be able to fix the Paida respawning problem as well if we can figure it out. Currently Paida respawns at Hedrack's room after being rescued and left in Hommlet.

 

Regarding your other post on store inventories, I mentioned that we couldn't access NPC inventories effectively.

I've just made a bit progress here and maybe you guys can expand further on it.

Taking Scorpp as an example, we all know that he uses Wonnilon's Repeating Crossbow when he fights you. This makes the fight horribly easy and makes him open to AoOs when surrounded by meleers. While Shin has adjusted his stats to reflect that of an ordinary Hill Giant more approrpiately, we are still stumped by how to make him use his Hill Giant Spiked Club. Yes he has one in his inventory but he doesn't use it.

I was thinking of first transferring the item (crossbow) to the player. Then getting Scorpp to equip his best item. Finally transferring the item back to Scorpp, who would hopefully not reequip it.

So under Scorpp's .py file just after
def san_start_combat( attachee, triggerer ):

I inserted
attachee.item_transfer_to_by_proto(triggerer,4130)

It worked. Well sort of. Now Scorpp no longer uses the crossbow in battle when combat starts but instead bashes you with his fists. However when I checked all my characters none of them had received the crossbow.


Not being sure what was wrong, I added
attachee.item_wield_best_all()
after attachee.item_transfer_to_by_proto(triggerer,4130)

Tested again. However now Scorpp appears to use the crossbow once more. Confused, I decided that perhaps the first command didn't transfer the crossbow to my PCs at all but the item stayed in Scorpp's inventory. When a attachee.item_wield_best_all() command was made, Scorpp naturally reequipped the crossbow.
Checking Scorpp's inventory after he surrendered revealed that the crossbow was indeed in his inventory.

I therefore surmised that perhaps attachee.item_transfer_to_by_proto(triggerer,4130) does not work properly when a battle is started and transfers the item to the attachee's inventory instead.


The next job was to get him to equip the Spiked Club. I tried putting Flanker in the last column of protos.tab (which represents AI strategy). This column was previously blank and probably uses Default.

Tested and well, nothing happened.

Then I saw another command:
item_transfer_to

and substituted:
attachee.item_transfer_to_by_proto(triggerer,4130)

with:
attachee.item_transfer_to(triggerer,4130)

Didn't really expect it to work but lo and behold, it did!!


By inserting:
attachee.item_transfer_to(triggerer,4130)
just after def san_start_combat( attachee, triggerer ):

and adding:
Flanker to Scorpp's entry in protos.tab (not sure if this is even necessary)

We now have gotten Scorpp to successfully put that blasted crossbow in his inventory and equip the Hill Giant Spiked Club.

I know there are still some issues we need to clear up but I reckon it is a start on managing NPC inventories and what they wield and so thought I'd post it early for your reference


I'm also thinking that perhaps if we used the original scheme of transferring to PC, equipping best item and retransferring back to NPC that would work if put in a dialog file when both sides are non-hostile. Anyone up for some testing?

Creating a new item in inventories can be done through the:
create_item_in_inventory( #, obj )
command and it shouldn't be a problem.

Deleting an existing item in NPC inventories is going to be harder.
The above commands merely transfer the item to PC or NPC or getting the NPC to deequip it but does not get rid of the item.
I suppose we could put an OIF_NO_DISPLAY flag or something but that would have global consequences.
Would appreciate any ideas on this.

 

Zhuge:

Adding the extra quests is more of a marker, really.

To clarify, let's use the following example:

You've done all the temple quests, and all the high priests are dead except for Romag. Romag escorts you to Hedrack. By putting checks to see whether each priest is alive next to each quest check in Hedrack's py, we can see that the logic in the elseifs will pop to Romag's dialog line.

However, what if one of the high priests was alive and you got another one to escort you down? For example, let's take Kelno's last quest. He asks you to kill one of the high priests -- either Alrrem or Belsornig. Suppose you finish Alrrem's quests, but refuse his offer to go down to Hedrack. Now, game.quests[54].state will be marked as completed and Alrrem is alive. Now we kill Belsornig and go back to Kelno to finish the quest. He escorts you down.. but wait! According to Hedrack's else-if lines, it will check Alrrem's status first since the "switch" is before Kelno's switch, which means it will jump to Alrrem's dialog line and not Kelno's line.

So I decided on a more rigorous approach and used some quest placeholders instead.

One more note is that I noticed that you can be escorted down to meet Hedrack by multiple head priests. Isn't that kind of strange? I'm planning to add something in the fix that would change that..

And concerning attachee.location -4, I tried that on some of the peasant laborers for debugging and it seems to be a radial thing, since I distinctly remember Hedrack spawning Iuz towards the right while the peasant spawned Burne to the north..

 

Sorry for the delay, but I finally got Romag 100% completed. Now for the rest of the priests...

 

Muhahaha

Alrrem now done!

Sorry for the lack of haste with these dialogs. School recently started so I'm juggling school work and modding.

 

Possible covered already (dunno):

Gnolls have damage reduction (presumedly a sloppy C&P job from the gnoll skeletons), and either the game's dice program sucks, or their AC is way too high as well. This makes them frikkin' godlike at lower levels.

Garad Durhs or whatever (from the Earth Node) are listed as CR 4 -- and though I don't have a MM2 or whatever book they appeared in, I don't think any creature with 100+ HP, a huge damage reduction, an AC in the high 20's, and two attacks that deal at least 15 damage is a CR4.

And this isn't a bug so much as a question...what genius at Troika decided to throw a Balor into a low-level game? No idea how hard it would be, but maybe you guys could reduce the guy's stats a bit? 5 attacks that do 30+ damage and a 15-foot reach = dead party.

Thassit.

 

Oh...another bug that I'm sure's been mentioned elsewhere:

If you purchase a MW light crossbow from the blacksmith in Homlet and equip it, it animates as a throwing dagger instead of a crossbow (IE, the character tosses his crossbow bolts at the enemy, and carries the crossbow around like a knife instead of, you know, a crossbow). It still uses bolts and works fine with the Weapon Focus (Light Crossbow) feat, but it just looks pretty weird.

 

@The Novak:
Gnolls have DR 5/Bludgeoning - known bug
Galeb Duhrs have low CR - many creatures have lowered CR, probably a design decision
The Balor has already been nerfed stats-wise. It is possible to beat that encounter.

Please refer to the buglist to know what has already been discussed before. The latest list is at:
http://www.ataricommunity.com/forums/showthread.php?s=&threadid=335222