Feature request: generalize "drop chosen"

[bron]

I admit I was thinking only about DROP_CHOSEN, rather than redoing the whole DROP mechanism, although I do like PowerDIver's suggestions.

I was thinking of having lines something like a line giving a list of possible choices,
only one of which would be selected per each such line. So
DROP_CHOSEN:item:272,272,359
to select one of either a Fire Bolt wand, or Rod, with the wand being twice as likely;
DROP_CHOSEN:item:384-387
to select one of the advanced Prayer Books, not including Wrath of God.

Morgoth would have 2 entries like:
DROP_CHOSEN:artifact:111
DROP_CHOSEN:artifact:34
to drop Grond and the Massive Crown.

If the whole DROP code were to be redone, it would certainly be nicer to use names rather than numerical indicies for this sort of thing. But that would probably take a lot more work.

[PowerDiver]

One more thing, I never understood FORCE_MAX_HP, e.g. why not just use 543d1 for a monster with exactly 543 hp?

[takkaria]

One more thing, I never understood FORCE_MAX_HP, e.g. why not just use 543d1 for a monster with exactly 543 hp?

It's gone now anyway, since 3.1-dev uses an average value for monster HP which is then somewhat randomised per monster, rather than hit dice.

[RogerN]

One more thing, I never understood FORCE_MAX_HP, e.g. why not just use 543d1 for a monster with exactly 543 hp?

ZAngband (and probably several other variants) use the number of hit dice to determine spell strength (e.g. a monster with 20d10 hit points has much stronger spells than a monster with 10d20 hit points). Vanilla may have used the same system previously.

[andrewdoull]

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.

That's not to say that there needs to be at least one significant improvement which will require writing a parser. At the moment, in Unangband, there are lots of numbers that refer to other entries in either the same file or other files. It would be far easier from a implementation and debugging point of view to allow text to be put in, instead of numbers.

E.g. the state transition for a closed door

K:OPEN:36

should really be:

K:OPEN: open_door

or something similar.

This will require a two-phase parse of the edit file, to allow forward references...

Andrew

[andrewdoull]

ZAngband (and probably several other variants) use the number of hit dice to determine spell strength (e.g. a monster with 20d10 hit points has much stronger spells than a monster with 10d20 hit points). Vanilla may have used the same system previously.

A separate power number, like Sangband, would make a lot more sense here, from a balancing point of view.

Andrew

[Nick]

K:OPENpen_door

Well, that rules out vBulletin as a parser

[bron]

> why not just use 543d1

This is probably a hold over from early Umoria implementations, where the number of dice, and the number of "sides," were each stored in a byte, so neither one could exceed 255.

[takkaria]

That's not to say that there needs to be at least one significant improvement which will require writing a parser. At the moment, in Unangband, there are lots of numbers that refer to other entries in either the same file or other files. It would be far easier from a implementation and debugging point of view to allow text to be put in, instead of numbers.

E.g. the state transition for a closed door

K:OPEN:36

should really be:

K:OPEN: open_door

or something similar.

This will require a two-phase parse of the edit file, to allow forward references...

Well, here's an idea you've probably already considered about how to do it without a two-pass parse. First, have a simple key-value hashtable where the value is something along the lines of:

struct {
uint32_t value;
uint32_t *refs[20];
}

When you first come to a token, you create an entry in the hashtable and save a pointer to the index you need to fill in into "refs". When you find the value bit, you fill that in too. Then you walk through all the tokens, fill in all the refs with the right value, and you're pretty much sorted. It doesn't require much rejigging of the current parser at all. If you don't want to have a fixed number of references, then it'd be easy enough to dynamically allocate that array instead.

V-dev already allows certain numbers to be strings within the existing format: shops' stocking lists are specified as "I:weapon:& Dagger~", and artifacts reference base items in a similar way. It does make the current fies a lot more readable, and has the handy effect of causing parse errors when items and objects change, so you don't end up with hanging references.