Breaking the Mutator Chain - UT2U1 style.

[MrLoathsome]

A few people pointed out that my UT2U1 mutator breaks the regular Mutator chain.

Higor even posted a most excellent example of how that is usually done.

Going to try to explain here why UT2U1 cannot do that or it breaks. And why it doesn't seem to break anything else.

If I use the conventional method, like EVERY (other) mutator should, this would be the 2nd link in the mutator
chain after DMMutator. In which case all the checkreplacement stuff DMMutator does, would now come back and
quite possibly a number of things would start happening twice.

Since the method I used hijacks the basemutator position to begin with, making itself the first link in the chain, there
is no chain to break at that point. BUT IT MUST BE LOADED FIRST.

The UT2U1 mutator and DMMutator both extend the same class, (mutator), and UT2U1 has ALL the code in it
that DMMutator does, except the bits I wanted to take out. Anything else that was making references to BaseMutator
later on should work the same as they always did.

[Higor]

Unless super relevancy isn't used, mutator order doesn't matter at all.
I have all kinds of mutator hacks running on public servers doing all kinds of weird stuff.

One of my profilers hijacks the base mutator position, takes all calls and directs them to the remaining mutators in it's own mutator array to analyse every single step and data between mutators (done with spawn, messages, etc).

Practical uses: ZPSkip (private, unreleased, running in uK Siege)
- Autolocates itself right before ZeroPing in the mutator chain, when ModifyPlayer() is called here, it then calls NextMutator.NextMutator.ModifyPlayer(), essentially skipping the ZP's ModifyPlayer, and preventing retarded piston and chainsaw destruction and re-creation.


Mutators are simple expansion chips, treat them as such.


EDIT:
SAMPLE DEBUGGING OF MESSAGES, THIS HELPS FINDING OUT HOW A MESSAGE GETS EDITED AND HOW PURE CAN BREAK MODS:

Code: Select all

function bool MutatorBroadcastLocalizedMessage( Actor Sender, Pawn Receiver, out class<LocalMessage> Message, out optional int Switch, out optional PlayerReplicationInfo RelatedPRI_1, out optional PlayerReplicationInfo RelatedPRI_2, out optional Object OptionalObject )
{
	local int i;
	local mutator M;
	Log("=====================================================");
	Log("LOCALIZED MESSAGE FILTER FOR "$GetItemName(string(Sender))$" TO "$GetItemName(string(Receiver))$" OF CLASS "$Message );
	Log("SWITCH IS "$Switch$", PRIs ARE: "$ GetItemName(string(RelatedPRI_1))$" AND "$GetItemName(string(RelatedPRI_1))$" WITH OBJECT "$OptionalObject);
	if ( iMsg == 0 )
	{
		For ( M=NextMessageMutator ; M!=none ; M=M.NextMessageMutator )
			MessageMutators[iMsg++] = M;
	}
	For ( i=0 ; i<iMsg ; i++ )
	{
		MessageMutators[i].NextMessageMutator = none;
		if ( MessageMutators[i].MutatorBroadcastLocalizedMessage( Sender, Receiver, Message, Switch, RelatedPRI_1, RelatedPRI_2, OptionalObject) )
			Log("PASS NUMBER "$i$": "$ GetItemName(string(MessageMutators[i])) $" > ACCEPT");
		else
			Log("PASS NUMBER "$i$": "$ GetItemName(string(MessageMutators[i])) $" > REJECT");
		MessageMutators[i].NextMessageMutator = MessageMutators[i+1];
	}
	Log("LOCALIZED ENDED FOR "$GetItemName(string(Sender))$" TO "$GetItemName(string(Receiver))$" OF CLASS "$Message );
	Log("SWITCH IS "$Switch$", PRIs ARE: "$ GetItemName(string(RelatedPRI_1))$" AND "$GetItemName(string(RelatedPRI_1))$" WITH OBJECT "$OptionalObject);
	return true;
}

[MrLoathsome]

Thanks for that info. I think it just helped me realized the mutator chain processing is happening a bit
differently than I was assuming it was. But what you posted makes sense. I have always included the code to not
break the chain in all my previous stuff. (I hope...) For some reason I was thinking BaseMutator was always going to
process first.

However I am still a bit puzzled as to why my current version does not seem to be breaking other mutators.....
You should try out the current RC2 version of that with FerBotz. It would be interesting if it gave them the same
sort of boost that it seems to be having with the default bots and scriptedpawns. (And everything overall it seems to me....)

Will take another look at it closer, soon as I get this backup PC updated, and restore the missing 2 years of crap from my backups etc.
Going test out those examples you posted in the other thread, and run a number of various tests with a LOT of logging going on, just
to confirm that the change I made in checkreplacement is causing those most interesting side effects that have been reported by testers.

Was thinking about it all day at work. Then I get home, and my goddamn pc wont even power up....

This PC crash has set my schedule back a bit.

[JackGriffin]

One of my profilers hijacks the base mutator position, takes all calls and directs them to the remaining mutators in it's own mutator array to analyse every single step and data between mutators (done with spawn, messages, etc).

I've spent the day learning JGrass and this is the path PCube took. You have to register everything with your base and declare the mutators by class but it's a really secure way to craft a server. You can essentially separate server security from having to be subject to the limitations that mutators create. I probably get about 40% of it so far but I understand the overall concept. It's a lot of work to get right but when you do it's the way to run a server.