added some colors to item lists. see attachment for image.

in the meantime, i replaced mersenne twister with PCG32 (prngs), and made currently equipped items in e/w/W menus highlighted.

actually, i think i should make more improvements in item lists. at least make "enchantement level" and attack/armor numbers differently colored, so it will be easier to "quickscan" a list.

p.s.: is is somewhat… inconsistent that the bottle is the only thing which spawns separate "broken" object instead of BROKEN config. i guess it is either leftover from the early developement stages, or a hack to ease implementing damage from broken bottles lying on the floor.

oops. wrong edit.

@MrMagolor:
>I feel like modding should be streamlined, in a fashion perhaps similar to
>Cataclysm DDA.
it is not that easy to make I.V.A.N. "trully moddable". the codebase is... messy, and alot of game logic is hardcoded, with alot of "gum solutions", as original devs called it. in my fork, i separated monolithic .dat files to "one .dat file per entity", though, and did the same for C++ code for objects (that's why i like my fork more — it is more maintaineable, and way easier to extend: you can see how fast i ported full new quest, and new Attnam into it). initially, i wrote some tools to split monolithic sources and dats into separate files, and now it "just works".

but to turn this into "real mod system", we need a full-featured scripting language, with access to all game internals. i started the work on such language — based on javascript — some time ago, and even produced a working prototype (vasya), but then the work is stalled for various reasons. tbh, script interpreter is a small part of the work; the biggest part is exposing game internals to a scripting language.

what i mean is that adding "real mods" will require alot of work, and almost complete reworking of the codebase. considering the small number of developers, it doesn't look like a doable task right now. it is better to continue with what we have now, and add new features with C++ code.


@4zb4:
player can also dump cans with non-liquid contents. so you can take a can of banana flesh, dump bananas on the floor, and fill the can with a liquid from bottle. there is "make it possible to fill cans with lumps of flesh" bullet in my TODO list (butchery! , but it is not implemented yet.

>It would also have other applications, like emptying acid on a wall or object without needing to break the bottle.
yeah, that is already working, thanks to game liquid mechanics.

the code is quite easy to fix too. actually, i think it will be better to add a flag, something like "Indivisable" (my Engrish sux), that indicates that the given bottle type cannot be divided by two with "!". then we'll be able to get vials of different size. this way, trying to dip a bottle into a full "indivisable" vial will transfer liquid from vial, so refilling bottles will be easy. yet, this is somewhat harder to do, 'cause you will need to relax the check used to build "!" list, and check for "compatible" liquids.

i feel that the next step will be: "but i want to mix healing liquid and water to get 'smaller healing liquid'!" a can of worms.

as for breaking, this is in `potion::Break()`: it uncoditionally creates "brokenbottle" item. quite easy to fix: the code can take config id from potion, and create the corresponding "brokenbottle" config, instead of defaulting to... default — see `item::Break()` for the code.

my OS is 32-bit Slackware GNU/Linux. usually installed packages are not bleeding-edge, 'cause i prefer to build most things from the sources, and rarely bother updating — unless i hit a bug in a lib, or have some time i need to waste.

by the way, comm. scripts has some duplicate properties and one syntax typo (at least). i made a tool to compare definitions and configs to port Tomb ('cause doing it manually is tedious, of course), and found alot of this in my scripts, and some in comm. scripts. would you like to get a patch in PM? or, i can send you tool source instead (with 32-bit GNU/Linux binary, or windows binary, on your choice), but beware: it is written in D language, and a simple throw-away thing. i.e. the code is crap.

back to I.V.A.N., tho. the fire system looks really interesting. actually, in my TODO file (it is not in repo) i have "make things burnable" bullet. will take a look.

in the meantime, you can steal "a := { b, c, d; }" syntax from k8ivan — arrays without counter. also i have go command that follows turns, and can stop on non-seen-before items or doors. and dUmp commad, which allows you do dump bottle/can contents on yourself or on adjacent tile. this should be a great addition to fire system: PC will be able to dump some water on itself or a friend to remove fire. i guess that you, or some other dev can steal those features to comm. fork.

as community seems to restarted "I.V.A.N. improved" project, i decided to backport some features to my fork. specifically, i'll try to port Tomb Of Xinroch quest. k8ivan has a placeholder for it: you can get this quest (but not the way you'll get it in "community version"), yet Tomb is empty for now.

it's been a long time since i touched I.V.A.N. code, and i see that comm. is somewhat diverged from CVS (on which mine fork is based), so don't hold your breath. still, this will be The Adventure on it's own!

p.s.: why don't just drop my fork and join comm. one, you may ask. 'cause i like my code way more than comm. code. and i HAET cmake. and i will never ever register on github. and comm. fork simply doesn't work on my box. and... because i can! k8ivan has some features i like, and i'm not ready to port 'em to comm. fork (especially 'cause i cannot even run it without segfault .

p.p.s: so far i ported alot of code, and Tomb at least loads now. also, it seems that my libpng haets xml crap shitdoze loves to put into pngs, and segfaults. by the way, that shit often is bigger than the other png data.

p.p.p.s: "community version" of Attnam is working now, and it is possible to get a quest from imprisoned necromancer (so you have two ways to get Tomb location!). i also ported all missing/new items and characters. but there are no plans to port the fire system: i am not sure if i really want to have it. also, there are no plans to port AI improvements (yet).

anything done for windows increases (or not decreases) m$ userbase. looking at recent m$ actions convinced me that i don't want to support m$ in any way. it can be childish, but this is the only thing i can do. if *every* developer will do the same, it will change the world. someone have to start.

'android case' is not the only thing i hate. 'tom-tom case', for example. 'SCO case' (SCO was funded by m$). and many other things. too much for me.

sorry, guys, i have nothing against you, but i don't want to work for my personal enemy in any way (heh, corporation *can* be personal enemy). so i removed windoze support from all my FOSS projects. as a side effect this will make my life easier, 'cause GNU/Linux have alot of useful libraries which i can use now and don't think about OS that have more than 25 years of development but still cannot into concept of 'software repositories'.

now. i claim that windoze support is over. no more k8ivan windows builds, no more hacks to support windoze. sorry you all. this will change when m$ will stop charging money for android phones.