Button structures:
005187E8 = ButtonSet button_sets[0xfa]
ButtonSet: (Size 0xc) - Corresponds to Firegraft's Units tab
0x0     u32 button_count
0x4     Button *buttons
0x8     u16 linked_button_set?
0xa     u16 padding?

Button: (Size 0x14) - Firegraft's Button Sets tab
0x0     u16 pos
0x2     u16 icon_id
0x4     func *Condition(), ecx var, edx local_player, arg 1 Unit *unit
0x8     func *Action(), ecx var, edx shift_down
0xc     u16 cond_var
0xe     u16 act_var
0x10    u16 enabled_string_id
0x12    u16 disabled_string_id

These are hardcoded in the exe, and the modloader can just change these values at any point when the
game is running.
I don't have a mapping of function address - meaning for the conditions/actions though.

---

Status screen:

005193A0 = StatusUiFunc status_screen[0xe4]
StatusUiFunc: (Size 0xc) - Firegraft's Units tab
0x0     u32 debug_id
0x4     func *DoesNeedRedraw()
0x8     func *Draw(), ecx Control *ctrl

Pretty much same idea with hardcoded data/function pointers as with buttons.

---

Dat requirements:

Units: 00514178
Orders: 00514CF8
Tech use: 00514A48
Tech research: 00514908
Upgrades: 005145C0

These are arrays of u16 describing the dat requirements in the following format:
   u16 unused/0
{
   u16 dat_id
   u16 opcodes[]
   u16 0xffff
}
   u16 0xffff

Opcodes smaller than 0xff00 are unit ids (Always unit ids) that the player has to own, other opcodes
are:
   0xff01 = or,
   0xff02 = Current unit is [+1],
   0xff03 = Has unit [+1],
   0xff04 = Has addon [+1] attached,
   0xff05 = Is not lifted,
   0xff06 = Is lifted,
   0xff07 = Is not busy building (Train/tech/upgrade/addon),
   0xff08 = Is not constructing addon,
   0xff09 = Is not teching,
   0xff0a = Is not upgrading,
   0xff0b = Is not constructing building,
   0xff0c = Has no addon,
   0xff0d = Has no nydus exit (Or anything other things, as it's an union)
   0xff0e = Has hangar space,
   0xff0f = Tech is researched,
   0xff10 = Only if has no nuke
   0xff11 = Only if not burrowed or ai controlled,
   0xff12 = Only if not landed building,
   0xff13 = Only if landed building,
   0xff14 = Only if can move,
   0xff15 = Only if can attack,
   0xff16 = Only if worker,
   0xff17 = Only if can liftoff,
   0xff18 = Is transport,
   0xff19 = Only if powerup,
   0xff1a = Only if subunit,
   0xff1b = Only if has spider mines (Or addons etc),
   0xff1c = Is hero,
   0xff1d = Only if can rally or rclick (Can hold position..?),
   0xff1e = Allow on hallucinations,
   0xff1f = Upgrade level based jump:
       jumps to next 0xff20 if level == 1 and 0xff21 if level >= 2.
   0xff22 = Disabled,
   0xff23 = Blank,
   0xff24 = Only if bw,
   0xff25 = Only if tech [+1] researched,
   0xff26 = Only if burrowed,
   0xffff = end

Not all of these apply to units and not all of these apply to non-units. No notes on which work
where. You could look at the switches in functions 0046E1C0 (units) and 0046D610 (non-units)

I don't know if firegraft does this, but since the dat requirements are not behind a pointer,
adding more datreq opcodes than there originally were would cause unrelated data to be corrupt.
So it would be a good idea to search exe code for any references that access datreqs and change them
to refer to elsewhere instead of trying to fit the new datreq data where it originally was.

---

Exe edits:
You can extract the exe edit file from firegraft mpqs, they are text files describing memory
patches.