Tutorial Reading a Party Member

Tutorial: Reading a Party Member

Ask what one monster in the party actually is — its species, its typing, its level, its HP — from any event or item script.

The two readers

There are two per-slot readers, and the difference between them is worth holding onto:

	answers
get_mon_ext(slot, field)	what your project declared about this individual — the mon_fields you invented
get_mon_field(slot, name)	what the engine derived about it

Everything else is party-wide. party_has, party_has_type and party_count answer questions about the whole team, never about the one in front of you.

The names

get_mon_field takes a slot and one name from a fixed list:

name	answers
"species"	the bare species id
"type1" / "type2"	the individual's resolved types
"level"	its level
"hp" / "maxhp"	current and max HP

let kind = get_mon_field(slot, "type1")
if kind == "ROCK" {
  say("The stone remembers this one already.")
  return true
}

That's the whole list. It is deliberately closed — the rest of a monster's internals are engine bookkeeping, and freezing them into a public surface would make them impossible to change later.

Resolved types, not the species' own

This is the part that matters most.

type1 and type2 are what your effective_types kernel wrote, not what the species table says. If your project retypes individuals — a shrine that imprints an element, a regional form, a curse — a script reading type1 sees the same typing the battle engine uses. It agrees with the fight.

A monster with one type answers that same type for both halves rather than an empty string, which is how the underlying data stores it. So you never have to special-case a mono-type.

Why you want it

Say your project has a site that imprints an element onto whichever monster you bring, and imprinting an element a monster already has is a wasted trip. Without a per-slot read, the best you can do is ask "does anything in my party have this element?" and refuse if so — which turns a player away because of some unrelated monster three slots down, for a reason nothing on screen explains.

With get_mon_field you ask about the one you're holding:

if get_mon_field(slot, "type1") == "ROCK" or get_mon_field(slot, "type2") == "ROCK" {
  say("The stone has nothing to teach this one.")
  return true
}
set_mon_ext(slot, "imprint", "rock")
say("Something in the rock settles into it.")
return true

The same read is what lets an appraisal tool report what a monster is underneath an imposed type, instead of only reporting that something was imposed.

Typos fail loudly

A bad slot, or a name that isn't on the list, is a runtime error at the call — the event aborts and says so. It does not quietly answer 0, which for "level" or "hp" would be a very convincing lie.

Read-only

There is no set_mon_field. Writing to an individual goes through set_mon_ext, which is your own declared surface; species, level and HP belong to the engine.

Pairs with Per-Individual Fields and Item Field Scripts — a use_on item hands you the slot, and this is what you do with it. Gate: --extauthtest.