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!

For this feature, it was the only way I knew to do this without creating newfangled bug-prone code. In the game, when sound damage is done by , the damage gets divided up into different body parts according to body part volume. Head is least volume, so it typically receives less damage, in the order of 1-2 damage points. The full helmet SoundResistance = 2; For the damage output of , it only seems like it is 100% protection because you only have to put in a few points of resistance.
I could lower the SoundResistance to 1 for full helmets and special helmets (perp, attractivity etc)? That way there would be some resistance from a few tiles back, but you would still be vulnerable at point blank range, as one would expect with . Downside is, I don't think players would notice the difference from before. I made the changes here.



The change really is just a bit of a quirk. Is it really worth donning a crappy tin helmet just to evade ESP when you could be using ESP and wearing a more powerful helmet to help you find your enemies and kill them instead? I haven't tested whether it improves one's chances against battle mages etc, but it doesn't prevent you being infraseen, so I think a hapless, tin-helmet-wearing player would still get bombed by the corporation in the end.