Party HP/SP Bars Guide
Each party member's gauge is split into an HP half on top and an SP half underneath, with the SP number beside it in the party window. The split bar reaches the detached mini widgets too.
One bar becomes two.
Both fills are the client's own: HP #16EA25, SP #1D65DB, the values the gauge is seeded with at +0x84 and +0x88.
Half of this patch is on your server
The client can draw an SP bar, but it has nothing to draw with until the server tells it each member's SP. Stock rAthena never sends that. So this is two changes that only work together.
SHOW_PARTY_SP build flag makes the map-server emit the 22-byte 0x0BAB party packet carrying sp and maxsp, adds the @spbar command, and pushes every same-map member's HP and SP both ways on map load, then once more a second later so a row that was still being built gets the values.SHOW_PARTY_SP sends 0x0BAB to every party member. A stock 2025-07-16 client parses that packet and throws it away, so party HP bars stop updating for that player altogether. Hand out the patched exe and flip the build flag in the same maintenance window: whichever half is missing, party bars are degraded until both are in place.
1 Apply the server patch
The patch is one file in the WARP0716 repository, under examples/ShowPartySP/, and a WARPGATE install already has it on disk, because the WARP tab installs the whole repository. Otherwise download it from GitHub. It is cut against rAthena master and proven on e985006 (2026-08-21): it applies cleanly there and the map-server builds with it. From the root of your rAthena tree:
git apply --check /path/to/ShowPartySP.server.patch
git apply /path/to/ShowPartySP.server.patchIt touches six files in ten hunks: conf/groups.yml, src/custom/defines_pre.hpp, src/map/clif.cpp, src/map/packets_struct.hpp, src/map/pc.hpp and src/map/atcommand.cpp. Always run --check first; it tells you about a bad apply before it happens rather than after. If your tree is far from that commit and a hunk refuses, the patch is short enough to read as a diff and apply by hand. It adds only #define SHOW_PARTY_SP to defines_pre.hpp; it does not touch your PACKETVER.
2 Rebuild and restart the map-server
The flag is compile-time, so the running binary has to be replaced: rebuild the map-server, then stop and start it. An unchanged binary sends no SP no matter what the client does.
Check it took before you go further: log in on a GM account and type @spbar. A rebuilt server answers Your SP is now hidden from the party, and a second @spbar puts it back. @spbar is Unknown Command means the old binary is still running, or the build wrote its output somewhere other than the folder you start the server from. Use a GM account for this: an ordinary player in group 0 has no spbar grant, so the client just says the text out loud either way.
3 Tick Party HP/SP Bars (Reforged) in WARP and apply
Load your clean 2025-07-16 Ragexe (build 175220998) in WARP, tick Party HP/SP Bars (Reforged) under UI CUSTOMIZATION along with every other patch you normally apply, then press Apply Patches. WARP writes a new exe and never edits the one you hand it.
Do not run WARP over an exe you already patched. A second pass gives you stock plus only the patches ticked this time, so everything from the earlier round is dropped. Always start from the clean exe. The apply then asks a few questions, all covered below, and all optional.
4 Say yes to the mini party backgrounds
Near the end of the same apply, the patch offers three replacement backgrounds for the detached mini party widgets, the small party panels you drag out of the party window. Answer Yes, point it at your client folder, and they are copied as soon as the exe is written. Skip it if you never detach the widgets. Why the backgrounds need replacing covers what the three files are and how to undo them.
These are loose files, so the exe needs Read data folder first as well, in the DATA CUSTOMIZATION group. It is a recommended patch and it is in the community recommended profile, but without it the client keeps reading the originals out of data.grf and nothing changes.
What the patch asks you
| Question | Default | What it changes |
|---|---|---|
| SP number | Show the number | Two choices: Show the number or Bar only, no number. The split bar is unaffected either way. A row shows no number until real SP arrives for it, because every gauge starts on a max SP seed of 1. |
| Bar colours | Keep the native colours | Two choices: Keep the native colours (stock green HP over blue SP, and no colour code is written at all) or pick your own, which opens the four pickers below. Either way a bar under 25% HP still turns red, so the low-HP warning is never lost. |
| Your HP bar colour | Native | The top half of your own row. |
| Other members' HP bar colour | Native | The top half of everyone else's row. |
| Your SP bar colour | Native | The bottom half of your own row. |
| Other members' SP bar colour | Native | The bottom half of everyone else's row. Giving yourself different colours from everyone else is what makes your row easy to find in a full party. |
| Copy the mini party backgrounds | Yes | Offers the three widget backgrounds that have room for the taller bar. |
| Where to put the backgrounds | Beside the patched exe | Where those three files are written. Point it at your client folder to use them straight away. |
Why the backgrounds need replacing
The mini party widgets draw the same gauge, so they get the same split bar. They get the bar, not the number: the mini widgets draw no HP number either. Their background is a texture, not something the exe can resize, and the stock one is 37 pixels tall with the gauge sitting at y23. A 5px bar fits. A 12px bar ends flush with the frame.
C0 AF C0 FA C0 CE C5 CD C6 E4 C0 CC BD BA, which Windows shows as À¯ÀúÀÎÅÍÆäÀ̽º. That mojibake is the correct name. Let step 4 create the folder, or copy the name off an interface folder you already have under data/texture/. A folder you type as Korean characters is a different folder and the client never reads it.
The three bundled files are the client's own, grown from 37 pixels to 44 by repeating a single fill row seven times, which leaves both border lines and all four rounded corners exactly as they were:
renewalparty folder and the client falls back to the originals inside data.grf. Nothing was written into the archive.
@spbar, for players who would rather not show it
The server half adds @spbar, a per-player toggle, granted in conf/groups.yml to Super Player (group 1). SP is shared by default: the first @spbar hides it, the next shows it again, and the server says which way it went in chat. It is a session setting, not a saved one, so it resets to shown on the next login. While a player is hiding, their SP is sent as sp=0, maxsp=1 rather than being withheld, which matters more than it looks: the client's dual gauge only renders either half when both maximums are non-zero, so sending nothing at all would blank their HP bar too.
If your normal players sit in group 0, the default group for every new account, add spbar: true to that group's Commands: block yourself, or the command does nothing for them and the text is spoken in chat instead. A GM account needs no grant: the Admin group carries all_commands.
Troubleshooting
0x0BAB. The build flag is missing, or the map-server was not rebuilt after applying the patch.@spbar off.@spbar again to show it, if their group has the command.PARTY_AREA_WOS), so this is the server's send target, not a client setting. The patch already pushes every same-map member's HP and SP both ways on map load and once more a second later, so this bites members who move away afterwards.data.grf..epi manifest WARP writes beside the patched exe (same name, .epi extension) and search it for ShowPartySP. That is the patch's script id: the tick box reads Party HP/SP Bars (Reforged), the manifest records the id, which never changes. No ShowPartySP in the file means it did not apply, so run WARP again from the clean exe with the box ticked.