GBEF "SDK"/Plugin

[Detanup01]

SSE has a Plugin Development Kit, and sdk's.
Stupid idea but what about adding our own into it?
Still requires to load plugins / dll's and the "Exports" in the file could be used to call the function.
For example steam_ini would be:

foreach all plugin with calling "gbfe_SteamInit" (if exists)
Param would be same a the ori function + bool* so we can see if we should skip our own function.
If bool* returns true we continue in our function. If false we return.
Whichever plugin has higher "priority" will run first.
If first plugin bool* returns false we return the normal result and no longer calling other plugins

[otavepto]

every time I look at flat.cpp my stomach contracts a little :/

[otavepto]

How should the plugins interact with the interfaces ?
Let's take steam_gameserver interface as an example.

Here this function changes the state variable logged_in

gbe_fork/dll/steam_gameserver.cpp

Lines 196 to 205 in af904d9

	void Steam_GameServer::LogOff()
	{
	PRINT_DEBUG_ENTRY();
	std::lock_guard<std::recursive_mutex> lock(global_mutex);
	if (logged_in) {
	call_servers_disconnected = true;
	}
	logged_in = false;
	}

If we call the plugin's function, and it set it's bool* to false (we skip our own function) then this variable will not be updated.

Later, the game might call another function from the same interface like this one which also depends on the state variable logged_in

gbe_fork/dll/steam_gameserver.cpp

Lines 209 to 214 in af904d9

	bool Steam_GameServer::BLoggedOn()
	{
	PRINT_DEBUG_ENTRY();
	std::lock_guard<std::recursive_mutex> lock(global_mutex);
	return logged_in;
	}

So again we call the plugin's equivalent function, but unfortunately this time it set its bool* to true (we don't skip our own function) and in this case will return a value which was never updated and doesn't really reflect the actual state of the interface.

A possible solution is to let the plugin decide whether we should skip our own interface entirely or not during initialization, for example while the game is calling this

gbe_fork/dll/steam_client_interface_getter.cpp

Line 321 in af904d9

void *Steam_Client::GetISteamGenericInterface( HSteamUser hSteamUser, HSteamPipe hSteamPipe, const char *pchVersion )

The drawback of this solution is that devs have to either fully implement the interface or not, meaning that partial tweaks and fixes will not be possible.

What do you think ?

[Detanup01]

Ye I think that would be more beneficial.
We would have to make a RegisterInterface / UnregisterInterface in there.

void PDK::RegisterInterface(void* interfaceMakePtr, const char* interfaceVersion);
void PDK::UnRegisterInterface(void* interfaceMakePtr);

A regular maker would be

// return ptr is our interface.
void* MakeMyAppList(HSteamUser hSteamUser, HSteamPipe hSteamPipe);

and reg/unreg would be

PDK::RegisterInterface(&MakeMyAppList,"STEAMAPPLIST_INTERFACE_VERSION001");
PDK::UnRegisterInterface(&MakeMyAppList);

And inside GetISteamGenericInterface we should foreach in the List that we provide and if interface exists load that.

[Detanup01]

Added basic for this to a PDK Branch.

[Detanup01]

We should able to share the Settings and the base/common things.
Idk how it would be done as the other project.
Thinking something like.

#include "gbe_fork/dll/base.h"
#include "gbe_fork/pdk/pdk.h"

DLL_EXPORT void Load_Plugin()
...

DLL_EXPORT void Unload_Plugin()
...

In pdk we should be able to call those functions (load,unload)
Plus maybe something like Setttings* GetSettings() or something