Flames

Shouldn't

truth Burning = false;

do?

Or in the constructor(s) for object set

: Burning(false)

And I love the randomly burning floor tiles, especially the one in the middle of the wall in your last screenshot.

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.

For some reason, I find the concept of running into a new enemy type that is on fire to be absolutely hilarious.

"Torgna, the Enthusiastic Kamikaze Dwarf is standing here. He is hostile. He is on fire."

Probably carrying a lot of mines and his usual backpack...

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?

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.

Ok fellas, here is a bit of an update since the post above:
I have got the game to cause materials, specifically solids, to burn progressively according to the scheme "not burnt", "slightly burnt", "moderately burnt" and "heavily burnt". Right now they combust at a fixed rate, which is set to 10 times as fast as bananas spoil. Solid materials now have a Be(); function which facilitates progressive burning as per the spoil subsystem. I am planning to have a separate flag in item.dat for materials that can specifically burn. To my feeling, the solid materials with ConsumeType flags CT_MISC_ORGANIC is a good subset.
I have also got IVAN to store data about the condition of a material as it burns, à la rust subsystem. It manipulates bitmaps in a similar way, but I am still looking for a clever and efficient way to colour the pixels black, according to a range of colour intensities (right now I just set RGB to a fixed dark colour).
At the moment a burning stick does not say if it is on fire or not (which needs to be coded in as well).
The changes have been pushed to the repo warheck-sandbox.

In the pictures below you can see the abovementioned behaviour, where the trusty burning stick now acquires the appearance of charring on its surface.

I'm not going to pretend I completely understood that, but mayhaps you could have a variety of ConsumeType flags for different rates of burning? Highly flammable, moderately flammable, stuff like that? Possibly add a slow burning wick for lanterns so they eventually burn out, forcing us to grab another one if we haven't already got an alternate light source? This idea could potentially extend to weapons; sticks of dynamite, napalm, etc.

Spoilable materials have a SpoilModifier variable in material.dat, so a BurnModifier could be used in a similar way.

As with the rust code you mentioned above, could you not just appropriate it for burn code and instead have it filter the most intense RGB value down (to around 30 or 20? 20% maybe?) and set the other two to zero?
Though, given what I could understand from your post it doesn't sound like it'll be that simple? Why does it need identical RGB values to work?

You three guys are right onto it. Yep the next thing is to set up some database values for materials. I think I will make use of the material interaction flags to indicate whether a material can burn (being sure to deactivate the part of the code that causes scrolls to spontaneously combust, which is a function I want to preserve by building it into the new fire scheme). I want to make the burn-time dependant on the density of the material and perhaps the mass of the object. I will also introduce a new database variable BurnModifier, set this to a standard value except for materials which will have longer burn times, and allow this variable to dynamically influence the burn time and activation energy in conjunction with say rings of fire resistance, cloak of fire resistance etc.
To answer Azba:
Yep I have appropriated that code from the rust subsystem, down to the letter. The few lines that cause pixels in the ironalloys to take on a rusty poo colour, I replaced with a hard-coded colour value, sort of a dark grey. Identical RGB values give colours that appear along the grayscale, the darker end of which I would like to exploit to turn the pixels to a charcoal colour. It is just a bit of mathematics to finish the last step, and there are a multitude of ways of doing it, so I'm just letting my subconscious think of a way for me. Basically it is the problem where I have a material which has a particular colour, and I need to change a random colour to dark grey. There is a variable, Index, in the relevant part of the function which represents the intensity (so whether it is a light shade or a dark shade). I think I will normalise the colour to a known shade of gray and use the intensity to scale the brightness within a small range of values. I think this is your suggestion right?

Close.
I was thinking more like taking the random colour you find and "dulling" it down to equivalent, yet much lower RGB values so the pixel on the object does appear burnt yet retains a little of its original colour. This way the burns will look more dynamic than having the object turn into a mass of identically coloured dark pixels.

What you've mentioned with the Index variable seems like it'd do this by itself if you just set it really low, though I wouldn't know how it'd actually look in-game.

Or, is it not possible to retrieve the actual RGB values from a single pixel in the object's bitmap? (e.g. is the way IVAN "shades" its objects making this more complex?)

Would it be possible to make gunpowder explode if ignited? I can't wait to donate a large chest socm'd into gunpowder to the Cathedral of Attnam.

Just another quick update and summary of things I've coded so far since the last post:

- Material strength values decrease with degree of burnt-ness (slightly, moderately, heavily), as per rust subsystem
- Introduced an material "Activation Energy", which is tested during explosions. If the fire damage done to an item is greater than the value of the activation energy, then the material will "ignite". ActivationEnergy = 0.5 x MaterialStrength + 5 x MaterialFireResistance + FireResistanceItemEnchantment
- Fire resistances have been added for some solid materials
- Items other than sticks are now able to burn
- Objects are destroyed once they are completely burnt, as per rust, spoil subsystems
- Different materials now have different burn times

The next things I will be concentrating on are:
- Getting flames from burning items in inventory or on the ground to propagate to other items in a player's inventory, or to other items on the ground. I have found this step to be deceptively tricky (means it requires quite a bit of pencil and paper work to get a good model going).
- The above will probably require some means of assigning a "thermal energy" to each item. This will also allow energy from cascading explosions to accumulate, allowing higher activation energies to be achieved
- Including wetness in the formulas for activation energy and burn time
- Introduce ways of putting out fires

While it is not an exhaustive list, there is a lot more to do!

In general, shouldn't the things that burn slower have a lower chance to catch other things on fire?
...then again they'd be checking that chance for burning other things for a lot longer huh.

Awesome update Warheck. Can't wait to try this all out!

Man I can't shake this idea off. I want to implement this for the next release.

When I read "resist death" it makes me think that there's some kind of enemy that has like an instant death spell or something, and having the amulet of resist death reduces the chance that the instant death spell is successful.
As opposed to resisting death by blunt force trauma at the hands of an angry shopkeeper, say.

I dunno. Since there isn't any instant death spell, I envisioned it more as...

*Merka stabs you through the heart!*
*The Amulet of Resist Death glows!*
*You retain consciousness up until the last drop of blood is spilled from your body.*
*You die.*

Another little update

It's not a major one, but I thought I'd scratch around the code a bit to tackle some functional issues. I haven't managed to come up with a good model for a quantity I like to call "thermal energy", but I think more and more it will need to come into play some time soon.

EDIT: there is too much stuff going on, have now introduced burnt colours according to material. See attached for visual clues.

So fellas, which gods should we pray to if we want to put out some flames?

Good question. Maybe at least one per alignment?
I can bullshit up some explanations for most of the gods being able to help, perhaps some gods would be better for it than others:

Valpurus: No action.
Legifer: Makes you explode violently with the power of the explosion being based on how raging the fires are on your person. (Extinguishes, and no damage to yourself)
Atavus: No action, since he's unique among the gods in how he acts.
Dulcis: No idea.
Seges: No action - not sure how a god of nutrition could help. Maybe removing the fat from your body so you don't burn as fast, at the expense of hunger.
Sophos: Teleports off and replaces burning limbs
Silva: Briefly encases you in rock / smothers the flames with vines, forcing you to stay still for a few turns.
Mellis: "Trades" your fire for smoke/air/skunk smell/something else.
Loricatus: Strikes you while the iron is hot, extinguishing the flame but hurting you a buttload. Might increase END very rarely?
Cleptia: Slows the item so it takes longer to burn through your stuff
Nefas: Spills vomit or vodka (!!!) over you to extinguish the flames. (Could cause rapid rusting, acid burns, or in the case of vodka, explosions)
Scabies: Douses you with poison. (Poisons you)
Infuscor: Outright removes the flames via magic / teleports the affected items off you.
Cruentus: Dunks the player in blood/acidous blood. (Rust/acid burns)
Mortifer: No action.

Atavus: Gives you a bottle. Hopefully water.
Dulcis: Flames are extinguished depending on how many pets you have?
Seges: I like that idea, removing flames based on how full you are.
Loricatus: More like chance to harden something!
Cleptia: Does slow work like that? As the goddess of assassins, how about turning those flames into straight up damage against the nearest enemy? Spontaneous combustion.
Nefas: Flames are transferred whenever you hit/are hit?
Scabies: And throw in the vomit and various liquids all here. Basically like Atavus, except there's more possibilities and they're thrown directly onto you instead of a bottle.
Infuscor: "Trades" the flames for a wand effect! Not a wand, just an effect. Perhaps throw a random wand in the player's inventory and auto-'a'pply?
Cruentus: Flames are absorbed into your body for straight up damage. Limbs take priority. Chance to destroy said limbs.

should breaking lanterns have a chance to start a fire? I am assuming they are filled with flammable lamp oil.

They should, and they shall...

But first, I'd like to know which gods should inflict fire damage/set things on fire, as a bad/good prayer effect?

Legifer already detonates you spectacularly so he should be a shoe-in for additional flame effects.