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:

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:

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

JELYHACK is not an active event hub in the same sense as EVENT, NPCTRIG, or _BOOT classes.
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).
The actual readable body before return is tiny: one set_info(0x0207, *(arg_06)), one process_exclude(), then return.
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.
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:

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.

6.6 KiB Raw Blame History