Co8 8.1.0 bugs

How come you can't target the gate during combat?

 

The gate starts as non-hostile. You have to force-attack it. I didn't realize it was even possible to attack the gate until I accidentally caught the thing in a Fireball. There isn't any way to come back from that to the dialogue options for bypassing it -- unless the gate can be Charmed, which would be awfully weird.


As for my bug, it appeared when the gate came down before the start of combat. The bug did not appear the time combat started before the gate dropped. The gate dropped in the middle of combat as it was supposed to, and combat played out normally.

Edit: Actually, I'm not sure force-attacking the gate works.

 

Has anyone else been experiencing a ctd when leveling up a multi classed character?

It seems my last two playthroughs of 8.1.0 have resulted in a ctd when adding the third or more level of multi classing. This always happens when distributing skill points. The stats and the amount of skill points to be spent are legitimate.

This has proven most disconcerting.

 

I have had no ctd then.

 

Hey, can someone point me at a guide for what the Reactive Temple mod changes? I'm noticing some odd behavior with some of the subtemple quests, but I don't know if it's WAD. Looks like Kelno's first quest can't be finished anymore, for instance, unless I'm misreading the .dlg file. And how are things like hostility and temple robes supposed to work post-Reaction?

 

I noticed this as well. After a little digging, it looks like a .mob problem... the properties in the mob are trumping whatever is in the prototypes. Most of the mobs (7 out of 10 or so) have duplicate properties of type monster:zombie or monsterlant instead of the DR property. The protos look ok and the original mob files (those packed in toee.dat) have the DR property for all instances, but no monster type properties. So I assume the monster properties are a Co8 addition (curious what they do, exactly) and the DR omission is either an oversight or maybe a deliberate nerf for that encounter.

Can anyone confirm whether that's intentional? The encounter is a bit too easy, imho. The zombies can't move and attack in the same round, so the DR requiring the party to switch to close combat (by effectively removing ranged weapons) is more interesting.

The proto IDs in question are

14092 (x2)
14123 (x4)
14124 (x3)
14126 (x1)

Copies are used to fill out the group. 14125 is also in the mob, but I don't see it spawning.

 

I'm curious how you change a Property Type in a mob file. You can check it in TOEE Obj View, but I don't see how you can create a mob with a different Property Type from World Builder.

EDIT: Assuming you can't assign an overriding Property Type when you create the mob (that is, you are stuck with using the one that is in the proto at the time), the reason for the defective mobs is that the the protos were screwed up at the time the mobs were made. Then at a later date the protos were fixed. That's the only way I can see it.

I don't think this is intentional.

Nice find!

 

Just found an odd one with Falrinth. I did the first stage of the fight where he disappears and moved the party away (mostly to see if Alrrem had anything to say about Falrinth being gone and the Skull not being found), then came back for round 2. After beating on Falrinth for a bit, he surrendered and spilled the beans. Since my party are good guys, they agreed to spare his life. Unfortunately, this just brought us right back into combat. Every time Falrinth got an action he surrendered again. The only way to end the loop was to go ahead and kill him.

Note that during the fight Falrinth charmed one of my PCs, but the party mage charmed him back. I don't know if this had anything to do with the problem -- is the game maybe thinking of that PC as a living enemy? That doesn't usually happen with charmed NPCs, though.

(Incidentally, my party for this run is based on the Order of the Stick. The twice-charmed PC is Belkar, which is wholly consistent with the comics.)

 

Sounds logical.

Aside from stripping the properties completely (via the 'clean d20 state' option) I don't see a way to touch that data directly in WB.

EDIT: Fixed it, tentatively, by cleaning the .mobs and clearing the cache files in /maps. It is indeed a more interesting fight with all 10 zombies having th DR.

Does anyone know what the effects are of the monsterlant and monster:zombie properties? Cleaning the .mob removes those (along with other things) and I'd like to be sure that the prototype is being referenced and not the packed .mobs (which lacks the additional properties).

 

If you have fixed the zombies, this could be a Eurika moment.

They've always seemed way to easy. I believe they had their DR in a much earlier version of the Modpack.

 

As I recall, it was the gnolls that had DR... maybe whoever removed that got a little overzealous and removed it from the zombies as well.

 

Right -- I remember when the regular gnolls had the skeleton gnoll DR.

This isn't a bug per se, more of a documentation issue. The walkthrough isn't correct about one of the ways to obtain the password for the electrical trap on Temple Level 4. It isn't enough to complete the tasks for one of the 4 elemental temples, you also need to have some Listen skill on the PC doing the talking. If you don't, you can get into a fairly absurd situation if you go to work for the Greater Temple, since you'll be on the far side of the trap with no way back. "Excuse me, Mr. Hedrack sir? How am I supposed to solve your hill giant problem if I can't get up to the third level?" I guess the absurd situation is WAD -- that's what the TZGY scarab is for, I presume, though it's still kinda silly -- but the documentation shouldn't tell you something that isn't true.

Although there may be an actual bug here, since it looks like Romag doesn't tell you the password under any circumstance.

 

Trying to determine the purpose of all of the hardcoded data that gets stripped from the .mob when you clean it in WB. I'd like to be certain that all of this is retained and read from the prototype (or otherwise extraneous). If it isn't, then we might need new .mobs instead of cleaning the old.

Here's an example mob for zombie proto #14123 in the moathouse before cleaning it. obj_f_conditions, obj_f_permanent_mods and obj_f_permanent_mod_data all get removed. Some of that is self descriptive and definitely in the prototype as well, but I'm not certain about all of it, especially the 32bit values in obj_f_permanent_mod_data.

Spoiler

And here's the original packed .mob, pulled from toee.dat for comparison

Spoiler

You can see in the first shot why the DR wasn't working (it's absent and there's a duplicate property). So wiping the hard data fixes the issue and pulls data from the prototype. The plant and zombie properties are still present, along with the DR and I presume anything else in the proto (e.g. toughness feat). My question here is: what's not in the proto that might be necessary, if anything?

I'm helping to test TemplePlus over at the Codex and would be happy to submit fixes for these sorts of things as they come up. Not a bad time to do it... going over the game with a watchful eye. But I'd like to be sure I'm not breaking anything or removing intentional additions in the process, so I'd appreciate some feedback.

 

I was wrong about those TZGY scarabs upthread. They're all on the other side of the electrical barrier. So are all the trolls with the password. So if you're stuck on the wrong side, you've just got to suck it up and run through the barrier, or go ahead and beat the Temple from there. All you need is to get one character through the barrier and up the stairs.

I still don't know what Livonya was thinking when that trap got put in, but this isn't bug related anymore.

As far as bugs go, shouldn't Dismissal work on elementals? Right now it seems to only work on outsiders. Aren't elementals extraplanar?

 

Have you tried using the Temple map added in the latest version? That should allow you to go anywhere in the Temple without having to cross the trap.