Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I can't seem to get this template to work out of the box anymore #8

Open
Jeidoban opened this issue Nov 8, 2023 · 4 comments
Open

Comments

@Jeidoban
Copy link

Jeidoban commented Nov 8, 2023

Hi there! I wanted to preface this with that I'm rather new to modding in general and I'm not a master with C++ by any means, so I apologize if what I'm talking about might be obvious.

When I first pulled this template about 3 weeks ago everything for the most part worked great. I ran the python script, built with vcpkg, and I could drop the DLL into the plugins directory for SFSE and it would recognize and load it great. I got my mod working the way I wanted to and didn't have any issues.

I decided to pull this template again to work on a different mod and I have run into some issues that are preventing me from even getting a DLL from this template to run properly with zero changes. In the SFSE.txt file I'm getting this issue:

checking plugin NoReload.dll
plugin NoReload.dll (00000000  00000000) no version data 0 (handle 0) 

After some sleuthing, I found out the culprit was the 'inline' keyword on the version dll export #define in the CommonLibSF:

#define SFSEPluginVersion extern "C" [[maybe_unused]] __declspec(dllexport) inline constinit SFSE::PluginVersionData SFSEPlugin_Version

This appears to be different than when I pulled this template (which in turn pulled commonlib) originally. Removing 'inline' got me past this issue and allowed my plugin to load.

However now trying to call any commonlibSF classes or functions results in a game crash. I even put in my previous working mod into my new project and just ended up with crashes any time my hook was fired.

I'm not totally sure what could be causing this. The game version hasn't changed in the time period that I've been using this template, so I'm not sure what would be causing all of these new issues. Maybe CommonlibSF changed the way offsets or IDs are calculated? Though my previously working mod also didn't work so maybe not?

I'm not getting build issues btw (other than with clang, but I'm not using that anyway), that part is working very smoothly. It's just after the plugin is loaded by SFSE that issues are arising.

@codersparks
Copy link

I'm also having this problem

@DennisSoemers
Copy link

I don't suppose either one of you happens to have found a good way to fix this in the time that has passed since you originally posted this? I'm still having the same issue now too...

@Jeidoban
Copy link
Author

Jeidoban commented Dec 31, 2023

I don't suppose either one of you happens to have found a good way to fix this in the time that has passed since you originally posted this? I'm still having the same issue now too...

I just kind of gave up unfortunately as it was taking too much time to figure out what was going on. I needed to move onto other things. The only thing I can recommend is try the other SFSE template linked in the CommonLib repo, though I haven't tried that so I'm not sure if it works. I've just decided to hold off on any further modding attempts for Starfield until the creation kit is out. Best of luck to you!

@alex-taxiera
Copy link

I got it working, but not without a bunch of manual work. It seems to be a problem with the CommonLib not matching the correct SFSE version. CommonLib hasn't been updated in 2 months so I think it is just missing the latest SFSE version.

I can detail my monkey patch, but for reference I am consuming CommonLib as a git submodule so YMMV if using other options.

  1. Removed the SFSEPluginVersion definition from CommonLibSF/include/SFSE/Interfaces.h, this is the last line of that file, I just commented it out:
//#define SFSEPluginVersion extern "C" [[maybe_unused]] __declspec(dllexport) inline constinit SFSE::PluginVersionData SFSEPlugin_Version
  1. Removed add_commonlibsf_plugin from CMakeLists.txt. This function generates a Plugin.h file with all of your plugin version data. We will now need to manually configure our mod like so:
# set all source files here
set(
  SOURCES
    ${CMAKE_CURRENT_SOURCE_DIR}/src/Main.cpp
)

source_group(
  TREE ${CMAKE_CURRENT_SOURCE_DIR}
  FILES
    ${SOURCES}
    ${CMAKE_CURRENT_SOURCE_DIR}/include/Plugin.h
)

source_group(
  TREE ${CMAKE_CURRENT_BINARY_DIR}
  FILES ${CMAKE_CURRENT_BINARY_DIR}/version.rc

)

#find_package(CommonLibSF CONFIG REQUIRED)
#add_commonlibsf_plugin(
#  ${PROJECT_NAME}
#  AUTHOR "Alex Taxiera"
#  SOURCES ${headers} ${sources}
#)
add_library(
  ${PROJECT_NAME}
  SHARED
    ${SOURCES}
    ${CMAKE_CURRENT_SOURCE_DIR}/include/Plugin.h
    ${CMAKE_CURRENT_BINARY_DIR}/version.rc
    .clang-format
    vcpkg.json
)
  1. Finally I hand created a Plugin.h file in my include folder based on the generated one:
#pragma once

namespace Plugin
{
    using namespace std::string_view_literals;

    static constexpr auto Name{ "StarfieldRichPresence"sv };
    static constexpr auto Author{ "Alex Taxiera"sv };
    static constexpr auto Version{
        REL::Version{0, 0, 1, 0}
    };
}

namespace SFSE
{
	constexpr REL::Version RUNTIME_SF_1_8_88(1, 8, 88, 0); // this was the version missing from CommonLib
}

extern "C"
{
	__declspec(dllexport) SFSE::PluginVersionData SFSEPlugin_Version = {
		SFSE::PluginVersionData::kVersion,

		1,							  // version 1
		"Starfield Rich Presence",
		"Alex Taxiera",

		1,                              // yes address independent
		0,                              // not structure independent
		{ SFSE::RUNTIME_SF_1_8_88.pack(), 0 },

		0,  // works with any version of the script extender. you probably do not need to put anything here
		0, 0,  // set these reserved fields to 0
	};
};

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants