From 9ab0d28ed24679404b44d891db8dd982848c44a4 Mon Sep 17 00:00:00 2001 From: Rob B Date: Fri, 6 Dec 2024 12:56:26 -0500 Subject: [PATCH] Rework SML index page to provide more info and remove reference to outdated SPL --- .../pages/Development/ModLoader/index.adoc | 34 ++++++++++++++----- .../pages/Development/OpenSourceExamples.adoc | 2 +- 2 files changed, 26 insertions(+), 10 deletions(-) diff --git a/modules/ROOT/pages/Development/ModLoader/index.adoc b/modules/ROOT/pages/Development/ModLoader/index.adoc index 6cb68909..e2ce9749 100644 --- a/modules/ROOT/pages/Development/ModLoader/index.adoc +++ b/modules/ROOT/pages/Development/ModLoader/index.adoc @@ -1,19 +1,35 @@ = SML The Satisfactory Mod Loader provides framework for all the stuff you as modder might encounter -but unreal doesn't provide help with. +but Unreal doesn't provide help with. == Mod "Types" -There are two main ways to load a mod into a game, each of those -variants have there advantages and disadvantages. +All Satisfactory mods are full Unreal Engine plugins. +There are three main ways to create a mod with this approach, +each with advantages and disadvantages. * {blank} -.dll (C++) Mods:: - `.dll` s are written in C++ and provide deep access to the - Satisfactory runtime and the logic written in there is extremely fast. +Blueprint Mods:: + Blueprint mods consist of Unreal Blueprint assets which can contain data (like meshes, sounds, textures) + and code written in Unreal Blueprint scripting. + SML provides a number of utilities and entry points to enable blueprint mods to function. + Blueprint mods can do a lot, but they can generally only access fields and methods have been made blueprint accessible from the {cpp} side. + * {blank} -Pak Mods:: - Paks are archives with classical assets like meshes, sounds and more. - SML also provides the SPL so you could make a mod without any C++ coding. +{cpp} Mods:: + Writing a mod in Unreal {cpp} provides deep access to the Satisfactory runtime + and is usually more performant than blueprint code because it does not need to go through the overhead of the blueprint VM. + However, it's a pain to reference blueprint assets (a frequent requirement for working with base game content) + in a non-brittle manner, and working with widgets is agonizingly verbose. + Performing delayed actions is also much more involved than in Blueprint scripting. ++ +* {blank} +Hybrid Blueprint and {cpp} Mods:: + Writing a mod with {cpp} does not mean replacing all of your Blueprint assets with {cpp} code. + The best mods are implemented with a careful combination of both {cpp} and Blueprint code + since each side covers for the other's disadvantages. + For example, you can implement references to blueprint assets and widgets on the + However, changes to your mod's class {cpp} structure will require closing the editor and rebuilding Development Editor + for the blueprint side to recognize the changes. ++ diff --git a/modules/ROOT/pages/Development/OpenSourceExamples.adoc b/modules/ROOT/pages/Development/OpenSourceExamples.adoc index f014e1eb..76305847 100644 --- a/modules/ROOT/pages/Development/OpenSourceExamples.adoc +++ b/modules/ROOT/pages/Development/OpenSourceExamples.adoc @@ -73,7 +73,7 @@ _Notable Techniques Used:_ * Save/loading of soft class and soft object fields * Hybrid Blueprint/{cpp} subsystems ** Subsystems' final implementations are in Blueprint, - but they are backed by custom {cpp} parent classes to allow + but they are backed by custom {cpp} parent classes to allow {cpp} mods to reference the data fields. * Zero-dependency cross mod interaction ** Mod is coded to inspect other mod's assets for fields with a certain name, and then change behavior based on those fields values.