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

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;
}

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.

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?! %-)

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.

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. %-)

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.

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).

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! %-)

older libpng still crashes on your pngs, due to iTXT chunk with xml crap. while this is definitely libpng problem, removing iTXT chunk is a good thing by itself: in some files that chunk alone is bigger than the rest of the data!

p.s.: this report is for binary built from source on my GNU/Linux, of course, not for official binary.