I tried it and I met with: Success! Awesome work Pent.
Attached is a screenshot of how I configured a separate command in Programmer's Notepad.
I also edited my local copy of the makefile using Pent's changes above.

Awesome!

So for example, I committed and pushed these changes to my branch "warheck-sandbox". Once I have fleshed out the full functionality more or less, then I can either create a pull request (preferable), or just push the changes to "master" myself (lucky admin guy).
Long live git!

So that's fork, clone, scalpel, change, commit, beer, push - right? Or is it beer first...?

Just for information which might be useful to others, I created a branch with help from the link below:
http://joelabrahamsson.com/remote-branches-with-tortoisegit/

too easy really

Good researching! Pent, your link from post #8 (chao's quote) provides some tantalizing clues as to the workings of the danger system. Holybanana hints at the fact that activated states are taken into account during monster generation. I wonder what else is taken into account?

I vote to keep it the way it is. I don't know to what degree this feature is intentional. What I'd really like to know first is how state activation affects the danger level and what the danger system does to increase the difficulty of the game.

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.


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.

If I set

int Burning = 0;

then the compiler says:

C:/CLIVAN/Main/Include/object.h:64: error: ISO C++ forbids initialization of member `Burning'

Which is a pretty classic error. I followed some discussions on stackoverflow and did the following:

In object.h:

static int Burning;

in object.cpp near the top:

int object::Burning = 0;

The problem goes away; the dungeon is no longer on fire and sticks light on fire when asked.

I'm not such an advocate of guaranteed items, artifacts or altars. Eddys would be the IVAN way, as Erno points out. On the other hand, you could put the altar on an island in the stream somewhere >:]
When I take on Mr. Enner, then I usually have some form of teleport control, and a means of teleporting and detecting materials. So I think the level doesn't need any bonus items. There always needs to be a long way around, so a bridge to the other side, placed randomly in the vertical axis of the river would be nice, as a way of getting to the other side by brute force.

Make sure Enner.pcx is included