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]

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]

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]

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]

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]

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]

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]

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]

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".

[andrewdoull]

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.

I've got reservations because I've yet to see any concrete suggestions that'll make it easier for new players to be able to come in and change the edit files.

And, as Unangband has shown, there's a huge amount of use and abuse of the existing edit file format left to do before we need to migrate to another standard.

Sometimes a standard works because it's what has been adopted.

Having said that, I've already moved away from the 1_IN_X format to a separate magic line M:innate:spell: power:mana when I adopted the 4GAI.

Andrew

[d_m]

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.

I also prefer a custom format. But I had to suggest it anyway... whenever one suggests a custom format, someone invariably suggests XML (and whenever someone suggests XML, someone else suggests a custom format).

[takkaria]

I've got reservations because I've yet to see any concrete suggestions that'll make it easier for new players to be able to come in and change the edit files.

And, as Unangband has shown, there's a huge amount of use and abuse of the existing edit file format left to do before we need to migrate to another standard.

I must admit to finding it a bit odd that you don't think some slightly more self-describing format would be a good idea for UnAngband, given the complexity of its edit files and the number of otherwise-unlabelled numbers in them. But yes, I can see your point.

[d_m]

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".

I think I prefer this to the wiki example--I like the enclosing braces. I agree with all the benefits you outlined.

[PowerDiver]

IAnd Eddie, what do you mean by "redo"?

I didn't have anything particular in mind. There are things that seem odd. It seems silly to get the size of the drop by using a bitwise or on different flags. For example

DROP 3d4 GOOD;
DROP 1d1 GREAT;
DROP 2d3 MONEY;

could describe the drops of a particular monster. No need to make it all-or-none on DROP_GREAT. You could extend so that

DROP Aglarang;

works too, solving one of the requests of the OP.

The way that amulets of trickery or launchers of power or assorted other items are produced should be specified in the txt files rather than hard-coded. My squelch code keeps getting uglier because of that! Specify the min and or max values there.

Again, I haven't really thought about it. I just know that reading the txt files is strange, so I guess that any reasonable person with some parser knowledge could make a substantial improvement.

I'm also opposed to a lot of the hard-coded values. IMO the parser should read object.txt and output sval_defines.h if one insists on sticking with the switch(sval) paradigm. It should be impossible to assign the same sval to 2 different rings, which happened and caused some strange NPP bugs back when with resist poison and resist nether having the same sval.