Can you dynamically name mobs?

[nmaligec]

Some eAthena script references say we can set the name of a mob when we spawn it and it should change the display/target name of the mob in the client. I know that the script tmw uses is out of date so I was wondering if it is possible to do a client independent fix to add this functionality (i.e. just modify the server).

I noticed that the new mob name gets stored server side in a mob_data struct, but that clif_spawnmob never references the new name to send it along with the packet when a new mob is spawned. I don't know anything about the client code or the packet structure, so I was wondering if someone knows if the 0.0.29.1 client can properly handle a packet modified to send along the mob name?

I guess support for dynamic naming is improbable if the official client only looks for the mob name in monsters.xml.

If I am completely misunderstanding the whole issue please help me understand whats going on.

[Crush]

I took a look at the client netcode and it doesn't seem to be possible to have named monsters on tmwAthena at the moment. It seems, however, to be possible to have named monsters on Manaserv, although I don't know of any server-sided way to create them.

When you think that named mobs on tmwAthena are an important feature, please create a ticket on the Manasource bug tracker http://bugs.manasource.org

[Crush]

I've just noticed that the official client will react to the SMSG_BEING_NAME_RESPONSE message (0x0095) by changing the displayed name of whatever game object is referenced in it (player character, monster or npc), no matter if it actually requested the name of the being.

When the "custom monster name" feature is going to be implemented, i would suggest to do it using this message.

[nmaligec]

I've just noticed that the official client will react to the SMSG_BEING_NAME_RESPONSE message (0x0095) by changing the displayed name of whatever game object is referenced in it (player character, monster or npc), no matter if it actually requested the name of the being.

When the "custom monster name" feature is going to be implemented, i would suggest to do it using this message.

Wow you are a genius Crush!!! How on earth did you find this out?? Your suggestion really gave me insight into the problem of why something that seems so simple was not implemented. The name is up to 24 chars, and wouldn't fit in the standard SMSG_BEING_SPAWN packet. Thanks to your discovery, a SMSG_BEING_NAME_RESPONSE packet can be sent to also update the name.

Here is my quick thought on how to add this. Make a new script command Monster2 or NamedMonster and have it call a new mob_once_spawn2 in mob.c which only need to be modified to call mob_spawn2 in mob.c that finally calls the modified version of calling clif_spawnmob2. I don't think changing the originals would be a good idea, in case scripters used weird names for their spawns.

After skimming through some of the client source and how the packets work, here is my first attempt at a modified clif_spawnmob2. I still don't know how to write a string to the buffer though...

Code: Select all

int clif_spawnmob2 (struct mob_data *md)
{
    unsigned char buf[64];

    // -- start modification --
    unsigned char buf2[64];
    // --  end modification  --

    int  len;

    nullpo_retr (0, md);

    if (mob_get_viewclass (md->class) > 23)
    {
        memset (buf, 0, packet_len_table[0x7c]);

        WBUFW (buf, 0) = 0x7c;
        WBUFL (buf, 2) = md->bl.id;
        WBUFW (buf, 6) = md->stats[MOB_SPEED];
        WBUFW (buf, 8) = md->opt1;
        WBUFW (buf, 10) = md->opt2;
        WBUFW (buf, 12) = md->option;
        WBUFW (buf, 20) = mob_get_viewclass (md->class);
        WBUFPOS (buf, 36, md->bl.x, md->bl.y);
        clif_send (buf, packet_len_table[0x7c], &md->bl, AREA);

        // -- start modification --
        // send the SMSG_BEING_NAME_RESPONSE packet to update mob name in the client
        memset (buf2, 0, packet_len_table[0x95]);
        WBUFW (buf2, 0) = 0x95;
        WBUFL (buf2, 2) = md->bl.id;
        WBUF????? (buf2, 6) = md->name;
        clif_send (buf2, packet_len_table[0x95], &md->bl, AREA);
        // --  end modification  --
    }

    len = clif_mob0078 (md, buf);
    clif_send (buf, len, &md->bl, AREA);

    if (mob_get_equip (md->class) > 0)  // mob equipment [Valaris]
        clif_mob_equip (md, mob_get_equip (md->class));

    return 0;
}

I still have to figure out how to add new script commands, so I probably wont be able to test it out for a while yet. I just wanted to know if I was making any sense and if I was at least on the right track.

PS thank you Crush for your quick and well informed/helpful reply.

[Crush]

Wow you are a genius Crush!!! How on earth did you find this out??

Being involved in client development for several years now helps.

I've looked at the Being class in the client sourcecode and noticed that the setName method is the only way so set it's name. So I searched the tmwa netcode files for "->setName(".


I am not familiar with the tmwAthena sourcecode though. But when I were in your shoes I would either look for another packet which I know has to include strings (anything chat-related?) or try to find the definitions of WBUFW and WBUFL because a related function for strings is likely to be defined nearby.

[nmaligec]

I finally got some spare time to try and add a few script commands that I was needing, and this was one of them.

On the upside, Crush's suggestion worked great for players already on the map when the mob is spawned.

The downside is that any players who warp into the map afterward will see the default mob name, as listed in monsters.xml. The situation where I want to use this will guarantee no one will warp into the map after the dynamically named mob is spawned. However, the downside means this addition to tmwAthena script is kind of worthless for anybody else...

Is there anyway to keep newly connected clients synchronized with the name change, or is it impossible as of the 0.5.2 client?