ToME 2.4.0-ah released

[AnonymousHero]

I'm starting to wonder if I shouldn't just provide a Docker container which the correct toolchain pre-setup just for compiling...

[Sky]

Broadly speaking ... what are the differences between TOME 1, 2, 3 and 4?

I played tome 1 and iirc it was similar to angband in style - although it had wilderness, colors, quests - many of the stats, commands, gameplay were similar.

But then i played tome 4 - Tales Of Copyright Infringment - that did away with the tolkien setting and changed pretty much everything.

When did the big change happen? What is the last angband-esque build?? (And where can i find it?)

[wobbly]

Tome 3 doesn't exist. It was Darkgod's 1st attempt at the new engine. He ended up abandoning it and writing T4. The 1st versions of T4 are still middle earth, though that's stretching it. The last version based on angband, you're probably in the thread for it? Not really an expert on Tome.

[Derakon]

ToME 2 is the last Angband-like ToME. This is the thread for the most recent release of that line.

ToME 1 was called PernAngband and got hit by a C&D from Anne McCaffrey's lawyers, so 2 stripped out the Pern references at the same time that it bumped the version number.

[Gwarl]

For apparently no reason at all I managed to build it this time, having done exactly the same thing I did last time.

However, I don't seem to be able to specify the user directory from the command line? I don't remember having this problem before.

[Gwarl]

grabbed the 2.4.0 release and I have the same problem.

looking at main.c I don't see anywhere that the user directory is parsed.

this makes no sense because I swear this worked before.

[AnonymousHero]

grabbed the 2.4.0 release and I have the same problem.

looking at main.c I don't see anywhere that the user directory is parsed.

this makes no sense because I swear this worked before.

Are/were you using the TOME_PATH environment variable, or...?

AFAIR it should still work -- I certainly haven't done anything to remove it or anything like that.

[Gwarl]

In my archive of the old site, in the source folder I have, within a folder labelled tome2-2.3.6-ah a main.c file with the following function:

/*
* Handle a "-d<what>=<path>" option
*
* The "<what>" can be any string starting with the same letter as the
* name of a subdirectory of the "lib" folder (i.e. "i" or "info").
*
* The "<path>" can be any legal path for the given system, and should
* not end in any special path separator (i.e. "/tmp" or "~/.ang-info").
*/
static void change_path(cptr info)
{
cptr s;

/* Find equal sign */
s = strchr(info, '=');

/* Verify equal sign */
if (!s) quit_fmt("Try '-d<what>=<path>' not '-d%s'", info);

/* Analyze */
switch (tolower(info[0]))
{
case 'a':
{
string_free(ANGBAND_DIR_APEX);
ANGBAND_DIR_APEX = string_make(s + 1);
break;
}

case 'f':
{
string_free(ANGBAND_DIR_FILE);
ANGBAND_DIR_FILE = string_make(s + 1);
break;
}

case 'h':
{
string_free(ANGBAND_DIR_HELP);
ANGBAND_DIR_HELP = string_make(s + 1);
break;
}

case 'i':
{
string_free(ANGBAND_DIR_INFO);
ANGBAND_DIR_INFO = string_make(s + 1);
break;
}

case 'u':
{
string_free(ANGBAND_DIR_USER);
ANGBAND_DIR_USER = string_make(s + 1);
break;
}

case 'x':
{
string_free(ANGBAND_DIR_XTRA);
ANGBAND_DIR_XTRA = string_make(s + 1);
break;
}

#ifdef VERIFY_SAVEFILE

case 'b':
case 'd':
case 'e':
case 's':
{
quit_fmt("Restricted option '-d%s'", info);
}

#else /* VERIFY_SAVEFILE */

case 'b':
{
string_free(ANGBAND_DIR_BONE);
ANGBAND_DIR_BONE = string_make(s + 1);
break;
}

case 'd':
{
string_free(ANGBAND_DIR_DATA);
ANGBAND_DIR_DATA = string_make(s + 1);
break;
}

case 'e':
{
string_free(ANGBAND_DIR_EDIT);
ANGBAND_DIR_EDIT = string_make(s + 1);
break;
}

case 's':
{
string_free(ANGBAND_DIR_SAVE);
ANGBAND_DIR_SAVE = string_make(s + 1);
break;
}

#endif /* VERIFY_SAVEFILE */

default:
{
quit_fmt("Bad semantics in '-d%s'", info);
}
}
}

I need this to keep everyone's character dumps and pref files seperate from each other. The only I really need is "case u:", and some variants do indeed collapse the -d switch into just this case (NPPangband is the first example that springs to mind).

The usual purpose of the ANGBAND_PATH variable (still referred to as such in the main.c I apparently used last time) is specifying the lib folder and hence every subfolder not just the user folder. main_real in github's main.cc looks a lot like main in the main.c I have, but comes around 200 lines earlier.

Now I remember, I think I resorted to 2.3.6 before and then forgot that I had done so. That explains why kobold was complaining that there were still traps in the game.

I will need -duser=<path> or at least -d<path> command line switches to host it on live.

[Gwarl]

for reference, this is NPP's far more concise handling of only the switch I need:

/*
* Handle a "-d<what>=<path>" option
*
* The "<what>" can be any string starting with the same letter as the
* name of a subdirectory of the "lib" folder (i.e. "i" or "info").
*
* The "<path>" can be any legal path for the given system, and should
* not end in any special path separator (i.e. "/tmp" or "~/.ang-info").
*/
static void change_path(cptr info)
{
if (!info || !info[0])
quit_fmt("Try '-d<path>'.", info);

string_free(ANGBAND_DIR_USER);
ANGBAND_DIR_USER = string_make(info);
}

He didn't bother to update the comments

[AnonymousHero]

Oh, yes, I see I did actually remove that -- it shouldn't be too much effort to bring it back, though.

Just curious... are you using the GCU/curses frontend or something else to handle the frontend for angband.live?

(I'm doing a... thing to the T2 codebase and if at all possible, I'd like to be able to remove curses. However, if angband.live needs it, then that might convince me to try harder to keep it. Still might get removed, obviously, but...)

[Gwarl]

It is indeed the gcu port, that's my universal point of compatibility for all the variants. It would be a nightmare patching in the code to do anything else for each variant individually.

I have vague plans for some angband-specific javascript version of noteye in the future, which would then also solve graphics for every variant at once.

[AnonymousHero]

It is indeed the gcu port, that's my universal point of compatibility for all the variants. It would be a nightmare patching in the code to do anything else for each variant individually.

Yeah, that was what I was afraid of...

(What I've been experimenting with is basically completely gutting the Term subsystem and going towards supporting only an Allegro5-based frontend -- and hopefully Windows via cross-compilation, but that's a bit further off. The whole UI/keyboard subsystem is so unbelievably hackish and broken... :/ )

I have vague plans for some angband-specific javascript version of noteye in the future, which would then also solve graphics for every variant at once.

I've actually been thinking of just doing away with the native GUI programming wholesale and changing T2 to just be a RESTful server and have a little bit of Javascript in the browser instead. It would be soooo much less painful.

(Just had a look at NotEye and it looks like even more hacks piled on top... it's kind of miraculous that such a monstrosity could even be made to work.)

[t4nk]

Yeah, that was what I was afraid of...

(What I've been experimenting with is basically completely gutting the Term subsystem and going towards supporting only an Allegro5-based frontend -- and hopefully Windows via cross-compilation, but that's a bit further off.

Why gut the Term, though?

The whole UI/keyboard subsystem is so unbelievably hackish and broken... :/ )

IMO, there is nothing wrong with it conceptually. It's just a quality-of-implementation issue.

[AnonymousHero]

Why gut the Term, though?


IMO, there is nothing wrong with it conceptually. It's just a quality-of-implementation issue.

I suppose most things could be argued to be quality-of-implementation, but it's a stretch in the T2 code base, at least. (No idea what you're using as a reference? Perhaps Vanilla...? I haven't actually looked into the vanilla code base, so these might not apply there. I'm guessing that it's at least vastly improved over T2 when the code base was modernized.)

Still, I'd argue that these are design problems:

• The term code has one key queue per term, but requires that the active term be set to the first term (angband_term[0]) when 'interacting' with the keyboard queue, etc. The keyboard queue (singleton) should never have been tied to a term (multiple).
• The handling of the UI event loop (singleton) is intermingled with the handling of each individual term. Again there's some nonsense where the current term must be set to the 0th one.
• Generally speaking the "current term" is horrifically tangled into the code base all over the place. There should never have been such a thing as the "current term". (The concept doesn't really make sense.). This is the one that closest to a QoI issue, but I think it could be argued either way.

(I'm sure there's more that I'm forgetting right now.)

[t4nk]

I suppose most things could be argued to be quality-of-implementation, but it's a stretch in the T2 code base, at least. (No idea what you're using as a reference? Perhaps Vanilla...? I haven't actually looked into the vanilla code base, so these might not apply there. I'm guessing that it's at least vastly improved over T2 when the code base was modernized.)

Vanilla's ui-term.c is the same thing... To my knowledge, I was the only person since Ben Harrison to substantially change this thing The Term is indeed horribly written, but I think its fundamental ideas are sound.

The term code has one key queue per term, but requires that the active term be set to the first term (angband_term[0]) when 'interacting' with the keyboard queue, etc. The keyboard queue (singleton) should never have been tied to a term (multiple).

True, and there is no reason why it must be like that. This is very easy to change, though.

Generally speaking the "current term" is horrifically tangled into the code base all over the place. There should never have been such a thing as the "current term". (The concept doesn't really make sense.). This is the one that closest to a QoI issue, but I think it could be argued either way.

I'm not familiar with Allegro, but a quick look at the documentation suggests the standard pattern:

void al_set_target_bitmap(ALLEGRO_BITMAP *bitmap);

"This function selects the bitmap to which all subsequent drawing operations in the calling thread will draw to. To return to drawing to a display, set the backbuffer of the display as the target bitmap, using al_get_backbuffer. As a convenience, you may also use al_set_target_backbuffer."
That's how it's done in low level APIs (OpenGL, DirectX). Of course, it's not the only possible way of doing things, but it's pretty standard and it doesn't seem overly crazy to me.

When working on textui2, I came to the conclusion that it's useful to divide the Terms into two kinds; permanent (map, messages, sidebar, monster list) and temporary (inventory, options, knowledge menu - the stuff that goes away when the user presses ESC). Organizing temporary terms as a stack, with the top of the stack being the current target of rendering operations, is very convenient (and there were no problems with using this architecture while writing ncurses frontend). OTOH, permanent terms don't need to be on the stack.

I'm actually (very slowly) writing an Angband-insired roguelike (in D ). So I've been thinking quite a bit about the architecture of the IO subsistem lately. The Term as an ADT (a two dimensional array of colored characters that keeps track of their updates since the last render) is surely worth keeping, and so is the stack of Terms. Anyway, hopefully you'll proceed with your ideas - I'm adding your TOME repo to bookmarks