Implementing the restructure changes

[PowerWyrm]

At this point, the code combines equipped and non-equipped items (the starting wielded torch and the ones in inventory), doesn't update equipped items properly (equipment shows nothing) and then makes the character wield the scroll of word of recall in the inventory next time it loads from the savefile...

I'm gonna take a 2-week break (holidays) and I suppose this is gonna be fun to fix all these when I come back (hoping most of this stuff is fixed with the next changesets).

[PowerWyrm]

Onto the next batch of updates: say goodbye to player inventory, say hello to player gear. This is clearly going to be a huge pain in the ass in my variant, which needs to maintain two separate sets of player gear, one for the client, one for every player on the server.

I've implemented the first big changeset (18fbf7d). The code compiles cleanly, the server starts, but the client crashes instantly when trying to generate a character. I hope it's just a problem with gear updates done too soon (before the character is actually "alive").

Edit: pfft, it was just a malformed scanf on the client...

[Nick]

Onto the next batch of updates: say goodbye to player inventory, say hello to player gear. This is clearly going to be a huge pain in the ass in my variant, which needs to maintain two separate sets of player gear, one for the client, one for every player on the server.

Wait until the bit where the object list gets removed

[PowerWyrm]

Onto the next batch of updates: say goodbye to player inventory, say hello to player gear. This is clearly going to be a huge pain in the ass in my variant, which needs to maintain two separate sets of player gear, one for the client, one for every player on the server.

[Nick]

The problem with average items is obvious: there is nothing to learn. That's why they are immediately identified.

There aren't flags to learn, but there are still ID_ flags to set. So an average item when picked up but not sensed should still have, for example, its ID_TO_H flag not set, so neither its name nor its description should include that information.

Once it is sensed, it then becomes clear that it doesn't have a + to hit (etc), and it gets recognised as average and completely identified.

This is the way I intended it to work, anyway.

[PowerWyrm]

Final problem for now: examining an unaware ring of strength says it "affects your strength", while it's obvious you have no knowledge about it.

In the old code, a first step was to collect all known mods, then iterate on the list and display "+x" if the mod is visible and "affects" if the mod is not visible. In the new code, the first step is omitted, so any non visible or non known mod is defaulted to "affects".

Fix: I'm assuming that being not aware is sufficient to mask all the mods, so simply adding a "if not aware return" in describe_stats() should be enough. The behavior for digging will be similar to 3.5, as a ring will not say anything, but an unidentified shovel of digging will.

[PowerWyrm]

While they make sense, these recommendations are the opposite to 3.5 behaviour.

Exactly, that was a bug in 3.5

[Carnivean]

And onto the next problem: ring of the dog shows the -2 to stealth (fixed) and the protection from fear, but also says "you do not know the full extent of this item's power" when everything is obviously known.

Trivial: easy_know is missing on the ring (object.txt).

While at it, the easy_know flag has been set on amulets of inertia, but since they have a variable penalty to speed, the flag should be removed.

While they make sense, these recommendations are the opposite to 3.5 behaviour.

[PowerWyrm]

And onto the next problem: ring of the dog shows the -2 to stealth (fixed) and the protection from fear, but also says "you do not know the full extent of this item's power" when everything is obviously known.

Trivial: easy_know is missing on the ring (object.txt).

While at it, the easy_know flag has been set on amulets of inertia, but since they have a variable penalty to speed, the flag should be removed.

[PowerWyrm]

Next problem: ring of resist poison will say "doesn't possess any abilities" until worn.

Obvious: elements are learned on any aware non-artifact jewelry when the item is worn. However, ring of resist poison (and similar) is "easy_know", and therefore appears as "known" when "aware". When displaying info, the "get_known_elements" method only checks against known flags and doesn't check against "easy_know".

Easy fix: replace "obj->el_info[element].flags & EL_INFO_KNOWN" checks by calls to object_element_is_known().

Hmm this makes me think that this will fix some pricing problems reported against the beta, since "easy_know" items with elements would not report these elements as known in element_power().

[PowerWyrm]

My feeling is that this isn't the case, because the ID_ flags are whether the player knows, not whether the object has. Maybe that's because I am mistaken about how average items were identified before. What more is there to learn after {average}?

The problem with average items is obvious: there is nothing to learn. That's why they are immediately identified. As I said, the old code was adding a "KNOWN" flag to any identified item, so average items still had to learn that flag by passing the identify check. Now that check isn't even made, since average items are automatically known.

[Carnivean]

My feeling is that this isn't the case, because the ID_ flags are whether the player knows, not whether the object has. Maybe that's because I am mistaken about how average items were identified before. What more is there to learn after {average}?

Previously, from the user perspective, you had to carry an item until the pseudo-id kicked in to recognise that an item was average, at which point you knew all the stats.

I haven't played the new version yet, but from what is being stated, you don't have the wait for pseudo-id step in the new id system, and therefore you're immediately aware of all of the 0 flags from the first turn and the object is identified. Maybe not fully identified from previous bug reports though.

Whether you think that should be the case is another question.

[PowerWyrm]

Next problem: ring of resist poison will say "doesn't possess any abilities" until worn.

Obvious: elements are learned on any aware non-artifact jewelry when the item is worn. However, ring of resist poison (and similar) is "easy_know", and therefore appears as "known" when "aware". When displaying info, the "get_known_elements" method only checks against known flags and doesn't check against "easy_know".

Easy fix: replace "obj->el_info[element].flags & EL_INFO_KNOWN" checks by calls to object_element_is_known().

[Nick]

2) Average items immediately identified

This is because they have no properties at all! So "object_all_flags_are_known" returns true, "object_all_elements_are_known" returns true, "object_all_brands_and_slays_are_known" returns true and "object_all_miscellaneous_are_known" returns true.

My feeling is that this isn't the case, because the ID_ flags are whether the player knows, not whether the object has. Maybe that's because I am mistaken about how average items were identified before. What more is there to learn after {average}?

[Carnivean]

Shouldn't be too much time - PowerWyrm's done half the work

While he finishes doing your job then...