another one IVAN fork

it is now possible to deactivate traps. currently it does the same Dex check as for activating a bear trap (for all kind of traps). failing to deactivate a bear trap hurts one of your arms, but mine and gastrap goes BOOM instead. so it's up to you to decide if it worth the risk.

also, flying over a trap doesn't prompt "you found a trap, press esc" anymore — it is useless, as the trap cannot be activated this way.

and implemented The Most Useful Command Ever:

gimme nanofiber nanofiber "katana of sharpness +8"

this works. sometimes.

Mock-up of the inner cave for the "Betrayal" site

I know music isn't IVAN's strong suit but if we can find a suitably ominous .mid for the site and cave it would go a long way toward the ambience.

sadly, k8I don't have a music player. mostly for two reasons: 1) adding it will require a sound system rewrite (not that hard, but i'm soooo lazy), and 2) we'll need to have a sound font for midi playback, and good sound fonts are HUGE (and not all of them are free).

one day i'll throw away SDL Mixer, and replace it with OpenAL and custom sound loaders, but it won't be soon. mostly because i prefer to listen some speed/power metal anyway, so i don't need in-game music that much.

p.s.: command console is SO useful… even with a limited set of commands. how could i live without it all this time?!

There's a reason dedicated sound design is a thing though. A repetitive track is worse than no track at all.

A fair statement, but i think the bar could be a bit lower for a single optional level with one tiny sublevel that the player might visit once in their entire playthrough, maybe twice if they're RP'ing so hard they come back to drop markers for the fallen and engrave memorials.

yeah, considering that this will be a random encounder, and there's nothing much to do there actually, this is one of the places where appropriate music will Just Work, creating the atmosphere and mood. i tried to explain why k8I cannot play music, but it doesn't mean i don't want to have it at least in this particular place. (when i finally implement random encounters, thats it .

also, for random encounters we prolly need some new unique monsters too. i'm mostly thinking about desert-themed ones: there definitely should be at least quicksand (not a monster, of course , and sandworms moving in the sand. tbh, i'd like to have totally unique mosters for encounters, to give the player some actual reason to not leave encounters immediately. preferably unique monsters with some unique traits, so playing random encounter level will require some change of tactics. i don't have anything more detailed on this yet, tho, just… random thoughts.

p.s.: btw, the car sprite we already have could be used for Fallout reference. of course, it doesn't look like Highwayman, but hey, this is another reality, we don't need to be precise to pull this joke.

.....of course we have a car sprite.

Why am I even surprised at this point?

there are even more unused sprites in various sheets. like photocamera, for example. and we have unused worldmap POI icons too. there is also something that looks like… heavily armored steam tank, i believe (it's hard to tell with IVAN palette, i need to draw it in-game to check).

by the way, replaced all `RAND() % smth` expressions with proper `RAND_N(smth)`. as i am using multiplication instead of modulo, it is usually faster.

that is, for `RAND_N(42)` we can look at 32-bit random number as a fractional part of 64-bit fixed-point float, and at `N` (42) as normal integer. so we can multiply them to get full 64-bit fixed point number, and throw away fractional part — i.e. low 32 bits. as both numbers are less then 1 in this representation, we'll get our desired `[0..N)` range. and on most, if not all, current-day 32-bit CPUs we have 32x32->64 multiplication instruction. division is not guaranteed, though, and it is almost always slower than multiplication.

it doesn't matter much in terms of speed, of course, but why not? also, it is easier this way to replace bounded random number generation with uniform, for example. (because what we have with modulo or multiplication is biased; there is RAND_GOOD in femath to get unbiased bounded rn, but it is used only in several places, due to be slower than biased.)

tbh, we don't even need statistically good PRNG for IVAN, any LFSR will do as fine, but, again, why not?

i am also switched from PCG32 to Bob Jenkins' small PRNG. they both good, but i like Bob's one better, because it doesn't use LFSR, and hence doesn't require 64x64 multiplication.


p.s.: if all this sounds like some orcish speech to you, don't worry. most people (including me) don't know much about pseudorandom number generation anyway. we usually choose PRNG which we like most, and then just stick to our guns.

I've been waiting for this for over two decades.

This is such a cool concept.

I can also provide some fluff text for lore scrolls/books. I spend a LOT of time writing, and certain aspects of IVAN lore were stolen many years ago for my own world building (I play D&D and run my own world... has a few familiar gods, ommels, etc lol)

wow. with people so willing to help with texts, i almost feel obliged to implement "history scrolls"! it would be a shame to waste such talents. so i'll definitely move this feature closer to the top of TODO list.

and thank you all for your support. that's why, i guess, even wild ideas should be made public — people actually may like them more than expected.


p.s.: i also found myself carrying several bear traps around now, because it is fun to arm it, and then throw to an enemy. it may miss, but it may hit too! (or may trap yourself when you try to arm it. even more fun.)


p.p.s.: and as we have the way to disarm mines… maybe we should change the mine to explode when you're moving away from it? not always, because it will make mines mostly not a threat. but sometimes it could be like this, and you'll actually be able to disarm it. like, say, 30% of mines could be "pressure off" kind.

lol, "pocket beartrap!"

why would mines not be a threat if they went off when you moved away from them? are they easy to disarm? perhaps make something a requirement to disarm them, so you have to sacrifice an item to do it?

yeah, it is quite easy to disarm a mine. the process fails mostly at the start of the game, when your Dex is low, but most mines are in GC, and you usually have enough Dex by that time to succeed most of the time. i am not really keen in balancing such things, so i simply took `(User->GetAttribute(DEXTERITY) < femath::LoopRoll(90, 1000))` code from beartrap. this is how "failed to arm" is determined there, and i used it as disarm check for all traps.

i wanted mines to be fairly easy to disarm, because sometimes they block some path which i want to take. if they're hard to disarm, then it is not really better than simply kicking them and hope for the best, and i feel that there should be some advantages to try and do better work using your hands.

also, "pressure off" mines might be "disarmed" by another means: leaving something heavy enough on them. (by the way, a mine won't blow up if your weight is less then 5kg too, this is in the code.) some people already suggested such change, it is somewhere in one of ideas thread.

and it's also not that easy to implement too, because there is no such event as "on leaving a square". currently, the character which is moved onto the square checks for anything "interesting" there. yet there is no easy-to-use code to perform such checks when the character moves away. and we should consider various types of movement — like teleporting, for example. it is doable, but may need changes in several places in the code.

it would be much better to have it coded another way: the square itself should react to "enter" and "leave" events, and the characters simply sending such events. this will allow to add arbitrary square effects without changing a lot of the code each time. actually, `character` class is doing too many things on its own, things that should be delegated to other entities. but that's how the game is written, alas.

one day i will prolly do it "the right way", but i'm not sure what the day it will be. also, this will make stealing code from vanilla harder.

but i still feel that throwing ideas so people could tell their opinions is important. because i sux at game design.

If you wanted to implement actual short 'books' in the game, as in the screen changes to text and SPACE progresses, feel free to borrow "Treatise on the Lights of Legifer"

yeah, books will be interesting. maybe even with proper pagination, why not. i believe they should be shown in an overlaid window, because reading a page takes time, and the player should be able to see what's going on around, and stop reading if Sherry, for example, wants join the party.

deactivating mines is very useful.
1. get ring of searching.
2. deactivate some mines, take one with you.
3. oops, a werewolf. and you have a shitty equipment.
4. activate mine, throw to werewolf. he is no more.
5. profit.
6. kick booby-trapped door.
7. your other mines go BOOM. you are no more.
8. no more profit.

i finally found the source of Eldritch Zombie. it was… interesting. Florea (exiled priestess of Silva in New Attnam) is not a config under `priest` class in k8I, she is a separate `exiledpriest` class. this is because she has more logic than the normal priest, and it is easier to have that code separated instead of clutter main priest class with it. Florea herself is `Config SILVA;`, but… the base `exiledpriest` config had neither `IsAbstract`, nor proper bitmap positions.

now, "zombie creator" is using original head for new zombie. as base config is not abstract, the creator is free to make a zombie out of it. but there is no proper body bitmap position, so the head defaults to `(0, 0)`. and we have a pair of legs there. voila, here's our Eldritch Zombie. base config also has no name set, and for some reason (prolly due to out-of-bounds access bug) the game was using a random name for such zombie. and it is quite rare too. so i've seen it several times, and each time it was something different. of course, i checked the corresponding classes time and time again, without any success — as there was nothing wrong with them.

i found it by accident, looking at "SecretKnowledge" lists. there was a priest with only legs, which looks suspiciosly like our E.Z. i had to add some debug dumps, but finally i found the culprit.

oh, sorry! i was sure that i wrote "thank you" for that — yet i didn't. so thank you a lot! will steal it, for sure.

Text for the car!

short: "steel chariot"
long description: "You see here a strange steel chariot"

Too big to pick up, obviously!

Sit message: "you sit comfortably on one of the padded seats."
Rest message: "You stretch out on the long padded bench in the back. It is very soft and cozy."
Apply message (with an 'odd key'): "After much trouble you find a tiny slot in which the key clicks and turns, but nothing seems to happen."
Dig message: "You can't bring yourself to wreck this wonderous object."

…a-a-a-and… i was COMPLETELY wrong about Eldritch Zombies! it is way more interesting.

the game actually never creates zombies for the base configuration, that was the wrong analysis. what really happens is zombies for farmers and housewives are wrong. because for farmers and housewives head bitmap position is random and hardcoded in C++, it is not taken from the script. but zombie class doesn't know about this, and takes head position from the database… and it is `(0,0)` there, because it is unused. the vanilla might have the same problem, btw, if zombies of farmers and housewives are allowed there.

i need to find the way to tell zombie creator about random head positions. or disable zombies for those classes.


p.s.: workarounded by adding explicit `HeadBitmapPos` properties. non-zombies ignores them, and zombies will have non-randomized heads. it's sad that random heads feature is lost for zombies, but much better than zombies with legs instead of heads.

p.p.s.: this whole randomizing thing looks very suspicious. i think (not sure, though) that it is possible for farmers and housewives to switch their heads when the game needs to regenerate their bitmaps. i don't know if character bitmaps are ever regenerated, though — it is very hard to make heads or tails from the OOP code, especially from IVAN OOP code. so let's use the above "gum solution" for now.

also, there is the bug with xinrochghost both in k8I and in vanilla: it is the subclass of ghost, and ghosts are not humanoids. therefore the sprite is not composite, it is taken from "Char.png". yet the script specifies humanoid composite form for it, which it totally wrong, and the game displays random gfx instead. i believe that it should use `TorsoBitmapPos = 128, 16;`, for example, for spooky ghost-like face.

So what you're telling me, is that IVAN zombie code is spat out by eddies in space-time continuum.