Star Wolves 3: Script Extender

[Rawra]

I've made a script extender for the game and I thought I'd create a thread here for the people still semi active on this forum.

About
Star Wolves 3: Script Extender (SW3:SE) is a "script extender" that aims to improve the modding capabilities of the game Star Wolves 3: Civil War.
It currently has a number of new API extensions and unique features, including optional safety & performance improvements to the game.
The project is completely non-profit and not monetized in any way shape or form.

Features
SW3SE currently adds the ability to...

• modify runtime data of Carcasses
• modify runtime data of Modules (currently excluding Utility modules)
• register independent sw3se-based script mods with custom callbacks.
• add custom "extensions" to specific Carcasses and Modules (Allowing custom rocket fire sounds and custom shield textures!)

Aside from that it...

• Includes optional performance improvements (disable of Sleep calls by the game)
• Has high configurability of most features via config.
• Includes a localization decryption tool (English only currently, credits to dtooboss)
• Includes lua 4 compiled as a dll
• Includes imgui accessible via pressing VK_DELETE
• Includes steam api integration to some extent

Explanation
SW3SE works by using suspended process DLL INJECTION, where the payload dll sets up a HOOK that will get executed by the main game thread
to execute the rest of the payload.
In a sense we are guaranteeing that the main game / main game thread executes our new code that has been inserted inside the hooked functions.
The function which executes our hooks has been designed to be "eng_startup_ex" at #0x00655090.
For a detailed preview of the complete routine, here is a simplified illustration:

• INJECTOR: Starts up sw3cw.exe in SUSPENDED mode.
• GAME THREAD: Exists.
• INJECTOR: Injects dll and manipulates the RIP thread pointer to execute our own code first of all.
• INJECTOR: Resumes process.
• GAME THREAD: Resumed.
• PAYLOAD: DllMain entry DLL_PROCESS_ATTACH event makes sure to setup a detour using PolyHook2 to a critical game startup function to act as a loader for the rest of the payload.
• GAME THREAD: Loads the critical startup function and creates a new thread that takes care of creating the rest of the hooks. (NativeInjectionEntryPoint).
• GAME THREAD: Waits for flag set by thread to signal a ready state.
• GAME THREAD: Continues default routine to normal game startup.

Examples
SW3SE includes a LUA-based interface to the underlying calls to the engine to make it more simple for use.
They are included in the CORE mod Data/Mods/SW3SE. It is not recommended to modify it unless you know what you're doing.
But it may serve as a weak compilation of examples.
Aside from that, there is an ExampleMod included in the project that changes shield texture and shield impact sounds for the "Mothership" carcass, in addition to changing the
rocket launching sounds from the SRM2 missile to a more unique one.

Code-only example
In this example, we want to implement a continuous raycasting system where we print out all the modules of a ship to the game screen log.
In a vanilla environment, this would not be possible. Hence, we have to resort to using the new API.

function TryPrintModules()
	local tShip = GetEntityAtMouse(); -- Get the ship the player is currently hovering over
	local tId = tShip["id"]; -- Get the field "id" of the GetEntityAtMouse return table {id, xsdtype, carcasstype}
	local tMods = ModuleManager:GetModulesOfShip(tId);	-- Get all modules of the ship (By its id) using the ModuleManager lua interface

	for _, elem in tMods do
	  local tMod = NewManagedModuleByID(elem); -- Create a new managed module to keep track of it easier
	  tMod:LoadBase(); -- Load the base information (see the file for other properties)
	  OutputToScreenLog("Module = "..tMod.infoBase["ShortName"], 6); -- Output the short name of the module.
	end;
end;

So thats great and all, but can we change this data? The answer is yes! Even on a ship-per-ship basis.

function TryPrintModules()
	local tShip = GetEntityAtMouse(); -- Get the ship the player is currently hovering over
	local tId = tShip["id"]; -- Get the field "id" of the GetEntityAtMouse return table {id, xsdtype, carcasstype}
	local tMods = ModuleManager:GetModulesOfShip(tId);	-- Get all modules of the ship (By its id) using the ModuleManager lua interface

	for _, elem in tMods do
	  local tMod = NewManagedModuleByID(elem); -- Create a new managed module to keep track of it easier
	  tMod:LoadBase(); -- Load the base information (see the file for other properties)
	  tMod:SetModuleShortName("#My_Custom_ShortName"); -- Set the new shortname string key for this particular ship instance
	  tMod:LoadBase(); -- Reload the base information (This will get the updated information from the modified runtime values)
	  OutputToScreenLog("Module = "..tMod.infoBase["ShortName"], 6); -- Output the short name of the module.
	end;
end;

And... does it work?



Yes it does.

Final Info

Project Link: https://gitlab.com/Rawra/sw3se/-/tre...ref_type=heads
(The CoreCLR branch is the most up to date and free of bugs)

For all further information on how to create mods and other critical information, please see the project page. Its going to be alot easier maintaining one location instead of some ancient forum's thread.