logo
  (UTC)
 Change Template: 
  Oldunreal Forums › Editing, scripting, modelling and mapping › UScript Board › C++ Native Mods for UE1 › Is there a proper fix for TArray<Byte> linkage?
(Moderator: han)
‹ Previous Topic | Next Topic ›
Page Index Toggle Pages: 1 2 [3]  Send TopicPrint
Very Hot Topic (More than 25 Replies) Is there a proper fix for TArray<Byte> linkage? (Read 11687 times)
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 595
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: Is there a proper fix for TArray<Byte> linkage?
Reply #30 - Sep 15th, 2016 at 12:27pm
Print Post  
[]KAOS[]Casey wrote on Sep 8th, 2016 at 4:12pm:
edit2: FSoundData isn't even used in my code so why would changing that be necessary?

Actually that fixed it for me (and using the other UnTemplate.h I sent, along the removed ENGINE_API on the FMipmap[Base]), though the changes for FMipmap* might not be necessary.

Seems like there is some special thing going on with class
Code
Select All
ENGINE_API FSoundData : public TLazyArray<BYTE>

when the specializations happens as part of deriving from that template rather then using it as some (member) variable, while it gets exported at the same time.

Using a staged approach also removes the link errors:
Code
Select All
//class ENGINE_API FSoundData : public TLazyArray<BYTE>
class TLazyByteArray : public TLazyArray<BYTE> {};
class ENGINE_API FSoundData : public TLazyByteArray
{
public:
	USound* Owner;
	void Load();
	FLOAT GetPeriod();
	FSoundData( USound* InOwner )
	: Owner( InOwner )
	{}
};


Maybe MK can shed some light onto this.
  
HX on Mod DB. Revision on Steam. Löffels on Patreon.
Back to top
 
IP Logged
 
Masterkent
Developer Team
Offline



Posts: 1345
Location: Russia
Joined: Apr 5th, 2013
Gender: Male
Re: Is there a proper fix for TArray<Byte> linkage?
Reply #31 - Sep 15th, 2016 at 3:21pm
Print Post  
I don't see any explicit description of the behavior when a dllimport class is derived from a non-dllimport class (for dllexport, MSDN provides some description: https://msdn.microsoft.com/en-us/library/twa2aw10.aspx).

IMO, the best thing you can do here is to remove the dllimport attribute from the entire class FSoundData and add such an attribute to its members that surely have to be imported (if such members exist). If FSoundData::Load and FSoundData::GetPeriod belong to the set of entities that must be imported, the resulting code should look like:

Code
Select All
class FSoundData : public TLazyArray<BYTE>
{
public:
	USound* Owner;
	ENGINE_API void Load();
	ENGINE_API FLOAT GetPeriod();
	FSoundData( USound* InOwner )
	: Owner( InOwner )
	{}
};
  
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 595
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: Is there a proper fix for TArray<Byte> linkage?
Reply #32 - Sep 15th, 2016 at 4:54pm
Print Post  
Yeah, the only vague hint on the issue on that page is:
Quote:
Because of a change in behavior introduce in Visual C++ .NET to make the application of dllexport more consistent between regular classes and specializations of class templates, if you apply dllexport to a regular class that has a base class that is not marked as dllexport, the compiler will generate C4275.

But they won't state what they actually did change.


Masterkent wrote on Sep 15th, 2016 at 3:21pm:
IMO, the best thing you can do here is to remove the dllimport attribute from the entire class FSoundData and add such an attribute to its members that surely have to be imported (if such members exist). If FSoundData::Load and FSoundData::GetPeriod belong to the set of entities that must be imported, the resulting code should look like:

Code
Select All
class FSoundData : public TLazyArray<BYTE>
{
public:
	USound* Owner;
	ENGINE_API void Load();
	ENGINE_API FLOAT GetPeriod();
	FSoundData( USound* InOwner )
	: Owner( InOwner )
	{}
};

I agree, and thats actually the solution I came up with last year when trying to get ALAudio building for Nerf. But at least I now know a bit more about what causes the issue.
  
HX on Mod DB. Revision on Steam. Löffels on Patreon.
Back to top
 
IP Logged
 
[]KAOS[]Casey
Developer Team
Betatester
Offline


nedm

Posts: 3214
Joined: Aug 7th, 2011
Gender: Male
Re: Is there a proper fix for TArray<Byte> linkage?
Reply #33 - Sep 16th, 2016 at 2:09am
Print Post  
SetSize worked after I removed CORE_API on FArray. Looks like everything builds properly now, and I can import textures after a few changes to get file loading to work properly.

Thanks a ton to both of you -- hopefully this thread will be useful for someone else in the future too...

It may even revive my multi-map server mod attempt on DeusEx as a way to preserve gamestates between map changes... always wanted to see if that could work. Just couldn't get dot's mod to compile for DX.
  
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 595
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: Is there a proper fix for TArray<Byte> linkage?
Reply #34 - Sep 16th, 2016 at 7:24am
Print Post  
[]KAOS[]Casey wrote on Sep 16th, 2016 at 2:09am:
It may even revive my multi-map server mod attempt on DeusEx as a way to preserve gamestates between map changes... always wanted to see if that could work. Just couldn't get dot's mod to compile for DX.

Does it run all maps parallel, where players can be on each of the maps?
  
HX on Mod DB. Revision on Steam. Löffels on Patreon.
Back to top
 
IP Logged
 
[]KAOS[]Casey
Developer Team
Betatester
Offline


nedm

Posts: 3214
Joined: Aug 7th, 2011
Gender: Male
Re: Is there a proper fix for TArray<Byte> linkage?
Reply #35 - Sep 16th, 2016 at 3:25pm
Print Post  
yeah, it can. though I would probably want to enforce that only one map runs at a time since the game normally doesn't work like that
  
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 595
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: Is there a proper fix for TArray<Byte> linkage?
Reply #36 - Sep 20th, 2016 at 3:36pm
Print Post  
[]KAOS[]Casey wrote on Sep 16th, 2016 at 3:25pm:
yeah, it can. though I would probably want to enforce that only one map runs at a time since the game normally doesn't work like that

Yeah, Deus Ex content would most certainly totally break with players across different maps.

However, if you would limit it to one map anyway, what is the point in having some dual server thing anyway? Saving the map while comforming the savefile to the original map file during mapchange works too.
  
HX on Mod DB. Revision on Steam. Löffels on Patreon.
Back to top
 
IP Logged
 
[]KAOS[]Casey
Developer Team
Betatester
Offline


nedm

Posts: 3214
Joined: Aug 7th, 2011
Gender: Male
Re: Is there a proper fix for TArray<Byte> linkage?
Reply #37 - Sep 20th, 2016 at 4:43pm
Print Post  
edit:Oh crappity smack, I guess you could do that too..


Didn't even think of the conforming at all
  
Back to top
 
IP Logged
 
Leo T_C_K
Betatester
Offline



Posts: 1968
Joined: Aug 27th, 2005
Gender: Male
Re: Is there a proper fix for TArray<Byte> linkage?
Reply #38 - Sep 21st, 2016 at 7:01am
Print Post  
I did, but in case of maps I was always afraid of glitches resulting from client desync, however the changes in the save files are minimal...

this would even work with the hub system thing left in Unreal, the push and pop/peer system.
  
People who accuse others of trolling are usually the biggest trolls themselves.
Back to top
YouTube  
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 595
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: Is there a proper fix for TArray<Byte> linkage?
Reply #39 - Oct 15th, 2016 at 1:51pm
Print Post  
han wrote on Sep 7th, 2016 at 4:08pm:
As for compiler [VC6] bugs, I never ran into a single one so far, for uc i did.

Well actually I did before.

Code
Select All
// Load a class object.
template< class T > UClass* LoadClass( UObject* Outer, const TCHAR* Name, const TCHAR* Filename, DWORD LoadFlags, UPackageMap* Sandbox )
{
	return UObject::StaticLoadClass( T::StaticClass(), Outer, Name, Filename, LoadFlags, Sandbox );
}


Code
Select All
// Inside a single function.
UClass* ClientClass = LoadClass<UClient>( [...] );
UClass* RenderClass = LoadClass<URenderBase>( [...] );


When compiled under VC6 this translates in my case to:

Code
Select All
UClass* ClientClass = LoadClass<URenderBase>( [...] );
UClass* RenderClass = LoadClass<URenderBase>( [...] );



So as a workaround one can replace it with a direct StaticLoadClass() call. Eventually commenting this out in the headers to.

Other templates like ConstructObject doesn't seem to be affected, but maybe one shouldn't rely on it.
  
HX on Mod DB. Revision on Steam. Löffels on Patreon.
Back to top
 
IP Logged
 
Page Index Toggle Pages: 1 2 [3] 
Send TopicPrint
‹ Previous Topic | Next Topic ›
Bookmarks: del.icio.us Digg Facebook Google Google+ Linked in reddit StumbleUpon Twitter Yahoo
 
  « Board Index ‹ Board Top  

Oldunreal Forums » Powered by YaBB 2.6.11!
YaBB Forum Software © 2000-2022. All Rights Reserved.

Valid RSS Valid XHTML Valid CSS Powered by Perl Source Forge