I'm still working on this. So I can light things on fire, but I sometimes come across things in the dungeon which have spontaneously combusted upon generation! So far it has been a boot or a gauntlet - stuff that gets generated in pairs, and one gauntlet is fine (top of the stack), but the other is on fire (bottom of the stack). This tells me something about the way things are generated in pairs, and that I probably need to add something in a post construct to set the flaming variable to zero for that object.
red_kangaroo wrote
Btw, what happens to a wooden floor after it burns out? Does it change to e.g. charcoal/soot floor, or simply remains the same?
This does not exist yet. For this I want another visual cue, so I can actually keep track of things getting burnt and damaged visually, rather than setting some mystery number up in an arbitrary memory location somewhere and getting myself confused and bored.
My next step is to make it so that items like sticks and things appear to burn, progressively getting blackened. For this I intend on using the existing methods offered by the Rust subsystem. But this is not so trivial; I have to interpret what is going on inside rawbit.cpp. It's pretty crazy, but then, this is IVAN right?
There is namely this function:
bitmap* rawbitmap::Colorize(...)
which interprets the raw bitmap (.pcx files) and checks for those grand old "m-colours" to see where to fill in the main material and secondary materials, et cetera. This function has a subroutine that takes certain flags, namely RustData, and causes certain random pixels to take on decimated values of Green and Blue in the RGB colour scheme. It took me half a day just staring at the code to figure out that the colours, RGB are encoded in a single word 16 bits long. Red is represented by 5 bits, green by 6 in the middle and blue by 5 bits at the end. In this way, the devs can interpret and store the m-colours specified by the bitmaps as a subset of the 256 colour
intensity, by using intensities in steps of 8 bits; f. ex. Red from 0 to 255 is (roughly) represented by the subset
{0, 8, 16, 24, 32, ... , 255} == 8 * {00000, 00001, 00010, 00011, 00100, ... , 11111}
forgiving numerical roundoff error. This map of intensity values is then convolved, if you will, with the material main or secondary colours.
I have to say, it is just the most mesmerizing code I have ever seen. Real fun if you like interpreting bitwise logical operations. Just one simple 16x16 bitmap is a microcosm of the game itself! This ingenious decimation of the colour values makes for fairly memory un-intensive graphics. If you play in wizard mode with all the lights on (3-key a couple of times), then you see only this subset of colours. Playing with the lights off with only lanterns to see by, then the colours are all blended together due to the luminance subsystem (I have not looked at how that works). If you look at the first seven rows of m-colours, you'll also see these disrete colours also represented by this scheme. There is a formula somewhere which Holybanana wrote down, that is a statement about how this is actually implemented. See this
post, where you can find the document about colours and graphics in IVAN.
Anyway, there are only a couple of lines in the code that are responsible for colorizing the bitmap due to Rust. I have found those lines, which act as a filter for green and blue. It causes the (ironalloy) material to resemble a rusty poo-colour. This only works by virtue that the material colour of the ironalloys are specified in RGB triplets of the same value i.e. (120, 120, 120). I figure that ironalloys will not burn, so a particular material will be either burnt or rusted, but not both. (A wooden handle on a rusted sword could concieveably be burnt also, but colorization happens material-wise). So a "BurnData" flag could conceivably operate alongside "RustData" without causing a conflict in the colorization scheme.
I have used CLIVAN as a bit of a sand-box of late. A friend of mine explained how to use tortoise git (make branch, make small changes at a time to code, commit code with documented changes). This is the key to tracking changes because git has these powerful documentation features. It is the real, actual way to do it. Seeing as I haven't broken anything terribly so far, I think from now on I will work on a branch off the main line that we have in our repo and just commit changes straight out. That way everyone can see, and I don't have to document changes by hand, like an idiot.