Anyone know how to make a proper conveyor belt?

I’m working on a factory map, and I’d like to figure out how to create proper conveyor belts. From what I can tell, the func_conveyor entity only moves players and not physics objects. Using a trigger_push isn’t ideal because physics props of different weights move at different rates of speed.

I do know how to make a fully functional conveyor belt via spawning func_tracktrain entities paired with a point_template and a timer, but it is highly expensive to spawn hundreds of func_tracktrain entities, and I don’t think it would handle well in multiplayer. I really don’t want to go that route if I can help it. Also for some reason when the flashlight shines on the belt, it causes a severe FPS drop.

Does anyone know how to properly create a conveyor belt in Hammer?

You could have a model that has a moving animation or you could have a scrolling texture , you would then put a trigger_push over it with your settings.

Using a trigger_push isn’t ideal because physics props of different weights move at different rates of speed.

use both. just have the trigger_push only affect “Clients” in the entity flags, and the func_conveyor only affect props

furthermore, are you 100% sure that func_conveyor doesn’t work on players? I could have sworn the last time I used it, that it made me slide along the ground when i walked on it

Maybe you have the two switched around… Func_conveyor doesn’t affect props, it only moves players. Trigger_push can’t necessarily be used because it moves objects of different weights at different speeds. It isn’t constant.

oh sorry i’m retarded

I’d imagine you could do it by having the prop parented to an invisible func_tracktrain on a predefined path_track path placed on the conveyor, you’d just have to change the speed of the tracktrain to make sure the props move at the same rate as the conveyor. However, the props wouldnt really be able to be taken off (cause they’d keep moving) and so it wouldn’t really be ‘interactive’

Yeah, see I’ve thought of that and it could work that way, but like you said, it wouldn’t be interactive… And any props placed on the conveyor belt wouldn’t move either. Gah if only Valve properly created the func_conveyor entity in the first place, this would be so much easier. I’m still stuck on this…

This may be a bit crazy, but how about a trigger_gravity that only affects props? And to revert props to default gravity, make another box outside the conveyor belt.
It would be angled towards the direction of the belt, and there wouldn’t be friction problems.

That’s honestly a cool idea, but unfortunately trigger_gravity is a scalar from 0 to 1 in the vertical direction only. :confused:

Oh yes. :confused:

I probably mistook that for, try it out.

func_tracktrain seems to be the best solution.

But don’t use a logic_timer to spawn each entity. What I did was, I set up the second path track to tell the point_template to spawn the belt. I placed the first path_track right on the initial belt’s origin and gave it an output of OnPass > !activator > StartForward. This ensures that the belt will move forward when it spawns. And then for the final path track I just told it to OnPass > !activator > Kill

I gave this a shot, and while it does work to push objects of different weight at the same rate of speed, the objects wobble from side to side on the conveyor and fall off, because they are technically ‘skidding’ across the surface of the belt.

While I know this method would work, do you think servers could handle hundreds of func_tracktrain entities in multiplayer? It’s very resource expensive I would think?

I’ve actually had limited success with a new method I devised. I have a single (and invisible) func_tracktrain moving parallel to the conveyor belt, and a trigger_multiple covering the surface of the belt. When props are placed on the belt, they are parented to the func_tracktrain and move along the conveyor just fine.

I am having some issues with this though. The props can’t be taken off the belt after they are set down since they are parented to the tracktrain, and I’m not quite sure how to fix this. Also when I have a trigger at the end of the conveyor belt set to clear the parent of the props on the belt, the props literally teleport back to the position that they were first set down on the belt… I don’t understand why this is happening. If a parent is cleared, the prop should just be able to freely move again, not teleport…

The trigger_push moves different props at different speeds due to their weight, you say? Well, have you tried settings the props’ weights (masses actually) to the same value?
Add a trigger_multiple over the trigger_push, set its flags to only allow props, and then add the following output:

OnStartTouch → !activator → AddOutput → massScale n

For n, either put a really small number (e.g. 0.001) or a negative number. Originally I wanted to suggest 0, but that obviously won’t work as the default value is 0 (I assume it checks for that and doesn’t perform any scaling if the value is 0). To restore the prop’s mass when it exits the trigger volume, add the following:

OnEndTouch → !activator → AddOutput → massScale 0

You can also make it as lots of func_rotatings.

Since this scales the mass and doesn’t set it to an exact value, if the mass is scaled to 0.001 a trigger_push with a very small force value even makes the gun props fly down the conveyor belt. Basically in the end, it still runs into the same problem as a regular trigger_push. If the push is set to the correct value for guns, larger props don’t move on the conveyor.

Hmm this method does work. I’m assuming you’re referring to these kind of conveyors:

Although the catch to using this method is that the guns would have to be placed on a palette since the guns are too small and would fall between the rollers.

Are you making a GMod-specific map? Because Lua.

It’s a TTT map for Gmod so the lua_run entity could be used. How exactly could this be done using Lua?

[editline]23rd February 2014[/editline]

Add a trigger_multiple over the trigger_push as discussed before, and give it the following outputs:

OnStartTouch → !activator → AddOutput → targetname conveyor_prop_in
OnStartTouch → conveyor_run_in → RunCode (0.01 delay)
OnEndTouch → !activator → AddOutput → targetname conveyor_prop_out
OnEndTouch → conveyor_run_out → RunCode (0.01 delay)

conveyor_run_in and conveyor_run_out are lua_run entities with their code keyvalues set to the following:
[lua]for k,v in pairs(ents.FindByName(‘conveyor_prop_in’)) do local phys = v:GetPhysicsObject() v:SetVar(‘oldMass’, phys:GetMass()) phys:SetMass(<something>) end[/lua]
[lua]for k,v in pairs(ents.FindByName(‘conveyor_prop_out’)) do local old = v:GetVar(‘oldMass’, nil) if old then v:GetPhysicsObject():SetMass(old) end end[/lua]

[editline]23rd February 2014[/editline]

Screw that second approach. Also, make sure you don’t put quotation marks around the string, you’ll break your VMF. Use apostrophes instead, like I did in the edited post above.

[editline]23rd February 2014[/editline]

The more I think about this the more caveats I find, lol. There’s probably a much easier approach, but you’d have to ask someone who’s done any Lua in the past year.

Hmm I gave it a shot, but for some reason objects of different mass still move at different speeds, even with everything set up as you described. For the code I used:

[lua]for k,v in pairs(ents.FindByName(‘conveyor_prop’)) do v:GetPhysicsObject():SetMass(1) end[/lua]

But even so, I’m not certain a trigger_push of any kind is suitable since the props do veer off side to side on the belt since they are actually skidding across it. I appreciate your help, nonetheless. It’s an interesting method.

In all reality, does anyone know what the load on a multiplayer server would be with hundreds of func_tracktrain entities? Or hundreds of func_rotating entities? From a technical standpoint, would that actually cause lag or screw things up? I guess I’ve just assumed it would, but I don’t know for sure.

[editline]23rd February 2014[/editline]

Just saw you edited your original post lol.