using System.Buffers.Binary;
using AcDream.Core.Net.Packets;

namespace AcDream.Core.Net.Messages;

/// <summary>
/// Retail character-delete request and server acknowledgement, both riding
/// opcode <c>0xF655</c>.
///
/// <para>
/// Wire layout ported from retail <c>Proto_UI::SendDeleteCharacter</c> at
/// <c>0x00546b30</c>: the opcode, then <c>AC1Legacy::PStringBase&lt;char&gt;::Pack</c>
/// of the account id as a String16L, then a trailing u32 written directly
/// after the packed string (<c>*(uint32_t*)var_4 = arg2</c>):
/// </para>
///
/// <code>
///   u32       opcode            (0xF655)
///   String16L accountName
///   u32       characterSlot     (NOT the character guid)
/// </code>
///
/// <para>
/// The caller, <c>CPlayerSystem::DeleteCharacter</c> at <c>0x0055f830</c>,
/// resolves that trailing u32 from the target character's guid via
/// <c>CharacterSet::GetSlot(persistentData + 4, guid)</c> before sending —
/// retail deletes by **account + SLOT INDEX**, never the character guid.
/// This builder takes the already-resolved slot; resolving a selected
/// character to its slot is Runtime selection-state work (Campaign LA
/// slice LA7b), not this file's job.
/// </para>
///
/// <para>
/// The server's acknowledgement reuses the same opcode with no trailing
/// payload — ACE's <c>GameMessageCharacterDelete</c> constructs a bare
/// 4-byte body
/// (<c>ACE.Server/Network/GameMessages/Messages/GameMessageCharacterDelete.cs</c>,
/// base constructor called with <c>bodyLength: 4</c> and no further
/// <c>Writer.Write</c> calls). holtburger's inbound dispatcher
/// (<c>holtburger-protocol/src/messages/game_message/unpack.rs:50-58</c>)
/// disambiguates request vs. ack the identical way we do here — a request
/// has bytes remaining after the opcode, the ack does not.
/// </para>
///
/// <para>
/// Routing note for LA7b: retail transmits this request via
/// <c>Proto_UI::SendToLogon</c> (the restore request rides
/// <c>SendToControl</c>); ACE sends its acknowledgement and the follow-up
/// refreshed CharacterList on <c>GameMessageGroup.UIQueue</c>.
/// </para>
///
/// <para>
/// After the ack, ACE immediately follows with a fresh <see cref="CharacterList"/>
/// so the roster reflects the character's new pending-delete state
/// (<c>CharacterHandler.CharacterDelete</c>,
/// <c>ACE.Server/Network/Handlers/CharacterHandler.cs:322</c>, inside the
/// <c>SaveCharacter</c> success callback). Requesting and re-rendering that
/// refreshed roster belongs to LA7b's Runtime selection state — this file
/// only builds the request and recognizes the ack.
/// </para>
/// </summary>
public static class CharacterDelete
{
    public const uint Opcode = 0xF655u;

    /// <summary>
    /// Build the body bytes for an outbound <c>CharacterDelete</c> request.
    /// Layout: opcode(4) + String16L(accountName) + characterSlot(4).
    /// </summary>
    public static byte[] BuildRequestBody(string accountName, uint characterSlot)
    {
        ArgumentNullException.ThrowIfNull(accountName);
        var w = new PacketWriter(32);
        w.WriteUInt32(Opcode);
        w.WriteString16L(accountName);
        w.WriteUInt32(characterSlot);
        return w.ToArray();
    }

    /// <summary>
    /// Returns whether a complete game-message body is the server's
    /// delete acknowledgement — the canonical four-byte opcode-only form
    /// ACE emits. A fresh <see cref="CharacterList"/> follows separately
    /// and is not this method's concern.
    /// </summary>
    public static bool IsAcknowledgement(ReadOnlySpan<byte> body) =>
        body.Length == sizeof(uint) &&
        BinaryPrimitives.ReadUInt32LittleEndian(body) == Opcode;
}