another one IVAN fork (build: 2025, Apr 18)

just4fun i almost ported Alien Mod (along with new "Fearless" state, and Iron Claws weapon).

yep, i know that my fork looks like a terrible mess, and suffers from balancing issues, but idc. i cannot into balancing anyway, i never won a single I.V.A.N. game in almost 15 years, so i am absolutely FEARLESS of ruining the game expirience for me. and porting all those features is at least as fun as playing the game itself.

i will prolly need a new script with "worldmap config", where i will be able to enable/disable all those new dungeons, and possibly with a possibility of adding new world locations from the script. internally, engine is already simply registering all new locations at game init, so it should not be extraordinarily hard. i hope.

upd: fixed some bugs with states; "Fearless" now removes "Paniced"; the Alien Mod graphics copied to k8ivan, and there is Alien Queen on Alien Queen Level. dunno if it is playable, though. sure, there should be some quest attached, and custom rooms, but i sux at such things.

another (possibly) usable idea implemented: the game will ask you if you want to wear both gauntlets/boots if there are stack of two, and two usable limbs.

also, equipment screen is color-coded now: red color means "i have nothing usable for this slot", and pink color means "there is only one usable item for this slot, and it is equipped right now".

Now that is... a bit too much pink.

yeah, the color is too aggressive, i prolly should tone it down a bit. i just took the predefined constant, 'cause manually creating 16-bit colors is somewhat hard. yet i switched to c++14, so i can use constexpr for that now.

A little color is nice but I think this is overkill haha

i swapped the meanings, and changed pink to orange, and now it looks much better.

this one change, btw, was done not out of desire of add even more color, but for practical reasons. i want to know if i have something more to equip in a slot without selecting the slot and looking into new list. i'm not a Real Hardcore Player, so i often don't remember what i have in my inventory. %-)

sure, this can be turned into configurable option. but i'm not planning to turn it off anyway, so i am too lazy to add an option for that (i already have 27 options in list, lol).

i'm sure that the list can be made better with careful color selection, tho. designing good UIs is something i absolutely cannot do. %-)

p.s.: aaargh, vasily's engrish again. let it be.

i made a lantern little less bright, and made memorized tiles little darker. i think the undergrounds looks more… "undergroundy" this way.

Instead of just dimming the lanterns, how about switching the light values with the oil lamp? I always did like them better than lanterns for the atmosphere but they're too rare.

actually, dimmed lantern is almost the same as oil lamp. yet, why not? tnx for the idea, switched.

made equipment list slightly smarter: it now preselects slot with recently picked up item (one that was picked up less than 16 turns ago), and selects most recently picked up item in item list for a slot. most of the time this is what you want to do anyway, as you prolly just picked up something you want to equip (or compare). also, item list for empty slot preselects first non-empty item, 'cause it is unlikely that you want to select "None" for empty slot. %-)

finished (except some tiny bits) replacing hardcoded constant values with "define.dat" access. some things still have to be kept in sync between C++ and "define.dat" (like number of states, or some other counters), but almost everything else is taken directly from "define.dat", so no more two files to sync on changes!

quite happy with that.

also, there is (not currently used) mechanics to call simple functions from .dat scripts, which can (and should) be used to move some material and other effects to .dat files. basically, all EFFECT_* things are very simple and can be done with equally simple script commands. yet i don't know if i'll implement that: new material effects require C++ coding anyway...

almost working "universal worldmap POI system", that allows creating up to 255 worldmap locations without any modifications in C++ code.

instead of creating subtypes of owterrain, i chose to use differenct configs for different POIs. revealing quest POIs still require C++ code, tho.

i attached a working draft of owterra.dat. very WIP, i'll prolly add some more options there.

done. it seems to work. the code is a mixture of old and new parts, tho: it can be cleaned up a little more. still, it does it's job for now.

p.s.: and i made some sense of "database" code parts. what a mess! %-)

finally, made are more-or-less proper module system. abstract definitions are in "script/*.dat" files now, and there is "script/module.dat" file with <Module "name";> directives. the game then loads each module files from the corresponding module dir in "script/".

for now all game objects still must be defined in scripts (so you cannot create new enemy class, and skip it's definition, even if it is unused in game), but you can create standalone modules with new configs (tnx to my "Extend" directive).

for the demo purposes, i moved "Alien Mod" content to "zone69" module. you can't omit it for now, but i'll eventually fix it (so game will simply ignore entity classes without proper definition in scripts).

basically, module system is a simple extension of "Include" system, so it will be fairly easy to port it to comm. fork. see this commit. module system is fully backwards-compatible (except that "module.dat" file must present anyway, but it can be empty).

added some code to deal with entities without script definitions. it is now possible (i hope %-) to comment out "zone69", and the game will work. that is, you still need C++ classes for new entities, but if you won't load a module which defines those entities, the game will not use 'em.

so, now it is possible to split the game, for example, into "weapon mods" with additional weapon classes (not configs, but real classes), and selectively load those modules. item spawners will still fail on undefined entities, tho, so it is limited to new dungeons with new monsters and items, i think.

Wow, you're hard at work! How long until we can get our grubby mitts on this?

each announce here usually done after the corresponding "git push" command, so it is possible to clone the repo and try it out. yet, as i wrote somewhere in this topic, it is GNU/Linux only (actually, it should work on any POSIX-compatible OS), and it won't work on x86_64. i disabled 64-bit builds altogether, 'cause resulting binary is not working right anyway. i have no 64-bit OS installed, so i can't properly fix all 64-bit issues, hence i decided to not support 64bit at all for a moment.

i see my fork as a testbed for various ideas. those ideas can be taken to comm. fork later, if they're interesting enough. k8ivan is something like "developer's playground": hard to build, full of features, and totally off-balance. %-) yet, comm. programmers may take some inspiration from my changes, either by directly reading the sources, or by reading my announcements here. and i'm always (i hope %-) here to answer any questions regarding the code, of course.

that is, go on: build it, and play with it, if you want. i'd be very happy. if you're on 64-bit GNU/Linux, you will need multilib setup, with 32-bit compiler and dev. libraries installed, tho (sdl1, sdl_mixer, libpng16, zlib, x11 and opengl). k8jam-based build will force -m32 on such system. providing prebuilt binaries for GNU/Linux is useless anyway. %-)

converted gwterrains to configs.

it is absolutely not necessary to have different classes for gwterrain types, they're better described as configs. so, there is only one `gwterrain` base class left, and database system is used to spawn then corresponding world terrain config object.

moved some worldmap constants to configs (MAX_TEMPERATURE, etc.). it is now possible to override 'em in modules. not that it has much sense, tho, 'cause you may force creating unsuitable worlds, and the game will hang on world generation stage. but hey, it's about user's choice, right?! %-)

i must confess that since i implementet "smart item lists", the game becomed way more enjoyable; it reduced my "arrow key poking rate" to almost zero. it may have something with my playing style, of course, but now most of the time (with rare exceptions, slightly annoying, but not enough to make me revisit the code %-) i don't have to press any arrow keys at all.

added two new fields to item template: `MagicEffectChance` and `MagicEffectDuration`. they can be used in items like "slowaxe".
the syntax is:

  MagicEffectChance == 3; // will do !(RAND()%3)
  MagicEffectDuration = { rand: 200; add: 400; } // 400+RAND_N(200)

c++ part will now look like this:

truth slowaxe::HitEffect (character *Enemy, character *Hitter, v2 HitPos, int BodyPartIndex, int Direction, truth BlockedByArmour) {
  truth BaseSuccess = meleeweapon::HitEffect(Enemy, Hitter, HitPos, BodyPartIndex, Direction, BlockedByArmour);
  if (Enemy->IsEnabled() && GetMagicEffectChance().inRange()) {
    if (Hitter) {
      if (Enemy->IsPlayer() || Hitter->IsPlayer() || Enemy->CanBeSeenByPlayer() || Hitter->CanBeSeenByPlayer()) {
        ADD_MESSAGE("%s axe chills %s.", Hitter->CHAR_POSSESSIVE_PRONOUN, Enemy->CHAR_DESCRIPTION(DEFINITE));
      }
    } else {
      if (Enemy->IsPlayer() || Enemy->CanBeSeenByPlayer()) {
        ADD_MESSAGE("The axe chills %s.", Enemy->CHAR_DESCRIPTION(DEFINITE));
      }
    }
    //Enemy->BeginTemporaryState(SLOW, 400+RAND_N(200));
    Enemy->BeginTemporaryState(SLOW, GetMagicEffectDuration().rand());
    return BaseSuccess;
  }
  return BaseSuccess;
}

ah. and added `MagicEffect` field too, so it can be used instead of hardcoded `SLOW`.

and hey, why not? moved that code to `meleeweapon`, so any melee weapon can have magic effect(s) now. also, added `MagicMessageCanSee` and `MagicMessageCannotSee` arrays, to get rid of hardcoded "magic effect applied" messages.

fixed (i hope) a really ancient and really nasty bug with spilling liquids (use-after-free).

the game can `delete` liquid object in one of `SpillFluid()` methods, but will continue using deleted object for some time. this is really hard to catch bug, 'cause most of the time that use-after-free is not fatal, and works ok. but sometimes it randomly fails.

comm. fork has this bug too, btw. it is less disasterous, tho, 'cause comm. fork doesn't have some mosters k8ivan has, and the bug best manifests itself with `ADD_MESSAGE`, which tries to get a liquid name.