list-tvals.h

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • PowerWyrm
    Prophet
    • Apr 2008
    • 2986

    list-tvals.h

    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.
    PWMAngband variant maintainer - check https://github.com/draconisPW/PWMAngband (or http://www.mangband.org/forum/viewforum.php?f=9) to learn more about this new variant!
  • Pete Mack
    Prophet
    • Apr 2007
    • 6883

    #2
    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

    Comment

    • wobbly
      Prophet
      • May 2012
      • 2629

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

      Comment

      • wobbly
        Prophet
        • May 2012
        • 2629

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

        Code:
        bool tval_is_edible(const struct object *obj)
        
        {
        
        	switch (obj->tval) {
        
        		case TV_FOOD:
        
        		case TV_MUSHROOM:
        
        			return true;
        
        		default:
        
        			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:

        Code:
        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.

        Comment

        • Pete Mack
          Prophet
          • Apr 2007
          • 6883

          #5
          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.

          Comment

          • takkaria
            Veteran
            • Apr 2007
            • 1951

            #6
            Originally posted by Pete Mack
            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?
            takkaria whispers something about options. -more-

            Comment

            Working...
            😀
            😂
            🥰
            😘
            🤢
            😎
            😞
            😡
            👍
            👎