Quote:
Originally Posted by JellyBitz
You could try to check the region from character location directly.
They are pretty close to make a quick check about it.
I left here a quick example to detect if it's inside some fortress:
|
You should consider decomposing the RID bits into it's 3 components.
Code:
//(MSB) (LSB)
// | 15 | 14 | 13 | 12 | 11 | 10 | 09 | 08 | 07 | 06 | 05 | 04 | 03 | 02 | 01 | 00 |
// | DB | Z (0-127) | X (0 - 255) |
// DB = DungeonBit
Build a struct that access those Information from the backing field (ushort).
If that is to complicated you are lucky because altho we don't have language features to create bit fields in C# we can create a make-shift union with StructLayout because the major components happen be 8 bits.
Code:
[StructLayout(LayoutKind.Explicit)]
private struct RID : IEquatable<RID>
{
private const int DUNGEON_MASK = 0b10000000_00000000;
[FieldOffset(0)]
private ushort _value;
[FieldOffset(0)]
private byte _x;
[FieldOffset(1)]
private byte _z;
public bool IsDungeon => (_value & DUNGEON_MASK) != 0;
public byte X => _x;
public byte Z => _z;
public RID(byte x, byte z)
{
_value = 0;
_x = x;
_z = z;
}
public RID(ushort value)
{
_x = 0;
_z = 0;
_value = value;
}
public RID(short value)
{
_x = 0;
_z = 0;
_value = unchecked((ushort)value);
}
public override string ToString() => $"{_value} [{_x}x{_z}]";
public override int GetHashCode() => _value.GetHashCode();
public bool Equals(RID other) => _value == other._value;
public override bool Equals(object obj) => obj is RID other && this.Equals(other);
public static bool operator ==(RID left, RID right) => left.Equals(right);
public static bool operator !=(RID left, RID right) => !left.Equals(right);
public static implicit operator ushort(RID id) => id._value;
public static implicit operator short(RID id) => unchecked((short)id._value);
public static implicit operator RID(ushort id) => new RID(id);
public static implicit operator RID(short id) => new RID(id);
}
This is old code and I didn't care to implement any fancy logic to create a Dungeon RID at that time and I'll leave the rest as homework to you.
Now onto the topic...
Quote:
Originally Posted by #KB
if ignored the whole packet 0x385F gameserver won't recognize that there's a fortresswar and you won't even be able to check if theres a running fortresswar or no, i believe it is something related to 0x385F.
|
0x385F - SERVER_AGENT_SIEGE_UPDATE has a lot of SiegeUpdateTypes. It manages everything the client knows about fortress war but it does not specify the suit a given character is wearing. By default every character in a siege region during war period is wearing the green suit. Siege period is controlled by 0x385F. But the color of the suit is determined by the guild information about the other character, the client adjusts this automatically.
The left picture shows the character after spawn injection (0x3015).
The right picture shows the character after guild assign injection (0x30FF).
FLAGWAR (CTF) and BARENA (Battle Arena) are different tho. This is mostly off the top of my head because I didn't bother checking but here the suit is determined by the PKFlag from the spawn packet. The only proof I currently have for that is, that UIIT_MSG_FLAGWAR_PICKUP_MASTERKEY is only shown if the PKFlag of your player is the same as specified in the message (packet) which I assume to be from the triggering player...
There is no packet I know off, that updates the PKFlag of an entity in the client.
So with all that out of the way...
Quote:
Originally Posted by #KB
Yea recently i recognized that, no event no suit, but it is still there's a packet is being sent to the client to switch the player's uniform  |
I don't know any packet that does that and I've analyzed, named and documented about 1000 of them.
Quote:
Originally Posted by #KB
i will have to send 0xB070 everytime someone trying to teleport to the specific region.
|
This is currently your easiest option.
Now we come to the advanced/experimental solution.
Code:
// 0 = Green
// 3 = Red
// 4 = Blue
/setoptimizecloth 0
/setoptimizecloth 3
/setoptimizecloth 4
The GM console command /setoptimizecloth is able to do just what you want and an easy entry to reverse engineer and replicate how and where the client calls 00A60F90. Being able to call this from a custom packet is the first step. But every equipment change remove this effect. A more advanced way would be to hook 9DB940. This function evaluates whether or not optimized clothing should be applied whenever equipment changes. You may add your own logic to it to work with your World- or RegionIDs.
