there is another interesting bit of info the game tells you sometimes: weapon usability. it is that "you have much trouble using this item" prompt (and its various other versions). this is quite important info, and you can always check it by unwielding the weapon and wielding it again… but it is boring.

so i added color codes to paperdoll slots, and textual description to equipment string. slot background will be brown for "somewhat difficult", and progressive brighter red for higher difficulties.

i'm not sure about hit value yet: it is interesting info, and something you can roughly figure out by yourself from weapon stats… but i am too lazy to do it. i may remove this info later, though, or make it depend of PC Int level (so boosting Int will have yet another use).

and now i want a good way to destroy items. there are many items i want to completely get rid of, so monsters will not pick them up. suddenly, bottles with sulphuric acid are a scarce resource! and i started offering almost any trash i found too. any chests are great. and by the way, closing doors now has way more sense: the mosters cannot see items this way (if not spawned inside a room, of course). it's not fun to see a monster wearing ommel armor +20, you know. and they WILL run for it (literally run, monsters are running to get the equipment).

but it is fun to set a trap on some good item too. stupid thing will run for the item, and… traps are not mostly useless anymore!

also, rewrote file compression and decompression code.

reading compressed file now requires only one 64K buffer (and several kb for chunk table). on writing, the chunks are compressed as long as they are ready. it is quite important change, because the previous reading code was decompressing the whole file to memory first. in IVAN, save files are easily tens of megabytes of size. of course, we have plenty of RAM these days, but i still prefer to not waste it.

and the writer was doing essentially the same: collect the whole uncompressed file first, then compress it (allocating conservative second buffer of the same size), then write. twice as much memory. now the writer compresses chunks when they are full, and never keeps the whole uncompressed data. compression is usually 64K -> 7K, so it uses much, much less memory.

sadly, i cannot write compressed chunks to disk immediately, i still have to collect them all first. this is because SQLite cannot change blob size dynamically, it requires blob to be fully allocated before writing. so i need to know the final compressed file size, and i don't have any temporary storage to write into.

of course, it is possible to use either temp file, or temp SQLite db to store compressed chunks until everything is ready. i may rewrite the code later. but for now, i'm ok with using ~64KB RAM for 1MB of compressed data (this is how good IVAN data can be compressed, yeah).

also, my plan for SQLite worked perfectly! i fixed several crashes on saving (including crashes on level transition), and the save was never corrupted! on next load, SQLite magically reverted all unfinished changes. yay.

as usual, each time i decide that it's a BUILD TIME! the game crashes.

and don't forget that there is ticket tracker for k8I. if you want to add more tickets, or fill the wiki, PM me, and i'll create a login for you. it's not a demand, of course, just a remainder about Yet Another Useless Login option.

no problems! it's not like we're on duty here. i was silent for 7 years, so i'll be the last person to blame someone for infrequent posting.


and while i'm on it — i added green "target cursor" to doors PC is trying to open. when there is a question about a door ("locked. open?" "closed. open?" "closed. kick?") the corresponding door will be marked with green cursor. no screenshot, just imagine it.

also, sell UI now looks slightly better: prices are aligned and better color-coded.


p.s.: found fun bug in options list (introduced by me earlier). forgot to reset one array index, so after 5 or so option changes out-of-bounds access starts overwriting random memory. silently, of course, it's C++, not some stupid Oberon. sigh.

i was slightly wrong about danger map updates: the updater is called irregularily. so it's not 800 turns: with normal gameplay, it is around 200-400 turns (average figure). still way too much, i believe.

interesting facts.
1. danger map was not updating when you are in the wilderness. i think this is wrong, so i removed that check.
2. danger map updates much faster when you are resting. like, 3-7 times faster.

drop UI in a shop will show the prices. it is really boring to try to drop each item just to see how much it costs.

upd: screenshot below.

this is great idea, thank you!

but we need to decide what to do with her sister then. their chat lines says that sisters are caring about each other, so it doesn't look like she would leave the sister and just go away.

maybe make her friendly, but don't allow her to leave Attnam? something like the question on leaving: "XXX doesn't want to leave her sister alone, and prefer to stay here. Continue?"

also, they need names, i think. the names could be revealed after befrending them.

i think it's almost the time for the new build, mostly to show off new "finder AI". but i still can't decide on danger map update rate…

the problem is that i am very-very bad IVAN player, so what is "very hard" for me might be "normal" or even "easy" for others. there is the console variable to control the rate. i will prolly tell you how to change it (remind me, please!), so it would be possible to experiment a little and tell me what your preferred update rate is.

i tried to implement that. if the player turns Petrus hostile (and only Petrus), the code first moves princesses to the player team. haven't checked if it works yet, but i cannot see why it shouldn't. also, introduced special handling for gifts, so it's now possible to give them something besides luxuries.

but if the player managed to turn Attnam hostile by some other reason, ladies won't join. they hate Petrus, but not the whole city (how noble of them! .

wife #7 will prolly need a special handling, tho. i don't think that the code will work for her. besides, she needs a different logic: i bet she could always join, considering her… living conditions.

SPOILER ALERT. Click here to see text.