AngbandBase

[Nick]

The most significant is a code refactor which separates OBJ from MAINOBJ, which means that all the game code gets linked separately from all the UI code. To my amateur mind this seems like a crucial distinction for AngbandBase, so perhaps Nick will want to rebase AngbandBase from this one day.

I should think so. I am hoping that about mid-October I might be starting to actually work on this stuff again - I am going to be away from home (UK, in fact) but hopefully not completely AFK for a couple of weeks soon.

[Nick]

OK, I've spent some time in the last couple of days working out what needs to be done; here are some thoughts:

• The main* files, the z-* files, the Makefiles (apart from Makefile.src), and the doc, gtk, nds, osx and win directories are no-brainers to go in;
• Ditto for snd-sdl.c, game-event.*, ui.*, ui-menu.*, textui.h, h-basic.h, prefs.c, button.c, signals.c and ui-event.h, and probably util.c.
• It would be nice to have game-cmd.* and cmd0.c in in some form, but they have lists of commands specific to V which would need to be included from elsewhere, or something - similarly for ui-birth.* and birth.c;
• Tempting as it is, target.c, pathfind.c, death.c, and similar can't really go in.

I have kind of started afresh by forking current V from takkaria's github. This will mean (in theory) that I can stay in sync with V, while adding, amending and renaming stuff where necessary, and then just copy the relevant bits to the AngbandBase repo.

Once it is finished, the plan is to keep V and ABase aligned, so that any change to V will be made (by me, or preferably the relevant V developer...) to AngbandBase if necessary as well.

This only becomes really difficult when there's something like a complete re-write of pref file handling, but we can cross that bridge when we come to it.

Any comments on the above from people who know the relevant bits of code would be greatly appreciated.

[Nick]

Update - I have a list of src files, categorised by how they relate to AngbandBase. I'm planning to do a guide for maintainers at some point, too.

The list can be found here.

[Magnate]

Update - I have a list of src files, categorised by how they relate to AngbandBase. I'm planning to do a guide for maintainers at some point, too.

The list can be found here.

Sadly I know very little about angband UI so I'm really a supporter more in principle than in practice. Will have a look at the article when I'm caught up on Oook (just got back from hols, with no fewer than 16 deaths in comp 93 ...!).

I do know a bit about project management though, and I'm trying to come up with a systematic way to advance the authoritative dev versions of V now that so much stuff is going on on github. Most of the discussion will probably take place on #angband-dev so pls do drop in if you can - I'd quite like to make sure that V's developments are helpful to AngbandBase where possible.

[Nick]

Just in case anyone thought they understood what's going on with this, I've moved the goalposts again.

I now believe that the easiest way to host AngbandBase is to have it as a branch of Vanilla at github. It can be found here.

The major advantage of this is that it's very easy to keep it up to date (although a little effort is required when V filenames change). In fact, the other people who can push to the official git repository can now update it...

[Magnate]

In fact, the other people who can push to the official git repository can now update it...

Are you sure you wanted that ...?

But seriously, I think this is a good move. It will make the gradual adoption by V that much easier.

[Nick]

All right.

After several attempts, it has become obvious to me that the business of git updating AngbandBase from the Vanilla master (ie git merge official/master) is always going to leave a whole bunch of conflicts that need manual resolution. I'm sick of doing that, and I don't think it's actually a great idea for any variant maintainer who might actually use AngbandBase.

So the strategy now is

1. Merge in the latest VERSION changes to AngbandBase (most recently, 3.2.0);
2. Resolve resulting conflicts;
3. Wait for the NEXT VERSION.

AngbandBase is thus the low level code of the most recent officially released version. It will only update at version changes of V, which means greater stability for variant maintainers.

Next move is to get FA and O onto AngbandBase (which sounds OK if you say it quickly), and then write a guide to other maintainers for how to use AngbandBase. For the brave, it's ready to go now

[Nick]

For the brave, it's ready to go now

Well, kind of.

Up until now, I've been going on the idea that AngbandBase should be a collection of low-level files on which a variant can be built unchanged. But there are also some files (the things in src/osx, src/win, etc, for example) which can be imported almost unchanged.

Question is, should these ones be left out completely and referred to in the maintainer's guide, or included in some form with some sort of instructions on how to modify them? I can't see an obviously better choice, and would be delighted to hear opinions.

[Sirridan]

Question is, should these ones be left out completely and referred to in the maintainer's guide, or included in some form with some sort of instructions on how to modify them? I can't see an obviously better choice, and would be delighted to hear opinions.

Definitely they need referring at least, and I'd say include some for example's sake. Maybe get someone to write a script of some kind which can help automatically generate these types of files? I mean for the .rc files for windows, that should be pretty easy.

[Magnate]

Definitely they need referring at least, and I'd say include some for example's sake. Maybe get someone to write a script of some kind which can help automatically generate these types of files? I mean for the .rc files for windows, that should be pretty easy.

I think the platform-specific stuff should be included, because takk's intention is to separate it from the game code eventually, which should make it easier to incorporate unchanged over time.

[EpicMan]

It sounds like AngbandBase and Angband 4.0 are heading in parallel directions. Not to tell you what to do, which is to say that I am :-), but wouldn't your efforts be more productively spent working with Takk on the Angband 4 code, then altering FA/O to work with the new code base?

Maybe there are reasons not to do that (if only that y'all's timelines are very different) but it looks to me like you are going to a lot of work and then will have to do a whole lot more work when Tak's new architecture comes about.

Anyway, don't feel the need to explain or defend your approach, I just wanted to offer food for thought.

[Nick]

There is now a guide to the Angband source code for variant maintainers (and anyone else who's interested) on the trac wiki.

Comments welcome.

[CJNyfalt]

I have always wanted to see something like this done, and have in the past made a couple of failed tries, so I am excited that someone else has picked up the torch.

I hope some day this will become a real C library used by vanilla and several variants.

[Nick]

I have always wanted to see something like this done, and have in the past made a couple of failed tries, so I am excited that someone else has picked up the torch.

Your anglib was one of the things that inspired me to try and do this.

I hope some day this will become a real C library used by vanilla and several variants.

Yeah, eventually. Even the low level code for V is changing really fast at the moment (UTF-8 support is currently on the way in, for example), and according to takkaria everything will break before too long anyway, so this is really in a holding pattern for now. Still, I don't think any variant maintainer updating to the current V code will be wasting their time (or no more than usual, anyway ).

[Zireael]

Does AngbandBase still exist or is it my browser which throws an error (I've noticed it doesn't agree with git)?