AngbandBase

[Nick]

While we see if this is going to be a viable idea I thought it would be worth having a thread to dump everything into.

The idea in brief is to have the code for file-handling, display, UI etc separated out from the code for the game proper (where game can mean Vanilla or a variant). AngbandBase should contain all the code that there would be no reason for a variant maintainer not to want.

As I see it, the two big advantages are easier UI maintenance, and portability to more platforms for everyone; the main disadvantage is just getting it organised and keeping it organised.

There are some tricky issues at the boundaries of what to include and what to exclude (targeting, pathfinding and menus among them).

The AngbandBase repository is currently here. Anyone who wishes to contribute will be welcomed with open arms; they just need to make an account at github and let me know what it is, and I'll add them as a collaborator. I'm thinking of this repository as a community thing - it's under my name for convenience only.

[Nick]

Answering Jeff from another thread:

I am happy to help with implementing x-char.

Nick - I just posted another version of NPP, aptly titled:

http://download.nppangband.org/npp-0.5.1-src-buggy.zip

But the x-char features are no longer buggy, and it works with what is essentially the Angband v3.1.2v2 beta source. I have already done all the conversion and de-bugging, and I am happy to help out adding this to vanilla. No need for somebody else to re-invent the wheel.

This is excellent. I see two obvious options:

1. Change the AngbandBase repository yourself; that would involve making a github account and learning a little git
2. Let me to do it (which will happen at some point, when I decide to do some actual dev work instead of just sniping on the forum).

I'm fine with either.

[andrewdoull]

(when I decide to do some actual dev work instead of just sniping on the forum).

I'm happy to cover the sniping while you develop.

Andrew

[nppangband]

I can do that. I am close to finishing de-bugging the changes for NPP 0.5.1. I think it should be playtested a little bit before I put it into Vanilla, just to make sure I didn't miss anything, and to make sure it works on all operating systems. I can only test windows.

[Magnate]

I can do that. I am close to finishing de-bugging the changes for NPP 0.5.1. I think it should be playtested a little bit before I put it into Vanilla, just to make sure I didn't miss anything, and to make sure it works on all operating systems. I can only test windows.

Let me know when you've committed it - I'm happy to test it on Linux.

[Pete Mack]

@Nick
I just took a look at your code; ui-cmd.c won't compile as written.
You need to move the #if 0 stuff so that the menu names aren't commented out.
Eg:

/* Item use commands */static command_type cmd_item_use[] ={
#if 0
{ "Read a scroll", 'r', CMD_NULL, textui_cmd_read_scroll },
{ "Quaff a potion", 'q', CMD_NULL, textui_cmd_quaff_potion }, { "Use a staff", 'u', CMD_NULL, textui_cmd_use_staff },
{ "Aim a wand", 'a', CMD_NULL, textui_cmd_aim_wand },
{ "Zap a rod", 'z', CMD_NULL, textui_cmd_zap_rod },
{ "Activate an object", 'A', CMD_NULL, textui_cmd_activate },
{ "Eat some food", 'E', CMD_NULL, textui_cmd_eat_food },
{ "Fuel your light source", 'F', CMD_NULL, textui_cmd_refill },
{ "Fire your missile weapon", 'f', CMD_NULL, textui_cmd_fire },
{ "Fire at nearest target", 'h', CMD_NULL, textui_cmd_fire_at_nearest },
{ "Throw an item", 'v', CMD_NULL, textui_cmd_throw }
#endif
};

[Nick]

I just took a look at your code; ui-cmd.c won't compile as written.

I wasn't intending the code to compile by itself, just to be a set of files common across variants, although there is always the possibility of making it into a proper library. It's early days yet.

[Nick]

It seems to me that variants can be roughly divided into two categories - maintained, and not (with some grey areas).

Current maintainers can obviously choose whether to use AngbandBase or not.

One of the reasons I started this whole thing was because I have been 'maintaining' O (in the sense of updating the UI and squashing bugs), and was thinking of doing the same for Pos, but wanted the process a bit streamlined.

So my plan, then, is to put up individual repositories for unmaintained variants. Some of these I will update to AngbandBase (O, then Pos if I'm feeling energetic, then who knows?). If anyone wants to contribute to the modification of a variant, let me know and I will enable it.

[Twilight]

[SNIP]So my plan, then, is to put up individual repositories for unmaintained variants. Some of these I will update to AngbandBase (O, then Pos if I'm feeling energetic, then who knows?). If anyone wants to contribute to the modification of a variant, let me know and I will enable it.

I quite liked Pos ... at least as a novelty, the few times I played it. I think there was a competition 4-5 years back that got me into it. IIRC it was in an alpha(ish) state, but I may be far off track. Anyway, it would be nice to see it maintained in some form.

[ramela]

I liked pos because the Qs and Dragons give such a different playing experience from "normal" *bands, with the wildly different equipment slots.

The reason I went with Pos over Drangband was the quests.

I remember Drangband having a pretty murderous AI, though. I wonder if that was just me being inexperienced...

[Magnate]

While we see if this is going to be a viable idea I thought it would be worth having a thread to dump everything into.

The idea in brief is to have the code for file-handling, display, UI etc separated out from the code for the game proper (where game can mean Vanilla or a variant). AngbandBase should contain all the code that there would be no reason for a variant maintainer not to want.

As I see it, the two big advantages are easier UI maintenance, and portability to more platforms for everyone; the main disadvantage is just getting it organised and keeping it organised.

There are some tricky issues at the boundaries of what to include and what to exclude (targeting, pathfinding and menus among them).

The AngbandBase repository is currently here. Anyone who wishes to contribute will be welcomed with open arms; they just need to make an account at github and let me know what it is, and I'll add them as a collaborator. I'm thinking of this repository as a community thing - it's under my name for convenience only.

Nick,

Just wondering how this was going. There was some discussion on IRC and I thought it might be worth asking here: how does one build V from this?

#1. Clone the angband-base git repo to get the core files.

#2. Checkout the latest V from svn (or download a tarball, or whatever).

#3 ...? Presumably the ideal would be that you copy the angband-base files over into your local V source tree and it Just Works when you type "make"...

Is there more to it than this? If this were to work, one could develop for V and check relevant changes back in to angband-base ...

[Nick]

#1. Clone the angband-base git repo to get the core files.

#2. Checkout the latest V from svn (or download a tarball, or whatever).

#3 ...? Presumably the ideal would be that you copy the angband-base files over into your local V source tree and it Just Works when you type "make"...

Is there more to it than this? If this were to work, one could develop for V and check relevant changes back in to angband-base ...

Yes, this is pretty much how I was planning for it to work.

As for how it's going, currently not at all - RL has currently been absorbing all the time I usually put into *bands (and more). I'm hoping to get back into it all some time in the next couple of months, but that's a hope rather than a promise.

And while I'm here, apologies for the lack of competition at the moment. I'll try to get one up this weekend.

[camlost]

There are some tricky issues at the boundaries of what to include and what to exclude (targeting, pathfinding and menus among them).

Handling boundary cases seems pretty simple. A few defines and a few lines of code at the beginning of each function that has potential to be non-standard can redirect the function elsewhere to be handled.

The defines can live in the variant directory.

[Magnate]

Yes, this is pretty much how I was planning for it to work.

As for how it's going, currently not at all - RL has currently been absorbing all the time I usually put into *bands (and more). I'm hoping to get back into it all some time in the next couple of months, but that's a hope rather than a promise.

And while I'm here, apologies for the lack of competition at the moment. I'll try to get one up this weekend.

No probs - I too have been AFK a lot recently. Hope all is well chez vous.

[Magnate]

Well, it looks like some significant changes are coming to the V codebase - see http://github.com/elly/angband if interested. 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. But when is an interesting question, as it has not yet percolated back into trunk - I would have been confident that it would do so before 3.1.3, but Takkaria has just resurfaced (see http://trac.rephial.org/ticket/1193), and when he does he usually makes a release quickly before he disappears again ... lots of excitement ...