Author Topic: onPlant event - WHAT INSANITY IS THIS  (Read 801 times)

Edit: I'm dumber than I thought, outputs need a client value to work.

I could solve this by passing a random client, or the host, or get the client from the brick's brickgroup - but then if I do it that way, onPlant events are only really called on bricks of people who are in the game when it's loaded. Hm. But that way is probably the best idea.

So, as it stands now:
Code: [Select]
package PlantEvent
{
function fxDTSBrick::onPlant(%brick)
{
Parent::onPlant(%brick);
%brick.schedule(33,"processInputEvent","onPlant",0);
}
function fxDTSBrick::processInputEvent(%brick,%event,%client)
{
if(%event $= "onPlant")
{
$inputTarget_Self = %brick;
%client = getBrickGroupFromObject(%brick).client;
}
Parent::processInputEvent(%brick,%event,%client);
}
};
ActivatePackage(PlantEvent);
registerInputEvent(fxDTSBrick,"onPlant","Self fxDTSBrick");

And while we're here, see if anyone can figure out HOW this is useful. I know how it is; can anyone else follow my somewhat deranged train of thought?

Also, in my mind:
33ms delay is to let the brick initiate it's events.
Defining $inputTarget_Self in the parented ::processInputEvent is so that it's calling the right brick.
Defining the client then is also to ensure that it's got the right values.
« Last Edit: February 16, 2009, 01:36:54 AM by M »

I'm guessing it might be useful for some "event loops" that need to start as soon as the server is loaded. In one of my unfinished Portal builds, I have to go around clicking buttons to set a portal exit in one of the rooms and anti-portal bricks in others.

So, what's the current problem with this?

I'm guessing it might be useful for some "event loops" that need to start as soon as the server is loaded. In one of my unfinished Portal builds, I have to go around clicking buttons to set a portal exit in one of the rooms and anti-portal bricks in others.

So, what's the current problem with this?
None now, I just didn't bother to take it down while I continue giggling at the thoughts of a release thread for this...

And yes, that is more or less it. If you have values on bricks that don't save, loops to start, etc., you'd use this. As far as I know, this would also run when you duplicate something too.

Hm, doesn't the onPlant method have two parameters?
(Both of them are exactly the same, but there's two.)

It's two for fxDTSBrickData::onPlant (e.g. brick8xWaterData::onPlant(%data, %brick)) which are the datablock ID, then the brick ID but I think it's just one for fxDTSBrick::onPlant.