💬 [Discussion] Unimplemented SMSG_READ_ITEM_FAILED structure

[Wall-core]

The emulator currently supports blizzlike behavior when attempting to read items or objects. You either can read it, or you can't. Language features are not supported in the emulator because they were never really used in vanilla, short of binary checks for known languages.

However, language systems in the client are complex, and in terms of blizzard's backend, the handlers undoubtedly exist. The client supports a range of language skill, from 1-300, and algorithmically translates pagetext based on the characters language skill. In vanilla, this value is always either 300, or you simply dont know the language.

In terms of the backend handlers for SMSG_READ_ITEM_FAILED, there is an unimplemented portion of the packet structure that could be better handled internally to enable such features. The logic can follow vanilla blizzlike behavior in that these handlers will never reach the code.

Here is an example of the corrected structure:
Opcode: SMSG_READ_ITEM_FAILED
ObjectGuid (uint64)
State [0..2] (uint8)
Timer (uint32)

Currently in VMaNGOS, when reading a pagetext item/object, it should always return EQUIP_ERR_OK and send SMSG_READ_ITEM_OK.
It currently will never (or shouldn't, without error) send SMSG_READ_ITEM_FAILED as checks for using items/gameobjects are handled elsewhere. VMaNGOS currently only has handling for State [0] and does not include the timer at all. This packet can actually have three different states which the client handles, one of which utilizes the Timer (uint32):

State [0] = Send text; client is marked to translate it based on skill level
State [1] = Send text; do not translate; initiate timer instead
State [2] = Do not send text; client does not open pagetext panel

It's a complicated packet to understand and properly implement, mostly because we can only speculate what the behavior should be (as this was simplified before vanilla launch). As it stands, the packet for SMSG_READ_ITEM_FAILED should probably return STATE [2] so that the client does not even attempt to open the pagetext; If they somehow managed to reach SMSG_READ_ITEM_FAILED and they do not understand the language, it will send untranslated pagetext to the client.

As for how it actually worked, someone in wowmodding posted a video of their experimentation and I managed to reverse it and implement it into VMaNGOS natively:

void WorldSession::HandleReadItemOpcode(WorldPacket& recv_data)
{
    uint8 bag, slot;
    recv_data >> bag >> slot;

    Item *pItem = _player->GetItemByPos(bag, slot);

    if (pItem && pItem->GetProto()->PageText)
    {
        WorldPacket data;

        InventoryResult msg = _player->CanUseItem(pItem);
        if (msg == EQUIP_ERR_OK)
        {
            if (uint16 skill = _player->GetSkillForLanguage(pItem->GetProto()->LanguageID))
            {
                if (uint16 skillValue = _player->GetSkillValue(skill))
                {
                    if (uint16 skillMax = _player->GetSkillMax(skill))
                    {
                        data.Initialize(SMSG_READ_ITEM_FAILED, 8 + 1 + 4);
                        data << ObjectGuid(pItem->GetObjectGuid());
                        data << uint8(1);
                        data << uint32(5000);
                        SendPacket(&data);
                        _player->m_Events.AddLambdaEventAtOffset(
                            [this, pItem]
                            {
                                WorldPacket data2;
                                data2.Initialize(SMSG_READ_ITEM_FAILED, 8 + 1);
                                data2 << ObjectGuid(pItem->GetObjectGuid());
                                data2 << uint8(0);
                                SendPacket(&data2);
                            },
                            5000);
                    }
                    else
                        _player->SendEquipError(EQUIP_ERR_NO_REQUIRED_PROFICIENCY, pItem);
                }
                else
                    _player->SendEquipError(EQUIP_ERR_NO_REQUIRED_PROFICIENCY, pItem);
            }
            else
            {
                data.Initialize(SMSG_READ_ITEM_OK, 8);
                data << ObjectGuid(pItem->GetObjectGuid());
                SendPacket(&data);
            }
        }
        else if (msg == EQUIP_ERR_NO_REQUIRED_PROFICIENCY)
        {
            data.Initialize(SMSG_READ_ITEM_FAILED, 8 + 1);
            data << ObjectGuid(pItem->GetObjectGuid());
            data << uint8(2);
            SendPacket(&data);
            _player->SendEquipError(EQUIP_ERR_NO_REQUIRED_PROFICIENCY, pItem);
        }
        else
            _player->SendEquipError(EQUIP_ERR_NO_REQUIRED_PROFICIENCY, pItem);
    }
    else
        _player->SendEquipError(EQUIP_ERR_ITEM_NOT_FOUND, nullptr);
}

As you can see, if language systems are enabled in the client, this code will handle it as best as we can assume the behavior to be. There are also handlers implemented in CanUseItem() to check if the player knows the language; if not, CanUseItem() returns EQUIP_ERR_NO_REQUIRED_PROFICIENCY and SMSG_READ_ITEM_FAILED is sent with State [2] (do not open page text panel; failure)

If the player knows the language, it will then check the skill for the language (a new function with a switch enumerating all the Skill-Language pairings). It will then check the player's skill level and skill max for validity. Afterwards, it sends SMSG_READ_ITEM_FAILED with State [1] and a Timer (uint32) set to 5000ms (guessed value). This sends the page text to the client, marking it as untranslated from its origin language, along with a progress bar on the page text with the timer value in milliseconds.

It then creates a Lambda event with the same timer; After the timer expires, it sends SMSG_READ_ITEM_FAILED State [0] (translate page text based on client skill value).

This creates the effect of the page text being translated after the player character reads the letter. As stated, all of these functions exist natively in the client but were scrapped before vanilla launched. They existed until WoD when the client had many of the functions reworked or removed entirely. We can never truly know for certain how the behavior was precisely handled, and the function need not exist in such form to emulate Blizzlike vanilla. Nor do I expect any of this to be implemented in any way. But it's something that Brotalnia will find interesting, as it sheds light on more internal structures that we don't fully understand yet.

[Wall-core]

https://www.youtube.com/watch?v=ErkTF_sHrDw

[Wall-core]

Another thing to note; State [2] may not actually exist. It's only alluded to in the VMaNGOS comments. It is functionally the same as simply not sending the packet at all, and any states >= 2 yield the same result.

[GrenderG]

0.5.3 decompiled function:

//----- (005E5D20) --------------------------------------------------------
void __thiscall CGPlayer_C::ReadItemResult(CGPlayer_C *this, NETMESSAGE msgID, CDataStore *msg)
{
  CDataStore *v3; // esi
  C_OBJECTHASH *v4; // eax
  unsigned __int64 item; // [esp+Ch] [ebp-8h] BYREF
  int savedregs; // [esp+14h] [ebp+0h] BYREF

  v3 = msg;
  CDataStore::Get(msg, &item);
  if ( msgID == SMSG_READ_ITEM_OK )
  {
    v4 = ClntObjMgrObjectPtr((unsigned int)aDBuildBuildwow_172, 7359, item);
    if ( !v4 )
      return;
    CGItem_C::SetTranslated((CGItem_C *)v4);
    goto LABEL_4;
  }
  CDataStore::Get(v3, (char *)&msg + 3);
  if ( !HIBYTE(msg) )
  {
LABEL_4:
    CGItemText::DisplayText((int)&item, 1, (unsigned int)&savedregs);
    return;
  }
  if ( HIBYTE(msg) == 1 )
  {
    CGItemText::DisplayText((int)&item, 0, (unsigned int)&savedregs);
    CDataStore::Get(v3, (int *)&msgID);
    FrameScript_SignalEvent(0x112u, "%f", (double)(int)msgID * 0.001);
  }
  else if ( item == *(_QWORD *)&CGItemText::m_itemGUID )
  {
    FrameScript_SignalEvent(0x114u);
  }
}

Relevant frame script events (used by FrameScript_SignalEvent):

  SCRIPT_ITEM_TEXT_BEGIN = 0x111,
  SCRIPT_ITEM_TEXT_TRANSLATION = 0x112,
  SCRIPT_ITEM_TEXT_READY = 0x113,
  SCRIPT_ITEM_TEXT_CLOSED = 0x114,

---

As you noticed State = 2 isn't actually defined; any state different than 0 and 1 will yield the same result. It simply triggers the SCRIPT_ITEM_TEXT_CLOSED frame script event.

Here's how State values change the behavior of the SMSG_READ_ITEM_FAILED packet:

• State 0: shows translated text.
• State 1: shows untranslated text and a timer bar (event SCRIPT_ITEM_TEXT_TRANSLATION) with the specified time. The script event name implies, I think, that you are indeed translating the text while the timer is on.
• Any other state value: triggers SCRIPT_ITEM_TEXT_CLOSED event. I guess this simply closes the text UI?

[Wall-core]

Is it possible to dig through SCRIPT_ITEM_TEXT_TRANSLATION? I don't see any callback from the client after the translation bar reaches 100%, which I had anticipated in order to properly time the followup packet. It's possible that the script would either send a callback, or automatically SetTranslated afterwards, and the functionality was removed or disabled during development

[balakethelock]

https://github.com/MOUZU/Blizzard-WoW-Interface/blob/d162a4c0d198a4381b5b6573d975635ed7316702/1.12.1/FrameXML/ItemTextFrame.lua#L10
Some more info that could be useful, the framexml that handles these 4 events

If this feature existed in the alpha/beta and was then culled, then the framexml files from those versions could have a more indepth implementation of how half-way translated text will look like ingame

Edit: actually I just read this

This implies translating a text took time and that depended on the skill? If so that's very cool.

I thought the higher skill, the more words get dejumbled until you reach full skill and can understand the whole text, maybe it's both that and it takes less time, either way both cool things to look into.

[Wall-core]

I had originally implemented my code with a skill-based timer, but realized it didn't make much sense to have both a longer cast time and less words translated based on skill. I think the timer is just a variable, and perhaps more lengthy items (such as a book) would've taken longer to read than shorter articles (such as a note). There's no item data pointing to this timer, and it may have been implemented clientside but never used on any DB column.

[Wall-core]

Now that I think about it further, there is no item data or object data for the translation timer. Nor is there differentiation between a single page of text or multiple in the item/object data; However, it could have checked NextPage chain for total pages and then calculated based off that.