Package incompatibility when compiling with UCC (PostBeginPlay)

[1337GameDev]

I am making a subclass of

Code: Select all

Botpack.ut_bossarm

and have PostBeginPlay in my subclass. When building with UCC, i get this message:

Code: Select all

Function MyPackage.My_bossarm.PostBeginPlay has superfield Engine.Decoration.PostBeginPlay.  This superfield was not present in UT v436, so this package will not work on UT v436 clients or servers. Do you want to use Engine.Actor.PostBeginPlay as the superfield to fix this compatibility problem? (Y/N): n
Aborted because of package incompatibility

I assumed that if

Code: Select all

ut_bossarm 

didn't have PostBeginPlay, or Decoration didn't, I would merely override

Code: Select all

Actor.PostBeginPlay

and all will be fine.

Is this because

Code: Select all

Engine.Decoration

is a native class? What's a way to explicitly specify the override in code, to avoid answering this every build, if there's no way around this?

[Aspide]

After investigating I noticed that Engine.Decoration has a big difference between 469 and 436: the 469 version has this:

Code: Select all

event PostBeginPlay()
{
	//Make this decoration appear in the skybox on net clients
	if ( (SkyZoneInfo(Region.Zone) != None) && !bHidden && (RemoteRole != ROLE_None) )
	{
		bAlwaysRelevant = true;
		NetPriority *= 0.5;
	}
	//Reduce amount of network ticks on decorations that don't need them
	if ( bStatic && (RemoteRole != ROLE_None) )
	{
		if ( NetUpdateFrequency == 100 )
			NetUpdateFrequency = 5;
		NetPriority *= 0.5;
	}
}

while the 436 version doesn't have this function at all. You could try to copy paste that code in yours and see what happens.

[1337GameDev]

Hmm, doesn't work.

My guess is that because 436 doesn't have this code, and my package overrides this method, it doesn't know which version to "override" as code in 436 won't work with a 469 server (as the compiler won't know which "method" to override).

I assumed the compiled code will just mark which code to execute for overriding functions, but it seems it instead marks which function is overriden, and because this function exists in v469 and not v436, it doesn't know which function to mark as overridden (and the code will crash a v436 server as it references a function that doesnt exist to mark as overridden).

I feel I just need to avoid this method as the unreal VM doesn't work how I expected. Sigh... Will have to use another one of the "begin play" methods and see if that works for what I want in the lifecycle.

[Feralidragon]

When code is compiled, the methods are linked directly to the right class if the method is available in that class.

As such, if UCC allowed your code to compile as it is, it would break v436 clients, because they technically do not have that method in that class (link-wise), hence why it's (currently) not allowed.
So yeah, you have to use an alternate BeginPlay method, which in most cases should not make a difference.

Furthermore, if you're extending Decoration, you might want instead extend Actor directly: unless you really want to keep Decoration-specific code/functionality, or really want to keep an actor under Decoration for semantic purposes, there isn't a very good reason to extend from it.