Bug Reports

http://attnam.com/topics/Bug-Reports


The Cathedral of Attnam > IVAN Development

# Dec 1, 2014, 10:00 pm Hide

Pent

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? )
# Dec 2, 2014, 2:01 am Hide

slob

I don't thing dismembered limbs holding leprosy is a bug. You could get leprosy from a severed leper limb IRL.
# Dec 2, 2014, 3:49 am Hide

4zb4

slob wrote
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.
# Dec 2, 2014, 5:57 am Hide

chaostrom

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.
# Dec 2, 2014, 7:35 am Hide

red_kangaroo

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.

Pent wrote
~ Severed enner beast head is still animated.

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).
# Dec 2, 2014, 8:42 am Hide

Pent

red_kangaroo wrote
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.

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.
# Dec 2, 2014, 1:33 pm Hide

slob

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.
# Dec 2, 2014, 1:41 pm Hide

capristo

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
# Dec 2, 2014, 4:58 pm Hide

fejoa

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?
# Dec 2, 2014, 7:03 pm Hide

Pent

Warheck wrote
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.
# Dec 4, 2014, 2:08 pm Hide

fejoa

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;
      }
# Jan 1, 2015, 4:10 am Hide

Pent

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.
# Jan 1, 2015, 10:19 am Hide

fejoa

Pent wrote
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?
# Jan 1, 2015, 1:08 pm Hide

Pent

Warheck wrote
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.
# Jan 1, 2015, 2:32 pm Hide

fejoa

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!");
...
# Jan 1, 2015, 4:03 pm Hide

Pent

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).
# Jan 1, 2015, 4:42 pm Hide

fejoa

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;
?
# Jan 1, 2015, 6:09 pm Hide

Pent

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.
# Jan 3, 2015, 8:01 am Hide

fejoa

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?
# Feb 17, 2015, 7:27 pm Hide

chaostrom

So, while doing the adamantine chest wielding tests I discovered that broken locks... Can spawn locked.
# Feb 20, 2015, 10:11 am Hide

Batman?

I dont think the shoutbox is working
# Feb 20, 2015, 10:57 am Hide

Ernomouse

Saying something is broken, and then explaining how it's broken in the thing that's broken is kind of counter productive. =D
# Feb 20, 2015, 2:11 pm Hide

capristo

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
# Feb 21, 2015, 1:13 am Hide

chaostrom

Wrong thread Batman? this is the IVAN development bug thread.
# Apr 11, 2015, 11:45 pm Hide

capristo

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 )