Author Topic: Unable to find players when killing a brick (Read 1347 times)

Mr. Wallet · June 03, 2008, 04:07:30 PM

package MyPackage {
	function fxDTSBrick::OnDeath(%this)
	{
		echo("RUN");
		initContainerBoxSearch(%this.getposition(), "100 100 100", $TypeMasks::PlayerObjectType);
		while(%x = containerSearchNext()) {
			echo("FOUND: " @ %x);
		}
		Parent::OnDeath(%this);
	}
};
activatePackage(MyPackage);

This echoes RUN but not FOUND. I've also tried the containerFindFirst method with no luck. What's even more aggravating is that echoing %this spits out the brick's handle correctly, and copy/pasting the search into the console, replacing %this with the brick's handle, works perfectly. But when it comes time to perform it inside this function, no luck. I've even tried defining a separate function for the search and calling that from here, but no dice.

Anyone know what the problem is, and/or a workaround?

Ad Bot · Advertisement

Ephialtes · June 03, 2008, 04:13:17 PM

Create a new function that does a box search for players and takes a position as a parameter, then call that in the onDeath. That way you know if its your containerBoxSearch messing up, or the onDeath callback messing up.

Trader · June 03, 2008, 04:55:43 PM

Are you sure that it's not FxDTSBrick::onDeath(%this,%obj), where %this is the datablock and %obj is the actual object instance?

Ephialtes · June 03, 2008, 04:58:37 PM

That'd only be if you were doing fxDTSBrickData::onDeath, this is an object callback.

Trader · June 03, 2008, 05:02:15 PM

OK, try %this.position instead of %this.getPosition().� Put this in just before your RUN echo:

Code: [Select]

echo(%this.getPosition() @ " | " @ %this.position);
See if it's returning a valid position.

You forgot the bolding, bitch.

rkynick · June 03, 2008, 05:10:11 PM

Quote from: Trader on June 03, 2008, 05:02:15 PM

OK, try %this.position instead of %this.getPosition(). Put this in just before your RUN echo:

Code: [Select]
echo(%this.getPosition() @ " | " @ %this.position);
See if it's returning a valid position.

Mr. Wallet · June 03, 2008, 11:52:36 PM

Yes, yes, it's all valid; the call, the object, the position, everything. I've turned it into swiss cheese with echoes and everything runs fine except containerSearchNext immediately returns 0.

Again, if I just replace %this with the object handle and put the code in the console, it returns my player object, but if I do the exact same thing while the brick is dying... containerSearchNext returns 0.

My next idea is a 10ms schedule for the search, since it's only broken during the brick's death.

laremere · June 05, 2008, 12:43:21 AM

I think you might need to use a schedule, I remember hearing something about how some things don't quite work right inside a package or something.

Also try doing the search with a vehicle or something, and see if it the player that is the problem.

!!hammerdwarf!! · June 08, 2008, 04:54:57 PM

I got it to work with while(isobject(%x = containerSearchNext()))
Anywhere in RTB uses while((%x = containerSearchNext()))

Try one of those.

Zor · June 08, 2008, 06:04:18 PM

I noticed a few curious things while playing around with this:

When you hammer or wand a brick, it doesn't find your player, but if you undo the brick, it works properly.
When you hammer or wand a brick, it returns other player objects in the box, just not yours.

laremere · June 08, 2008, 07:41:58 PM

Must be because of the fact that those require chain reactions to destroy bricks they destroy, therefor using a slightly different way of killing bricks.

rkynick · June 08, 2008, 11:59:54 PM

Quote from: Trader on June 03, 2008, 05:02:15 PM

OK, try %this.position instead of %this.getPosition().� Put this in just before your RUN echo:

Code: [Select]
echo(%this.getPosition() @ " | " @ %this.position);
See if it's returning a valid position.

You forgot the bolding, bitch.

You can't bold in [ code ], trader...

Code: [Select]

[b]this isnt bold[/b]

Zor · June 09, 2008, 01:32:25 AM

Quote from: laremere on June 08, 2008, 07:41:58 PM

Must be because of the fact that those require chain reactions to destroy bricks they destroy, therefor using a slightly different way of killing bricks.

But it IS possible for a chain reaction to occur when undoing bricks.

laremere · June 09, 2008, 02:29:55 AM

Hmmmm.� Didn't think about that, but I just realized something, the meathods that don't work are caused by item.� Try making a train reaction with a wand hitting one brick, and see if a brick it supports will cause an echo.

Mr. Wallet · June 17, 2008, 03:38:34 AM

Oh yeah I forgot to mention, a schedule of 10ms worked fine. Good enough for my purposes (or someone else's, technically).