PSwiki - Recent changes [en]

Add Waypoints and paths

Talad — Sun, 08 Nov 2026 17:33:34 GMT

← Older revision		Revision as of 17:33, 8 November 2026
Line 4:		Line 4:
	If you want to extend the path network in a certain direction, do this:		If you want to extend the path network in a certain direction, do this:

			0) Define the format of the new waypoint name:
			/path format Ghosts_{0}
	1) Walk on top of an existing waypoints and then use		1) Walk on top of an existing waypoints and then use
	/path start		/path start 0.5
	You have to be within 2 meters of the waypoint you want to start with.		You have to be within 2 meters of the waypoint you want to start with. The 0.5 will be the radius of the waypoint, if you don't specify it the radius will be 2 meters.

	2) Create new points with		2) Create new points with
	/path point add		/path point add
	3) Stop the new path and create a waypoint at the end with		3) Stop the new path and create a waypoint at the end with
	/path stop		/path stop 0.5
			Same as for start, the 0.5 will be the radius of the waypoint, if you don't specify it the radius will be 2 meters.

Character Variables

Talad — Sat, 31 Oct 2026 20:43:58 GMT

← Older revision		Revision as of 20:43, 31 October 2026
Line 5:		Line 5:
	\|'''Quest progress and cross-quest memory'''		\|'''Quest progress and cross-quest memory'''
	\|Records facts, choices, milestones, or counters that dialogue and other quests can check. Conditions can test whether a variable exists, matches a particular value, or falls within a numerical range. Dialogue and scripts can set or remove these records.		\|Records facts, choices, milestones, or counters that dialogue and other quests can check. Conditions can test whether a variable exists, matches a particular value, or falls within a numerical range. Dialogue and scripts can set or remove these records.
			Remembers access granted through quests. Examples include the '''Hydlaa winch.''' Records discoveries made during an active quest. Credit for defeating a tribe — '''<code><tribe_name>_vanquished</code>'''
	\|-		\|-
	\|'''~~Permission to enter restricted areas~~'''		\|'''scale: Permanent character size'''
	\|~~Remembers access granted through quests~~. ~~Examples include the '''Black Flame Temple''', '''Hydlaa winch''', '''spirit house''', '''Mansion Beyond'''—including temporary access—'''Lennston’s location'''~~, and ~~permission to '''see Gibbsite'''~~. ~~Entrances check these values before allowing access~~.		\|Applies an individual size multiplier on top of the character’s racial scale. For example, <code>1.5</code> means 50% larger and <code>0.5</code> means half size. Administrators can save or reset this size adjustment.
	\|-		\|-
	\|'''~~Quest exploration triggers~~'''		\|'''ghost: character gets the ghost shader'''
	\|~~Records discoveries made during an active quest. One concrete example checks whether the character~~ is ~~supposed~~ to ~~explore, then records that they '''found~~ the ~~entrance to the old mine'''.~~		\|A ghost shader is applied to the character.
	\|-
	~~\|'''Permanent~~ character ~~size — <code>scale</code>'''~~
	\|Applies an individual size multiplier on top of the character’s racial scale. For example, <code>1.5</code> means 50% larger and <code>0.5</code> means half size. Administrators can save or reset this size adjustment.
	\|-		\|-
	\|'''Magic, poison, and disease resistance'''		\|'''Magic, poison, and disease resistance'''
Line 20:		Line 18:
	\|'''Temporary resistance and other numerical bonuses'''		\|'''Temporary resistance and other numerical bonuses'''
	\|Spells and effects can temporarily modify the numerical value of a character variable, including resistances. Calculations see the modified value, and the character’s modifier summary displays these bonuses. These temporary adjustments use the same runtime system but do '''not inherently become permanent table values'''.		\|Spells and effects can temporarily modify the numerical value of a character variable, including resistances. Calculations see the modified value, and the character’s modifier summary displays these bonuses. These temporary adjustments use the same runtime system but do '''not inherently become permanent table values'''.
	\|-
	~~\|'''Pet energy — <code>pet_energy</code>'''~~
	\|Persists a pet’s current energy. Summoning consumes energy, eating restores it, and low energy triggers food-seeking or requests for food. It is also displayed in the pet interface. The maximum is calculated separately from the pet’s evolution/size.
	\|-
	~~\|'''Credit for defeating a tribe — <code><tribe_name>_vanquished</code>'''~~
	\|When the tribe loses its last building, participating players receive this variable. Its value is the number of buildings destroyed during that defeat, allowing quests or rewards to recognize the victory and potentially scale rewards.
	\|}		\|}
	There are also two pet-related entries worth distinguishing from active functionality:		There are also two pet-related entries worth distinguishing from active functionality:
Line 31:		Line 23:
	!Variable		!Variable
	!Current meaning/status		!Current meaning/status
			\|-
			\|'''Pet energy — <code>pet_energy</code>'''
			\|Persists a pet’s current energy. Summoning consumes energy, eating restores it, and low energy triggers food-seeking or requests for food. It is also displayed in the pet interface. The maximum is calculated separately from the pet’s evolution/size.
	\|-		\|-
	\|<code>pet_happiness</code>		\|<code>pet_happiness</code>

Character Variables

Talad — Sat, 31 Oct 2026 20:27:56 GMT

Created page with "{| class="wikitable" !Usage !Actual meaning |- |'''Quest progress and cross-quest memory''' |Records facts, choices, milestones, or counters that dialogue and other quests can check. Conditions can test whether a variable exists, matches a particular value, or falls within a numerical range. Dialogue and scripts can set or remove these records. |- |'''Permission to enter restricted areas''' |Remembers access granted through quests. Examples include the '''Black Flame Tem..."

New page

{| class="wikitable"
!Usage
!Actual meaning
|-
|'''Quest progress and cross-quest memory'''
|Records facts, choices, milestones, or counters that dialogue and other quests can check. Conditions can test whether a variable exists, matches a particular value, or falls within a numerical range. Dialogue and scripts can set or remove these records.
|-
|'''Permission to enter restricted areas'''
|Remembers access granted through quests. Examples include the '''Black Flame Temple''', '''Hydlaa winch''', '''spirit house''', '''Mansion Beyond'''—including temporary access—'''Lennston’s location''', and permission to '''see Gibbsite'''. Entrances check these values before allowing access.
|-
|'''Quest exploration triggers'''
|Records discoveries made during an active quest. One concrete example checks whether the character is supposed to explore, then records that they '''found the entrance to the old mine'''.
|-
|'''Permanent character size — <code>scale</code>'''
|Applies an individual size multiplier on top of the character’s racial scale. For example, <code>1.5</code> means 50% larger and <code>0.5</code> means half size. Administrators can save or reset this size adjustment.
|-
|'''Magic, poison, and disease resistance'''
|Stores resistance to '''Azure, Blue, Brown, Crystal, Dark, and Red Way''', plus '''Poison''' and '''Disease'''. Damage scripts use these values to reduce the relevant damage. The inspected formulas use <code>max(0, 1 − resistance / 200)</code>: a value of 100 halves damage; 200 prevents that damage.
|-
|'''Temporary resistance and other numerical bonuses'''
|Spells and effects can temporarily modify the numerical value of a character variable, including resistances. Calculations see the modified value, and the character’s modifier summary displays these bonuses. These temporary adjustments use the same runtime system but do '''not inherently become permanent table values'''.
|-
|'''Pet energy — <code>pet_energy</code>'''
|Persists a pet’s current energy. Summoning consumes energy, eating restores it, and low energy triggers food-seeking or requests for food. It is also displayed in the pet interface. The maximum is calculated separately from the pet’s evolution/size.
|-
|'''Credit for defeating a tribe — <code><tribe_name>_vanquished</code>'''
|When the tribe loses its last building, participating players receive this variable. Its value is the number of buildings destroyed during that defeat, allowing quests or rewards to recognize the victory and potentially scale rewards.
|}
There are also two pet-related entries worth distinguishing from active functionality:
{| class="wikitable"
!Variable
!Current meaning/status
|-
|<code>pet_happiness</code>
|The pet interface reads it, but then explicitly overrides happiness to '''100'''. Stored happiness currently has no effect on that display.
|-
|<code>pet_lastfed</code>
|Existing database rows contain timestamps for the last feeding. I found '''no reader or writer in the current source''', so it appears to be leftover data rather than an active mechanic.
|}

PSUnreal Config

Talad — Sat, 31 Oct 2026 19:52:32 GMT

Dynamic elements

← Older revision		Revision as of 19:52, 31 October 2026
Line 22:		Line 22:
	== Dynamic elements ==		== Dynamic elements ==

			* [[Character Variables]]
	* [[PSUnreal Proximity Triggers]]		* [[PSUnreal Proximity Triggers]]

PSUnreal Proximity Triggers

Talad — Mon, 26 Oct 2026 22:15:12 GMT

← Older revision		Revision as of 22:15, 26 October 2026
Line 6:		Line 6:

	1) '''Action Locations'''. You can set [[Action locationsTable\|action_locations]].triggertype field with the value PROXIMITY, and responsetype SCRIPT, to trigger a certain script when the player is within range from the action location. The range is defined with the field action_locations.radius		1) '''Action Locations'''. You can set [[Action locationsTable\|action_locations]].triggertype field with the value PROXIMITY, and responsetype SCRIPT, to trigger a certain script when the player is within range from the action location. The range is defined with the field action_locations.radius

			For generated dungeons I created an action location on the ground, with polygon 0 , mesh none, trigger=PROXIMITY, type=SCRIPT and this script:

			<run script="go_to_dungeon" with="Actor=Target;Param0='YourDungeonName';" />

Loot

Talad — Mon, 26 Oct 2026 21:29:50 GMT

← Older revision		Revision as of 21:29, 26 October 2026
(One intermediate revision by the same user not shown)
Line 18:		Line 18:
	These have a special consume script stored in [[ItemStatsTable\|item_stats.consume_script]] which is pointing to a [[ProgressionEventsTable\|progression event]] . This can be the legacy 'treasure_chest' script looking at the base price and scaling rewards accordingly, OR it can be a new script using the [[ProgressionEvents#LootSetOp\|LootSetOp]] which points to [[Loot rulesTable\|loot_rules.id]].		These have a special consume script stored in [[ItemStatsTable\|item_stats.consume_script]] which is pointing to a [[ProgressionEventsTable\|progression event]] . This can be the legacy 'treasure_chest' script looking at the base price and scaling rewards accordingly, OR it can be a new script using the [[ProgressionEvents#LootSetOp\|LootSetOp]] which points to [[Loot rulesTable\|loot_rules.id]].

	2.2) For Procedural Dungeon Generation we added a new feature. The chests are generated with a defined item_quality, which will determine the loot rule to use. In psScheduleItem::CreateItem() we set the quality, and then the consume script (treasure_chest_rnd_loot) uses the quality to determine the loot rules. The chest used is ID 7111 (Arcana treasure Chest).		2.2) For Procedural Dungeon Generation we added a new feature. The chests are generated with a defined item_quality, which will determine the loot rule to use. In psScheduleItem::CreateItem() we set the quality, and then the consume script (treasure_chest_rnd_loot) uses the quality to determine the loot rules. The chest used is ID 7111 (Arcana treasure Chest). The pickup operation is guarded now, it checks if the item is a dungeon item, and it checks the resource associated to the dungeon (example Lesser Dispeller) and the quantity required. The quantity required is calculated automatically based on the size of the dungeon.

	3) Killing creatures will allow players to loot. Loot is defined in [[CharactersTable\|characters.npc_addl_loot_category_id]] field, which points to [[Loot rulesTable\|loot_rules.id]] , and then to [[Loot rule detailsTable\|loot_rule_details]] table. Here we can control the list of items and the % of chance to be random.		3) Killing creatures will allow players to loot. Loot is defined in [[CharactersTable\|characters.npc_addl_loot_category_id]] field, which points to [[Loot rulesTable\|loot_rules.id]] , and then to [[Loot rule detailsTable\|loot_rule_details]] table. Here we can control the list of items and the % of chance to be random.

Mac ARM64 vs X86

Talad — Sun, 25 Oct 2026 21:31:09 GMT

Created page with " = PlaneShift — Mac Shipping Build: ARM64 / x86_64 Architecture Issues = '''Environment:''' Unreal Engine 5.7.4, macOS Sonoma 14.6.1, Xcode 16.2, Apple Silicon M1. == 1. Problem encountered — October 25, 2026 == When building the Mac Shipping client, Unreal Engine started failing during cooking: <code>UnrealEditor-Cmd: Illegal instruction: 4 ExitCode=132 Cook failed</code> Even running <code>UnrealEditor-Cmd -help</code> produced the same error, before loading Pl..."

New page

= PlaneShift — Mac Shipping Build: ARM64 / x86_64 Architecture Issues =
'''Environment:''' Unreal Engine 5.7.4, macOS Sonoma 14.6.1, Xcode 16.2, Apple Silicon M1.

== 1. Problem encountered — October 25, 2026 ==
When building the Mac Shipping client, Unreal Engine started failing during cooking:
<code>UnrealEditor-Cmd: Illegal instruction: 4
ExitCode=132
Cook failed</code>
Even running <code>UnrealEditor-Cmd -help</code> produced the same error, before loading PlaneShift.

=== Root cause: conflicting architectures ===
The Mac Shipping script requested <code>x86_64</code>:
<code>-architecture=x86_64
-specifiedarchitecture=x86_64</code>
Without additional flags, UnrealBuildTool also rebuilt the '''Unreal Editor for x86_64''', overwriting the working native ARM64 editor binaries.

We confirmed this in the logs:
<code>Building PSUnrealEditor, ShaderCompileWorker,
UnrealPak and PSUnrealClient...

[15/911] Link [Intel] UnrealEditor-Core.dylib</code>
The resulting x86_64 editor crashed under Rosetta with <code>SIGILL</code>.

'''Important:''' The exact cause of the illegal instruction inside the Intel editor was not conclusively established. The last library initializer reported before the crash was <code>libembree4.4.dylib</code>, making Embree a possible contributor.

Rebuilding Unreal Engine in Xcode for ARM64 restored the working editor.

== 2. Correct architecture configuration ==
The intended arrangement is:
{| class="wikitable"
!Component
!Architecture
|-
|UnrealEditor
|ARM64
|-
|UnrealEditor-Cmd (cooker)
|ARM64
|-
|UnrealEditor-Core.dylib
|ARM64
|-
|UnrealEditor-PSUnreal.dylib
|ARM64
|-
|PSUnrealClient Shipping
|x86_64
|}
The cooking editor and its PlaneShift game module must have matching architectures. The packaged client can target a different architecture.

== 3. Required Shipping build flags ==
Keep the existing x86_64 client options, but add:
<code>-nocompileeditor -skipbuildeditor</code>
Full command:
<code>/Volumes/DATA-2TB/5.7.4-release/Engine/Build/BatchFiles/RunUAT.command \
BuildCookRun \
-project="/Users/luke/PSUnreal511/PSUnreal.uproject" \
-nop4 \
-Prereqs \
-package \
-target=PSUnrealClient \
-clientconfig=Shipping \
-utf8output \
-specifiedarchitecture=x86_64 \
-platform=Mac \
-architecture=x86_64 \
-targetplatform=Mac \
-build \
-nocompileeditor \
-skipbuildeditor \
-cook \
-allmaps \
-pak \
-stage \
-archive \
-archivedirectory="/Users/luke/temp/PSUnreal_Ship"</code>
These flags successfully prevented AutomationTool from rebuilding <code>PSUnrealEditor</code> for Intel in our tests.

The build log should list:
<code>Building UnrealPak and PSUnrealClient...</code>
It should NOT list:
<code>Building PSUnrealEditor...</code>

== 4. Pre-build verification commands ==
Run these before creating a Shipping release.

=== Check Unreal Editor executable ===
<code>file /Volumes/DATA-2TB/5.7.4-release/Engine/Binaries/Mac/UnrealEditor-Cmd</code>
Expected:
<code>Mach-O 64-bit executable arm64</code>

=== Check engine Core library ===
<code>file /Volumes/DATA-2TB/5.7.4-release/Engine/Binaries/Mac/UnrealEditor-Core.dylib</code>
Expected:
<code>Mach-O 64-bit dynamically linked shared library arm64</code>

=== Check PlaneShift editor module ===
<code>file /Users/luke/PSUnreal511/Binaries/Mac/UnrealEditor-PSUnreal.dylib</code>
Expected:
<code>Mach-O 64-bit dynamically linked shared library arm64</code>

=== Check Shipping client architecture ===
<code>file /Users/luke/PSUnreal511/Binaries/Mac/PSUnrealClient-Mac-Shipping</code>
Expected:
<code>Mach-O 64-bit executable x86_64</code>

=== Check installed build tools ===
<code>uname -m
sw_vers
xcodebuild -version</code>

== 5. Repairing the project editor module ==
If cooking fails with:
<code>The game module 'PSUnreal' could not be found.
Please ensure that this module exists and that it is compiled.</code>
First check <code>UnrealEditor-PSUnreal.dylib</code>.

In our case, this file was x86_64 while the engine was ARM64, so Unreal couldn't load it.

Rebuild the project editor module for ARM64:
<code>cd /Volumes/DATA-2TB/5.7.4-release

./Engine/Build/BatchFiles/Mac/Build.sh \
PSUnrealEditor Mac Development \
-Project="/Users/luke/PSUnreal511/PSUnreal.uproject" \
-architecture=arm64</code>
Verify the architecture again before launching the Shipping build.

== 6. If UnrealEditor-Cmd crashes again ==
Test the editor independently:
<code>/Volumes/DATA-2TB/5.7.4-release/Engine/Binaries/Mac/UnrealEditor-Cmd -help

echo "Exit code: $?"</code>
If the result is <code>Illegal instruction: 4</code> (exit code 132):

# Check whether the editor binaries became x86_64.
# Inspect the build logs for <code>PSUnrealEditor Mac Development -architecture=x64</code>.
# Rebuild the editor for ARM64 in Xcode.
# Verify the PlaneShift editor module is also ARM64.
# Ensure the Shipping script contains <code>-nocompileeditor -skipbuildeditor</code>.

An x86_64 editor is not automatically invalid, but that configuration caused startup crashes on this Mac.

== 7. Where to find cooking logs ==
AutomationTool logs are stored in:
<code>~/Library/Logs/Unreal Engine/LocalBuildLogs/</code>
The cooking log filename can change when AutomationTool copies it from the engine directory.

Find the latest logs:
<code>ls -lt "$HOME/Library/Logs/Unreal Engine/LocalBuildLogs/" | head -20</code>
To inspect the latest Cook log:
<code>LOG=$(ls -t "$HOME/Library/Logs/Unreal Engine/LocalBuildLogs/"/Cook-*.txt | head -1)
tail -n 120 "$LOG"</code>

== 8. Final notes ==

* Don't force the entire build environment into x86_64 using the old <code>arch -x86_64</code> shell workaround.
* Don't rebuild the Intel editor just because the game client targets Intel.
* Avoid running Xcode editor builds and Shipping builds simultaneously.
* Always verify both the engine and game-module architecture after rebuilding.
* The compilation phase can succeed even when the resulting editor cannot run.
* The ARM64 editor successfully progressed into static-mesh processing and Metal shader compilation after these fixes.

'''Resolution status:''' The ARM64 editor and matching PlaneShift editor module successfully reached the cooking stage with the new Shipping flags.

Building PSUnreal on macOS

Talad — Sun, 25 Oct 2026 21:11:39 GMT

Compilation on M1 hardware

← Older revision		Revision as of 21:11, 25 October 2026
Line 264:		Line 264:
	Detected max mem exceeded - forcing shader compilation flush		Detected max mem exceeded - forcing shader compilation flush
	MemoryMinFreePhysical=256		MemoryMinFreePhysical=256

			=== Mac Shipping Build - ARM64 vs X86_64 issues ===
			[[Mac ARM64 vs X86\|Read this summary]].

	== Running a local server ==		== Running a local server ==

PSUnreal Foliage

Talad — Thu, 15 Oct 2026 21:26:21 GMT

← Older revision		Revision as of 21:26, 15 October 2026
Line 11:		Line 11:

	Trees: 500 meters (for now, let's see how much they pop)		Trees: 500 meters (for now, let's see how much they pop)

			=== LODs ===
			For bushes we used these settings:

			* Number of LOD: 3
			* Auto compute LOD distances : OFF
			* Custom: ON
			* LOD1, screen size: 0.1, Percent Triangles: 30
			* LOD2, screen size: 0.05, Percent Triangles: 1

	=== Procedural Foliage Volume ===		=== Procedural Foliage Volume ===