playerset_handling_improvement.md

title	layout
playerset handling improvement	wiki

{% include toc.md %}

Player and equipment layers handling

This page will attempt to provide specifications improving the current playerset layer definition, including race specific sprites for the body, equipment, and hairstyles support:

Currently, the layer specification is made of these layers for each supported protocols:

Current static layer specifications

TmwAthena: SPRITE_BASE = 0, SPRITE_SHOE, SPRITE_BOTTOMCLOTHES, SPRITE_TOPCLOTHES, SPRITE_MISC1, SPRITE_MISC2, SPRITE_HAIR, SPRITE_HAT, SPRITE_CAPE, SPRITE_GLOVES, SPRITE_WEAPON, SPRITE_SHIELD,

Mana server: SPRITE_BASE = 0, SPRITE_SHOE, SPRITE_BOTTOMCLOTHES, SPRITE_TOPCLOTHES, SPRITE_HAIR, SPRITE_HAT, SPRITE_WEAPON,

Pseudo-dynamic layer handling

From the different problems encountered, for instance when firing with a bow, or some annoyance when sprite makers have to erase part of their sprites to get the illusion that an particular equipment layer is behind another, even if drawn after it, I’ve listed the following possible layers:

Identified playerset layer definition so far:

Hairs – back (2 versions: 1 under covering helmet, 1 without helmet or with uncovering helmet equipment.) Hairs – front (2 versions: 1 under covering helmet, 1 without helmet or with uncovering helmet equipment.) Eyes Head Torso Arms-back Arms-front Legs

Identified equipment layer definition so far:

Helmet – back Helmet – front Chest Gloves Legs armor Shoes – back Shoes - front Weapons back Weapons front

Merged together: //(in a logical order, from background to foreground)//

Weapons - back Shoes – back Legs Arms – back Helmet – back Hairs – back Torso Head Eyes Legs armor Shoes - front Chest armor Arms – front Gloves Hairs – front Helmet front Weapons-front

Every layer being optional, only the needed layer (even if two are present for a specific body part) would have to be drawn, of course.

Exception handling:

To handle layout exceptions, some layers will have to be drawn in another order for a specific item. To keep things simple for the equipment makers, empty layer spaces should be left between each defined layer, permitting specific changes or additions. We could number them 5 by 5, for instance:

5. Weapons - back
6. Shoes – back
7. Legs
8. Arms – back
9. Helmet – back
10. Hairs – back
11. Torso
12. Head
13. Eyes
14. Legs armor
15. Shoes - front
16. Chest armor
17. Arms – front
18. Gloves
19. Hairs – front
20. Helmet front
21. Weapons-front

The layer numbering should be defined in a xml definition file to be the most flexible, for instance :

{% highlight xml %}

{% endhighlight %} N.B.: The same file could also providing a default hair xml file, and default sfx:

{% highlight xml %}

... ...

{% endhighlight %}

For each piece of equipment, the keywords given above would make the equipment by drawn at the given layer number, for instance:

• Given in the items.xml file when willing to apply the layer to every sprites: {% highlight xml %}

...
<item id="624"
    image="armor-chest-vnecksweater.png|W:#A4B2B2,FFFFFF"
    name="V-Neck Sweater"
    description="A soft, warm sweater."
    effect="+8% Defense"
    type="equip-torso"
    layer="chest-armor"> <!-- new layer parameter. Not optional here -->
    <sprite gender="male">chest-vnecksweater-male.xml|#A4B2B2,FFFFFF</sprite>
    <sprite gender="female">chest-vnecksweater-female.xml|#A4B2B2,FFFFFF</sprite>
</item>

…

{% endhighlight %}

• And /or for each animation in the corresponding equipment xml file: {% highlight xml %}

... ... {% endhighlight %}

And for special cases where a specific layer must be drawn differently than the current set, a ‘layer’ parameter could be added, setting specifically the layer number where it should be drawn. Values used by preset definition (multiple of 5 in this case) would be refused and make the equipment piece fall back to its default layer number.

For instance: {% highlight xml %}

... ... {% endhighlight %}

A example where the given value is bad (because already preset and will fall back to the generic one: {% highlight xml %}

... ... {% endhighlight %}

Other needed parameters identified so far:

Flip flag for frames:

• h-flip: Would horizontally flip the given image part when drawing it.
• v-flip: Same for vertical flip. N.B.: Keep in mind that the flipped part should not be drawn on the opposite side, but still on the same coordinate as if it wasn’t flipped.

Example: {% highlight xml %}

... ... {% endhighlight %}

Hairs flag definition when covered or not by an helmet:

An 'hair_type' flag should tell which sub-image should be drawn if the player is equipped with a covering helmet (not every helmet would be hair-covering, like the bandana.). If no parameter is used, the sprite would be used for both.

Example: {% highlight xml %}

... {% endhighlight %}

Helmets should then indicates wether they're covering, defaulted to no if no parameter is given:

{% highlight xml %}

... head-santahat.xml ... {% endhighlight %}

Hair styles moved into the hair.xml file

Hairstyles definition, currently in the items.xml file, should be moved into the hair.xml. The configuration would become more logical:

Future hair-xml file sample: {% highlight xml %} ...

{% endhighlight %}

Discussion

{% highlight c++ %} class DBManager { public: enum DBTypes { ITEM_DB = 0, MONSTER_DB, ... };

DBManager() { init(); }

~DBManager() { deinit(); }

void init() { mItemDB = new itemDB(...); mMonsterDB = new MonsterDB(...); ... }

void deinit();

bool exist(DBTypes type, int id) const;

ItemInfo& get(int id) const { return mItemDB::get(id); }

ItemInfo& get(std:string name) const { return mItemDB::get(name); }

MonsterInfo& get(int id) const { return mMonsterDB::get(id); }

MonsterInfo& get(std:string name) const { return mMonsterDB::get(name); }

...

protected: /** Logs any eAthena specific ID problems */ static void checkeAthenaSpecificID();

private: ItemDB *mItemDB; MonsterDB *mMonsterDB; ... }; {% endhighlight %}