Feature request: generalize "drop chosen"

[bron]

A feature I would like to see added to the game is a generalization of the "drop chosen" attribute. Right now (3.0.9b; I haven't see top-of-trunk) only Morgoth has this attribute, and there is a lot of special code in the source to deal with it. But it has the potential to add a lot of chrome if it could be applied to other monsters. Say, have Fundin Bluecloak always drop a high level prayer book. Or a dark elven mage always have a wand or rod (or other magical device). I don't know that you'd want to have monsters (other than Morgoth) always drop specific artifacts in Vanilla as that might affect play balance in unexpected ways, but other sorts of drops would seem to add nice chrome without really changing the game significantly. It also seems like it would be a boon for crafting variants, where there might be "side quests" where you need to go defeat some specific villain in order to gain the special magic sword, etc.

[d_m]

I think you'd have to do rejigger the monster.txt (or some other file) to allow this. Currently flags can't really be parameterized, so unless you want a new DROP_CHOSEN_* flag for every different "chosen item" you'd need a way of specifying which chosen item(s) got dropped.

That said I think the general idea is interesting. For V, it seems like you could solve it with (new) flags like DROP_HI_PRAYER or something. As far as having some uniques drop other specific items, it might be harder.

[PowerDiver]

Originally Posted by d_m

I think you'd have to do rejigger the monster.txt (or some other file) to allow this. Currently flags can't really be parameterized, so unless you want a new DROP_CHOSEN_* flag for every different "chosen item" you'd need a way of specifying which chosen item(s) got dropped.

It doesn't have to be that bad. You could have a single DROP_WHAT_THEY_NEED flag, and then code the drop according to the attacks and or spells present. So if they can heal 300, they drop the book that heals 300 or !heal, etc. I assume that's not what the OP meant, and just me being me, but you could generalize that idea to code the special drops in a more general way still depending upon a function of the other flags.

It wouldn't work for artifact drops, but it gets about halfway to the request.

OTOH, perhaps it *is* time to redo the txt files. Do we have any yacc experts with too much free time?

[d_m]

Originally Posted by PowerDiver

OTOH, perhaps it *is* time to redo the txt files. Do we have any yacc experts with too much free time?

I too would love to normalize the .txt files and update them. I've got a pretty good lexer/parser for them in python.

In particular, having the first S: line mean "how often does the monster cast" and every other line mean "which spells does the monster cast" seems like a horrible hack (albeit a very very old horrible hack).

[takkaria]

Originally Posted by d_m

I too would love to normalize the .txt files and update them. I've got a pretty good lexer/parser for them in python.

In particular, having the first S: line mean "how often does the monster cast" and every other line mean "which spells does the monster cast" seems like a horrible hack (albeit a very very old horrible hack).

I hate to think of the number of people who have a pretty good parser for the text files. There must be one in every semi-popular language these days.

Note that it isn't necessary that the first S: line means that. You can do 1_IN_x anywhere and it works.

What exactly do you mean by "normalise and update"? And Eddie, what do you mean by "redo"? I've had syntax for a new kind of text file around for ages, and Shanoah Alkire wrote a parser and outputter to write that new format a while ago.

[d_m]

Originally Posted by takkaria

What exactly do you mean by "normalise and update"/

I said "normalize and update."

What I meant was at least the following:

1. Filter the current files according to a deterministic set of rules so that "editor/creator" programs have a deterministically correct way outputting records, that is guaranteed to jive with the file and not cause unnecessary SVN diffs.

2. Move all important info out of comments and into fields (the HD and FORCE_MAXHP fields are good examples of this in the monster.txt file).

And possibly including:

3. Use a less opaque format, either something like XML, or a custom format that has labels. For instance:

monster {
id 2
name "Scrawny Cat"
...
}

4. Include one or more parsing libraries in the distro so that people who write tools can link against (or use) these rather than writing their own.

[Nick]

Originally Posted by d_m

3. Use a less opaque format, either something like XML, or a custom format that has labels.

Could I suggest a custom format, rather than something tied to a current fad^H^H^H programming paradigm? One of the big reasons for Angband's survival (apart from general awesomeness) is that "agility" has mostly been restricted to platform-specific code.

[takkaria]

Originally Posted by Nick

Could I suggest a custom format, rather than something tied to a current fad^H^H^H programming paradigm? One of the big reasons for Angband's survival (apart from general awesomeness) is that "agility" has mostly been restricted to platform-specific code.

The custom format I was working out was something like: http://rephial.org/wiki/NewParsing

I mooted it a while ago, but for this kind of thing to be useful, multiple people have to be interested in adopting it, not just V. If there was interest, that'd be nice, but I believe UnAndrew isn't a massive fan of adopting a new format and I didn't hear anyone say "yes, this would be really good" rather than just "sounds alright" at the time.

OTOH, if people were interested, I'd be very happy to write a parser, since I find writing parsers quite fun.

[Nick]

Originally Posted by takkaria

The custom format I was working out was something like: http://rephial.org/wiki/NewParsing

Sounds alright

I wouldn't be averse to adopting it, actually - especially since FA has a few numbers (resist percentages, spell power) which are a bit hackishly read in from flags.

OTOH, if people were interested, I'd be very happy to write a parser, since I find writing parsers quite fun.

Well, that's good enough reason in itself - if you're not enjoying developing, you'll stop fairly soon.

And make sure you get enough sleep

[takkaria]

Originally Posted by Nick

Sounds alright

I wouldn't be averse to adopting it, actually - especially since FA has a few numbers (resist percentages, spell power) which are a bit hackishly read in from flags.

http://takkaria.org/angband-parsing-plan.txt is an outline of the kind of code I was thinking about. It should be really quite a lightweight parsing model. Another advantage of moving to a key-value model would be that parse errors can get reported far better/more accurately; it can say things like "expected number, got string" or "not a valid tval", or "that's above 255" rather than just "sscanf() failed, guess why from this string".