i always wondered why backpack with powder has so little uses. so… i think that if you have "flaming something" in your inventory… we have several choices here.

first, the moment you pick up flaming thing and already have a backpack (or vice versa), the backpack should KABOOM! because why not? it's I.V.A.N. we are talking about!

second, we can turn backpack into a grenade instead. 'B'urn it (i already have that command for webs), and then throw away. kinda like Holy Grenade. this is less fun than KABOOM, but more useful.

by the way: if you're wielding a flaming weapon, it will automatically burn the webs. with a random chance, of course, but most of the time it succeeds. (this is already implemented.)


any other ideas how to turn the backpack into a grenade? i really love to do it, but i want flaming weapons to perform KABOOM! too.

The Main Problem of I.V.A.N. Development…

…is insolveable.

somehow you need to convince yourself to stop "testing the game" (aka playing, and playing, and playing, and pla…), and start coding. but hey, what if i'll catch some bug on the next playthrough? ok, just one more time…

there is missing `{` after `if(PLAYER->GetRelativeDanger(this, true) > 0.1)` there. both statements should belong to `if`, but only one does. hey, this is not Python!

thank you, i'll take a look!

meanwhile, i implemented saving massacre history to hiscores db. it is not possible to view it yet, but at least it is preserved.

moved hiscore table to SQLite database. the game will still show top 100 entries, but there is no reason to remove anything from db, so db will never be wiped. now i can start accumulating high-scores again, and check what will be there in another 20 years.

and btw. if you'll look into k8ivan directory after the first run, you'll find ".ivan.keys.rc" file there. it is not just a help, this is actual keybind config the game is using.

oh, missed this one. they prolly came from CLIVAN or some other fork. k8ivan was the amalgamation of several forks when i created it. LIVAN, IVANX, CLIVAN, Alien Mod, community fork — i robbed everyone i could.

yes, changing the resolution increases internal game resolution, not scaling. you have to use scale setting to make the window bigger then. as you may know, internally the game is using hardcoded 800x600 bitmap to render everything. i tried to un-hardcode that, but it may fail for too big or too small resolutions, or fail randomly due to me forgetting to unhardcode something somewhere.

config window needs help text, badly. some owls there are not what they seem to be!

it currently using simple bilinear filtering (just OpenGL blit). i am planning to change that to use oversampling. i.e. the picture will be crispier, and "sharp pixels" mode will look much better. it's not hard to do, but there are always other things to implement first, so it always slips to the bottom of the list.


you can even use ctrl+arrow for "Go" command. and the player will follow tunnel turns.

yes, there is even a setting "Kick closed doors" there, which you prolly noticed. what you haven't noticed, i believe, is that there are several valid anwers on "do you want to open … door [y/n]". you can simply press the corresponding direction key again, and it will be counted as "yes". i.e. just press the direction key until the door opens, you don't even need to read that message.


thank you! it is one of those things which seems obvious… when implemented. i now cannot understand how i didn't thought about it before, and how i managed to play without it. but it took me amost two decades to realise that i need it.


have you ever looked at IVAN code? i spent a lot of time restructuring it. it is still shit, but now it stinks slightly less.

thank you! sadly, i don't know if (or, rather, when) i'll run out of steam again, but until then… i'm living in Ukraine, so it's hard to predict anything.

i love roguelikes, and played a lot of them, including much hyped ADOM and DF. but there is only one game i'm still playing after almost two decades, and only one game in which i want to invest my coding time. among roguelikes, i mean.

tbh, i really wonder why IVAN is not widely known. yes, it is mindless fun, but there is surprisingly deep and rich game under that cover. maybe it's just because not many people managed to get under the cover. but it seems that those who did became dedicated IVAN followers.

wow. SQLite rox.
how much items we have in db?

SELECT COUNT(name) FROM objects WHERE base=0 AND class<>name ORDER BY name;

well, 340.
now for something more interesting: how many items can be made from balsa wood?

SELECT objects.id, objects.class, objects.name, objects.config FROM objects
INNER JOIN definitions ON definitions.objectid=objects.id AND
  definitions.schemaid IN (SELECT id FROM schemas WHERE class='item' AND name LIKE 'mainmaterialconfig') AND
  svalue LIKE '%balsa%';

and the reply:
| id  | class |     name      |    config     |
|-----|-------|---------------|---------------|
| 484 | item  | meleeweapon   | QUARTER_STAFF |
| 508 | item  | meleeweapon   | ROLLING_PIN   |
| 752 | item  | helmet        |               |
| 835 | item  | stick         |               |
| 838 | item  | mangoseedling |               |

DB scheme still sux, though. but at least this is something i can experiment with.

i finally found the bug in my compiler (in case you wonder, yes, i am that crazy: i using my own Oberon compiler written from scratch as my main programming tool). and i partially converted .dat files to SQLite db. i am not happy with the result yet, but i'm planning to do it in two stages: first, full conversion to the current database schema. that schema is not ideal, nor even good, but it will allow me to never ever reparse scripts again. from there, i can work with the DB i have, experimenting with various data representations, don't bother with text parsing anymore. and second, experiment with DB schemes (raw, dictionary, strictly key/value, etc.).

the main problem is that if i'll implement SQLite DB into the game, i'd have to stick with it. so it is better to spend some time trying various schemes than to implement the first one which came to my mind, and then force myself to use something which is barely usable. as i have no prior expirience with designing DBs for games like IVAN, R&D phase is inevitable.

of course, it is possible to convert db back to raw text files readable by the game, so if i'll manage to produce some usable tools, comm. fork may benefit from them too: just convert comm. fork dat files to database, run the tools, and convert it back. or, even better: switch to SQLite db too!