also, another feature i always wanted to implement: automatic registration and verification of material and config names.

there is no reason to manually list all materials and possible configs, the game could infer them on its own. k8ivan already using constants from "define.dat" instead of hardcoded C++ defines, so it would be the next logical step. there is no reason why the game could not generate the numbers itself instead of using hand-made enumerations. we will need to save config and material names instead of numbers to saves, but this is something which is actually *better* for savegame compatibility.

most of the foundation code to implement this is already in there, i only need to do final 20% of work (which takes 80% of time, of course .

also, saved game selector now has not only in-game screenshot, but some game description too. this description is just a .txt file inside saved game archive, so i can add various things there without touching savegame selector.

by the way, worldmap! i rewrote POI placement several times already, and will rewrite it at least one more time, but there are some interesting things in there already:

  // special POI
  Config ATTNAM;
  {
    NameSingular = "Attnam";
    BitmapPos = 0, 48;
    NameStem = "mighty cathedral reaching the clouds";
    UsesLongArticle = false;
    AttachedDungeon = ATTNAM;
    CanBeGenerated = true;
    NativeGTerrainType := { LEAFY_FOREST, EVERGREEN_FOREST, STEPPE }
    WantContinentWith = ATTNAM; // yeah, sorry
    RevealEnvironmentInitially = true;
    // UT exit is generated *BEFORE* Attnam, this is how the game works!
    DistancePOI = UNDER_WATER_TUNNEL_EXIT;
    MinimumDistanceTo = 3;
    MaximumDistanceTo = 6;
    MinimumContinentSize = 25;
    MaximumContinentSize = 700; // it was 1000 before, but i want smaller continents
  }

here, you can see some new properties. `WantContinentWith` (for Attnam it is a hack, though, because Attnam actually placed *after* UT Exit). `*ContinentSize` fields moved out of source code. `DistancePOI` and distance props are there to enusre that you don't have to travel half of the continent to find Attnam. there is nothing interesting in overworld as of yet, so there is no reason to spread POIs. most POIs are more-or-less close now.

  Config ASLONA_CASTLE;
  {
    Probability = 100;
    CanBeSkipped = false;
    NameSingular = "Aslona Castle";
    BitmapPos = 96, 128;
    NameStem = "mighty seaside castle";
    UsesLongArticle = false;
    AttachedDungeon = ASLONA_CASTLE;
    CanBeGenerated = true;
    NativeGTerrainType := { STEPPE, LEAFY_FOREST }
    SeparateContinent = true;
    CloseTo = ATTNAM; // try to move as close as possible to Attnam
    //RevealEnvironmentInitially = true; //for debug
    MinimumContinentSize = 25;
    MaximumContinentSize = 0; // any size
  }

  Config REBEL_CAMP;
  {
    Probability = 100;
    CanBeSkipped = false;
    BitmapPos = 16, 64;
    NameSingular = "Rebel Camp";
    NameStem = "hidden camp";
    UsesLongArticle = false;
    AttachedDungeon = REBEL_CAMP;
    CanBeGenerated = true;
    NativeGTerrainType := { JUNGLE, STEPPE, LEAFY_FOREST, EVERGREEN_FOREST }
    WantContinentWith = ASLONA_CASTLE;
    //RevealEnvironmentInitially = true; //for debug
    DistancePOI = ASLONA_CASTLE;
    MinimumDistanceTo = 5;
    MaximumDistanceTo = 9;
  }

now, some more interesting things. `SeparateContinent = true;` — this does exactly what it says on the tin. Aslona will be placed on a separate continent. then `WantContinentWith = ASLONA_CASTLE;` in Rebel Camp will ensure that Rebels will not travel too far away. `CloseTo = ATTNAM;` — this will try to find the point close to Attnam (but still on another continent), so you won't be forced to sail over the whole world.

the additions are not fully working yet (POI placement algo sux), but even in half-working state they make the overwold more manageable.

now we prolly need an overworld compass too: Aslona still might be quite away, and it is sometimes to hard to find it on a worldmap, and then even harder to keep the direction to it. maybe even "autotravel" command, so the ship will automatically sail to Aslona and back.


the problem with current POI placement code is that it only tries once with random coords, and if it fails, it throws away the whole world, starting from scratch. it doesn't have to be this way: we might still find suitable POI placements if we'll try hard enough. this is kind of graph searching problem, which i tried to solve with brute force first. and you might guess how well it goes — solving graph problems exploring all possibilities, without any heuristics to cut off dead ends. that is, it never finishes even once.

i have to rewrite the code, aggressively pruning impossible solutions. this way it should work MUCH faster, and satisfy all constraints in no time. at least i believe so. for the time being, the old algo is still used.


p.s.: and completely unrelated note: the game shows "saving…" popup when saving the game. it might take some time now due to all compression and such (less than half of a second, but still noticeable), so the popup will tell you that the game is busy archiving your precious character and dungeons, not stuck in some endless loop.

thank you!

basically, you need k8jam, and it should do the rest. k8jam has no external dependencies, and should be buildable with provided shell script, producing single standalone binary. it need not to be installed.

then "k8jam config --help" will show configure options. but i'm not sure if all of them work. i believe that "k8jam config" should work, tho. then "k8jam" again to build the binary. do not try to install it, this is not supported yet. just run from where it built.

please, note that 64-bit builds are not supported, so you will need 32-bit support installed. k8jam should automatically add "-m32" flags on 64-bit system (i hope . also, SDL2, SDL2 Mixer, zlib, libpng 1.6, and working OpenGL libs. k8jam will detect them and complain. also, i believe that ALSA is required for sound, due to one callback in the source; it can be disabled, tho; everyhting it does is silences ALSA "pcm buffer underrun" errors. i'll add libalsa detection to configure later.

i believe that's it. everything should be fairly starightforward.

i am really tired of counting materials. i bet all other script writers too. so i implemented new syntax for material configs:
instead of:

    MainMaterialConfig := { COPPER, BRONZE, IRON, STEEL, METEORIC_STEEL,
                            MITHRIL, OCTIRON, LEAD, ALUMINIUM, NICKEL,
                            CHROME, STAINLESS_STEEL; }
    MaterialConfigChances := { 25, 150, 50, 10, 5, 1, 1, 150, 75, 25, 1, 5; }

you can use:

    MainMaterialConfigExt := { COPPER:25, BRONZE:150, IRON:50, STEEL:10, METEORIC_STEEL:5,
                              MITHRIL:1, OCTIRON:1, LEAD:150, ALUMINIUM:75, NICKEL:25,
                              CHROME:1, STAINLESS_STEEL:5; }

much better, isn't it?

this is ugly hack in parser, not new database property. but hey, it works.

btw. as we have cleavers now, shouldn't they be used to butcher corpses to lumps of flesh? so we could can those lumps.

saved games are stored in single archive file now. coincidentally, it is the same vwad format which is used for game data. because my library supports creating it, and it is compressed (and the compression is even slightly better than with zip archives; nothing to be proud of, tho).

this is not only handy for savescumming (and don't tell me you've never done that! , but also allows atomic save updates. i.e. the old save will be replaced by the new one only if saving succeeded, and this operation is atomic. this should cause much less broken saves from various game crashes.

fun thing: Kaethos is in his own team (tourist guide). so it is possible to slay whole New Attnam, and still have him friendly, and asking to plant the seedling to free… various lumps of flesh lying around, i guess.

thank you! it's really, really strange indeed. it sure doesn't look like there is something blocking there.

i am working on the new build, and then you'll be able to send me a save. i will delay breaking changes for some time to be able to analyze it. i really don't have a slightest idea, and need to look at the loaded game.

the problem with saves is that they're breaking even on small script changes. i ought to tag the build in version control so i could checkout it, but i forgot. sorry. i'll try to tag it this time.

couldn't sleep properly (irl , and thought: maybe carnivorous plants should eat bodies in adjacent squares too? it doesn't matter much in gameplay sense, but looks more interesting, i believe. often players don't even know that those plants are not simply named "carnivorous".

in case somebody wonder why i'm pushing so much code and ideas… it is horn of plenty… er… i haven't played IVAN for several years (simply had no time), and now i am looking on it with a fresh pair of eyes. and i started noticing quirks i took for granted and got used to. so i am trying to implement as much as possible before running out of steam again.

p.s.: i believe the new test build is on its way. also, is there any way to manage attachments on the forum?