Automatic beta game profiles: Difference between revisions
More actions
Bonsaibauer (talk | contribs) Create en-GB source page for translation |
Bonsaibauer (talk | contribs) Marked this version for translation |
||
| Line 15: | Line 15: | ||
<translate> | <translate> | ||
<!--T:1--> | |||
Optional beta discovery compares a new game build with a saved, supported version. It creates a complete beta profile only when the required evidence is available. Matching regular game profiles take priority. | Optional beta discovery compares a new game build with a saved, supported version. It creates a complete beta profile only when the required evidence is available. Matching regular game profiles take priority. | ||
== Prepare before a game update == | == Prepare before a game update == <!--T:2--> | ||
<!--T:3--> | |||
The module is enabled by default and can be switched off. An explicitly saved disabled setting stays disabled. Its switch is under '''Settings → General → Game profile''', beside the profile selector. | The module is enabled by default and can be switched off. An explicitly saved disabled setting stays disabled. Its switch is under '''Settings → General → Game profile''', beside the profile selector. | ||
<!--T:4--> | |||
# Check that '''Dynamic game profile creation (Beta)''' is enabled. Switch it on if needed. | # Check that '''Dynamic game profile creation (Beta)''' is enabled. Switch it on if needed. | ||
# Fully restart the game or dedicated server while a matching regular profile is still available. | # Fully restart the game or dedicated server while a matching regular profile is still available. | ||
| Line 26: | Line 29: | ||
# After a later game update, the new game process starts the comparison automatically and uses the saved baseline. | # After a later game update, the new game process starts the comparison automatically and uses the saved baseline. | ||
<!--T:5--> | |||
The client and dedicated server keep separate baselines. A client cannot replace a server baseline. If the module is first enabled after an update and no matching baseline was saved, it cannot reconstruct the previous version. | The client and dedicated server keep separate baselines. A client cannot replace a server baseline. If the module is first enabled after an update and no matching baseline was saved, it cannot reconstruct the previous version. | ||
== What happens at game startup == | == What happens at game startup == <!--T:6--> | ||
<!--T:7--> | |||
Analysis runs during game startup. The game waits for the result before continuing startup. No loaded world is needed for this step. | Analysis runs during game startup. The game waits for the result before continuing startup. No loaded world is needed for this step. | ||
<!--T:8--> | |||
ShroudForge first looks for a regular profile matching the exact running executable. Automatic selection uses that profile when one exists. With discovery enabled, it also caches the supported executable for future updates. | ShroudForge first looks for a regular profile matching the exact running executable. Automatic selection uses that profile when one exists. With discovery enabled, it also caches the supported executable for future updates. | ||
<!--T:9--> | |||
If no matching regular profile exists, the module checks the latest suitable regular baseline for the same process target and KFC format. The previously cached executable must match that baseline exactly. It compares code, references, registered types and the required structure contracts from the comparison images. Target addresses must be established from the new image. | If no matching regular profile exists, the module checks the latest suitable regular baseline for the same process target and KFC format. The previously cached executable must match that baseline exactly. It compares code, references, registered types and the required structure contracts from the comparison images. Target addresses must be established from the new image. | ||
<!--T:10--> | |||
The result preserves the complete previous profile contract, including its feature flags. Unresolved or conflicting evidence prevents publication of the entire beta profile. Diagnostics state the reason. Waiting longer or entering a world does not resolve missing static evidence. | The result preserves the complete previous profile contract, including its feature flags. Unresolved or conflicting evidence prevents publication of the entire beta profile. Diagnostics state the reason. Waiting longer or entering a world does not resolve missing static evidence. | ||
== Storage and selection == | == Storage and selection == <!--T:11--> | ||
<!--T:12--> | |||
Regular and generated profiles share the configured profile directory. The default paths are: | Regular and generated profiles share the configured profile directory. The default paths are: | ||
<!--T:13--> | |||
{| class="wikitable" | {| class="wikitable" | ||
! Content !! Location | ! Content !! Location | ||
| Line 52: | Line 62: | ||
|} | |} | ||
<!--T:14--> | |||
Generated profiles start with <code>beta_</code>. '''Automatic''' selection can use a completely verified matching beta profile when no matching regular profile is available. The profile selector lists available profiles. A matching regular profile added later takes priority. | Generated profiles start with <code>beta_</code>. '''Automatic''' selection can use a completely verified matching beta profile when no matching regular profile is available. The profile selector lists available profiles. A matching regular profile added later takes priority. | ||
<!--T:15--> | |||
Changing the switch or profile selection requires a full restart of the affected game or server. Reopening the Modloader window does not restart the runtime. | Changing the switch or profile selection requires a full restart of the affected game or server. Reopening the Modloader window does not restart the runtime. | ||
== Distinguish discovery, profiles and a running world == | == Distinguish discovery, profiles and a running world == <!--T:16--> | ||
<!--T:17--> | |||
The blue '''Dynamic profile search in progress''' notice describes an active profile search. '''Workflow and help''' opens this guide. If the search ends without a matching profile, the problem is shown in red. The orange '''Experimental game profile active''' notice identifies the beta profile actually selected. Actual runtime errors continue to be displayed as errors. | The blue '''Dynamic profile search in progress''' notice describes an active profile search. '''Workflow and help''' opens this guide. If the search ends without a matching profile, the problem is shown in red. The orange '''Experimental game profile active''' notice identifies the beta profile actually selected. Actual runtime errors continue to be displayed as errors. | ||
<!--T:18--> | |||
Structural executable checks do not require a loaded world. World operations additionally need their live contexts, registrations and runtime safety checks. A generated profile does not establish that game commands were executed or produced visible effects. Functional checks must also test the client and server separately. | Structural executable checks do not require a loaded world. World operations additionally need their live contexts, registrations and runtime safety checks. A generated profile does not establish that game commands were executed or produced visible effects. Functional checks must also test the client and server separately. | ||
<!--T:19--> | |||
If no profile is generated, read the reported reason and technical details. A missing saved baseline, unsuitable source profile or unresolved code and layout evidence each requires the relevant input or further analysis. A matching regular profile or a suitable ShroudForge update may provide support. | If no profile is generated, read the reported reason and technical details. A missing saved baseline, unsuitable source profile or unresolved code and layout evidence each requires the relevant input or further analysis. A matching regular profile or a suitable ShroudForge update may provide support. | ||
== Detailed logging == | == Detailed logging == <!--T:20--> | ||
<!--T:21--> | |||
The Debug Console shows discovery messages from the main log under the <code>game-profile-discovery</code> source. To see every comparison and rebase field, set '''Settings → General → Logging → Minimum level''' to '''Diagnostic'''. '''Advanced''' shows additional summaries. | The Debug Console shows discovery messages from the main log under the <code>game-profile-discovery</code> source. To see every comparison and rebase field, set '''Settings → General → Logging → Minimum level''' to '''Diagnostic'''. '''Advanced''' shows additional summaries. | ||
<!--T:22--> | |||
The red runtime banner and the log entry <code>[compatibility-check] check=runtime</code> come from the same runtime check. The existing UI refresh logs the state change before sending the same status to the Modloader. The Debug Console applies its existing popup setting to warning and error lines from that main log. | The red runtime banner and the log entry <code>[compatibility-check] check=runtime</code> come from the same runtime check. The existing UI refresh logs the state change before sending the same status to the Modloader. The Debug Console applies its existing popup setting to warning and error lines from that main log. | ||
<!--T:23--> | |||
On failure, the main log gives the path to the current <code>''.v2.unresolved.json</code> or <code>''.v2.error.json</code> report. On success, it gives the path to the <code>''.v2.proof.json</code> evidence and the full save path of the generated <code>beta_''.json</code> profile. Reports are stored in the discovery cache. | On failure, the main log gives the path to the current <code>''.v2.unresolved.json</code> or <code>''.v2.error.json</code> report. On success, it gives the path to the <code>''.v2.proof.json</code> evidence and the full save path of the generated <code>beta_''.json</code> profile. Reports are stored in the discovery cache. | ||
== Linux and Proton == | == Linux and Proton == <!--T:24--> | ||
<!--T:25--> | |||
Discovery runs inside the native runtime module and requires no external PowerShell or Python programs. This workflow has not yet been live-tested under Proton. | Discovery runs inside the native runtime module and requires no external PowerShell or Python programs. This workflow has not yet been live-tested under Proton. | ||
<!--T:26--> | |||
For runtime, mod API and parser guidance, see [[Special:MyLanguage/Engine|Engine]]. | For runtime, mod API and parser guidance, see [[Special:MyLanguage/Engine|Engine]]. | ||
Latest revision as of 21:38, 6 November 2026
Optional beta discovery compares a new game build with a saved, supported version. It creates a complete beta profile only when the required evidence is available. Matching regular game profiles take priority.
Prepare before a game update
The module is enabled by default and can be switched off. An explicitly saved disabled setting stays disabled. Its switch is under Settings → General → Game profile, beside the profile selector.
- Check that Dynamic game profile creation (Beta) is enabled. Switch it on if needed.
- Fully restart the game or dedicated server while a matching regular profile is still available.
- ShroudForge verifies the exact current executable and saves it as a comparison baseline in the cache. You do not need to download a historical executable.
- After a later game update, the new game process starts the comparison automatically and uses the saved baseline.
The client and dedicated server keep separate baselines. A client cannot replace a server baseline. If the module is first enabled after an update and no matching baseline was saved, it cannot reconstruct the previous version.
What happens at game startup
Analysis runs during game startup. The game waits for the result before continuing startup. No loaded world is needed for this step.
ShroudForge first looks for a regular profile matching the exact running executable. Automatic selection uses that profile when one exists. With discovery enabled, it also caches the supported executable for future updates.
If no matching regular profile exists, the module checks the latest suitable regular baseline for the same process target and KFC format. The previously cached executable must match that baseline exactly. It compares code, references, registered types and the required structure contracts from the comparison images. Target addresses must be established from the new image.
The result preserves the complete previous profile contract, including its feature flags. Unresolved or conflicting evidence prevents publication of the entire beta profile. Diagnostics state the reason. Waiting longer or entering a world does not resolve missing static evidence.
Storage and selection
Regular and generated profiles share the configured profile directory. The default paths are:
| Content | Location |
|---|---|
| Client profiles | shroudforge/runtime/profiles/enshrouded/client/
|
| Server profiles | shroudforge/runtime/profiles/enshrouded/server/
|
| Saved comparison images and evidence | shroudforge/cache/game-profile-discovery/
|
Generated profiles start with beta_. Automatic selection can use a completely verified matching beta profile when no matching regular profile is available. The profile selector lists available profiles. A matching regular profile added later takes priority.
Changing the switch or profile selection requires a full restart of the affected game or server. Reopening the Modloader window does not restart the runtime.
Distinguish discovery, profiles and a running world
The blue Dynamic profile search in progress notice describes an active profile search. Workflow and help opens this guide. If the search ends without a matching profile, the problem is shown in red. The orange Experimental game profile active notice identifies the beta profile actually selected. Actual runtime errors continue to be displayed as errors.
Structural executable checks do not require a loaded world. World operations additionally need their live contexts, registrations and runtime safety checks. A generated profile does not establish that game commands were executed or produced visible effects. Functional checks must also test the client and server separately.
If no profile is generated, read the reported reason and technical details. A missing saved baseline, unsuitable source profile or unresolved code and layout evidence each requires the relevant input or further analysis. A matching regular profile or a suitable ShroudForge update may provide support.
Detailed logging
The Debug Console shows discovery messages from the main log under the game-profile-discovery source. To see every comparison and rebase field, set Settings → General → Logging → Minimum level to Diagnostic. Advanced shows additional summaries.
The red runtime banner and the log entry [compatibility-check] check=runtime come from the same runtime check. The existing UI refresh logs the state change before sending the same status to the Modloader. The Debug Console applies its existing popup setting to warning and error lines from that main log.
On failure, the main log gives the path to the current .v2.unresolved.json or .v2.error.json report. On success, it gives the path to the .v2.proof.json evidence and the full save path of the generated beta_.json profile. Reports are stored in the discovery cache.
Linux and Proton
Discovery runs inside the native runtime module and requires no external PowerShell or Python programs. This workflow has not yet been live-tested under Proton.
For runtime, mod API and parser guidance, see Engine.