Modding:Defining Names

From SkyCorp Global
Revision as of 01:52, 25 February 2026 by SkyCorp (talk | contribs) (Document how to use initial values name for entity mods)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This page will detail some general information about how names are defined for mods.

Most situations will fit into one of the following patterns:

Simple Monster Mod - Static Name

A simple monster mod (no code) who always has the same name can do something like this:

{
   ...,
   "name": "Harpy"
   },
   ...
}

See Spider or SCLab for examples.

Entities - Static Name

Physical objects (ex: a painting) probably just need a single name, in which case they will not define a dynamic function and just use use the 'literalString' functionality.

{
   ...,
   "name":
   {
      "literalString": "Fox Painting"
   },
   ...
}

Example: Radio

Entities - Static Name

A second option for setting names is to use the initial name field:

{
  ...,
  "initialValues":
  {
	"name": "Fox Painting",
	...
  },
  ...
}

The initial name will set the object's initial name, but let other functions modify it. This is ideal if the entity will later on end up owning the player or might otherwise have a name change during gameplay. Basically, consider this a softer version of setting a name that tries to respect existing game logic, whereas the name function override described above is a harder version which will override other game functionality.

Advanced Monsters - Static Name

Most monsters don't change names. In this case, it is fine to use the 'initialValues' to set their base name. This has the advantage that when the UI name changes, the existing logic will handle this because name is not being overridden. For instance, when the monster sleeps, or becomes your owner. Example:

{
  ...,
  "initialValues":
  {
	"name": "Wyvern",
	...
  },
  ...
}

Example: Wyvern Shemale

Advanced Monsters - Personal Name

You may want to have a monster appear to be generic at first, but use a personal name once they become the player's owner or in gametext. In this case, you can use the personal name feature:

{
  ...,
  "initialValues":
  {
	"name": "Fox",
	...
  },
  "personalName": {
    "literalString": "Tina"
  },  
  "pronoun": {
    "literalString": "she"
  },
}

Advanced Monsters - Random Name

You may want to have many monsters of a specific type (ex: Fox), but each of those monsters have their own individual random name (ex: Veronica, Amy, etc). In this case, you can use the random name feature:

{
  ...,
  "initialValues":
  {
	"name": "Fox",
	...
  },
  "usesRandomizedName": {
    "literalBoolean": true
  },  
  "pronoun": {
    "literalString": "she"
  },
}

Pronoun is also set so that the correct name gender will be pulled from the random list.

Example: SetOwnerWithScene

Custom (Entity or Adv. Monster)

You can also completely override how name is shown and displayed by implementing name(nameType)

function name(nameType)	
	if nameType == NameType.UI then
		return "Blep-Button";
	end
		
	if nameType == NameType.GameText then
		return "Blep-Personal";
	end
	
	return "Blep-General"; 
	-- For testing purposes only.  In a real situation, the
	-- UI and Unspecified types should usually be the same thing.
	-- Ex: UI&Unspecified is "Fox" and GameText is "Veronica"
end

More practically, for advanced monsters, you could also set the name normally, and when needed, override it in certain circumstances, ex:

function name(nameType)	
	if blepping == true then
		return "Blepper";
	end
	
	return this.defaultGetName(nameType);
end

Most mods won't need to override the name function like this though to accomplish normal game behavior.