I’m currently trying to compile my SteamWorkshopAccessor Plugin for Linux to help out one of the customers.
One issue is that a variable of the parent class is unknown in the child class
template <typename SteamResultType, typename CallbackPayloadType>
class **FSteamAsyncObject**
{
...
protected:
CallbackPayloadType **m_callbackPayload**;
...
};
template <typename QueryParameterType, typename QueryResultType>
class FSteamAsyncObjectQueryWorkshopForItems : public **FSteamAsyncObject**<SteamUGCQueryCompleted_t, QueryResultType>
{
public:
FSteamAsyncObjectQueryWorkshopForItems(const SteamAPICall_t& apiCall, const QueryParameterType& queryParams, TFunction<void(QueryResultType)>&& inCallbackFunction)
: FSteamAsyncObject<SteamUGCQueryCompleted_t, QueryResultType>(FString("QueryWorkshopForItems"), apiCall, MoveTemp(inCallbackFunction))
{
**m_callbackPayload**.queryParams = queryParams;
}
};
**m_callbackPayload **is unknown member variable. Why?..
Another issue is a
#define **R_OK**
inside the crosscompile chain which seems to inject files in the plugin files when compiling.
It conflicts with
UENUM(BlueprintType)
enum class EResultBP : uint8
{
R_INVALIDRESULT = 0, // FIX unreal wants a 0 value since UE4.24
// Success.
**R_OK **= 1,
...
}
It even conflits with clear references to the enum
EResultBP::R_OK
I could fix most of the code by
#ifdef R_OK
#pragma push_macro("R_OK")
#undef R_OK
#define NEED_R_OK_POP
#endif
CODE
#ifdef NEED_R_OK_POP
#undef NEED_R_OK_POP
#pragma pop_macro("R_OK")
#endif
but now there is the generated code from the header tool that generated
...
UEnum* Z_Construct_UEnum_SteamGeneral_EResultBP()
{
#if WITH_HOT_RELOAD
UPackage* Outer = Z_Construct_UPackage__Script_SteamGeneral();
static UEnum* ReturnEnum = FindExistingEnumIfHotReloadOrDynamic(Outer, TEXT("EResultBP"), 0, Get_Z_Construct_UEnum_SteamGeneral_EResultBP_Hash(), false);
#else
static UEnum* ReturnEnum = nullptr;
#endif // WITH_HOT_RELOAD
if (!ReturnEnum)
{
static const UE4CodeGen_Private::FEnumeratorParam Enumerators] = {
{ "EResultBP::R_INVALIDRESULT", (int64)EResultBP::R_INVALIDRESULT },
{ "EResultBP::R_OK", (int64)EResultBP::R_OK },
...
more R_OK that again conflict with the toolchain, where I’m not able to inject the undefine fix from above …
The simplest thing would be to rename R_OK to something else, which probably causes a mess in blueprint …
any ideas?