Wired Mover sounds

[Barbie]

Today I noticed wired behaviour of MoverSounds: I have two movers with MoverEncroachType=ME_ReturnWhenEncroach and IntialState=BumpOpenTimed. If I activate one mover by bumping and block it, I hear the opening or closing sound of the other mover, too. I've taken a short video of that; a small test map is also available.

[Red_Fist]

Hmm, I wonder if that "group" thing comes into play, in the mover properties. add a group name see what happens.

(not talking about editor groups)

And did you read my post before yours in the duplicate actor thread ?

[sektor2111]

Happens because that mover is triggered and blocked by pawn which is making it to return and cycle is repeating faster. What's not clear? It's not anything magic.
Like I said for MH = CRUSH EVERYTHING - is the best ever fix even if you believe me or not + tiny delay for those without delay in order to prevent unwanted Levers crush. I got rid of this thing 2 years ago when monsters were bugging things + idiots campers in purpose to annoy the rest of players. In that moment I've decided CRUSH with a HUGE amount of damage + PawnProximity used - end of problems.

[editor Dave]

Yeah, it's the "ReturnGroup" in the mover properties that changes the behavior. Movers of the same ReturnGroup are set to return at the same time, so if an encroach happens to one mover of the group of movers, the others return, too. That includes the sounds as well, of course. If you wanna change that, just specify different ReturnGroups.

@sektor: The problem was the sounds of both movers were heard, although only one was activated. Regarding your solution I think "crush" is a little bit too sadisic for mere doors I rather make the trigger's radius bigger or set the mover to Ignore (although this isn't without problems either).

[Barbie]

I wonder if that "group" thing comes into play

it's the "ReturnGroup" in the mover properties

Yep, that was it! Thanks
Additionally to this I found in Mover.BeginPlay():

Code: Select all

// find movers in same group
if ( ReturnGroup == '' )
	ReturnGroup = tag;

what means that the problem can also be prevented by having ReturnGroup empty and different values for Tag.

Annotation: IMO this is a very silly default: If a mapper doesn't set a value for ReturnGroup, he doesn't want anything else to have moved with this Mover. The code overrides this assumption, and the statement

Code: Select all

if (ReturnGroup != None)

is also missing in the loop in Mover.PostBeginPlay():

Code: Select all

ForEach AllActors( class'Mover', M )
	if ( (M != self) && (M.ReturnGroup == ReturnGroup) )
	{
		M.Leader = self;
		M.Follower = Follower;
		Follower = M;
	}

But I wasn't asked by Epic unfortunately...

[Barbie]

just specify different ReturnGroups.

Would it be safe to set every Mover's ReturnGroup to an unique value (eg its name) on server side if mapper has left it empty? I cannot see any side effects by now.
<EDIT>
I've implemented that now in the BaseMutator, because sometimes I've noticed wired Mover behaviour while playing on Mars' server: I guess one Mover was blocked by a pawn or whatever, and from that on nearly all Movers didn't open anymore and were playing their AmbientMoveSound. My guess is that it has to to with that undesired set ReturnGroup.

Code: Select all

function FixMover() {
local mover M;
	foreach AllActors(class 'Mover', M)
	{
		if (M.ReturnGroup == '')
			M.ReturnGroup = M.Name;
		if(bFixCrushingMover)
			...

</EDIT>