Modding:MainScreen - Revision history

SkyCorp: Add claim ownership sample mod link

2026-02-04T02:04:57Z

Add claim ownership sample mod link

← Older revision		Revision as of 02:04, 4 February 2026
Line 135:		Line 135:

	Added in r56.1		Added in r56.1

			Sample code: [https://skycorp.global/skyscript/mods/v/96/sample-claim-ownership Claim Ownership Sample Mod]

	=== static void changeToSimpleDynamicOptionsScene([[Modding:DynamicOptions\|DynamicOptions]] dynamicOptions) ===		=== static void changeToSimpleDynamicOptionsScene([[Modding:DynamicOptions\|DynamicOptions]] dynamicOptions) ===

SkyCorp: Link some sample code

2026-01-16T00:46:40Z

Link some sample code

← Older revision		Revision as of 00:46, 16 January 2026
Line 141:		Line 141:
	Unlike many other types of scenes, Simple Dynamic Options is similar to a 'continue' scene. That is, it will not clear text from the UI by itself. Furthermore (and unlike a continue scene), it also does not clear existing buttons by itself. It will, however, immediately add any buttons registered with the dynamic options object.		Unlike many other types of scenes, Simple Dynamic Options is similar to a 'continue' scene. That is, it will not clear text from the UI by itself. Furthermore (and unlike a continue scene), it also does not clear existing buttons by itself. It will, however, immediately add any buttons registered with the dynamic options object.

	~~Example~~: DynamicOptionsExample		Sample: [https://skycorp.global/skyscript/mods/v/91/sample-dynamic-options-example DynamicOptionsExample]

	Added in r56.1		Added in r56.1

SkyCorp: clarification

2026-01-16T00:35:39Z

clarification

← Older revision		Revision as of 00:35, 16 January 2026
Line 139:		Line 139:
	Changes to simple dynamic options scene.		Changes to simple dynamic options scene.

	Unlike many other types of scenes, Simple Dynamic Options is similar to a 'continue' scene. That is, it will not clear text from the UI by itself. Furthermore, it also does not clear existing buttons by itself. It will, however, immediately add any buttons registered with the dynamic options object.		Unlike many other types of scenes, Simple Dynamic Options is similar to a 'continue' scene. That is, it will not clear text from the UI by itself. Furthermore (and unlike a continue scene), it also does not clear existing buttons by itself. It will, however, immediately add any buttons registered with the dynamic options object.

	Example: DynamicOptionsExample		Example: DynamicOptionsExample

SkyCorp: documentation for changeToSimpleDynamicOptionsScene(...)

2026-01-16T00:34:58Z

documentation for changeToSimpleDynamicOptionsScene(...)

← Older revision		Revision as of 00:34, 16 January 2026
Line 137:		Line 137:

	=== static void changeToSimpleDynamicOptionsScene([[Modding:DynamicOptions\|DynamicOptions]] dynamicOptions) ===		=== static void changeToSimpleDynamicOptionsScene([[Modding:DynamicOptions\|DynamicOptions]] dynamicOptions) ===
			Changes to simple dynamic options scene.

			Unlike many other types of scenes, Simple Dynamic Options is similar to a 'continue' scene. That is, it will not clear text from the UI by itself. Furthermore, it also does not clear existing buttons by itself. It will, however, immediately add any buttons registered with the dynamic options object.

			Example: DynamicOptionsExample

	Added in r56.1		Added in r56.1

SkyCorp: New modding functions added to MainScreen

2026-01-16T00:31:57Z

New modding functions added to MainScreen

@@ Line 133: / Line 133: @@
 ==== function customAfterSceneScript = null ====
 Instead of doing default scene handling and going back to map, this function can be called instead.  This lets you do some other scene or action instead.
 Added in r56.1
 [[Category:LUA Class Reference]]

SkyCorp: Documentation for changeToClaimOwnershipScene

2026-01-03T04:11:14Z

Documentation for changeToClaimOwnershipScene

← Older revision		Revision as of 04:11, 3 January 2026
Line 81:		Line 81:
	Added in r56.1		Added in r56.1

			=== static void changeToClaimOwnershipScene([[Modding:Entity\|Entity]] potentialOwner, string textPrefix, bool withContinueScene, bool sleepAfterward, function customAfterSceneScript = null) ===
			Transitions to the claim ownership scene -- a scene that displays some intro text, information about the entity (presumably a dom/monster, but can be any entity), and then offers the player the ability to accept or reject them as their new owner. This scene already performs logic for handling if player is already owned by another dom and includes preset text variables.

			You don't need to re-define text variables for this function (most monsters currently don't), but if you wish to, you should redefine these:
			{\| class="wikitable"
			\|+
			!Text Variable
			!Purpose
			\|-
			\|<PREFIX>_CLAIM_START
			\|Initial text, shown regardless of whether player has been claimed by some other dom or not.
			\|-
			\|<PREFIX>_CLAIM_FAIL_ALREADY_OWNED
			\|After the initial text, the NPC will check if player is owned by someone else. There are multiple ways for this detection to happen, and this particular field overrides all of them.
			If player is already owned by another dom, this text can be optionally defined if the NPC has some unusual way of identifying ownership over the player. Generally though it's safe to leave this undefined, and one of the standard identification methods below will be used instead.
			\|-
			\|<PREFIX>_CLAIM_FAIL_ALREADY_OWNED_DETECT_SMELL
			\|If your dom can be smelled by any other dom
			\|-
			\|<PREFIX>_CLAIM_FAIL_ALREADY_OWNED_DETECT_COLLAR_SLAVE
			\|Slave collar if player is wearing one
			\|-
			\|<PREFIX>_CLAIM_FAIL_ALREADY_OWNED_DETECT_COLLAR_PET
			\|Pet collar if player is wearing one
			\|-
			\|<PREFIX>_CLAIM_FAIL_ALREADY_OWNED_DETECT_GENERIC
			\|Generic fallback if none of the above apply
			\|-
			\|<PREFIX>_CLAIM_FAIL_ALREADY_DETECT_END
			\|The above detection text is then followed by this
			\|-
			\|<PREFIX>_CLAIM_OK
			\|Scene for player accepting ownership
			\|-
			\|<PREFIX>_CLAIM_FAIL_RESIST
			\|Scene for player rejecting ownership
			\|}

			==== [[Modding:Entity\|Entity]] potentialOwner ====
			The entity (probably a monster) who is trying to claim ownership over player

			==== string textPrefix ====
			Defines the <PREFIX> part of the text keys, per the above table.

			==== bool withContinueScene ====
			If true, prepends a continue scene prior to switching the scene to the TF sequence scene. (Set true if you already have text on screen player should have a chance to read first)

			==== bool sleepAfterward ====
			If true, monster will go to sleep after this scene. (This is ignored if customAfterSceneScript parameter is defined)

			==== function customAfterSceneScript = null ====
			Instead of doing default scene handling and going back to map, this function can be called instead. This lets you do some other scene or action instead.

			Added in r56.1
	[[Category:LUA Class Reference]]		[[Category:LUA Class Reference]]

SkyCorp: Added documentation for changeToForcedTransformationScene(...)

2025-12-31T04:04:21Z

Added documentation for changeToForcedTransformationScene(...)

← Older revision		Revision as of 04:04, 31 December 2025
Line 10:		Line 10:

	Added in r35		Added in r35

			=== static void changeToForcedTransformationScene(string prefix, [[Modding:Species\|Species]] species, bool allowEscape = true, function switchSceneAfterTransformationSequence = null, function teleportPlayerOnFinish = true, bool resetLustHP = true, function customOutputFunction = null, bool withContinueScene = true) ===
			Using this, you can play the forced transformation sequence scene. This is primarily useful if you are doing a forced transformation sequence that should be triggered from customized monster logic (ex: not normal defeat logic) or triggered from an arbitrary object.

			[https://skycorp.global/skyscript/mods/v/90/sample-fox-painting Sample code]

			Note there are several other methods you may want to consider instead of this:

			* If you just want to cause a single body part to be transformed at a time, see [[Modding:Species#void causeTF()\|causeTF()]]
			* If you do want a multi-step tf sequence, and are already triggering this on player defeat to a monster, you probably want to use the normal player defeat logic. This will also check to see if the player is TF'able before trying to TF the player, as well as updating the monster's state to sleep, and inseminating the player if configured. You can trigger this logic on defeat by either
			** Not defining the doMonsterVictory function in the json, or
			** Defining the doMonsterVictory function, but inside your custom function, calling doMonsterVictoryDefault() to do normal logic

			If you do want to call this function, then you'll need to define the following text variables:
			{\| class="wikitable"
			\|+
			!Text Variable
			!Purpose
			\|-
			\|<PREFIX>_PLAYER_DEFEAT
			\|Initial text shown to player on defeat
			\|-
			\|<PREFIX>_DEFEAT_TFTIME
			\|Text shown every step player is being tf'ed
			\|-
			\|<PREFIX>_DEFEAT_TFTOTAL
			\|Text shown at conclusion of tf
			\|-
			\|<PREFIX>_DEFEAT_TFESCAPE_SUCCESS
			\|Player tried to escape, and did
			\|-
			\|<PREFIX>_DEFEAT_TFESCAPE_FAILURE
			\|Player tried to escape, but failed
			\|-
			\|<PREFIX>_DEFEAT_TFACCEPT
			\|Player did not try to escape / accepted the tf
			\|}
			Function parameters:

			==== string prefix ====
			Defines the <PREFIX> part of the text keys, per the above table.

			==== [[Modding:Species\|Species]] species ====
			Which TF is being done

			==== bool allowEscape = true ====
			If escape is possible. Button will still be shown, but it will be impossible to escape regardless of lust level.

			==== function switchSceneAfterTransformationSequenceScript = null ====
			This can be used to transition to a different scene after the sequence, instead of back to the normal mapscene.

			If not null, called to determine logic for switching scene. (If not set, just goes back to mapscene). The bool indicates if the full tf played out (false if the player escaped mid-tf)

			(Most users will just leave this as 'null')

			==== function teleportPlayerOnFinish = true ====
			Whether to teleport player to a respawn position after the sequence finishes

			==== bool resetLustHP = true ====
			On full tf: whether to reset lust + hp.

			On early escape: whether to reset lust.

			==== function customOutputFunctionScript = null ====
			If set, this function is called with the text key suffix each tf instead of outputting monsterPrefix+suffix text. (Most users will just leave this as 'null')

			==== bool withContinueScene = true ====
			If true, prepends a continue scene prior to switching the scene to the TF sequence scene. (Set true if you already have text on screen player should have a chance to read first)

			Added in r56.1

	[[Category:LUA Class Reference]]		[[Category:LUA Class Reference]]

SkyCorp: SkyCorp moved page MainScreen to Modding:MainScreen

2025-06-17T07:28:42Z

SkyCorp moved page MainScreen to Modding:MainScreen

← Older revision

Revision as of 07:28, 17 June 2025

SkyCorp: /* Public Methods */

2018-12-27T23:00:43Z

Public Methods

← Older revision		Revision as of 23:00, 27 December 2018
Line 5:		Line 5:

	Unlike io.write, will only accept one string parameter, making it useful to get around the [[LUA Implementation Limitations & Notes\|LUFA garbage array bug]].		Unlike io.write, will only accept one string parameter, making it useful to get around the [[LUA Implementation Limitations & Notes\|LUFA garbage array bug]].

			=== static void continueSceneToMapScene() ===
			Removes screen buttons (but not shown text). Will display one 'continue' button, which when pressed, will redirect flow back to the map (/ player navigation). This is a shortcut into the game's scene flow control that handles most cases, but for instance, if you wanted to continue then go to somewhere else, you should bug Skye to expose the full scene control system.

			Added in r35

	[[Category:LUA Class Reference]]		[[Category:LUA Class Reference]]

SkyCorp at 05:45, 30 December 2017

2017-12-30T05:45:31Z

← Older revision		Revision as of 05:45, 30 December 2017
Line 4:		Line 4:
	Output string to screen. Does not automatically add newlines.		Output string to screen. Does not automatically add newlines.

	Unlike io.write, will only accept one string parameter, making it useful to get around the LUFA garbage array bug.		Unlike io.write, will only accept one string parameter, making it useful to get around the [[LUA Implementation Limitations & Notes\|LUFA garbage array bug]].

	[[Category:LUA Class Reference]]		[[Category:LUA Class Reference]]