Variant Project

[Pete Mack]

Jeff--
it doesn't have to be permanent, it just has to follow some reasonable API.
Nick made a whack at it with buttons and small displays, I made a whack at it with menus and reworked knowledge menus, tak made a whack at it with cleaned up timed effects and flags, and ajps made a whack at it with the new command function pointers (cmd0.c and game-cmd.c is a huge step in the right direction).
Since then, others have done similar things (I've been a bit out of the loop, but d_m and marble dice have done a lot of work.)

All together, these form at least a small part of a usable API.

[AnonymousHero]

That's exactly what I was talking about (at a more abstract level).

It's been a while since I looked at the Vanilla source, but I have a hard time imagining that most of the "terminal emulation" that's going on in Angband couldn't be extracted into a reasonably simple "external" library. It basically just needs to provide a way to put colored characters (or tiles!) at (X,Y) assuming a monospace font. Almost all the complexity can be hidden behind such a simple API.

Yes, there's some slightly nontrivial bits having having to do with resizing, small screens, etc. but I don't see them as insurmountable obstacles.

The key thing is to start small; export a single well-defined subsystem: Start with just the simple "draw a character (or tile)" and on top of that you might be able to build a subsystem for most of the remaining UI.

[Nick]

Unfortunately, I think in the end the only way for a variant to stay constant with Vanilla is for the maintainers to update their code base every time Vanilla udpates.

I have certainly thought this way in the past (and, who knows, may again in the future). On the whole, though, I think that making an API that is fairly stable and that all variants can use is feasible.

There will be cases (like your extended characters) where the appropriate thing to do is change the API rather than your variant. This is certainly a change, and isn't simple to do, but I think it's worth it on the whole.

@AnonymousHero - yes.

[nppangband]

I have certainly thought this way in the past (and, who knows, may again in the future). On the whole, though, I think that making an API that is fairly stable and that all variants can use is feasible.

There will be cases (like your extended characters) where the appropriate thing to do is change the API rather than your variant. This is certainly a change, and isn't simple to do, but I think it's worth it on the whole.

OK, I see. I was thinking the variants would have to conform to the API, not the other way around.

The extended characters are definitely broken with the new Angband code. That is next on my list after I get the NPP stores to work with the new UI(they offer quests and services in addition to items). The other thing with the extended characters is they use their own set of fonts instead of the standard Angband fonts. Unfortunately I can't find a copy of the original extended character patch, which would make finding the problem much simpler. Did anyone by chance download a copy?

The only thing I have had to add to the core files (util, all the files that start with "z-") are a couple simple functions where it doesn't like having have to use standard C file functions with files declared as ang_file rather than simple FILE. Examples are:

void file_flush(ang_file *f)
{
fflush(f->fh);

return;
}

void file_putc(byte v, ang_file *f)
{
putc(v, f->fh);

return;
}

byte file_getc(ang_file *f)
{
byte v = getc(f->fh);

return (v);
}

[Nick]

OK, as a first attempt for discussion, I'd suggest the following things from Vanilla:

• All the z-* files
• All the main-xxx files and Makefiles (except Makefile.src) and the build system
• All the port-specific subfolders
• ui.*, ui-event.*, ui-menu.* and most of ui-birth.*
• pathfind.c, button.c, target.c
• game-event.*, game-cmd.*, bits of cmd0.c
• Bits of other files including init*.c, cave.c (the vinfo stuff)

Added to that I would like to see (YMMV) the xchar support from NPP, double and triple tile support from Un, complete mouse/button support (and maybe new character screen) from FA.

So, what to do first? Set up a repository with this stuff in it? Or something else?

[Nick]

OK, I see. I was thinking the variants would have to conform to the API, not the other way around.

It would go both ways a bit, I guess.

The extended characters are definitely broken with the new Angband code. That is next on my list after I get the NPP stores to work with the new UI(they offer quests and services in addition to items). The other thing with the extended characters is they use their own set of fonts instead of the standard Angband fonts. Unfortunately I can't find a copy of the original extended character patch, which would make finding the problem much simpler. Did anyone by chance download a copy?

I copied from NPP I have got a different set of fonts in FA - I'm not sure if that helps.

The only thing I have had to add to the core files (util, all the files that start with "z-") are a couple simple functions where it doesn't like having have to use standard C file functions with files declared as ang_file rather than simple FILE.

Yeah, I've done a little of this sort of thing too - largely for the WinCE port. One of the big possible wins here is having all the platforms available to everybody.

[Nick]

Even in Subversion there's a way to have an "external project folder" inside of your project that actually updates from somewhere else (and theoretically can commit back there if you want). I've seen this used before.

You might also want to check out Mercurial or Git--it would be easier for different variants to share patches and code that way (and also easier to maintain patches or branches). Takkaria has said he wants to move V to Mercurial (which I like), and Magnate (and others on IRC) like and use Git, so you should be able to get help with whichever.

I've just found this tool for dealing with multiple version control systems, which may be worth a look.

[camlost]

FWIW, I think this (in general) is a good idea. As a (interim) variant maintainer, I'd rather deal with balance and content rather than chasing UI improvements. I'd vote for something more like C++; dealing with bit-masks is annoying, even if trivial.

[Nick]

OK, as a first attempt for discussion, I'd suggest the following things from Vanilla:

• All the z-* files
• All the main-xxx files and Makefiles (except Makefile.src) and the build system
• All the port-specific subfolders
• ui.*, ui-event.*, ui-menu.* and most of ui-birth.*
• pathfind.c, button.c, target.c
• game-event.*, game-cmd.*, bits of cmd0.c
• Bits of other files including init*.c, cave.c (the vinfo stuff)

http://github.com/NickMcConnell/AngbandBase is now a repository containing the above files.

My next step is going to be to move FAangband to using these, which will involve some changes to said files and many changes to FA

Anyone else that wishes to become involved just needs to set up an account at github.com (I believe you need to give them an ssh key), and let me know and I will add you as a collaborator. This just about exhausts my knowledge git and github.

And if anyone's wondering why github...

EDIT: Due to my vagueness, the files are as at r1973.

[Magnate]

http://github.com/NickMcConnell/AngbandBase is now a repository containing the above files.

My next step is going to be to move FAangband to using these, which will involve some changes to said files and many changes to FA

Anyone else that wishes to become involved just needs to set up an account at github.com (I believe you need to give them an ssh key), and let me know and I will add you as a collaborator. This just about exhausts my knowledge git and github.

And if anyone's wondering why github...

EDIT: Due to my vagueness, the files are as at r1973.

Hey Nick, just wanted to say well done setting this up - I'll register as soon as I can. If you can get Takk to use this as the base for this part of the V codebase, so much the better - it'll stay (more) up to date. Means a bit more work for him linking into his hg repo or whatever he sets up, but might be worth it.

[Nick]

If you can get Takk to use this as the base for this part of the V codebase, so much the better - it'll stay (more) up to date. Means a bit more work for him linking into his hg repo or whatever he sets up, but might be worth it.

We'll see. I just wanted to get something in place, and it can all be changed later if it's not working.

[andrewdoull]

ajps made a whack at it with the new command function pointers (cmd0.c and game-cmd.c is a huge step in the right direction).

I'm not convinced that the command function pointers were abstracted at the right level - or more correctly, I think there's a huge opportunity to be had with a slightly different abstraction where the commands which select an object are a(nother?) set of function pointers.

In particular, transitive commands (apply x to y) are handled as two separate commands in the Unangband system, and it allowed an incredibly easy implementation of 'pick an object and choose which command to apply to it' which may be useful for various UI implementations.

Andrew

[Nick]

Progress:

• Decided init*.c are too specific, and removed them.
• Renamed cmd0.c to ui-cmd.c and marked most of it for removal.
• Renamed (by sticking a ui- on the front of) pathfind.c, button.c, target.c.
• Renamed cave.c to ui-view.c, with the intention of ripping everything but the update_view stuff out of it.

I'm not sure about the last one - maybe none of that should be in, or maybe more should. Also there's some specific terrain mentioned in the pathfinding, which will need to be replaced by a reference to a (variant-specific) list.

The idea is that exactly the src directory files from V with names starting with ui, game, main and z will be in AngbandBase. I guess I'm kind of assuming that takkaria etc are OK with some file splitting and renaming too - if we're tying to keep the two aligned, which seems like a good idea if it's easy enough.

[Magnate]

Decided init*.c are too specific, and removed them.

Interesting. I'd have thought that standardised cross-platform code for reading edit files was a big win.

The idea is that exactly the src directory files from V with names starting with ui, game, main and z will be in AngbandBase. I guess I'm kind of assuming that takkaria etc are OK with some file splitting and renaming too - if we're tying to keep the two aligned, which seems like a good idea if it's easy enough.

It's fine with me. Haven't heard from Takk for a few weeks but don't suppose he will mind. I'll update the filenames after checking with him. (Though it might be better for him to give you commit access and cut out the middle man.)

[Nick]

Interesting. I'd have thought that standardised cross-platform code for reading edit files was a big win.

It would be, except for the differences in edit files. There are some cases (the cmd0.c list of commands is another) where there will be few differences, but enough that the file can't be used.

It's fine with me. Haven't heard from Takk for a few weeks but don't suppose he will mind. I'll update the filenames after checking with him. (Though it might be better for him to give you commit access and cut out the middle man.)

I already have commit access, so I can do the dirty work once we have the OK.