UE1 - UT Extremely aggravating online physics issue

[Rajada]

I have a decorative element that attaches to a player. It is supposed to stay positionally with the player, but remain at 0,0,0 rotation. It works fine offline, but the minute I test it online it rotates forward 90 degrees in pitch. THe physics state is PHYS_Trailer, if I change it to any other physics state, it is COMPLETELY invisible online. This subclasses effect. I tried subclassing Projectile, exact same issues.

var rotator NoRot;
var() float TimeLeft;
var(Sounds) sound MiscSound;

function PostBeginPlay()
{
	SetTimer(0.1, True);
	SetLocation(Owner.Location);
	SetRotation(NoRot);
	DrawScale = Pawn(Owner).DrawScale;
	if(DrawScale <= 0.0)
	DrawScale = 1.0;
	
	NoRot.Pitch = 0;
	NoRot.Yaw = 0;
	NoRot.Roll = 0;
}

simulated function timer()
{
	TimeLeft -= 0.1;
	
	if(Pawn(Owner).Health <= 0 || TimeLeft <= 0.0)
	{
	Pawn(Owner).GroundSpeed = Pawn(Owner).Default.GroundSpeed;
	Pawn(Owner).AirSpeed = Pawn(Owner).Default.AirSpeed;
	Pawn(Owner).WaterSpeed = Pawn(Owner).Default.WaterSpeed;
	Pawn(Owner).Buoyancy = Pawn(Owner).Default.Buoyancy;
	Pawn(Owner).JumpZ = Pawn(Owner).Default.JumpZ;
	Destroy();
	}
	else
	{
	SetLocation(Owner.Location);
	SetRotation(NoRot);
	DrawScale = Pawn(Owner).DrawScale;
	if(DrawScale <= 0.0)
	DrawScale = 1.0;
	}
}

simulated function TakeDamage(int Damage, Pawn EventInstigator, vector HitLocation, vector Momentum, name DamageType)
{
	local FrozenShatter S;
	
	Pawn(Owner).TakeDamage(Damage/3, Instigator, HitLocation, Momentum, DamageType);
	S = Spawn(class'RajMutators2.FrozenShatter',,,HitLocation);
	S.RemoteRole = Role_SimulatedProxy;
	S.Drawscale = 1.0;
}

 

[gopostal]

You are adding new values that must be replicated. Projectile doesn't get much positional update, the code treats it as fire-and-forget to a large extent.
To do this you'll have to declare positional and physics replication and set up the updating of it, which will need to be pretty regular.

 

[Rajada]

This version subclasses Effect for now. Also, it is rotationally screwing up when physics is PHYS_Trailer, so does that mean it is positionally screwing up in other physics states? Lastly, I'm a bit unclear on which values you think I need to replicate. You are referring to NoRot correct? It seems odd that I have to replicate an empty rotator to get this to work.

 

[gopostal]

Think about it for a second. If you subclass effect, when is the next time it's going to get positional update? Never, effect spawns then doesn't ever get new data so you'll need to force new positions to it constantly.
I'm not sure what you are building here but effect isn't the way to go. I would work from weapon since it becomes player inventory, updates regularly, and you have specific ownership tied to it that is also updated.

 

[Rajada]

Yeah, but I have forced it to update with my code, it moves with the owner pawn (owner is set in a projectile class). When the owner pawn is falling through the air the effect is oriented 100% correctly, but once he or she lands the effect returns to the 90 degree pitched forward position. I don't think making this a weapon is going to help any if I'm using the same basic code. Plus, this effect is decorative.

You know the Shield Belt effect? I'm doing something like that. This class is spawned by a freezing weapon. It creates a pillar of ice around the player and immobilizes the player (can still be moved by weapon momentum). My effect works 100% fine offline, and the only issue online is the rotation bug. Everything else works as coded moving with the pawn (should he or she be moving).

 

[gopostal]

First are you subclassing Effects or is there another class in your mod called Effect?
Secondly are you declaring all the default properties for it as it is spawned?

 

[Rajada]

Oh, sorry, yes it subclasses Effects. And there aren't really many default properties to declare except my TimeLeft variable which I've defined as 5 already.

 

[gopostal]

OK then consider the parent Effects. It's almost exclusively something that is rendered simulated. What you are doing is not simulated at all since everyone needs to see it. Can you see now why it's a bad parent class to use?

These are the defaults for Effects:

defaultproperties
{
     DrawType=DT_None
     Physics=PHYS_None
     bNetTemporary=true
     bGameRelevant=true
     CollisionRadius=+0.00000
     CollisionHeight=+0.00000
}

No drawtype, no physics and nettemp. Three strikes for it replicating.

 

[Rajada]

I put it back under Projectile and set bTrailerPrepivot=True; and bTrailerSameRotation=True; in PostBeginPlay() which I also forgot to simulate (d'oh!). Then I used PHYS_Trailer with an offset of (0,0,0). Works perfect now.

Correct stupid mistake + bTrailerSameRotation seems to have fixed it right up!

 

[gopostal]

Not a stupid mistake, it's a common one. Replication wears out everyone and I mean EVERYONE at one point or another. Probably 2/3rds of the pure coding questions I see have at least one foot standing in replication.

 

[Zur]

Must admit that I never managed to wrap my head around replication. The trouble is that it's poorly documented and those who've figured it out can't really explain it in a few words. The furthest I got into understanding the subject is that a replication class exists on both the client and server but only certain variables or functions carry over from on to the other.

 

[Wormbo]

It is possible to explain each part of replication with few words, but that would rip it out of context and thus not help anyone. The real problem isn't understanding the individual rules of replication, but putting them together to solve a problem.