I forgot about this story! It all fits!

I think weeping blade should stay Scabies because it is SPOILER ALERT. Click here to see text.. Didn't our Izzy code them?
So what have we agreed on so far?

Long sword
Cruentus -> Valpurus

Spear
Cruentus -> Sophos

Battle-axe
Loricatus -> Cruentus

Axe
Loricatus -> Loricatus (?)

Mace
Cruentus -> Legifer

Thunder hammer
Terra/Silva -> Loricatus

Flaming sword
Loricatus -> ?

Weeping blade
Scabies -> ?

Turox
Cruentus -> Legifer

Nah there were no significant changes being made to the original story arc. I now get what red-kangaroo is doing with dialogues, and it's good because it is intended to expand the world a bit more.

What I was keen to protect against was any structural changes to the dungeon layout and balance of Gloomy Caves (GC), or levels added to GC that would wreck the power curve etc. I think GC is about the best example of dungeon design we have so far.

That's interesting, I'd never considered that before.

Necrophilic?

I should know, but I don't. Since burning is related to spoiling, the same thing should happen if something is on fire and burns more.

My instincts tell me a fruit is "preserved" on another level.

I merged in sound protection from full helmets, but I've left ESP blocking from tin helmets out.

Hey it's Azba!

Yeah it's stiull being worked on. Reminds me, I should put out the next windows release.

It's true. I start to doubt this tin helmet thing. I can't see any advantage in it.

And ditto Izzy. I always hark back to this post as a touchstone whenever I wonder what to do next.

I remember SquashMonster saying something about IVAN already being feature-length. His thread about how to accomodate further development was really inspiring and I've tried to work in that direction as well.

Right now you can split creatures, items and dungeons according to theme, but there are some core mechanics that are immutable and make IVAN what it is.

The hardest thing to appreciate, is how balanced the game already is at the moment. So much of the game engine is buried in code. Things like the danger system, weapons families, material strengths and densities, items bestowing special abilities, all contribute to how the game is balanced presently.

Anyone remember the fruit bat from CLIVAN? (What fruit bat?)

I like emergence, so I think adding properties to materials is preferable over creating a new item that does what it says on the box. Admittedly, the effect is restricted to helmets, and further limited to tin helmets. I guess it's borderline easter egg, but there is (very marginal) scope for players to discover the effect outside of this thread. Heck between us we've created stollen knives and christmas trees haven't we?

The code was ported from vasiliy's k8.i.v.a.n. which does the former part. I added some more code to prevent a character being ESP-seen while wearing a tin helmet, which does the latter part (which I felt was missing). The BlockESP flag actually deactivates the state... hmm. I wonder if this affects the danger level? A player would have to weigh the pros and cons for themself, but I think having ESP and using it is great, and a player would have to have an INT level of less than 5 to wear one anyway. Think of those people who wear them IRL?
To answer your question, it does both. Why? Because tin conceivably blocks ESP in both directions.

How do you do these sums so quickly? A player could equip its pet with one.

It adds minimal depth, but I'd say it adds minimal complexity at the same time. Would it be fair to say that the two probably cancel?

Yup and all you need to do is add the hostile replies to char.dat : )

[/quote]

A programming question! There is a hierarchy between characters and humanoids, just as there is between, for example, items and meleeweapons.
carnivorous plants, priests, hedgehogs and bananagrowers are all characters. Carnivorous plants and hedgehogs are both non-human, (see nonhuman.h for their instantiations), while priests and bananagrowers are both humans (see human.h). Both humans and non-humans are characters, and they derive their base attributes and functions from characters, unless those functions are overridden by downstream functions.
All characters should have a character::BeTalkedTo. Bizarrely, you sometimes see humanoid::BeTalkedTo() in human.cpp. It seems weird, but it just defaults to character::BeTalkedTo, that holds for all characters.
priest::BeTalkedTo is, for example, a special case of npc responses devoted to all humanoid characters that are priests. The replies in that function vary by their divine configuration, and in general, by their relation with the player character.

If we don't specify any special humanoid::BeTalkedTo for a human character, then because a humanoid is a <C++>derived class</C++> of a character, it will look upward in the hierarchy tree and use character::BeTalkedTo as a default case. Conversely, priest::BeTalkedTo overrides character::BeTalkedTo, unless you want to access the default behaviours of character::BeTalkedTo by writing either humanoid::BeTalkedTo(); or character::BeTalkedTo(); inside the priest::BeTalkedTo() function.

Might be time for some Stroustrup? Get a linux virtual machine and compile IVAN!