Author Topic: Nessisary events!  (Read 1119 times)

---INPUT---
onvehicaltouch (when any vehical touchs that brick)
onvehicaluse (when someoen is useing the vehical)
onpassengercount>1 (when you have passengers in the vehical this happens)

---OUTPUT---
vehicals can do anything a player (and just about everything) a brick can do

could someone make this?


I'm pretty sure a vehicle touch event would be possible with a trigger placed around the brick. MrPickles' "Cube Triggers" worked like that. If it was only placed on bricks with the event (check servercmdAddEvent), it wouldn't be very laggy - only as much as placing a physicalzone like the water bricks.

I'm pretty sure a vehicle touch event would be possible with a trigger placed around the brick. MrPickles' "Cube Triggers" worked like that. If it was only placed on bricks with the event (check servercmdAddEvent), it wouldn't be very laggy - only as much as placing a physicalzone like the water bricks.

Please don't do it this way.

What, just give up because a perfect method isn't immediately obvious?

Apparently Badspot/Ephialtes find this method efficient... Similar code is in the Tutorial.

This seems to do checks every 50ms while something is inside the trigger to see if it's the object you want. Obviously this could be increased (playerTouch is about only every 200ms) and edited to check for vehicles only and it wouldn't need all the checks for the tutorial bricks.
« Last Edit: August 26, 2008, 02:13:26 PM by Space Guy »

Having a few semi-hackish checks to make certain parts of a single-player tutorial work is not even close to allowing those sort of checks for any brick in a server.  People need to get out of the habit of making hackish things when the real solution doesn't exist or is too hard to achieve.  Also, get rid of the code block because it breaks the page.

A trigger is very efficient and based almost entirely through the engine. Water bricks are almost identical (in the engine code, "an defined area with a game-created object that checks for objects inside it and does things with them") and they work fine - do you count those as 'hackish'?

A trigger is very efficient and based almost entirely through the engine. Water bricks are almost identical (in the engine code, "an defined area with a game-created object that checks for objects inside it and does things with them") and they work fine - do you count those as 'hackish'?

Water bricks add physical zones to a very specific set of brick types.  Adding a trigger to every brick instance when you want it to check for touching vehicles is not the same thing as adding a physical zone to simulate water.  I'm sure it's possible for the engine collision detection to trigger an onVehicleTouch event.  Give Badspot some time and I'm sure he can add this the appropriate way in a later version.

It would be more possible to crash, lag or spam a server with water bricks - you can place them quicker - than bricks that detect vehicle collisions, or through mass amounts of any other kind of brick, emitter or event.

I made a simple system a while ago where it only creates the trigger (singular) when the brick has the specific event set.

It would be more possible to crash, lag or spam a server with water bricks - you can place them quicker - than bricks that detect vehicle collisions, or through mass amounts of any other kind of brick, emitter or event.

I made a simple system a while ago where it only creates the trigger (singular) when the brick has the specific event set.

I understand what you're suggesting and how it works.  I'm just saying that going about detecting vehicle->brick collisions when bricks don't currently trigger a collision method for vehicles seems like a fool's errand.

It's being suggested by a lot of people so I'd guess it's a wanted feature.

But I think its something that should be added in the engine and should be in the official Blockland releases. This sort of thing needs to be tightly integrated into the events system and the only way to do that is by getting Badspot to do it. Triggers just aren't a robust way of accomplishing a task of this magnitude, especially when its likely to be a regularly used thing.
« Last Edit: August 26, 2008, 02:49:14 PM by Ephialtes »

Still, why do the water bricks work in the way they do? Shouldn't an "is water" option be integrated into the engine with that logic instead of using physical zones?

Physical zones already have all the detection required to make fake water blocks so its a logical decision. There's a toggle in the physical zone to disable/enable the water effect though.

It's still using a created object and scripts to work when it could potentially be counted as a feature that needs to go with the engine and events system - an entirely new event had to be created specifically to make detecting players in water work, for instance, when it should probably be put with onPlayerTouch.