FEAT_INVIS and FEAT_DOOR_HEAD

[fizzix]

If I'm reading the code correctly, the numbering of terrains in terrain.txt is used directly by the code in order to determine what to do with specific features. Adding more floor terrains seems like it would require one of the following:

1) simplest solution: move all non-floor terrains later in terrain.txt, and change the values of FEAT_INVIS and FEAT_DOOR_HEAD. Then add the new floor types to the beginning. This keeps the old clunky format, but won't break anything.

2) Abandon FEAT_INVIS and FEAT_DOOR_HEAD and instead use flags for all the calls. There are a *lot* of changes that would need to be done, but may be doable.

Is there a good reason why door selection was not done by flags and rather by calling the indexes in terrain.txt directly?

[takkaria]

If I'm reading the code correctly, the numbering of terrains in terrain.txt is used directly by the code in order to determine what to do with specific features. Adding more floor terrains seems like it would require one of the following:

1) simplest solution: move all non-floor terrains later in terrain.txt, and change the values of FEAT_INVIS and FEAT_DOOR_HEAD. Then add the new floor types to the beginning. This keeps the old clunky format, but won't break anything.

2) Abandon FEAT_INVIS and FEAT_DOOR_HEAD and instead use flags for all the calls. There are a *lot* of changes that would need to be done, but may be doable.

Is there a good reason why door selection was not done by flags and rather by calling the indexes in terrain.txt directly?

Like a lot of horrible stuff in Angband, because it made sense in Pascal in the 80s. Either approach seems justifiable, but I'd advocate the first. The second will take a lot of work and it might not even be worth it.

[Sirridan]

I'm dealing with this in pyAngband as well, and I've decided to add a feature_arg variable to the DungeonCell structure which holds information about terrain and such. This basically would just tell how jammed and locked the door is, so that way you don't have to fuss with a new terrain type for each level of jammed/lockedness the doors have.

But as for how it works in the C code, it does, and yeah, changing it will/would be a huge hassle.

[andrewdoull]

Like a lot of horrible stuff in Angband, because it made sense in Pascal in the 80s. Either approach seems justifiable, but I'd advocate the first. The second will take a lot of work and it might not even be worth it.

I'd argue that the flag based approach is worth it. But I've gone through that pain and have probably forgotten how bad it was...

Andrew

[Nick]

I'd argue that the flag based approach is worth it. But I've gone through that pain and have probably forgotten how bad it was...

I've gone to mostly flag based in FA, too - and my recollection is that it was relatively not too bad.

[nppangband]

I'd argue that the flag based approach is worth it. But I've gone through that pain and have probably forgotten how bad it was...

Andrew

NPP terrain is all flag based, and I think it was worth it. Of course, I 'borrowed" all of Andrew's hard work istead of creating it from scratch.

It actually wouldn't be too much work to take the code out of NPP and put it in vanilla, since the code bases are similar again.