Quote from HalfPortalLife3 on October 6, 2012, 3:45 pm

You could use some func_brushes textured with the invisible texture, check physics objects in the flags, then put the walls right near where the cube will sit. Then, have the brushes start disabled, and put a trigger_mutliple in between those walls where the cube will sit, check physics objects, then add the outputs

onstarttouch
<name of brushes>
enable

and

onstoptouch (I think thats what it is, but I rarely use trigger_multiples)
<name of brushes>
disable

Just have the brushes tight against the trigger, and have the trigger be cube sized.

edit: Oh, and you might want to check NPCs too, in case someone puts a turret in there (assuming there is a turret in the level)

Quote from josepezdj on October 6, 2012, 5:41 pm

HalfPortalLife3 wrote:

.........................

WTF????

@Xtreger: you're completely right. I remember that cube stop at the funnel intersection in maaaany maps (I think "Levitation" by Idolon was based in that mechanic indeed)... And I discovered recently (in Chander's Test 13) that this is no longer as before...

You can do many things here depending on the setup or layout of your map:

1. You can force the cube to join a tracktrain as long as it reaches a certain point and then lead it to your desired destination.

2. You can use soft trigger_pushes to help it get rid of the intersection towards your desired direction.

I'll tell you more options as they come to my mind...

Quote from Xtreger on October 6, 2012, 6:55 pm

Thanks for the replies

Actually the cube is not supposed to have any fixed position.

For better context see only the part 3:44 - 3:52 of this video:

http://www.youtube.com/watch?v=jxWDIYD8PzM

Adjusting the floor portal slighty will also move the cube above its new position, but the cube will again become still in the intersection. It can have different locations (where it remains fixed) depending on the floor portal.
Anything that I can do to again make the mechanism (shown in the above video from 3:44 - 3:52) work again?

Quote from josepezdj on October 7, 2012, 4:58 am

Hi Xtreger. OK, I understand it (I forgot your map Dispersed was based in cube stopping). Due to the complexity of your map's solution, this is going to be kind of difficult. All I can think of is this:

1. First of all you'll need func_portal_detectors: make as many as you need along each white (portalable) floor and walls in order to setup several cube positions... To make the detectors: make a brush with the trigger or invisible texture at least 2 units above and 2 units under the white area you want it to detect the portals and tie it to a func_portal_detector. Name them.

2. Now the goal is to stop the cube, that's to say to counteract the funnel's strength, right in the intersection. You could make a couple trigger_push volumes with its force set to any negative number (both the same values) to pull the cube to the opposite direction of each funnel, towards the portals. These 2 volumes should be named and set to start disabled. And do not forget to check the flag "Physics Objects" (maybe you can also filter them)

3. What you do next is to enable the trigger_pushes when:
- both portal_detectors are detecting that the portals are open
- the tractor_beam is active

Do this by logic_branches, 3 of them, and a logic_branch_listener

Every portal_detector will send to a logic_branch outputs like so:

(portal_detector1)
OnStartTouchPortal > logic_branch1 > setValue > 1
OnEndTouchPortal > logic_branch1 > setValue > 0

(portal_detector2)
OnStartTouchPortal > logic_branch2 > setValue > 1
OnEndTouchPortal > logic_branch2 > setValue > 0

Now for the floor_button or maybe the logic_relay that activates the funnel do the same:

(if it's a button)
OnPressed > logic_branch3 > setValue > 1
OnUnPressed > logic_branch1 > setValue > 0

(if it's a couple of logic_relays, one "rl_on" and "rl_off" for example)
Ontrigger ("rl_on") > logic_branch3 > setValue > 1
OnTrigger ("rl_off") > logic_branch1 > setValue > 0

Then the logic_listener will activate the trigger_pushes:

OnAllTrue > trigger_push1 > Enable
OnAllTrue > trigger_push2 > Enable
OnAllFalse > trigger_push1 > Disable
OnAllFalse > trigger_push2 > Disable
OnMixed > trigger_push1 > Disable
OnMixed > trigger_push2 > Disable

Anyway, you will have to try it... maybe it's buggy...

Good luck

Quote from greykarel on October 7, 2012, 3:16 pm

josepezdj wrote:

2. Now the goal is to stop the cube, that's to say to counteract the funnel's strength, right in the intersection. You could make a couple trigger_push volumes with its force set to any negative number (both the same values) to pull the cube to the opposite direction of each funnel, towards the portals. These 2 volumes should be named and set to start disabled. And do not forget to check the flag "Physics Objects" (maybe you can also filter them)

Well, there's an easier way to stop cube in funnel. Just give your cube a name and when you detect it is in funnel intersection send an input DisableMotion to it. Hammer showes it in red, that's nothing. And EnableMotion when the funnel intersection gets off or on player pick up the cube.

Quote from Idolon on October 7, 2012, 6:33 pm

Xtreger wrote:

If a funnel were redirected perpendicular to itself (through portals) or if two same-state (both blue or both orange) funnels intersected, and if a cube were kept in the funnel intersection, it would remain fixed there.

But now this mechanic has probably been broken by an update

;_;

brb /wrists

Quote from FelixGriffin on October 8, 2012, 8:35 pm

You can parent to portals, you know.

So you'd only need one detector per wall, not a bunch of them.