force-dropping a cube
Hey, simple question: how do I make the player drop the cube they are carrying?
Also, I had this in an other thread, but it kind of got overlooked:
"The white parts of some overlays become black if I put them on a darker surface. (For example the bullseye, or the "test subject waiting area" text) Is this fixable?"
If you know they're carrying it, send the cube the Use input. You can check using a filter_player_held.
Felix, man, did you study all entities? 
Lol, I'm learning a lot just by reading your suggestions! Thanks mate! 
So, on the topic, your suggestion would be to surround the cube with a parented trigger brush filtered by that (awesome, btw)filter and to fire the output TestActivator whenever we need the player to drop the cube plus using "OnPass" into the cube's outputs and.......... what then? what output should we fire to the cube? I mean, this far, all we can do is detecting if we player holds the cube or not, but how to make him drop it? If we fire USE output it might do nothing...
Could a basic script do this though? I mean: we can detect the cube coordinates, also the player's coordinates and set the cube's coordinates a bit further from the player's coordinates, right? how about this suggestion?
useful tools and stuff here on TWP 
[spoiler]
[/spoiler]Thanks! When the Authoring Tools first came out I read everything I could from the VDC's List of Portal 2 Entities.
The easiest way (with a simple script) might be something like this: when the cube needs to be dropped, have the script iterate through all prop_weighted_cubes (not hard) and, for each one, send a TestActivator input to the filter with that cube as the activator (also not hard). Give the filter one output: OnPass !activator Use.
Then when the loop finds that, in fact, the player is holding one of the cubes, the filter will pass and send the Use input to that cube. Since we know that cube is held, Use will drop it.
(If this is for single-player we can also terminate the loop when that happens, although the delay required in the script might cancel out the efficiency gain.)
Use doesn't really seem to work for me. Unless I wanted the cube to do some beatboxing, in which case it works just fine 
http://www.youtube.com/watch?v=aahkJhZZ9GQ
In this video I had a simple trigger with the "cubename Use" output, without any filters and with 0 reset time.
But even when I was careful not to get spam-attacked by the trigger (ie. increased the reset time), the cube didn't do anything. It made a sound, but it remained in my hand. Shouldn't use drop it? Or did I misunderstand something? *headscratching*
In this video I had a simple trigger with the "cubename Use" output, without any filters and with 0 reset time.
But even when I was careful not to get spam-attacked by the trigger (ie. increased the reset time), the cube didn't do anything. It made a sound, but it remained in my hand. Shouldn't use drop it? Or did I misunderstand something? *headscratching*
HAHAHAHAHAHAHAHA... 
useful tools and stuff here on TWP [spoiler]
[/spoiler]That does work, thanks. But I can't wrap my head around how filter_player_held actually works. I mean I thought using filters was pretty straight forward, but this doesn't have any properties..
EDIT: Okay, I realized this thread has a 2nd and 3rd post; I may be starting to piece it together 
EDIT: Okay, never mind, I still don't get it
You can use TestActivator to find out if a certain entity is held or not. That might be the simplest usage. Or make a trigger where you want the box to be dropped, with that filter. OnTrigger there's a held box in that area.
Ok, I made a quick test with this filter upon all information gathered here. It's a very basic test to drop the cube down when the player crosses a line.
Note that if you fire the console command +Use, the player will no longer be able to use the USE button again, unless you fire -Use...
useful tools and stuff here on TWP [spoiler]
[/spoiler]