Bug Reports

Dec 1, 2014, 10:00 pm
#1
Joined: Feb 20, 2012
Posts: 232
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
#2
Joined: Dec 2, 2007
Occupation: Big Daddy
Location: Under a pile of my own offspring
Interests: Caves
Posts: 612
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
#3
Joined: Dec 11, 2008
Posts: 1,770
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
#4
Joined: Dec 3, 2007
Occupation: Chaos Weaver
Location: Standing between all life and death
Posts: 2,780
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
#5
red_kangaroo's avatar
orc general


Joined: Apr 2, 2014
Location: North Tyris
Posts: 429
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
#6
Joined: Feb 20, 2012
Posts: 232
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
#7
Joined: Dec 2, 2007
Occupation: Big Daddy
Location: Under a pile of my own offspring
Interests: Caves
Posts: 612
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
#8
capristo's avatar
The Imperialist


Joined: Dec 2, 2007
Location: New Attnam
Interests: bananas
Posts: 1,997
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
#9
Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 953
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
#10
Joined: Feb 20, 2012
Posts: 232
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
#11
Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 953
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
#12
Joined: Feb 20, 2012
Posts: 232
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
#13
Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 953
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
#14
Joined: Feb 20, 2012
Posts: 232
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
#15
Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 953
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
#16
Joined: Feb 20, 2012
Posts: 232
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
#17
Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 953
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
#18
Joined: Feb 20, 2012
Posts: 232
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
#19
Joined: Sep 8, 2010
Occupation: Petty Functionary
Location: Drinking pea soup in the world map
Interests: Mangoes
Posts: 953
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
#20
Joined: Dec 3, 2007
Occupation: Chaos Weaver
Location: Standing between all life and death
Posts: 2,780
So, while doing the adamantine chest wielding tests I discovered that broken locks... Can spawn locked.
Feb 20, 2015, 10:11 am
#21
Joined: Dec 17, 2007
Occupation: Taking Names, Formerly Kicking Ass
Location: New Jersey
Posts: 791
I dont think the shoutbox is working
Feb 20, 2015, 10:57 am
#22
Ernomouse's avatar
Master mine stomper


Joined: Dec 16, 2007
Occupation: Wasting air
Location: Arse-end of Europe
Interests: Small living
Posts: 2,040
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
#23
capristo's avatar
The Imperialist


Joined: Dec 2, 2007
Location: New Attnam
Interests: bananas
Posts: 1,997
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
#24
Joined: Dec 3, 2007
Occupation: Chaos Weaver
Location: Standing between all life and death
Posts: 2,780
Wrong thread Batman? this is the IVAN development bug thread.
Apr 11, 2015, 11:45 pm
#25
capristo's avatar
The Imperialist


Joined: Dec 2, 2007
Location: New Attnam
Interests: bananas
Posts: 1,997
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 )
Jump to