A name belongs to a unit type, so "this Marine, but with a different name" looks impossible. It is not, because the only unit whose name is ever on screen is the one currently selected.
- 1Reserve one map string longer than the longest name you will write, and take its address.
- 2Point that unit type's Map String field at it. When that field is not zero the game reads the name from the map's own strings instead of stat_txt.
- 3Each cycle read the currently selected unit, and write a new name into that string only when the selection has changed.
The rank works the same way: borrow one of stat_txt's existing rank entries and write into it.
There are two length constraints. The reserved map string must not be shorter than the names you write, and the borrowed rank entry's original text must be longer than what you write into it. Both show up later as "it broke when I added one longer name".
Call it once in afterTriggerExec and not inside a player loop: the selected unit is a per-machine value and does not belong in one. The unit's owner is read off the unit; the person clicking is this machine's own player id. They are different numbers.
If all you want is to rename the whole type rather than one unit, it is much cheaper. There are three routes and only the last one changes at runtime.
| 맵 에디터에서 바꾸기 | When the name never changes. |
|---|---|
| SetUnitsDat("Map String", 종류, 문자열) | Compile time, and it reads as data, which is easier to maintain. |
| wwrite(0x660260 + 2 * 종류, 문자열번호) | At runtime, in a single action. |
wwrite(0x660260 + 2 * $U("Terran Marine"), $T("\x08붉은 \x1F해병"));
// 종류가 변수일 때 / when the unit type is a variable
const q, r = div(unitType, 2); // 한 칸에 u16 두 개 / two u16 per dword
Trigger(r == 1, r.SetNumber(2)); // 0 아니면 2 / 0 or 2, never 1
wwrite_epd(EPD(0x660260) + q, r, strIndex);You will see that second line written with a 1, and it is wrong. wwrite_epd's third argument is a byte position - the address mod 4. The odd slot of a u16 array is 2, not 1. For the record 3 is valid too and straddles the dword boundary; that one case had a bug before euddraft 0.8.9.6 where the trailing byte was not written.
0x660260 works because it is the exception: it redirects one type's name to the map's own strings. Everything else that reads a name - a button tooltip, the kill feed - reads stat_txt.tbl, not a map string. For those the route is to patch the table and have dataDumper load it.
This is the unit panel. It is a different thing from putting a title beside a name in chat, and that does not come out of this.