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!

that's what we need SQL queries for! of course, while writing the converter, i hit crash bug in my Oberon compiler. i HAET chain bug explosion!

hm. it should not crash (obviously , just change the resolution on restart. but tbh, that part wasn't really tested: i set the resolution once, and never touched it again. thank you, i'll take a look!

like what? maybe i'll eventually port them too. just throw all your wishes and crazy ideas into me, and something will stick.

thank you! the colors should be configurable, but… k8ivan has only one active user so far, and he never complained.

you mean the whole stack, not just comparisons? yes, i will prolly do it later.

the first version of item comparison was writing messages into log window, and i didn't want to clutter the log, so i implemented only the most necessary stats. when i switched to popups, i basically kept the same code, because i wasn't sure if it will work at all, and if i will like it or not. and then i simply forgot to improve it. so i will definitely add other things there.


i remember that this was the problem in some older IVAN versions too. it was either fixed in the mainline, or in some fork from which i inherited it.

thank you for pointing that! i definitely don't want leprosy to be that easy to get. it is mostly just an annoyance (run back, return, run back, return), and it doesn't feel like something interesting if it happens too often. you get used to it, and it's harder to miss it accidentally. so i'm with you here.

eh… it is really hard to balance such huge and mostly random game as IVAN, especially considering that the game basically a black box. we can change some values here and there, but it is not easy to predict the outcome. and after a lot of playing you got used to it, and may honestly think that it is perfectly balanced.

so i'm not blaming the team for that. just wrote some of my thoughts as somebody who missed almost a decade of updates. sadly, IVAN lacks proper tools (actually, any tools to work with its databases, and this makes everything really hard and tedious. like, if you want to add a new material, you also have to go through most items, adding new material configs, tweaking the probabilities, and such. it quickly gets out of control.

i am trying to convert scripts to SQLite database now, just to see how it goes. if i'll ever succeed, it would be much easier both to query, and to change things. but i need to create a good DB schema for that… and i already redesigned the schema like dozen times.

and a side note: you may noticed the SQLite amalgamation in source archive, and wonder what the hell it is doing there? well, i have the answer! it is to make the code big… oops. wrong one. i actually plan to store hiscores in sqlite database. and not only hiscores, but all things the game shows you when you're dead: message history, detiled kill statistics, and so on. hey, it's important info (which nobody needs, of course). and instead of inventing my own storage format for it, i'd better use SQLite. tbh, i want save games to be SQLite databases too, but this is too much work. maybe someday…

to be even more honest, i want EVERYTHING to be stored in SQLite database. imagine how easier it would be to manage materials, items and such if you can use SQL queries to find various things about them? you want to see the hardening chain? ok, here's SQL query for ya. you want to know which items can use the given material? SQL query to the rescue! the possibilities are infinite.

i will prolly experiment with converting scripts to SQLite db. let's see how far i could take it.

i haven't looked at dungeon changes in comm. fork yet, only to new materials, and to some new items. comparing and porting those things is mostly mechanical work, after all. but for dungeons i prolly need to write some tool to visualise them, because it is hard to build a mental picture of a dungeon from textual description (especially with multilayered special room maps).

tbh, i always wanted to write a kind of "visual dungeon builder" (and visual item/material editor too). maybe i'll do it this time instead of looking at walls of script text.


i fully agree that more materials is more fun, and edible golems are really fun too. but i prolly need to introduce "chance to make a golem" instead of simply "golem allowed" boolean. this way we can both have our lunch and eat it too.

i decided to not revert the changes, and try to think out the way to incorporate them instead, 'cause i really love all new things added.


the biggest problem is that i don't understand how the game calculates danger levels and spawn chances, so i prefer to not touch that code. i have a very rough idea of it, but as this is the core of the game, any change there may break everything. and i won't be able to tell if this is due to my changes in the code, or due to tweaking some probabilities, or if this is simply a bug i introduced.

that is, i tried the lazy route, and failed. now i'll try it for real.


still, the problem with SoHM needs to be solved too. SoHM basically skips materials with Int requirement much lower than the player's Int, but i feel that it needs some rebalancing too. it currently simply makes skips gradually harder with each step. maybe it should look not only on the number of steps, but on Int requirement difference too, to easily skip various trash materials… dunno, i need to write a "material chain visualiser" first, to see all new chains, and then try several approaches to find a good one.

ok, i'll try to forbid golems from weak materials first. this should prevent low-tier golems spawns in UT, and should not affect the game. i mean, who would want to create a cheese golem anyway, wasting the scroll on it? it is fun, of course, but this is "one-time fun", doesn't worth ruining the game.

copypasted most new materials and liquids from the comm fork… and i'm not sure if i like it. maybe it's simply because i used to the old set, and confused by the new things (and i really do), but maybe it's because there is too much almost similar things. tbh, the game starting to look filled with… well, fillers: a lot of "almost the same" items, differs in almost nothing, creating illusion of rich content without the real content itself.

besides, the game started generating CROWDS of golems in UT1. most new materials are ok for golems, and there are many weak golem possibilities… and i DEFINITELY don't like it. it feels like a very different game, which only looks like I.V.A.N. i mean, hordes of golems on UT2? 'cmon! (actually, even on UT1.) seeing golem for the first time should be terrifying. in the previous versions golems sometimes spawns in UT, but they were quite rare, and each encounter was terrifying. now it is almost trivial: "eh, another golem. get out of my way, you stupid thing!"

for the time being i will prolly revert all changes. or block new content from appearing in the game: no golems for new materials, no item config extensions… and no way to harden into new things too. this is because hardening is more-or-less balanced around current material chains. with new materials there, everything need to be rebalanced: materal probabilities in items, probabilities of SoHMs, and so on.

nope. i prolly revert most added things. i appreciate all the hard work community put into this new content, and it is prolly my fault trying to simply dump it in k8ivan. i hoped that it would work… but no. it simply killing the game.

i believe that comm. fork was gradually rebalanced, so new content works there. i mean, adding new materials to weapons, for example. it means that the game has wider choice of things to spawn, and doesn't have to resort to golems. without such balancing adding dozens of new materials simply destroys everything.

so i think that i will have to rework new dungeons and characters, replacing new comm. materials with ones already in the game.

i prolly need to play more of comm. fork games too, to see if it has the same feel.

in the end of the day… our corporation is always happy to serve our customers! here is win32 preview version some of our customers asked for. don't forget to visit our store to buy skins and shiny new DLCs!

SPOILER ALERT. Click here to see text.

upd: quickfix for one crash (wrong config value in "define.dat", lol).

not yet, sorry. yet i am planning to create win builds when the thing stabilizes a little. for now it works, but crashes frequently (even for I.V.A.N. standards), due to all that new code i added.

just keep an eye on this topic, and you eventually will be able to try it. once i consider it "ready for pre-beta", i plan to public win builds more-or-less regularily (until i decide to make another 7-year pause .

if you are tracking my git repository, please, re-clone it from the scratch. i switched to Fossil, and git repo is just a mirror now. essentially, git repo was recreated from scratch using fossil export command, and all commit hashes were changed. this is one-time inconvenience, and you can keep tracking the repo as usual after re-cloning. sorry for the inconvenience! but i prefer Fossil these days, and cannot stand using git anymore.