SexLab - Hide HUD Elements

[King-Crimson]

1 hour ago, Hawk9969 said:

Yes, the debug build is not intended for playing, just testing.

Just compare the size difference and you can have an idea of its lack of optimization.

 

Sooo, since it works now, i just did some extensive testing (i don't have the crosshair "problem"), can you compile it into a public version? Pretty please?

[Guest]

10 hours ago, XenonS3 said:

 

Sooo, since it works now, i just did some extensive testing (i don't have the crosshair "problem"), can you compile it into a public version? Pretty please?

I'll release a new version today (unless a problem shows up), which among other things, will include the crash fix.

 

EDIT:

 

Delayed because I had to rewrite the whole hiding mechanics.

[Guest]

Bleh, my GPU finally died while testing the new version (GPU was hanging for about a year, dollar was/is way too expensive to replace it then/now).

 

I can release it if you guys want it. It's feature complete, performs better (only one execution per SexLab animation instead of every event), fixes the reported bugs/crashes and everything that I managed to test before the GPU died was working properly.

I however can't guarantee that every single feature is bug free, as I couldn't test them fully.

[King-Crimson]

2 hours ago, Hawk9969 said:

Bleh, my GPU finally died while testing the new version (GPU was hanging for about a year, dollar was/is way too expensive to replace it then/now).

 

I can release it if you guys want it. It's feature complete, performs better (only one execution per SexLab animation instead of every event), fixes the reported bugs/crashes and everything that I managed to test before the GPU died was working properly.

I however can't guarantee that every single feature is bug free, as I couldn't test them fully.

Shit, im sorry that happened to you.

I would highly appreciate a public version of the current build. I found no bugs so far.

 

Hope you manage to get a new GPU soon...

[Guest]

Version 1.1.0 released.

 

For anyone who was either crashing or using the debug build, please update.

Sorry for taking so long, between me taking 1.5 days to track down an issue that eventually turned out to be linked to SkyUILib hooking some action script functions and my GPU dying, I also rewrote a good portion of the HUD code.

 

If any other issue arises, please let me know.

I can still fix/change the code and compile, but I can't test it in-game due to my GPU dying (I only have the video feed from it, its drivers will no longer work, and as such, Direct3D will also not work).

 

If you want to hide SkyUI's active effects widget:

[Custom]
X = WidgetContainer.0.widget

Where X is a sequence number starting at 1.

 

If you want to hide all SkyUI widgets:

[Custom]
X = WidgetContainer

 

[Lilzt3hcat]

8 hours ago, Hawk9969 said:

Version 1.1.0 released.

 

For anyone who was either crashing or using the debug build, please update.

Sorry for taking so long, between me taking 1.5 days to track down an issue that eventually turned out to be linked to SkyUILib hooking some action script functions and my GPU dying, I also rewrote a good portion of the HUD code.

 

If any other issue arises, please let me know.

I can still fix/change the code and compile, but I can't test it in-game due to my GPU dying (I only have the video feed from it, its drivers will no longer work, and as such, Direct3D will also not work).

 

If you want to hide SkyUI's active effects widget:

[Custom]
X = WidgetContainer.0.widget

Where X is a sequence number starting at 1.

 

If you want to hide all SkyUI widgets:

[Custom]
X = WidgetContainer

 

I will try it out as soon as I can, also sorry to hear about your gpu crappin out on you - just had mine die on me a couple months ago >_<


Edit: I can now report several hours of gameplay with no issues.

[Guest]

8 hours ago, Lilzt3hcat said:

I will try it out as soon as I can, also sorry to hear about your gpu crappin out on you - just had mine die on me a couple months ago >_<

I bet it was Nvidia, their hardware is a joke. I bought this 970 GTX early 2015, which has been malfunctioning since early 2018, while at the same time, I still have an ATI HD 5770 from 2010 working perfectly. Too bad AMD's software is even more of a joke.

I wish I could go back to AMD, but problems with drivers and games are a big no no for me.

[Guest]

Version 1.1.1 released!

 

As mentioned before, I cannot test it.

I just found this logical error in the code and decided to fix it.

 

Let me know if I broke anything.

[Lilzt3hcat]

10 hours ago, Hawk9969 said:

Version 1.1.1 released!

 

As mentioned before, I cannot test it.

I just found this logical error in the code and decided to fix it.

 

Let me know if I broke anything.

I'll test it out shortly.

(as to previous post, it was indeed - a 550ti to be specific)

 

Edit: about a couple hours of testing so far, no issues.

[Guest]

Version 1.1.2 released!

 

This is just a hotfix for version 1.1.1.

 

@Lilzt3hcat Thank you for testing them.

[Lilzt3hcat]

19 minutes ago, Hawk9969 said:

Version 1.1.2 released!

 

This is just a hotfix for version 1.1.1.

 

@Lilzt3hcat Thank you for testing them.

No problem, It's nice to feel like I'm being helpful lol.

[Nymra]

CTD issue is gone. Played a while and had no serious issues.

 

I just think the mod stops working sometimes because of general script load (apropos2, fillherup, sexlabutil1 all firing). But it seemed to work again in the next scene (will have to keep an eye on that). 

 

I also dont know if this mod is perfectly compatible with "Toggle Options" mod which has a hotkey for toggle the HUD on/Off, I faced some strange bug where I was stuck in "no HUD visible" and hotkeys did not work anymore. 

 

In that regard: wouldnt it be an option to create a mod that links toggle options to sexlab? So if SL starts an animation, it calls toggle options and activates "Hide HUD"? (of course this is an all or nothing method, but I honestly dont think that hiding only parts of the HUD is actually the main requirement of people).

 

I would also allow the funny thing of activating God Mode while in a sexlab animation, which I often use because many defeat mods do not manage to calm all nearby NPC... or new NPC that join in on the party (which then keep attacking the Player, making it all a mess).

 

And even more: allow Sexlab to link with toggle options, so that when you hit "Reposition Scene" in Sexlab it would automatically also toggle "collissions off" so that repositioning is easier and faster (in some situations at least) and then toggle collisions on when the 7 seconds are over.

 

Just some thouhgts

[Guest]

On 4/15/2019 at 9:28 PM, Nymra said:

I just think the mod stops working sometimes because of general script load (apropos2, fillherup, sexlabutil1 all firing). But it seemed to work again in the next scene (will have to keep an eye on that). 

This mod is written entirely in C++, not Papyrus. Papyrus load will not affect its operation.

The only time Papyrus load can play a hand is when SexLab sends its events (as SexLab is written in Papyrus).

But that should only affect this mod if Papyrus didn't send an event at all (stack dumping) and every mod, whether Papyrus or not, that relies on SexLab sending those events would break.

 

Please show me your SexLab - Hide HUD Elements.log for when this happens.

 

On 4/15/2019 at 9:28 PM, Nymra said:

I also dont know if this mod is perfectly compatible with "Toggle Options" mod which has a hotkey for toggle the HUD on/Off, I faced some strange bug where I was stuck in "no HUD visible" and hotkeys did not work anymore. 

I don't know which mod is Toggle Options, but I assume it just hides HUD elements by calling Debug.ToggleMenus(), which in turn hides everything.

This mod is compatible with mods doing that because they do different things. ToggleMenus simply stops rendering menus (including but not limited to HUD Menu), while this mod individually scales elements within HUD Menu to 0.

Of course an element configured to be hidden during SexLab won't be visible by another mod doing something completely different. The element scaling will only be back to normal after the animation ends.

 

On 4/15/2019 at 9:28 PM, Nymra said:

In that regard: wouldnt it be an option to create a mod that links toggle options to sexlab? So if SL starts an animation, it calls toggle options and activates "Hide HUD"? (of course this is an all or nothing method, but I honestly dont think that hiding only parts of the HUD is actually the main requirement of people).

Again, read above, they do different things. And no, you would be wrong.

Debug.ToggleMenus() hides EVERYTHING, including the console, custom menus (like the ones used by SexLab Tools), subtitles, SkyUI Widgets (like the ones used by Apropos), etc.

Obviously this and SexLab - Hide Crosshair Reference were developed because there was no proper solution before.

And if you really want this, you can easily do this with a few lines of code in Papyrus, calling Debug.ToggleMenus() on a SexLab start event and calling it again on a SexLab end event.

 

On 4/15/2019 at 9:28 PM, Nymra said:

I would also allow the funny thing of activating God Mode while in a sexlab animation, which I often use because many defeat mods do not manage to calm all nearby NPC... or new NPC that join in on the party (which then keep attacking the Player, making it all a mess).

 

And even more: allow Sexlab to link with toggle options, so that when you hit "Reposition Scene" in Sexlab it would automatically also toggle "collissions off" so that repositioning is easier and faster (in some situations at least) and then toggle collisions on when the 7 seconds are over.

How are these even related to hiding HUD elements?

[Ed86]

is there some sort of guide on finding game addresses for C++? preferably for skyrims/skse plugins

[Guest]

6 hours ago, Ed86 said:

is there some sort of guide on finding game addresses for C++? preferably for skyrims/skse plugins

It depends on what you want.

 

If you want to use a game's native function in your plugin you can dump the game's RTTI.

One easy way I found to get those addresses was to do the following:

class NativeFunctionDebug : public NativeFunction
{
public:
    const UInt32 CallbackAddress(void) const { return (UInt32)this->m_callback; }
};

class FunctionVisitorDebug : public VMClassFunctionVisitor
{ 
public:
    bool Accept(IFunction* func)
    {
        BSFixedString* className = func->GetClassName();
      
        if (className == nullptr || className->data == nullptr)
            return false;
      
        BSFixedString* funcName = func->GetName();
      
        if (funcName == nullptr || funcName->data == nulltr)
            return false;
      
        NativeFunctionDebug* funcDebug = reinterpret_cast<NativeFunctionDebug*>(func);
  
        _MESSAGE("Function %s::%s -> 0x%08X", className->data, funcName->data, funcDebug->CallbackAddress());
      
        return false;
    }
};

void DebugClass(BSFixedString& className)
{
    VMClassRegistry* registry   = (* g_skyrimVM)->GetClassRegistry();
    VMIdentifier*    identifier = nullptr;
      
    if (registry->Unk_13(&className, &identifier))
    {
        if (identifier != nullptr && identifier->m_type != nullptr)
        {
            FunctionVisitorDebug fDebug;

            identifier->m_type->Visit(fDebug);
        }
    }
}

Now just call DebugClass after DataLoaded:

case SKSEMessagingInterface::kMessage_DataLoaded:
{
    BSFixedString classGame("Game");
    BSFixedString classMath("Math");
    BSFixedString classUI("UI");

    DebugClass(classGame);
    DebugClass(classMath);
    DebugClass(classUI);
}

 

Now, if you need to get the address of an internal engine function or a subroutine, you will need to attach a debugger.

An easy one is Cheat Engine.

If you do know the value(s) a subroutine or function is accessing, you can find the address storing that value and then attach the debugger for write or read operations (depending on what the subroutine/function does).

Cheat Engine's Ultimap is also very useful, if your CPU supports it.

 

For finding calling conventions on a function, you will likely want to use a more robust debugger, like WinDbg or IDA. It's not a simple process as it will require you to go through the stack trace and it's also not a joyful process (can be extremely boring).

 

You also need at least some rudimentary level of x86 assembly knowledge for this, or else you won't even understand what those instructions are doing.

[Nharra]

On 4/7/2019 at 7:44 AM, Hawk9969 said:

If you want this to work with SKSE64, you will need to recompile.

1. Load SKSE64's solution into Visual Studio.
2. Right-click the solution, click "Add/Existing Project" and add this project.
3. Right-click this project, click "Properties", click "Configuration Manager" and change "Platform" to "x64".
4. Right-click this project, click "Properties", select "Configuration Properties/Linker/Advanced" and change "Target Machine" to "MachineX64".
5. Fix any error that might be caused from the library change (SKSE -> SKSE64).
6. Compile.

Would this work for your previous mod too (https://www.loverslab.com/files/file/8301-sexlab-hide-crosshair-reference/ )? I've never done anything like this before but am willing to try. I did read your instructions on that mod's thread, but they were a bit harder to follow without prior knowledge than this.

 

[Guest]

On 5/31/2019 at 6:46 PM, Lilimorphine said:

Would this work for your previous mod too (https://www.loverslab.com/files/file/8301-sexlab-hide-crosshair-reference/ )? I've never done anything like this before but am willing to try. I did read your instructions on that mod's thread, but they were a bit harder to follow without prior knowledge than this.

 

Not as easily. The other plugin uses some 32-bits addresses from Legendary Edition to hook its functionality.

I've made sure this one requires no literal addresses as to make it much easier to port it over.

The reason I didn't port it myself is that I refuse to give Bethesda any more money, thus having no SE to test it myself.

 

This plugin can do everything the other plugin does, and since version 1.1.0, the performance between them is very much the same.

This plugin should be preferred over the older one as it has more features.

 

[HUD]
HideActivate=yes

[Controls]
DisableActivate=yes

These will have the same effect as running the other plugin.

[Nharra]

On 6/2/2019 at 4:49 PM, Hawk9969 said:

This plugin can do everything the other plugin does, and since version 1.1.0, the performance between them is very much the same.

This plugin should be preferred over the older one as it has more features.

Thanks for your reply! Will try my luck with this one then

[Guest]

19 hours ago, Lilimorphine said:

Thanks for your reply! Will try my luck with this one then

Feel free to post in here if you need further assistance.

 

If you do recompile and test it out for SSE, feel free to attach the compiled DLL to your post and I'll include it in the first post as an unofficial port for SSE.

[Nharra]

On 6/4/2019 at 8:26 PM, Hawk9969 said:

Feel free to post in here if you need further assistance.

I've been tinkering with it for several days now, but I feel like I'm missing something fundamental. I did everything from your guide and also changed all #include that required skse to appropriate skse64 and that part seems to be ok, but I'm still getting overwhelming amount of errors seemingly more related to something I just don't have installed in my visual studio or included in solution or project or something. Big part of those errors are because VS apparently has no clue what are UInt8, 16, 32, 64 and SInt8 etc. Do I have to somehow add SexLab source too? And it's dependencies? Install something additional for VS? IF it's too long and troublesome to explain, I'll understand. Just wanted to give this thing a try.

[Guest]

2 hours ago, Lilimorphine said:

I've been tinkering with it for several days now, but I feel like I'm missing something fundamental. I did everything from your guide and also changed all #include that required skse to appropriate skse64 and that part seems to be ok, but I'm still getting overwhelming amount of errors seemingly more related to something I just don't have installed in my visual studio or included in solution or project or something. Big part of those errors are because VS apparently has no clue what are UInt8, 16, 32, 64 and SInt8 etc. Do I have to somehow add SexLab source too? And it's dependencies? Install something additional for VS? IF it's too long and troublesome to explain, I'll understand. Just wanted to give this thing a try.

Those data types are declared at common/ITypes.h.

I just checked SKSE64 and they are there.

typedef unsigned char		UInt8;		//!< An unsigned 8-bit integer value
typedef unsigned short		UInt16;		//!< An unsigned 16-bit integer value
typedef unsigned long		UInt32;		//!< An unsigned 32-bit integer value
typedef unsigned long long	UInt64;		//!< An unsigned 64-bit integer value
typedef signed char			SInt8;		//!< A signed 8-bit integer value
typedef signed short		SInt16;		//!< A signed 16-bit integer value
typedef signed long			SInt32;		//!< A signed 32-bit integer value
typedef signed long long	SInt64;		//!< A signed 64-bit integer value
typedef float				Float32;	//!< A 32-bit floating point value
typedef double				Float64;	//!< A 64-bit floating point value

You are probably missing the Windows API, which then fails to include those common headers into the project. You can tell VS to download the API for you, although it generally does that when you load a solution that requires it.

 

You also need to change the SKSE project (not the solution) to Static Library and compile it as Release, not Debug.

Properties/Configuration Properties/General/Configuration Type to Static Library (.lib).

[Nharra]

On 6/10/2019 at 2:58 AM, Hawk9969 said:

You are probably missing the Windows API, which then fails to include those common headers into the project. You can tell VS to download the API for you, although it generally does that when you load a solution that requires it.

 

You also need to change the SKSE project (not the solution) to Static Library and compile it as Release, not Debug.

Properties/Configuration Properties/General/Configuration Type to Static Library (.lib).

Thanks so much for your help! Now I'm down to just 7 errors and lots of warnings, but sadly build failed anyway
Here is the error list just in case

Spoiler

and the warning list

Spoiler

 

 

 

[Guest]

4 hours ago, Lilimorphine said:

Thanks so much for your help! Now I'm down to just 7 errors and lots of warnings, but sadly build failed anyway
Here is the error list just in case

  Reveal hidden contents

and the warning list

  Reveal hidden contents

 

 

 

The warnings can be ignored as those are from SKSE, not the plugin.

I did fix all the SKSE warnings that I came across for the sake of OCD, but that was for the original SKSE not SKSE64.

Right click SexLab - Hide HUD Elements project and click Properties. Configuration Properties -> C/C++ -> General, change Warning Level to Level3 (/W3).

Do this for both Debug and Release.

 

First add this as the first line of the plugin's main.cpp:

#define __SKSELE_PORT__

 

Error 1:

Open skse64/GameInput.h with VS and find the class PlayerControls declaration.

Then change this:

	PlayerInputHandler*	movementHandler;	// 170
	PlayerInputHandler*	lookHandler;		// 178
	PlayerInputHandler*	sprintHandler;		// 180
	PlayerInputHandler*	readyWeaponHandler; // 188
	PlayerInputHandler*	autoMoveHandler;	// 190
	PlayerInputHandler*	toggleRunHandler;	// 198
	PlayerInputHandler*	activateHandler;	// 1A0
	PlayerInputHandler*	jumpHandler;		// 1A8
	PlayerInputHandler*	shoutHandler;		// 1B0
	PlayerInputHandler*	attackBlockHandler; // 1B8
	PlayerInputHandler*	runHandler;			// 1C0
	PlayerInputHandler*	sneakHandler;		// 1C8
	PlayerInputHandler*	togglePOVHandler;	// 1D0

For this:

	#ifdef __SKSELE_PORT__
	PlayerInputHandler* inputHandlers[13];
	#else
	PlayerInputHandler*	movementHandler;	// 170
	PlayerInputHandler*	lookHandler;		// 178
	PlayerInputHandler*	sprintHandler;		// 180
	PlayerInputHandler*	readyWeaponHandler; // 188
	PlayerInputHandler*	autoMoveHandler;	// 190
	PlayerInputHandler*	toggleRunHandler;	// 198
	PlayerInputHandler*	activateHandler;	// 1A0
	PlayerInputHandler*	jumpHandler;		// 1A8
	PlayerInputHandler*	shoutHandler;		// 1B0
	PlayerInputHandler*	attackBlockHandler; // 1B8
	PlayerInputHandler*	runHandler;			// 1C0
	PlayerInputHandler*	sneakHandler;		// 1C8
	PlayerInputHandler*	togglePOVHandler;	// 1D0
	#endif

 

Error 2:

Change both unk04 in HUD.cpp lines 35 and 42 to unk08.

 

Error 3:

Plugin's main.cpp line 62 change RUNTIME_VERSION_1_9_32_0 to RUNTIME_VERSION_1_5_73.

 

Error 4 and 5:

I don't know why the SKSE team commented out a bunch of class VMClassInfo's declaration for SKSE64.

You will have to work around this.

Since memory isn't an issue for SSE, you can just leave the older function objects around while registering yours.

 

Plugin's PapyrusUI.h, remove or comment this:

		static const BSFixedString ClassName("UI");

		class NativeUIFunction final : public NativeFunction
		{
		public:
			const void* GetCallback(void) const           { return this->m_callback; }
			void        SetCallback(const void* callback) { this->m_callback = const_cast<void*>(callback); }
		};

		class OverrideFunction final : public VMClassFunctionVisitor
		{
			const std::string m_funcName;
			NativeUIFunction* m_func = nullptr;

			bool m_found = false;

		public:
			OverrideFunction(const std::string&, const void* const, VMClassRegistry* const, bool&);
			~OverrideFunction(void) { }

			bool Accept(IFunction*) override;
		};

Plugin's PapyrusUI.cpp, remove or comment this:

Plugin::PapyrusUI::OverrideFunction::OverrideFunction(const std::string& funcName, const void* const func, VMClassRegistry* const registry, bool& result)
	: m_funcName(funcName)
{
	VMIdentifier* identifier = nullptr;

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

	if (this->m_func != nullptr)
	{
		this->m_func->SetCallback(func);

		#ifdef _DEBUG
		Logger::Pretty("DEBUG", "Function '%s::%s' has been overridden.",
			PapyrusUI::ClassName.data, this->m_funcName.c_str());
		#endif

		return;
	}

	if (!this->m_found)
	{
		Logger::Pretty("WARNING", "Function '%s::%s' not found.",
			PapyrusUI::ClassName.data, this->m_funcName.c_str());
	}

	result = false;
}

bool Plugin::PapyrusUI::OverrideFunction::Accept(IFunction* func)
{
	BSFixedString* funcName = func->GetName();

	if (funcName != nullptr && funcName->data != nullptr && this->m_funcName == funcName->data)
	{
		this->m_found = true;

		PapyrusUI::NativeUIFunction* uiFunc = reinterpret_cast<PapyrusUI::NativeUIFunction*>(func);

		if (uiFunc == nullptr)
		{
			Logger::Pretty("WARNING", "Function '%s::%s' is not native.",
				PapyrusUI::ClassName.data, this->m_funcName.c_str());
		}
		else if (uiFunc->GetCallback() == nullptr)
		{
			Logger::Pretty("WARNING", "Function '%s::%s' has no callback.",
				PapyrusUI::ClassName.data, this->m_funcName.c_str());
		}
		else
		{
			this->m_func = uiFunc;
		}

		return true;
	}

	return false;
}

Plugin's PapyrusUI.cpp, change this:

bool Plugin::PapyrusUI::RegisterFuncs(VMClassRegistry* registry)
{
	bool success = true;

	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);

	if (success)
		Logger::Pretty("PAPYRUS", "UI functions successfully overridden.");

	return true;
}

For this:

bool Plugin::PapyrusUI::RegisterFuncs(VMClassRegistry* registry)
{
	registry->RegisterFunction(
		new NativeFunction3<StaticFunctionTag, void, BSFixedString, BSFixedString, bool>("SetBool", "UI", PapyrusUI::Override::SetT<bool>, registry));
	registry->RegisterFunction(
		new NativeFunction3<StaticFunctionTag, void, BSFixedString, BSFixedString, UInt32>("SetInt", "UI", PapyrusUI::Override::SetT<UInt32>, registry));
	registry->RegisterFunction(
		new NativeFunction3<StaticFunctionTag, void, BSFixedString, BSFixedString, float>("SetFloat", "UI", PapyrusUI::Override::SetT<float>, registry));
	registry->RegisterFunction(
		new NativeFunction3<StaticFunctionTag, void, BSFixedString, BSFixedString, BSFixedString>("SetString", "UI", PapyrusUI::Override::SetT<BSFixedString>, registry));

	registry->RegisterFunction(
		new NativeFunction2<StaticFunctionTag, bool, BSFixedString, BSFixedString>("GetBool", "UI", PapyrusUI::Override::GetT<bool>, registry));
	registry->RegisterFunction(
		new NativeFunction2<StaticFunctionTag, UInt32, BSFixedString, BSFixedString>("GetInt", "UI", PapyrusUI::Override::GetT<UInt32>, registry));
	registry->RegisterFunction(
		new NativeFunction2<StaticFunctionTag, float, BSFixedString, BSFixedString>("GetFloat", "UI", PapyrusUI::Override::GetT<float>, registry));
	registry->RegisterFunction(
		new NativeFunction2<StaticFunctionTag, BSFixedString, BSFixedString, BSFixedString>("GetString", "UI", PapyrusUI::Override::GetT<BSFixedString>, registry));

	Logger::Pretty("PAPYRUS", "UI functions successfully overridden.");

	return true;
}

 

[Guest]

The only warning that comes from this plugin is from main.cpp:

		Plugin::Logger::Pretty("PLUGIN", "Plugin instance successfully created at 0x%08X.", (UInt32)g_plugin);

Change to:

		Plugin::Logger::Pretty("PLUGIN", "Plugin instance successfully created at 0x%016llX.", (UInt64)g_plugin);

 

EDIT:

Also open SexLab - Hide HUD Elements.vcxproj with a text editor and change this:

    <ProjectReference Include="..\..\common\common_vc9.vcxproj">
      <Project>{20c6411c-596f-4b85-be4e-8bc91f59d8a6}</Project>
      <CopyLocalSatelliteAssemblies>true</CopyLocalSatelliteAssemblies>
      <ReferenceOutputAssembly>true</ReferenceOutputAssembly>
    </ProjectReference>

For this:

    <ProjectReference Include="..\..\common\common_vc14.vcxproj">
      <Project>{472E19AB-DEF0-42DF-819B-18722E8DC822}</Project>
      <CopyLocalSatelliteAssemblies>true</CopyLocalSatelliteAssemblies>
      <ReferenceOutputAssembly>true</ReferenceOutputAssembly>
    </ProjectReference>

[Nharra]

You are my hero for putting up with me, I hope you know! Sadly, I feel like I fucked up somewhere, though, since after all your advised changes I failed again and now I'm getting these errors:
 

Spoiler

 

I probably should have mentioned earlier that it's an earlier version of SSE and SKSE64 I'm trying to port this to - 1.5.53 and 2.0.10 respectively. I'm really sorry if that is the reason I keep failing >_< I was hoping to re-do the port for a more recent versions if/when I let steam update and use this one until then...

 

I have two questions. About changing common_vc9 for common_vc14 that I did in the text editor; would it have been the same as if I right clicked your plugin's references and added vc14 from the list and then removed vc9? And the second one; when I choose "build", I do it just for your plugin, not the whole solution, right? >_>;