140 lines
No EOL
6.6 KiB
Markdown
140 lines
No EOL
6.6 KiB
Markdown
# JELYHACK USECODE Analysis
|
|
|
|
## Scope
|
|
|
|
This note focuses on the currently exported pseudocode and byte-level decode for `JELYHACK` class `277` / class id `0x04D3`, especially its only non-zero event body: slot `0x01` (`use`).
|
|
|
|
Current generated pseudocode lives at:
|
|
|
|
- `USECODE/EUSECODE_extracted/pseudocode/JELYHACK/slot_01_use.txt`
|
|
- `USECODE/EUSECODE_extracted/pseudocode/JELYH2/slot_01_use.txt`
|
|
|
|
## Direct decompilation result
|
|
|
|
Current readable decompilation for `JELYHACK::use`:
|
|
|
|
```text
|
|
function jelyhack_use() /* entry=277 class_id=0x04D3 slot=0x01 */
|
|
{
|
|
entry:
|
|
set_info(0x0207, *(arg_06));
|
|
process_exclude();
|
|
return;
|
|
|
|
}
|
|
```
|
|
|
|
Byte-faithful decode of the same body:
|
|
|
|
```text
|
|
00D4: 5A init local_bytes=0x0
|
|
00D6: 5C symbol_info symbol=JELYHACK
|
|
00E2: 0B push_word_immediate value_u16=0x0207
|
|
00E5: 40 push_local_dword [BP+06h]
|
|
00E7: 4C push_indirect size=0x2
|
|
00E9: 77 set_info
|
|
00EA: 78 process_exclude
|
|
00EB: 5B line_number line_number=0x00DB
|
|
00EE: 50 ret
|
|
```
|
|
|
|
The parser still sees bytes after `ret`, but on the current readable pass they are intentionally elided because control has already returned. Those post-`ret` bytes are identical between `JELYHACK` and `JELYH2`, so they do not currently support any class-specific behavioral claim.
|
|
|
|
## What is directly supported
|
|
|
|
1. `JELYHACK` is not an active event hub in the same sense as `EVENT`, `NPCTRIG`, or `_BOOT` classes.
|
|
2. Its only non-zero slot is `0x01` (`use`), with `raw_event_entry_word = 0x002A`, `raw_code_offset = 0x00000001`, and body range `0x00D4..0x00FE` (`42` bytes).
|
|
3. The actual readable body before return is tiny: one `set_info(0x0207, *(arg_06))`, one `process_exclude()`, then return.
|
|
4. `JELYH2` is the same script body for practical purposes. The only pre-return differences are the symbol label string and line-number metadata; control flow and active ops are otherwise the same.
|
|
5. `JELYHACK` still exposes only the `referent` field on the descriptor side, which keeps it in the `referent-anchor` category rather than the event-bearing category.
|
|
|
|
## Comparison against the exported pseudocode corpus
|
|
|
|
The `JELYHACK::use` body is not unique. Normalizing away only the function header, the exact same readable body currently appears in these seven exports:
|
|
|
|
- `AVATAR/slot_01_use.txt`
|
|
- `GRAVITON/slot_01_use.txt`
|
|
- `IONIC/slot_01_use.txt`
|
|
- `JELYHACK/slot_01_use.txt`
|
|
- `JELYH2/slot_01_use.txt`
|
|
- `PLASMA/slot_01_use.txt`
|
|
- `WEA_BOOT/slot_01_use.txt`
|
|
|
|
That matters because it argues against a special-purpose `JELYHACK` event implementation. The more defensible reading is that this is one small generic `use` stub reused across several classes.
|
|
|
|
There is also a second useful comparison: other classes often start with the same `set_info(...); process_exclude();` prologue and then continue into much richer logic. `DATALINK::use` is a good example: it begins with the same opening but then expands into a larger branch-heavy routine. So the `set_info/process_exclude` pair is best treated as a common preamble, not the whole semantic payload of a class family.
|
|
|
|
## What `JELYHACK::use` most likely does
|
|
|
|
Current safest reading:
|
|
|
|
- It performs a small generic `use`-entry setup using info id `0x0207` and the dereferenced word at `arg_06`.
|
|
- It then marks the current process or handler for exclusion/suppression through `process_exclude()`.
|
|
- It does not itself implement the richer trigger logic one would expect from an active gameplay event script.
|
|
|
|
The unresolved part is the exact gameplay meaning of `set_info(0x0207, *(arg_06))`. The exported corpus shows this exact pattern in multiple unrelated classes, so `0x0207` currently looks more like a shared UI/message/interaction setup code than a JELYHACK-specific action.
|
|
|
|
## What it probably does not do
|
|
|
|
The current evidence argues against several stronger claims:
|
|
|
|
- It is probably not the main script that drives the JELYHACK gameplay behavior by itself.
|
|
- It is probably not the actual event-bearing payload that reaches the richer runtime opcode lanes recovered around `000d:208b`, `000d:21ed`, and `000d:22bc`.
|
|
- It is probably not a unique script template specialized only for the JELYHACK object.
|
|
|
|
## Relationship to JELYH2 and the surrounding island
|
|
|
|
`JELYHACK` and `JELYH2` remain the clearest referent-anchor twins in the extracted USECODE data:
|
|
|
|
- same lone live slot `0x01`
|
|
- same event-table row shape (`0x002A / 0x00000001`)
|
|
- same `42`-byte body length
|
|
- same readable `use` body before return
|
|
- same descriptor-side role: `referent-anchor`
|
|
|
|
This fits the broader neighborhood evidence already captured elsewhere:
|
|
|
|
- `JELYHACK` / `JELYH2` sit beside event-bearing neighbors such as `REE_BOOT`, `SURCAMEW`, and `SFXTRIG`
|
|
- those neighbors expose `event` or `eventTrigger` fields and carry materially richer behavior bodies
|
|
- the current best model is therefore still `referent anchor + neighboring event-bearing attachment`, not `JELYHACK as a standalone active event core`
|
|
|
|
## Comparison with nearby event-bearing neighbors
|
|
|
|
The generated pseudocode reinforces that split.
|
|
|
|
`REE_BOOT` slot `0x0A` and `SFXTRIG` slot `0x0A` diverge immediately from the JELYHACK body:
|
|
|
|
- they use `set_info(0x0211, *(arg_06))` instead of `0x0207`
|
|
- they perform status checks, helper calls, spawns, waits/suspends, and other active logic
|
|
- they therefore look like genuine event-bearing routines rather than passive anchor stubs
|
|
|
|
`DATALINK` slot `0x01` is also instructive in the other direction:
|
|
|
|
- it starts with the same `set_info/process_exclude` preamble
|
|
- but it then continues into a much larger routine
|
|
- so the shared opening is not enough to classify a body as anchor-only or event-bearing by itself
|
|
|
|
## Current best conclusion
|
|
|
|
The decompiled `JELYHACK::use` body is important mainly because it supports a negative result cleanly:
|
|
|
|
- `JELYHACK` is not hiding a large active event script in its only live slot
|
|
- its visible `use` handler is a minimal generic stub shared with several other classes
|
|
- the interesting gameplay semantics around the JELYHACK island are still more likely to live in neighboring event-bearing descriptors attached to the same referent context
|
|
|
|
So the current best human-readable model remains:
|
|
|
|
```text
|
|
anchor JELYHACK(referent)
|
|
anchor JELYH2(referent)
|
|
|
|
use:
|
|
set_info(shared_use_code_0x0207, deref(arg_06))
|
|
process_exclude()
|
|
return
|
|
|
|
actual island behavior:
|
|
likely carried by neighboring event-bearing attachments such as REE_BOOT / SURCAMEW / SFXTRIG
|
|
```
|
|
|
|
That is a stronger and cleaner claim than the older vague label `referent anchor`: the exported pseudocode now shows that the anchor really does have code, but the code is a tiny shared interaction stub, not the island's main behavior engine. |