I think this is a good idea. What I will do with the fire subsystem when I have a first iteration done is to make a pull request. I am 50% convinced that I have 70% of the work done on the fire subsystem. Once the other bits are done, I suppose we then make a thread to play-test IVAN 0.51?

I think the consensus was as per the first post in the thread. I will root around on the github site and put these milestones up.

Yep and spilled fluids call a function which applies effects to whatever they are touching, so rusting things and poisoning characters etc. (I know this now since I am working on putting out flames at the moment).

Doesn't Leprosy accelerate the reduction of attributes like Cha? Or am I thinking of Lycanthropy?

What about praying to scabies so that all the mages in the mage room get leprosy? Does that shut them down easily?

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?

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;

?

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!");
...

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

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;
      }

I vote sticky!

In addition, golems should be able to eat materials of which they are made and repair themselves in this way.

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?