Why not?
Not only do no input events currently exist for them, but there's a number of other problems.
The client gui assumes everything being evented is a brick.
The ServerCmdAddEvent function assumes everything receiving an event is going to be in a brickgroup (via .getGroup instead of getBrickGroupFromObject), thus, named bricks will not work for anything other than bricks.
The SimObject::processInputEvent:
Assumes that the object is inside a brickgroup, which would break named bricks for events applied to anything but a brick.
Assumes the input class is a brick for determining number of args. The reason this breaks things is...
Let's say... fxDTSBrick::onActivate has an ID of 0, with targets Self ID 0, Player ID 1, Client ID 2, Minigame ID 3.
Let's say... Player::onActivate also has an ID of 0, with targets Self(Player) ID 0, Self(Client) ID 1, ActivatingPlayer ID 2, ActivatingClient ID 3, Minigame ID 4.
This next part isn't exactly correct and is only used as an example:
And now... let's say... fxDTSBrick::setColor has an ID of 0, with only 1 arg, client appending.
And that Player::SpawnProjectile also had an ID of 0, with 3 args, client appending.
If you had an event set up like... Player: OnActivate > Self(Player) > SpawnProjectile > 20, arrowProjectile, 3 3 3
What would happen when you activated it... is that it's going to check for input targets assuming that the input class is a brick. So it's going to check fxDTSBrick::onActivate's target list instead of Player's.
So it ends up on Self, because we were using Self(Player). Self is an fxDTSBrick class for fxDTSBrick::onActivate. So it's going to check for the output event by ID now.
It checks for fxDTSBrick::setColor, which only has 1 arg, and client appending.
So now it's going to call Player::SpawnProjectile(%this,20,%client); And I'm sure you can guess, that %client is not the arrow projectile datablock it's expecting. So nothing happens.
I've fixed all of this already, I just haven't like, done anything useful with it yet.