SexLab - Hide HUD Elements

yeahhowaboutnooo · August 8, 2020

built a version which stores the logs in the correct folder, also changed the "GAME_VERSION" makro to be set to "CURRENT_RELEASE_RUNTIME" -> no need to update that makro with every new SKSE64 release. SKSE_LIB makro is no longer used for an SSE build (instead relying on the references to link correctly).
diff between the last SSE-compatible source and my version:

Spoiler


diff -ur "SexLab - Hide HUD Elements 1.1.2 (Source - SKSE64)/SexLab - Hide HUD Elements/SexLab - Hide HUD Elements.vcxproj.SKSE64" "SexLab - Hide HUD Elements (1.1.2) - skse64_2.0.19 - Source/SexLab - Hide HUD Elements/SexLab - Hide HUD Elements.vcxproj.SKSE64"
--- "SexLab - Hide HUD Elements 1.1.2 (Source - SKSE64)/SexLab - Hide HUD Elements/SexLab - Hide HUD Elements.vcxproj.SKSE64"	2019-06-12 16:59:52.346175700 +0200
+++ "SexLab - Hide HUD Elements (1.1.2) - skse64_2.0.19 - Source/SexLab - Hide HUD Elements/SexLab - Hide HUD Elements.vcxproj.SKSE64"	2020-08-08 18:06:24.261699900 +0200
@@ -22,17 +22,18 @@
     <SccProvider>
     </SccProvider>
     <Keyword>Win32Proj</Keyword>
+    <WindowsTargetPlatformVersion>10.0</WindowsTargetPlatformVersion>
   </PropertyGroup>
   <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
   <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
     <ConfigurationType>DynamicLibrary</ConfigurationType>
-    <PlatformToolset>v140</PlatformToolset>
+    <PlatformToolset>v142</PlatformToolset>
     <CharacterSet>MultiByte</CharacterSet>
     <WholeProgramOptimization>true</WholeProgramOptimization>
   </PropertyGroup>
   <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="Configuration">
     <ConfigurationType>DynamicLibrary</ConfigurationType>
-    <PlatformToolset>v140</PlatformToolset>
+    <PlatformToolset>v142</PlatformToolset>
     <CharacterSet>MultiByte</CharacterSet>
   </PropertyGroup>
   <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
@@ -127,16 +128,6 @@
     </Link>
   </ItemDefinitionGroup>
   <ItemGroup>
-    <ProjectReference Include="..\..\common\common_vc14.vcxproj">
-      <Project>{472E19AB-DEF0-42DF-819B-18722E8DC822}</Project>
-      <CopyLocalSatelliteAssemblies>true</CopyLocalSatelliteAssemblies>
-      <ReferenceOutputAssembly>true</ReferenceOutputAssembly>
-    </ProjectReference>
-    <ProjectReference Include="..\skse64_common\skse64_common.vcxproj">
-      <Project>{5fd1c08d-db80-480c-a1c6-f0920005cd13}</Project>
-    </ProjectReference>
-  </ItemGroup>
-  <ItemGroup>
     <ClCompile Include="src\Config.cpp" />
     <ClCompile Include="src\PapyrusUI.cpp" />
     <ClCompile Include="src\HUD.cpp" />
@@ -163,6 +154,17 @@
   <ItemGroup>
     <ResourceCompile Include="SexLab - Hide HUD Elements.rc" />
   </ItemGroup>
+  <ItemGroup>
+    <ProjectReference Include="..\..\common\common_vc14.vcxproj">
+      <Project>{472e19ab-def0-42df-819b-18722e8dc822}</Project>
+    </ProjectReference>
+    <ProjectReference Include="..\skse64\skse64.vcxproj">
+      <Project>{7028b79c-06e3-4d9a-b38c-1dc3680b1bdb}</Project>
+    </ProjectReference>
+    <ProjectReference Include="..\skse64_common\skse64_common.vcxproj">
+      <Project>{5fd1c08d-db80-480c-a1c6-f0920005cd13}</Project>
+    </ProjectReference>
+  </ItemGroup>
   <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
   <ImportGroup Label="ExtensionTargets">
   </ImportGroup>
diff -ur "SexLab - Hide HUD Elements 1.1.2 (Source - SKSE64)/SexLab - Hide HUD Elements/src/include/Info.h" "SexLab - Hide HUD Elements (1.1.2) - skse64_2.0.19 - Source/SexLab - Hide HUD Elements/src/include/Info.h"
--- "SexLab - Hide HUD Elements 1.1.2 (Source - SKSE64)/SexLab - Hide HUD Elements/src/include/Info.h"	2019-06-12 16:49:45.357457900 +0200
+++ "SexLab - Hide HUD Elements (1.1.2) - skse64_2.0.19 - Source/SexLab - Hide HUD Elements/src/include/Info.h"	2020-08-08 19:19:29.759866400 +0200
@@ -3,8 +3,8 @@
 #include "include/Plugin.h"
 
 #ifdef __SKSE64__
-#define GAME_VERSION RUNTIME_VERSION_1_5_73
-#define SKSE_LIB     skse64_1_5_73
+#define GAME_VERSION CURRENT_RELEASE_RUNTIME
+#define SKSE_LIB     skse64_1_5_97 //no longer used for SSE
 #else
 #define GAME_VERSION RUNTIME_VERSION_1_9_32_0
 #define SKSE_LIB     skse
diff -ur "SexLab - Hide HUD Elements 1.1.2 (Source - SKSE64)/SexLab - Hide HUD Elements/src/include/Logger.h" "SexLab - Hide HUD Elements (1.1.2) - skse64_2.0.19 - Source/SexLab - Hide HUD Elements/src/include/Logger.h"
--- "SexLab - Hide HUD Elements 1.1.2 (Source - SKSE64)/SexLab - Hide HUD Elements/src/include/Logger.h"	2019-04-07 01:46:12.605715400 +0200
+++ "SexLab - Hide HUD Elements (1.1.2) - skse64_2.0.19 - Source/SexLab - Hide HUD Elements/src/include/Logger.h"	2020-08-08 17:55:32.739677800 +0200
@@ -10,7 +10,11 @@
 {
 	namespace Logger
 	{
+		#ifdef __SKSE64__
+		static const std::string LOG("\\My Games\\Skyrim Special Edition\\SKSE\\SexLab - Hide HUD Elements.log");
+		#else
 		static const std::string LOG("\\My Games\\Skyrim\\SKSE\\SexLab - Hide HUD Elements.log");
+		#endif
 
 		inline void Open(void)
 		{ 
diff -ur "SexLab - Hide HUD Elements 1.1.2 (Source - SKSE64)/SexLab - Hide HUD Elements/src/main.cpp" "SexLab - Hide HUD Elements (1.1.2) - skse64_2.0.19 - Source/SexLab - Hide HUD Elements/src/main.cpp"
--- "SexLab - Hide HUD Elements 1.1.2 (Source - SKSE64)/SexLab - Hide HUD Elements/src/main.cpp"	2019-06-12 16:56:27.795476100 +0200
+++ "SexLab - Hide HUD Elements (1.1.2) - skse64_2.0.19 - Source/SexLab - Hide HUD Elements/src/main.cpp"	2020-08-08 19:18:04.759049200 +0200
@@ -7,14 +7,16 @@
 #include "include/PapyrusUI.h"
 #include "include/Logger.h"
 
+/* DAFUQ!? why? that's what references are for? */
+/* maybe it's necessary for oldrim?*/
 #ifdef __SKSE64__
-	#ifndef _DEBUG
-	#pragma comment(lib, "../x64/Release/skse64_common.lib")
-	#pragma comment(lib, "../x64/Release/" MACRO_STRINGIFY(SKSE_LIB) ".lib")
-	#else
-	#pragma comment(lib, "../x64/Debug/skse64_common.lib")
-	#pragma comment(lib, "../x64/Debug/" MACRO_STRINGIFY(SKSE_LIB) ".lib")
-	#endif
+//	#ifndef _DEBUG
+//	#pragma comment(lib, "../x64/Release/skse64_common.lib")
+//	#pragma comment(lib, "../x64/Release/" MACRO_STRINGIFY(SKSE_LIB) ".lib")
+//	#else
+//	#pragma comment(lib, "../x64/Debug/skse64_common.lib")
+//	#pragma comment(lib, "../x64/Debug/" MACRO_STRINGIFY(SKSE_LIB) ".lib")
+//	#endif
 #else
 	#ifndef _DEBUG
 	#pragma comment(lib, "../Release/" MACRO_STRINGIFY(SKSE_LIB) ".lib")

SexLab - Hide HUD Elements (1.1.2) - skse64_2.0.19 - Source.7z SexLab - Hide HUD Elements (1.1.2) - skse64_2.0.19.7z

August 8, 2020

1 hour ago, yeahhowaboutnooo said:

...

Statically linked so I could avoid SKSE code from being recompiled each time I would rebuild projects (in the case of project references). It just pulls the already compiled code from the lib. No other reason and I do this for my all my SKSE projects, having to compile SKSE code only once.

GAME_VERSION was like that because the person that was compiling it for SKSE64 wanted to compile it for a previous version of the game, not the current.

If you want to fix an issue that I've noticed a while ago but didn't care enough to do it myself; the HUD object should be cleaned after a new game/load game in case the user left its previous game without finishing a SexLab scene.

Plugin.cpp:

void Plugin::Plugin::_HandleSKSEMessage(SKSEMessagingInterface::Message* msg)

From:

	if (this->m_state == Plugin::State::kState_Ready)
	{
		#ifdef _DEBUG
		Logger::Pretty("DEBUG", "Received SKSE message after the plugin has been fully loaded. Ignoring...");
		#endif

		return;
	}

To:

	if (this->m_state == Plugin::State::kState_Ready)
	{
		switch (msg->type)
		{
			case SKSEMessagingInterface::kMessage_PreLoadGame:
			case SKSEMessagingInterface::kMessage_NewGame:
				this->hud->Finish();
				break;
			default:
				#ifdef _DEBUG
				Logger::Pretty("DEBUG", "Received SKSE message after the plugin has been fully loaded. Ignoring...");
				#endif
				break;
		}

		return;
	}

This doesn't affect me at all because I always restart my game when having to load a new save as to prevent data leaks from mods and the engine itself.

yeahhowaboutnooo · August 8, 2020

On 8/8/2020 at 10:59 PM, Hawk9969 said:

If you want to fix an issue that I've noticed a while ago but didn't care enough to do it myself; the HUD object should be cleaned after a new game/load game in case the user left its previous game without finishing a SexLab scene.

fixed version: (built using SKSE64 2.0.19 (game runtime 1.5.97 -> should work fine with SKSE 2.0.17 and 2.0.18 as well))

SexLab - Hide HUD Elements (1.1.2) - skse64_2.0.19.7z

source code:

SexLab - Hide HUD Elements (1.1.2) - skse64_2.0.19 - Source.7z

changelog compared to the last posted SSE built .dll to the best of my knowledge:

Spoiler

logs now stored in the correct location "My Games\Skyrim Special Edition\SKSE"
HUD will correctly reset on new-game/load-game

August 9, 2020

3 hours ago, yeahhowaboutnooo said:

fixed version:

Could you add the game and SKSE versions to this post? Linked it to the first post.

yeahhowaboutnooo · August 10, 2020

Fixed.

Put the SKSE version i built it for into the filename initially, but that's getting omitted because the filename is too long...

(and i never mentioned the runtime version)

Thanks for the support and the mod again

Corsec · November 1, 2020

I find that when I use this mod there seems to be 8 unattached instances being created in the save at the start of a new game.

I checked it both with and without the mod installed, and the unattached instances seem to be coming from this mod.

I was surprised because I didn't know that SKSE plugins could create scripted bugs like this.

it may also be causing a single unattached instance that stays permanently with the save and never disappears. I'm not 100% sure because I haven't had the time to test it on an hour long savegame both with and without this mod. I only tested for an hour on a savegame with this mod, but not without.

*Nymra* · November 2, 2020

1 hour ago, Corsec said:

I find that when I use this mod there seems to be 8 unattached instances being created in the save at the start of a new game.

I checked it both with and without the mod installed, and the unattached instances seem to be coming from this mod.

I was surprised because I didn't know that SKSE plugins could create scripted bugs like this.

it may also be causing a single unattached instance that stays permanently with the save and never disappears. I'm not 100% sure because I haven't had the time to test it on an hour long savegame both with and without this mod. I only tested for an hour on a savegame with this mod, but not without.

hawk left loverslab, so this mod is unmaintained

I noticed this before either but didn't bother. The mod did not work reliably for me so I stopped using i anyway.

I am using the mod "Toggle Options" where you can set a hotkey for "Hide Hud" (I think other mods also have that option).

Bullfye · March 27, 2021

For me it works everything but this ..

ScreenShot288.png.8f06b86974e0bf8156f8afaf497abae7.png

still stays the name of the sex partner on the screen..

roulk · August 11, 2021

special edition?

stalPROm · August 21, 2021

Hey, somebody knows what to write in [Custom] for A Matter of Time - A HUD clock widget for time, date and clock widget itself? Can't find anything in source for like _root.<ELEMENT> only HUD_MENU something like this.

Edited August 21, 2021 by stalPROm

stalPROm · September 5, 2021

Just FYI: don't start new game with this mod enabled, it will cause immediately unattached instances of UI (i guess because Sexlab was not registered) in savefile and u will get random crashes, they are so random but during 5-10 mins like cell change or just crash in a middle of nowhere (in common you are fucked up). But when you install during middle gameplay it works fine so it was hard for me to find what cause random CTDs.

ballsy · September 11, 2021

On 9/6/2021 at 4:41 AM, stalPROm said:

Just FYI: don't start new game with this mod enabled, it will cause immediately unattached instances of UI (i guess because Sexlab was not registered) in savefile and u will get random crashes, they are so random but during 5-10 mins like cell change or just crash in a middle of nowhere (in common you are fucked up). But when you install during middle gameplay it works fine so it was hard for me to find what cause random CTDs.

TY for this. I was crashing even installing it mid-game but your post saved me the time of narrowing down the culprit

throwaway5826450 · September 11, 2021

On 11/1/2020 at 8:53 PM, Corsec said:

I find that when I use this mod there seems to be 8 unattached instances being created in the save at the start of a new game.

I checked it both with and without the mod installed, and the unattached instances seem to be coming from this mod.

I was surprised because I didn't know that SKSE plugins could create scripted bugs like this.

it may also be causing a single unattached instance that stays permanently with the save and never disappears. I'm not 100% sure because I haven't had the time to test it on an hour long savegame both with and without this mod. I only tested for an hour on a savegame with this mod, but not without.

On 9/5/2021 at 5:41 PM, stalPROm said:

Just FYI: don't start new game with this mod enabled, it will cause immediately unattached instances of UI (i guess because Sexlab was not registered) in savefile and u will get random crashes, they are so random but during 5-10 mins like cell change or just crash in a middle of nowhere (in common you are fucked up). But when you install during middle gameplay it works fine so it was hard for me to find what cause random CTDs.

4 hours ago, ballsy said:

TY for this. I was crashing even installing it mid-game but your post saved me the time of narrowing down the culprit

So... I no longer play or mod Skyrim and I have been gone from this site for about a year, but I've been informed of possible crashes with this mod, which is odd. I've played for over 500 hours with the same mods that I've released in here, this specific mod creates no script instances, serializes nothing into the save file, the UI script is a singleton with only global functions and no one has reported anything wrong for almost 2 years other than an initial crash that some users were experiencing, one that I could not reproduce. This crash was fixed shortly with a theoretical change.

I've also contacted @Lilzt3hcat a couple of times via throwaway accounts to help me test some mods that I hadn't released publicly and she reported none of these issues.

If these problems are indeed related to this mod, I am willing to put forward a fix. I hate leaving broken stuff behind.

Since I've never experienced any of these issues, I need the following files to properly debug them:

SKSE dump file of the crash: .dmp file located at <Documents>\My Games\Skyrim\SKSE\Crashdumps; SKSE.ini needs [Debug] WriteMiniDumps=1

Save file with these supposedly unattached instances: Just the .ess should be enough.

Lilzt3hcat · September 11, 2021

On 3/27/2021 at 9:41 AM, Bullfye said:

For me it works everything but this ..

still stays the name of the sex partner on the screen..

Super late I realize for replying to this but editing the config with this fixed for me (mod creator helped me with that one, was annoying me as well)

; Add any custom element in here (use a sequence starting at 1).
; Ex:
;
; [Custom]
[Custom]
1 = HUDMovieBaseInstance.RolloverText
2 = HUDMovieBaseInstance.RolloverButton_tf
3 = HUDMovieBaseInstance.RolloverInfoText
4 = HUDMovieBaseInstance.RolloverGrayBar_mc

Edited September 11, 2021 by Lilzt3hcat

Lilzt3hcat · September 11, 2021

On 9/11/2021 at 2:02 PM, throwaway5826450 said:

I've also contacted @Lilzt3hcat a couple of times via throwaway accounts to help me test some mods that I hadn't released publicly and she reported none of these issues.

Your @ summoned me lol

but yeah never had that issue in midgame, I usually leave a buncha stuff off during initial setup of new games and the times I did have this one active *while* starting a new game it (crashes) didn't happen.

if it helps my settings with this mod are

Spoiler

[SexLab]
Start = Start
End = Ending

[HUD]
HideHealth = yes
HideStamina = yes
HideMagicka = yes
HideChargeBars = yes
HideArrowInfo = yes
HideCrosshair = yes
HideCompass = yes
HideFloatingQuestMarker = yes
HideEnemyHealth = yes
HideActivate = yes
HideNotifications = no
HideQuestUpdates = no
HideTutorialHints = yes
HideSubtitle = no

[Controls]
DisableMovement = no
DisableLook = no
DisableSprint = no
DisableReadyWeapon = yes
DisableAutoMove = no
DisableToggleRun = no
DisableActivate = no
DisableJump = no
DisableShout = no
DisableAttackBlock = yes
DisableRun = no
DisableSneak = yes
DisableTogglePOV = no

Edited September 14, 2021 by Lilzt3hcat

ballsy · September 12, 2021

9 hours ago, throwaway5826450 said:

So... I no longer play or mod Skyrim and I have been gone from this site for about a year, but I've been informed of possible crashes with this mod, which is odd. I've played for over 500 hours with the same mods that I've released in here, this specific mod creates no script instances, serializes nothing into the save file, the UI script is a singleton with only global functions and no one has reported anything wrong for almost 2 years other than an initial crash that some users were experiencing, one that I could not reproduce. This crash was fixed shortly with a theoretical change.

I've also contacted @Lilzt3hcat a couple of times via throwaway accounts to help me test some mods that I hadn't released publicly and she reported none of these issues.

If these problems are indeed related to this mod, I am willing to put forward a fix. I hate leaving broken stuff behind.

Since I've never experienced any of these issues, I need the following files to properly debug them:

SKSE dump file of the crash: .dmp file located at <Documents>\My Games\Skyrim\SKSE\Crashdumps; SKSE.ini needs [Debug] WriteMiniDumps=1

Save file with these supposedly unattached instances: Just the .ess should be enough.

Ty for looking into this. I've attached the 2 dump files below

2021-09-11_12.15.17.dmp 2021-09-11_12.41.08.dmp

throwaway5826450 · September 12, 2021

11 hours ago, ballsy said:

Ty for looking into this. I've attached the 2 dump files below

2021-09-11_12.15.17.dmp 147.06 kB · 0 downloads 2021-09-11_12.41.08.dmp 151.12 kB · 0 downloads

Unhandled exception at 0x00F5340C (TESV.exe) in 2021-09-11_12.15.17.dmp: 0xC0000417: An invalid parameter was passed to a C runtime function.

This crash IS NOT related to this mod.

It's caused by a stack pointer corruption that is triggered when transferring an item from one's inventory to another (more specifically seems to be related to removing an item from an inventory).

David J. Cobb and two others talk about this specific crash here: https://www.nexusmods.com/skyrim/mods/96734?tab=posts (look for the post started by user Burgao and read the explanation on why the dump is useless and why this crash is tricky to fix by user robx99).

You can also read Burgao's DLL list and confirm for yourself that "SexLab - Hide HUD Elements.dll" is not present on his setup (the list is truncated to 140 entries though): https://pastebin.com/iAHVkBqV

The chances for this crash happening can be reduced by removing mods that make NPCs loot corpses, chests, etc, which when combined with mods that add bigger battles (Immersive Patrols for example), will make this crash more prominent.

P.S. Do not blame mods for crashes unless you've empirical evidences to support it; the author's time is otherwise wasted investigating a problem that they DID NOT cause.

ballsy · September 13, 2021

9 hours ago, throwaway5826450 said:
Unhandled exception at 0x00F5340C (TESV.exe) in 2021-09-11_12.15.17.dmp: 0xC0000417: An invalid parameter was passed to a C runtime function.
This crash IS NOT related to this mod.

It's caused by a stack pointer corruption that is triggered when transferring an item from one's inventory to another (more specifically seems to be related to removing an item from an inventory).

David J. Cobb and two others talk about this specific crash here: https://www.nexusmods.com/skyrim/mods/96734?tab=posts (look for the post started by user Burgao and read the explanation on why the dump is useless and why this crash is tricky to fix by user robx99).

You can also read Burgao's DLL list and confirm for yourself that "SexLab - Hide HUD Elements.dll" is not present on his setup (the list is truncated to 140 entries though): https://pastebin.com/iAHVkBqV

The chances for this crash happening can be reduced by removing mods that make NPCs loot corpses, chests, etc, which when combined with mods that add bigger battles (Immersive Patrols for example), will make this crash more prominent.

P.S. Do not blame mods for crashes unless you've empirical evidences to support it; the author's time is otherwise wasted investigating a problem that they DID NOT cause.

I apologize then. A series of coincidences that lead to faulty observations can still happen as unlikely as they are

stalPROm · September 13, 2021

@throwaway5826450 Hello, about those stuff i wrote before, well, i done a little bit further testing and seems random crashes was all about Crash fixes mod, always problems with memory on Skyrim LE But about unattached instances of UI, here two .ess almost without other mods enabled: Save 1 without your mod and Save 2 with your mod enabled.

So thanks for your little comeback and for awesome mod!

Also, can u help me with custom element hide? I want to hide A Matter of Time - A HUD clock widget for LE https://www.nexusmods.com/skyrim/mods/44091/ all widgets from this mod, but dunno what to write. I know, u wrote how fully hide SkyUI ([Custom] X = WidgetContainer) but it will also hide Apropos messages. It would be great if we had some guide how to find what need to paste in ini to hide custom elements for general users if it not so hard.

Save 1.ess Save 2.ess

Edited September 13, 2021 by stalPROm

throwaway5826450 · September 13, 2021

1 hour ago, stalPROm said:

But about unattached instances of UI, here two .ess almost without other mods enabled: Save 1 without your mod and Save 2 with your mod enabled.

I'd reverse-engineered member function VMClassRegistry::Unk_13, which I use to grab a Papyrus' class object by name so that I can dynamically override SKSE's Papyrus functions SetBool, SetInt, SetFloat, SetString, GetBool, GetInt, GetFloat and GetString.

Further analysis shows that Unk_13 not only grabs the class object but also creates a new reference for it, which should be destroyed after use. This never caught my eyes before because I never started a new game other than the first time, when this mod didn't exist yet.

The reason there are exactly 8 dummy instances is because we call Unk_13 on class "UI" 8 times.

PapyrusUI::OverrideFunction("SetBool", PapyrusUI::Override::SetT<bool>, registry, success);
PapyrusUI::OverrideFunction("SetInt", PapyrusUI::Override::SetT<UInt32>, registry, success);
PapyrusUI::OverrideFunction("SetFloat", PapyrusUI::Override::SetT<float>, registry, success);
PapyrusUI::OverrideFunction("SetString", PapyrusUI::Override::SetT<BSFixedString>, registry, success);

PapyrusUI::OverrideFunction("GetBool", PapyrusUI::Override::GetT<bool>, registry, success);
PapyrusUI::OverrideFunction("GetInt", PapyrusUI::Override::GetT<UInt32>, registry, success);
PapyrusUI::OverrideFunction("GetFloat", PapyrusUI::Override::GetT<float>, registry, success);
PapyrusUI::OverrideFunction("GetString", PapyrusUI::Override::GetT<BSFixedString>, registry, success);

Those unattached instances are empty (dummies) and will ABSOLUTELY NOT cause any problems. Each instance takes exactly 16 bytes; we only bloat the save file by 128 bytes (16 x 8).

You can safely remove those instances via Fallrim Tools ReSaver by manually deleting them or by clicking Clean -> Remove unattached instances. Otherwise, it's completely safe to leave them be if you want.

The reason they are present on New Game but not on Load Game is likely because the game engine does not clean up its script instances for a new game, but it does before loading a save file.

I don't feel like recompiling this project just to fix a harmless oversight, more so when I won't be able to edit the download page itself.

The source code is available though; you are free to fix it yourself, if you care to.

PapyrusUI.cpp -> Plugin::PapyrusUI::OverrideFunction::OverrideFunction:

FROM:

	if (registry->Unk_13(const_cast<BSFixedString*>(&PapyrusUI::ClassName), &identifier))
	{
		if (identifier != nullptr && identifier->m_type != nullptr)
		{
			identifier->m_type->Visit(*this);
		}
	}

TO:

	if (registry->Unk_13(const_cast<BSFixedString*>(&PapyrusUI::ClassName), &identifier))
	{
		if (identifier != nullptr)
		{
			if (identifier->m_type != nullptr)
				identifier->m_type->Visit(*this);
          
			identifier->Destroy();
		}
	}

throwaway5826450 · September 13, 2021

5 hours ago, stalPROm said:

Also, can u help me with custom element hide? I want to hide A Matter of Time - A HUD clock widget for LE https://www.nexusmods.com/skyrim/mods/44091/ all widgets from this mod, but dunno what to write. I know, u wrote how fully hide SkyUI ([Custom] X = WidgetContainer) but it will also hide Apropos messages. It would be great if we had some guide how to find what need to paste in ini to hide custom elements for general users if it not so hard.

There is no way to make a guide for this other than what is already written. The path and name of an element is entirely left to the author of the mod.

The best bets are to read the mod's Papyrus scripts if the mod dynamically modifies UI elements (like hiding an element when something at a script happens) or install a Flash decompiler like JPEXS, decompiling the .swf file that contains the element you want to hide and then manually looking for the element's path/name under "scripts".

The only guarantees are that all vanilla HUD elements are supported under [HUD] by default and that the root namespace for instantiated Scaleform objects is _root.

You SHOULD NOT write "_root" in the INI configuration; the DLL already prefixes all of them with _root.

bool MakeCustomHideInfo(const std::string& element)
{
    bool success = true;

    std::string var = std::string("_root.") + element;

    success = this->MakeVariableInfo(var + "._xscale", 0.0, false) && success;
    success = this->MakeVariableInfo(var + "._yscale", 0.0, false) && success;
    success = this->MakeVariableInfo(var + "._zscale", 0.0, false) && success;

    return success;
}

The one you asked about is just a SkyUI widget and SkyUI widget paths are always "WidgetContainer.X.widget", where X is the numerical widget ID for your game.

To find a specific widget ID for your game, launch the game and make sure the element is visible on your screen (loaded), then close the game.

Now open <Documents>\My Games\Skyrim\SKSE\skse.log with a text editor and look for these lines:

WidgetLoader.as: loadWidget(a_widgetID = X, a_widgetSource = Y)

Where X is the widget ID you want to copy and Y is the .swf file responsible for the widget, in your case, amotclockwidget.swf.

Edited September 13, 2021 by throwaway5826450

stalPROm · September 13, 2021

16 minutes ago, throwaway5826450 said:
There is no way to make a guide for this other than what I've already written. The path and name of an element is entirely left to the author of the mod.

The best bets are to read the mod's Papyrus scripts if the mod dynamically modifies UI elements (like hiding an element when something at a script happens) or install a Flash decompiler like JPEXS, decompiling the .swf file that contains the element you want to hide and then manually looking for the element's path/name under "scripts".

The only guarantees are that all vanilla HUD elements are supported under [HUD] by default and that the root namespace for instantiated Scaleform objects is _root.

You SHOULD NOT write "_root" in the INI configuration; the DLL already prefixes all of them with _root.
bool MakeCustomHideInfo(const std::string& element)
{
    bool success = true;

    std::string var = std::string("_root.") + element;

    success = this->MakeVariableInfo(var + "._xscale", 0.0, false) && success;
    success = this->MakeVariableInfo(var + "._yscale", 0.0, false) && success;
    success = this->MakeVariableInfo(var + "._zscale", 0.0, false) && success;

    return success;
}
The one you asked about is just a SkyUI widget and SkyUI widget paths are always "WidgetContainer.X.widget", where X is the numerical widget ID for your game.

To find a specific widget ID for your game, launch the game and make sure the element is visible on your screen (loaded), then close the game.

Now open <Documents>\My Games\Skyrim\SKSE\skse.log with a text editor and look for these lines:
WidgetLoader.as: loadWidget(a_widgetID = X, a_widgetSource = Y)
Where X is the widget ID you want to copy and Y is the .swf file responsible for the widget, in your case, amotclockwidget.swf.

Ok, seems clear for me, thanks a lot!

throwaway5826450 · September 14, 2021

The reported crashes are not caused by this mod and the unattached instances were an oversight that only happens at New Game but are completely harmless and can be removed via ReSaver, if they are bothering you.

Alternatively, you can start a new game with the mod disabled, save your game and then enable the mod.

If you are able to recompile, you can also implement the fix that I've provided here.

Note that the problem with unattached instances DOES NOT exist in the Skyrim SE version and no further action is necessary there.

Since there is nothing else that needs my attention, I am out; back to my coffin!

cetuximab · February 20, 2022

Can anyone recompile this for AE?

shar181 · May 7, 2022

On 2/20/2022 at 9:46 AM, cetuximab said:

Can anyone recompile this for AE?

I hope someone can. I have an SE version of it, but it doesn't work on AE. :c

Sign In

SexLab - Hide HUD Elements

Recommended Posts

Link to comment

Guest

Link to comment

Link to comment

Guest

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Create an account or sign in to comment

Create an account

Sign in

Recently Browsing 0 members

Important Information