another one IVAN fork

It's a good thing we have so much IVAN development going on that it doesn't really matter if this one is linux-only. Unfortunate for me because I doubt I'll be getting rid of my windoze anytime soon.

Well I'm not working on CLIVAN until the world economy has crashed irrecoverably, united states and europe are nuking each other and I'm nuking the girl next door.

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

I see. Well, good luck then.

Vasily, personally I don't see any harm in discontinuing k8IVAN development for windows. I certainly didn't have other operating systems in mind (other than my own) when I compiled CLIVAN.
I take the view that "no IVAN development is a sad developent", and I encourage you to go as far as you can with progressing the game in whichever medium you feel necessary. I still feel some loss though. Nevertheless, I think your stance as an activist is a valiant one and to be commended.
Please feel welcome to stick around and definitely keep us updated on your progress with development Who knows, I may try set up a dual boot on the work computer.

Yes, I agree entirely with what Warheck said. I actually have a linux dual boot set up already but I don't feel especially inclined to maintain a windows port. Please stick around and keep us posted, as the things you were working on seemed really cool.

Hello, I managed to make current code work on Linux with small changes.

I downloaded last tar.gz from here: http://repo.or.cz/w/k8-i-v-a-n.git

compiled using:

./0build.sh

but on execution it crashed. I changed this lines in game.cpp

1st change:

void game::InitDungeons () {
  Dungeons = *GetGameScript()->GetDungeons()+1;

to:

void game::InitDungeons () {
  Dungeons = 10;

2nd change:

void game::CreateTeams () {
  Teams = *GetGameScript()->GetTeams();

to:

void game::CreateTeams () {
  Teams = 17;

The 10 and 17 come from Script/dungeon.dat and Script/teams.dat

Sound worked nice using Ivan3D soundpack

Hopefully this will be changed on the sources and don't need to be done.

Thanks a lot!!!

Awesome! I always get a little excited when I see a post in the Programming section

Nice job finding the bug xavi2, it seems like it might be an imperfect fix though, i.e. if more teams or dungeons are added you will have to manually update this number instead of grabbing it from somewhere else.

Yes, it's abosulte imperfect, but I wanted to play in Linux, and play it now! and I had no time to do elegant fix because I don't know why was crashing

Haha, fair enough! Yes at least it's quick

Tried also on my 64 bits linux machine and first I couldn't compile.

To solve it I fixed 0build.sh

change this:

cflags="-Wno-narrowing -Isrc/felib"

to this:

cflags="-Wno-narrowing -Isrc/felib -fpermissive"

Then it compiled. It works, saves, ... but crashes on load a saved file. To load correctly just change in proto.cpp this:

void protosystem::LoadCharacterDataBaseFlags(inputfile& SaveFile)
{ 
  for(int c1 = 1; c1 < protocontainer<character>::GetSize(); ++c1)

to this:

void protosystem::LoadCharacterDataBaseFlags(inputfile& SaveFile)
{ 
  for(int c1 = 1; c1 < protocontainer<character>::GetSize() -1; ++c1)

As you can see, only put a -1 after the GetSize()

Sure other things will not work. At the moment I could kill the big plants on UT and have fun!

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

Good to have you back vasiliy!
What operating system are you using for to develop k8-i.v.a.n.? Love your work, steal all you want

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.

Yes please, I've been asking about whether we could do this since about when the fire system was introduced!
It would also have other applications, like emptying acid on a wall or object without needing to break the bottle.

Am I the only guy in the world who plays vanilla?

I feel like modding should be streamlined, in a fashion perhaps similar to Cataclysm DDA.

No, but it's a fact that all the variants are fun even if some of them make the game easier.
As it is, the official build of IVAN that still used ASCII art was considered easier than 0.50!


I can agree with this - efforts are being made to move more of the code into the script files to make it easier to mod, but perhaps very, very far down the line we can look into making a truly modular mod system. At the moment the focus is on just adding more content to vanilla.

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

oops. wrong edit.

I still play .50 vanilla almost exclusively. I like some of whats happening in the current version, but is seems kind of unbalanced right now.

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.

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

Cool! That would be awsome in vanilla.

What about making the material in item name use the material's color?

i thought about coloring matherial name, but with that the list start looking like a freakish rainbow, and defeats the purpose of coloring, 'cause the eye is immediately lost in those colored spans.

the matherial is roughly encoded in icon color, and i think that it is enough to do quick-scan.

p.s.: it is not hard to port that to comm. fork, the relevant patches are:
http://repo.or.cz/k8-i-v-a-n.git/commit/7dd5b3cd1a58cf9f9093...
to
http://repo.or.cz/k8-i-v-a-n.git/commit/9cce8f029224c922c230...