Help me update PosBand!

[pampl]

I like running around as a monster in Posband but I also like all the improvements that have been done to Angband in the last few years. I've taken it upon myself to try to create the best of both worlds, by porting/recreating Pos using the latest 3.2 RC. I've gotten some minor-medium features done, but I'm coming to the limits of my abilities as a programmer, and that's where you, the reader, come in. Help me! Specifically, help me figure out relatively straightforward ways of checking features off my to-do list.

So far I've got done (largely thanks to Nick's invaluable help):
*Several monster races are selectable, and they're automatically assigned the dummy class "monster" (the UI for this stinks though)
*Monsters gain AC and speed as they level, depending on what race they are
*When monsters reach a certain level (dependent on race) they "evolve" into a stronger race, e.g. when a 2 headed hydra reaches level 8 it grows a third head.
*Players display as the monster they are - instead of running around as an @ symbol you can be, for example, a dark brown M (and later an orange M!).
*Monsters start with a nifty item, race dependent, to make up for not having a class or something.

What I need to do before I consider this beta status:
*Monsters need to have variable numbers of EQ slots - Hydrae can't wield weapons but can wear multiple helmets and amulets, for example. I've already tried to do this once and aborted partway through it.
*Monsters need to be able to use monstrous powers, such as breathing elements.
*Monsters need to use the same set of melee attacks that their non-adventurer brethren use; e.g. a chaos drake should claw/claw/bite to confuse regardless of whether it's a "real" chaos drake or a player chaos drake. This is what I'm working on right now.

Long run goals:
*Players should be able to summon friendly monsters. Pretty hard to play as a Q without summoning..
*Questing needs to be added. This should be some straightforward cut and paste action.
*There should be "King" monsters, with lots of special rules that I don't really know (maybe someone who's been more successful at Pos could tell me about them)
*There should be special terrain and terrain modifying spells.. this is also probably just cutting and pasting.
*I guess I should try to implement possessors at some point, though it's going to be pretty hard with the way I'm doing things. I'll probably just make it a class, and give it a special ability that lets it change its race into a spirit then into the race of a corpse it's standing over.
*Monsters should have affinity for law or chaos and get in brawls over it.. the code needed for player monster melee and summoning should make this easy.
*There should be invisibility and monster blindness. I'm guessing this won't be too hard, but it's really far down the priority list anyway.

Right now I'm working on monster melee (the third TODO item above) and I'm handling it by making make_attack_normal (from monster/melee1.c) able to target an arbitrary map square instead of always targeting the player. I'll just have the player call it when he's unarmed and his race is a monster. It's a roundabout way of doing it, but I need monsters able to attack each other anyway for when I do summoning. Does this make sense?

[buzzkill]

Your grand plan sounds good. Good luck with it. Unfortunately mildly humorous criticism is all I have to offer.

*Players should be able to summon friendly monsters. Pretty hard to play as a Q without summoning..

I think it would be pretty hard to play regardless. What do you do, just teleport about until you land on an item or a staircase.

[kingvictory2003]

OMG so can a 12-headed hydra wear 12 helmets and 12 amulets??? I'm game!

[topazg]

One thing I will say is there is a lot of aspects of Pos that have already left V, and it may be easier to take the Pos code (which handles equipment slot changes, amongst other things) and update it to match the latest changes in V. IIRC, 4GAI and some advanced randart code are already implemented, and many of the fun Pos unique things (like each monster race having a "king" who drops the "race artifact") are kinda fun and probably a lot of effort to replicate from scratch.

If you'd like, you are very welcome to take the code-base and be the primary maintainer of the variant itself

[pampl]

I think it would be pretty hard to play regardless. What do you do, just teleport about until you land on an item or a staircase.

Original Pos assumed that players Q's had particularly limber psuedopods and were able to shuffle around, albeit at speed -5. Death Molds in ToME play like you imagine though. I couldn't tell you how well it works; they were too weird for me to try.

OMG so can a 12-headed hydra wear 12 helmets and 12 amulets??? I'm game!

I'd be willing to try that at least. Twelve helmets doesn't sound particularly overpowering, just because there are only about 3 really good helmets, but 12 amulets might be a bit much. The key thing is that hydras are sort of like warriors who can't use bows but have some ranged attack spells - would a warrior be overpowered if e.g. they could get +120/+120 (from 12 amulets of weapon mastery)? My attitude is wait and see. The bigger danger might be all the amulets with activations saving them from having to carry around a half dozen rods.

One thing I will say is there is a lot of aspects of Pos that have already left V, and it may be easier to take the Pos code (which handles equipment slot changes, amongst other things) and update it to match the latest changes in V. IIRC, 4GAI and some advanced randart code are already implemented, and many of the fun Pos unique things (like each monster race having a "king" who drops the "race artifact") are kinda fun and probably a lot of effort to replicate from scratch.

If you'd like, you are very welcome to take the code-base and be the primary maintainer of the variant itself

Now that I think about it you're almost certainly right about it being easier. The thing is, the Posband features I want V to have are very clear in my mind, but the V features I want Pos to have are a vague collection of a million little things. The way I'm doing it now is harder (possibly much harder) but also more straightforward.

On the other hand, it may be so much harder that it's beyond my ability.. and starting with a working, fully functional Posband means any work I get done on it is gravy, compared to all the work that would go into getting back to square one starting with V. So, I dunno. I'll have to look at Pos' code some more and think about it.

Are you the Pos maintainer? If so, congrats on such a cool variant!

[Adley]

OMG so can a 12-headed hydra wear 12 helmets and 12 amulets??? I'm game!

IIRC Pos just changes the items you can wear in a certain slot, not the number of slots. Which is explainable due to interactions between items making you unable to wear (with profit) more than the normal number of things.

[buzzkill]

I'd be willing to try that at least. Twelve helmets doesn't sound particularly overpowering, just because there are only about 3 really good helmets, but 12 amulets might be a bit much. The key thing is that hydras are sort of like warriors who can't use bows but have some ranged attack spells - would a warrior be overpowered if e.g. they could get +120/+120 (from 12 amulets of weapon mastery)? My attitude is wait and see. The bigger danger might be all the amulets with activations saving them from having to carry around a half dozen rods.

Well, you wouldn't always have 12 heads would you? Aren't hydras essentially killed by chopping off their heads one by one. The way I see it, over the course of a nasty battle, you may lose a few or even most of your heads and the amulets and helmets too, wouldn't they fall to the ground. Let's hope that none of your critical resists are lost in the process. You may want to wield 2x or 3x resists JIC. Could also lead to severe pack clutter upon a narrow survival. I'm guessing it takes a fairly long time to regenerate a head .

This variant sounds cooler with every passing moment.

[Nick]

Now that I think about it you're almost certainly right about it being easier. The thing is, the Posband features I want V to have are very clear in my mind, but the V features I want Pos to have are a vague collection of a million little things. The way I'm doing it now is harder (possibly much harder) but also more straightforward.

I see your point, although I had planned to do it the other way around.

Whichever way you decide to go, I suggest you

1. Look at the src/powers*.inc files - most of the monster power stuff is done there and
2. Do a diff between Pos and the version of NPP it forked from (which I believe was originally 0.3.1, updated to 0.3.4, and had some bugfixes from 0.4.0) - this should give a good idea of what needs to be added.

I would also suggest posting your code publicly somewhere (github is currently the most popular, but wherever), so others can comment and potentially (if you want to let them!) contribute.

[pampl]

Well, you wouldn't always have 12 heads would you? Aren't hydras essentially killed by chopping off their heads one by one. The way I see it, over the course of a nasty battle, you may lose a few or even most of your heads and the amulets and helmets too, wouldn't they fall to the ground. Let's hope that none of your critical resists are lost in the process. You may want to wield 2x or 3x resists JIC. Could also lead to severe pack clutter upon a narrow survival. I'm guessing it takes a fairly long time to regenerate a head .

This variant sounds cooler with every passing moment.

I don't want to disappoint you but I don't think I'm going to implement decapitation soon, if only because it's still beyond my ability. If this were Dungeon Crawl I'd know how to handle hydrae losing heads and slots being rendered unusable but alas..

I see your point, although I had planned to do it the other way around.

Whichever way you decide to go, I suggest you

1. Look at the src/powers*.inc files - most of the monster power stuff is done there and
2. Do a diff between Pos and the version of NPP it forked from (which I believe was originally 0.3.1, updated to 0.3.4, and had some bugfixes from 0.4.0) - this should give a good idea of what needs to be added.

I would also suggest posting your code publicly somewhere (github is currently the most popular, but wherever), so others can comment and potentially (if you want to let them!) contribute.

Thanks for the advice! Learning to use more of git's power was interesting.

https://github.com/simongre/RePosBand

I think it should be viewable by anyone now. The committed version will even compile and can be played, though you still won't feel very monstrous.

[pampl]

I got monster melee working, knock on wood. If I can do monster powers with the rest of the week (not unreasonable; it looks like it won't be too bad) then I'd have a full week to do slots in order to have a beta ready in time for New Year's. 'Course, there will be shiny distracting Christmas presents to consider, plus I don't want to burn myself out by working too fast..

Gameplay question: how should I handle players evolving into a form that requires more XP to gain levels? Right now the way it works is they stay their current level until they gain XP, then their level is recalculated and lowered. This is less than ideal. Should they immediately have their level lowered upon evolving, or not have it lowered at all (even though they technically have less XP than necessary to reach their current level)? And, lazy coding question, if the answer is "instantly lowered" what function should I be calling to recalc their level right when they evolve?

This is sort of a minor issue because in Pos the exp factor didn't actually change between forms as you evolve so I mostly won't make it change drastically either, but I'm curious what you guys think.

[AnonymousHero]

I'd treat it as (essentially) permanent EXP drain. So 1) your EXP is drained to the appropriate value for your new form, and 2) you can never devolve. I think that should cover it.

[pampl]

I'd treat it as (essentially) permanent EXP drain. So 1) your EXP is drained to the appropriate value for your new form, and 2) you can never devolve. I think that should cover it.

Nitpicking: their XP isn't reduced, it's just that XP needed to reach their current level increases, and can possibly increase to more XP than they have. But I get what you mean. Should their new level be displayed as yellow, as if it were drained? That's how it works now (I guess it's a simple test if max level > current level) but it might mislead people into trying !Restore Life Levels.

Does anyone know how to stop V from throwing up the following warnings? My term window only has so many lines and I need to use all of them for my new errors.

cmd0.c: At top level:
cmd0.c:119: warning: missing initializer
cmd0.c:119: warning: (near initialization for 'cmd_action[0].prereq')
cmd0.c:120: warning: missing initializer
cmd0.c:120: warning: (near initialization for 'cmd_action[1].prereq')
cmd0.c:121: warning: missing initializer
cmd0.c:121: warning: (near initialization for 'cmd_action[2].prereq')
cmd0.c:122: warning: missing initializer
cmd0.c:122: warning: (near initialization for 'cmd_action[3].prereq')

etc.

[Derakon]

If you're going to have different XP rates for different races, but allow the player to switch between races at will, then IMO the only way to handle this that makes sense is to recalculate their level when they change race. You don't need to display anything differently, though you should probably provide a message when the player levels up/down. "Your experience is not sufficient for level X in this form", say.

[pampl]

If you're going to have different XP rates for different races, but allow the player to switch between races at will, then IMO the only way to handle this that makes sense is to recalculate their level when they change race. You don't need to display anything differently, though you should probably provide a message when the player levels up/down. "Your experience is not sufficient for level X in this form", say.

I should have explained better beforehand: it's not at will, it's only at a set level. E.G. when a Hydra reaches level 8, it grows a third head.. possibly dropping it down to level 7 or lower, if the 3-headed form requires enough extra XP per level. Like AnonymousHero said, it won't trigger devolution (that would create an infinite loop). Your message idea is good though; as it stands it doesn't even tell the player their level has been reduced, let alone why.

Another coding question, this one more pressing than just cleaning up some warnings: can a parser guru tell me why the following code results in a parser error: unknown directive?

/* Parse the new monster power info -Simon */
static enum parser_error parse_p_p(struct parser *p) {
	struct player_race *r = parser_priv(p);
	struct racial_power *rp = mem_zalloc(sizeof *rp);
	int i = 0;
	if (!r)
		return PARSE_ERROR_MISSING_RECORD_HEADER;
	if (!parser_hasval(p, "lvl"))
		return PARSE_ERROR_NONE;
	rp->level = parser_getint(p, "lvl");
	rp->sp = parser_getint(p, "cost");
	rp->name = string_make(parser_getstr(p, "name"));
	rp->fail = parser_getint(p, "fail");
	/* get the first NULL power -Simon */
	while(&r->racial_powers[i] != NULL)
		i++;
	r->racial_powers[i] = *rp;
	return PARSE_ERROR_NONE;
}

/* Bunch of lines have been added -Simon */
struct parser *init_parse_p(void) {
	struct parser *p = parser_new();
	parser_setpriv(p, NULL);
	parser_reg(p, "V sym version", ignored);
	parser_reg(p, "N uint index str name", parse_p_n);
	parser_reg(p, "S int str int int int wis int dex int con int chr int ibac int mbac int ibs int mbs", parse_p_s);
	parser_reg(p, "R int dis int dev int sav int stl int srh int fos int thm int thb int throw int dig", parse_p_r);
	parser_reg(p, "X int mhp int exp int infra int pwrstat", parse_p_x);
	parser_reg(p, "I int hist int b-age int m-age", parse_p_i);
	parser_reg(p, "H int mbht int mmht int fbht int fmht", parse_p_h);
	parser_reg(p, "W int mbwt int mmwt int fbwt int fmwt", parse_p_w);
	parser_reg(p, "F ?str flags", parse_p_f);
	parser_reg(p, "Y ?str flags", parse_p_y);
	parser_reg(p, "C ?str classes", parse_p_c);
	parser_reg(p, "E sym tval sym sval uint min uint max", parse_p_e);
	parser_reg(p, "M int pmid", parse_p_m);
	parser_reg(p, "L int lvl int mlvl int nid", parse_p_l);
	parser_reg(p, "Q int mslt int rslt int islt int aslot int lslt int bslt int cslt int sslt int hslt int glst int oslt", parse_p_q);
	parser_reg(p, "P int lvl int cost str name int fail", parse_p_p);
	return p;
}

As you can see, I've added a bunch of lines to the parser, and they all work basically perfectly except this last one which doesn't work at all. I tried commenting out the lines that get the first NULL power, in case there was something wrong with the incomprehensible pointer code. I tried moving the order around, in case parser_reg was 'full' and was dropping the last line. I tried using a different letter in case it was just "P" that was jinxed. I'm about to try sacrificing a live chicken to see if it helps. If anyone knows a better solution then shoot.

[Nick]

The new parser is new - I suspect that takkaria is the main expert here. And I'm sure someone will correct me if I'm wrong