Bug Reports

We should probably keep this on GitHub for convenience; I'll submit each of these in the issues page there at some point.


Since we don't seem to have a thread for this already...

Here's the list I've been keeping; I'll update it as we go:


~~BUGS~~

// = fixed

// pea soup in world map

// library/banana abuse

// Valdemar spawn rate and base unarmed skill

// Gas immunity bones message

// main shop door spawning locked

// Elite guard taming

// wishing for ommel cerumen

// armed holy hand grenades in cathedral

// mustard gas hostility bug

// Silva earthquake crash in GC6

// Valpurus + Mortifer always saying "never prayed"

// segfaults when loading saves on 64-bit systems

~ Limbs severed after curing your leprosy still cause leprosy when eaten.

~ SoCM/SoHM can be used on itself; this should not be so.

~ Severed enner beast head is still animated.

~ Mushrooms should not vomit...

// zombie of a test1

// Loading image displaced on every level generated after Enner level.

// Decos' servants have different dialogue after the NA revolution, but they're on Decos' team, so you usually need to kill them
to trigger the revolution dialogue in the first place. They should be on the New Attnam team rather than Decos'.


// Ground description on wall with window. (see https://github.com/Attnam/ivan/issues/3)

/(fixed in branch) Temporary states becoming permanent at 0xFFFF (nobody seems to want this but me so I'll keep it to myself)

~"You hit the blink dog. The blink dog teleports away! You hit something. You sense the death of something."

~ Acid shield may spill acid on nonexistent weapons...

// Lycanthropy polycontrol prompt for NPCs.

~ Shop door bugginess. (Why? )

I don't thing dismembered limbs holding leprosy is a bug. You could get leprosy from a severed leper limb IRL.

Yeah this has to be intentional.

Yes, leprosy being retained by corpses/severed body parts is intentional, just as there are other effects that are retained such as teleport control on blink dogs.

I think Pent meant the bug he was talking about some time ago, when you get leprosy, cure it, then your arm is severed and eating it counts as if it still had leprosy from before your curing.


Not a bug, a feature.

This has to be a part of some in-game lore (quest, or at least a line or two in a dialogue).

Yeah, this is what I was talking about. I'll try to clarify it in the first post.

And for the enner beast, I just like to imagine that the damn thing is still alive, but can't make any sound without its vocal cords attached.

Makes me think about cured ham.

Gets leprosy. Arm falls off. Dips severed arm in bottle of brine. Arm is *cured* :grin. Eats cured arm. No more leprosy.

If only IVAN wasn't dead.

Thanks for collecting all of those. Ideally they should be copied to Github just because it's satisfying to see issues closed on there. It is a little annoying to copy back and forth though... I wonder if there's a way I could use Github's API to automatically create a bug report if somebody posts a topic in the right forum..

Edit: https://developer.github.com/v3/issues/#create-an-issue

hmm.. I'll see what I can do

Cool, a bug list. Great initiative!

Shop door bugfix suggested here.
This change has been made in master. Can anyone verify that it does what it should?

It does, but only for the "main" shop door. Sometimes the shop spawns with multiple doors, and sometimes those extra doors are locked.

What about adding the following to the room script:

Room
    {
      Size = 5,9;
      ...
      GenerateDoor = false;
      GenerateTunnel = false;
      
      Square, Pos 4, 4;
      {
        GTerrain = solidterrain(PARQUET);
        OTerrain = GRANITE door;
      }

This shop door bug just won't die...

Even with the AllowLockedDoors = false and AllowBoobyTrappedDoors = false in dungeon.dat, I still got a shop with one locked door and no other entrance.

I'm at a loss here, since the game seems to be outright ignoring the script file. The default room flags for Gloomy Cave do include AllowLocked/BoobyTrappedDoors set to true, but the individual room's flags should override that.

We could always force a static door on one side of the shop and set GenerateDoor to false, but that feels like a bit of a cop out.

Yeah I agree, it should just automate logically. I wonder if it's a problem with the code?

This line is the only one in the script for the shop that isn't really straightforward:

Type = ROOM_SHOP;

I'm not sure where in the code that room type is used, or how it affects it, and I havent had much luck searching for it.

I think it gets used in level.cpp:

  room* RoomClass = protocontainer<room>::GetProto(*RoomScript->GetType())->Spawn();

But you're right, it doesn't seem to do much else. Can you also check who the divine master is in a shop with a locked door? I wonder if it just reverts to the default script settings for the level or dungeon?
Doors get locked in only two places on the level generation method. One thing to do would be to get IVAN to abort if the program attempt to lock a shop door, and then distinguish between the parts of the code that are causing the problem:

....
Door->Lock();
      if(*RoomScript->GetType() == ROOM_SHOP)
        ABORT("Mate this parrot wouldn't 'voom' if you put four million volts through it!");
...

I gave it a try by removing the random number in the locking condition (so that every door would try to lock itself if allowed), and setting different ABORT messages for whether the shop door was allowed to be locked or not, but the game never aborted, and the shop doors continued to lock, as it it was just ignoring the AllowLockedDoors flag entirely (even though it's clearly there in the code).

In level.cpp I can see some annotations written by a dev, for example:

olterrain* Door = RoomScript->GetDoorSquare()->GetOTerrain()->Instantiate(); //Bug! Wrong room!

I'm not sure, but the comments seem to suggest that the properties of a door may be changed (in say, the shop door) while the settings of another room are being used to determine these properties. Say the status of a lock on a shop door is being changed while the method accesses the flags of another room on the floor?

The code associated with placing doors is enormous and hard to follow. I wonder if it would make sense to use a post-hoc method to unlock all the doors in a room that is not supposed to have locked doors?

Do you know whether the problem persists in non-shop rooms that have

AllowLockedDoors = false;

?

Setting the dungeon default to not allow locked doors seems to work (though I didn't test that with the shop, just regular doors).

I also tried giving the secret meteoric steel chest room doors and setting it to not allow locked doors, but it still got a locked door, so it seems to be some issue with having it override the level default setting.

Ok so it looks like we've isolated the problem in as far as we can make it consistently reproducible with the meteoric steel room.

What about if we set the dungeon default to no locked doors, but lock the shop door? Is the shop door unlocked on some occasions?

So, while doing the adamantine chest wielding tests I discovered that broken locks... Can spawn locked.

I dont think the shoutbox is working

Saying something is broken, and then explaining how it's broken in the thing that's broken is kind of counter productive. =D

Do you remember what you were trying to send in the shoutbox? Maybe there's a certain character that has issues... there were problems with the '+' sign a while back

Wrong thread Batman? this is the IVAN development bug thread.

Similar to JoKe's comment in the shoutbox, I think I also noticed that the reddish light didn't go away when my stuff burned away (leather gloves of dexterity )