Angband Forums

Angband Forums (
-   Vanilla (
-   -   list-tvals.h (

PowerWyrm November 4, 2019 17:11

I was under the impression that we could add more object types in the game via object_base.txt, but it's not the case since tvals are hardcoded in list-tvals.h, so adding a new object type requires adding an entry to this file and recompile the source code.

This is bad, not anyone is a dev that can edit the source and recompile it. It would be nice if tvals were dynamically generated when parsing object_base.txt.

Pete Mack November 5, 2019 02:59

List-tvals is necessary to make an enum used by the code. There isn't much point in adding a tval without also adding logic to handle it, so I see no benefit to changing this

wobbly November 5, 2019 10:10

You could break up the logic into actions perhaps? Stackable, Edible, Zapable, Chargable... etc.

wobbly November 5, 2019 15:36

So I may not have been exactly clear in the above post. The code has a bunch of this:


bool tval_is_edible(const struct object *obj)


        switch (obj->tval) {

                case TV_FOOD:

                case TV_MUSHROOM:

                        return true;


                        return false;



There's not much point adding a new object type in object_base unless you can specify edible etc. in object_base.

It's also got a bunch of this:


else if (tval_is_edible(obj1) || tval_is_potion(obj1) ||

                tval_is_scroll(obj1) || tval_is_rod(obj1)) {

                /* Food, potions, scrolls and rods all stack nicely,

                  since the kinds are identical, either both will be

                  aware or both will be unaware */

that's a small snipet. If it's addable outside the code that needs to be more like:

if stackable {

Note I'm not particularly suggesting doing it that way. It just seems to me that list-tvals.h isn't the only thing that has to change to put types editable in the edit files.

Pete Mack November 5, 2019 18:41

Yeah, that is pretty much what I felt, but was less clear. If you plan to add a non-trivially different object type, SOME code will be needed. If the addition is trivial, what is the point?

There are a few more attributes that could go into the edit files without massive code changes, but NOT actual gameplay logic. We got rid of lua for a reason.
Beyond the ones you mention, there is also shoot/throw break chance.

takkaria November 5, 2019 22:36


Originally Posted by Pete Mack (Post 141051)
We got rid of lua for a reason.

... which (for me at least) was because it was badly integrated. If it had been deeply integrated with more possibilities for extension then I wouldn't have removed it...

which isn't to take away from the overall point that there is a limit to the level of customisation you can get from the edit files.


Beyond the ones you mention, there is also shoot/throw break chance
This one is actually already in the object_base file I think?

All times are GMT +1. The time now is 07:24.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.