Trying to make ego lights for Angband 2.9.3

[Hajo]

I've been trying to make ego lights for Angband 2.9.3. It seems I got most of it right. The flags are set right when I inspect the items with the debug commands, and they work as expected.

But there is a strange side effect in inventory display.

a Wooden Torch of Brightness (-1) (with 2345 turns of light)

I wonder where the -1 comes from and what it means. The torch has SEE_INVIS and my newly introduced EGO_LIGHT flags. I tried to give it +1 to hit (due to the better light) but nothing else.

N:103:of Brightness
X:29:0:0
W:1:1:0:0
C:1:0:0:0
T:39:0:99
F:SEE_INVIS | EGO_LIGHT

I guess the -1 comes from the C line, but why is that (-1) then and not [+1, +0]? I might skip the idea of the attack bonus from ego lights if this causes too much troubles. I have even no idea if the bonus would transfer to the attack mods anyways, since this is a ego light and not a weapon.

[Timo Pietilä]

Originally Posted by Hajo

I've been trying to make ego lights for Angband 2.9.3. It seems I got most of it right. The flags are set right when I inspect the items with the debug commands, and they work as expected.

But there is a strange side effect in inventory display.

a Wooden Torch of Brightness (-1) (with 2345 turns of light)

I wonder where the -1 comes from and what it means. The torch has SEE_INVIS and my newly introduced EGO_LIGHT flags. I tried to give it +1 to hit (due to the better light) but nothing else.

N:103:of Brightness
X:29:0:0
W:1:1:0:0
C:1:0:0:0
T:39:0:99
F:SEE_INVIS | EGO_LIGHT

I guess the -1 comes from the C line, but why is that (-1) then and not [+1, +0]? I might skip the idea of the attack bonus from ego lights if this causes too much troubles. I have even no idea if the bonus would transfer to the attack mods anyways, since this is a ego light and not a weapon.

That first number is max to-hit. For some reason you get it negative. For to_hit and to_dam values you use parenthesis for AC brackets. 2.9.3 code doesn't show the other value for to_hit and to_dam if it is zero. That is why only one number.

I have no idea why it shows it as negative. Maybe just giving it a value as ego makes it possible to generate negative value too (flip value). That C: -line is max to_hit, not fixed value. Artifacts get fixed values. For egos there is some code for values.

[Hajo]

Must have been some kind of mishaps in early versions of my code I guess. Now I get only positive numbers. Thanks for clarifying the (..) vs [..] issue

I saw that I must adapt the "I"nspect command though, it gives wrong radius information. Still kind a cool to have made my first sort of ego item

[Hajo]

Seems to work fine now. Thanks again for the help, Timo! Was also good to learn about the differences in artifact and ego item configuration.

[Timo Pietilä]

Originally Posted by Hajo

Seems to work fine now. Thanks again for the help, Timo! Was also good to learn about the differences in artifact and ego item configuration.

Actually now that I read my reply to you again I think vanilla has some "hackish" code somewhere for displaying to_hit and to_dam. Armors and rings in 2.9.3 show only one value if another is zero and none if both are zero, but weapons show both even if they are both zero. It shows that differently based on item type, and that must have some kind of definition somewhere when to use which way to show those values. Might be a bit more complicated than I thought.

[Hajo]

I think I found the function. Looks a bit convoluted. Before hacking my way in the code I thought Angband would have much less special cases, but there are enough, still. On the other hand once one understood the logic it looks more reasonable. I'd assume that the code was state of the art when written, and it's just me who is not used to such code.

At the moment I think I do not need to adapt this place though.

I have a slightly off topic question: The number of 127 ego items seems to be limited through the use of a byte variable in the object_type structure for the link into the ego-item-date table. If I change that I assume I must also adapt game saving and loading routines. And somewhere the allocation of the e_info ego-item-data table (should have a define, IIRC). Is there more to it? It's not urgent, I think I have 20 ego-data slots left but if I continue modding Angband I sure run out of these slots, and maybe I'd better make the move early, if it alters the savegame structure.

On the other hand "unsigned char" seems to work reasonably well with gcc on all platforms that I know and it would already give a whopping 128 extra ego data slots, while keeping the save game format. A comment in types.h mentions that "unsigned char" is not properly supported on some platforms, but maybe this has improved in the past ten years?

[zaimoni]

Originally Posted by Hajo

On the other hand "unsigned char" seems to work reasonably well with gcc on all platforms that I know and it would already give a whopping 128 extra ego data slots, while keeping the save game format. A comment in types.h mentions that "unsigned char" is not properly supported on some platforms, but maybe this has improved in the past ten years?

More like past twenty (that comment sounds more appropriate for the K&R compilers available in Moria's time).

Any C90 compliant compiler targeting a normal platform should be fine with unsigned char for that field.

[Hajo]

Good to know. I don't have much experience with compilers other than gcc, thus I was a bit uncertain.

Keeping the variable to a 8 bit quantity should make things easier.