Rope problem in CS:S

[Unfocused]

I know that it's possible to make in Source two boxes - one still and the other moving, attached to it with a rope . I did that in HL2M. One box was about 7 meters above the floor and the other was attached to it on a 2 meter rope, swinging in the air.

However when I played the map in CS:S (of course after changing some textures and player spawn names) the box that was supposed to be swinging on a rope was not there and the rope was noclipping through the floor, as if it was too long and let the attached box noclip with it.

What's wrong? Is the rope "unsupported" in CS:S?

 

[Raeven0]

Welcome to Introduction to Inconsistencies in CS:S. I'll be your lecturer today. I'll also be a guest lecturer should you ever take Introduction to CS:S's Magic Bullets That Curve Around Walls.

Several CS:S entities aren't reset upon newround. Most, however, are. Resetting an entity involves the game completely deleting and remaking it.

When an entity, such as a rope, that isn't reset upon newround is parented to an entity, such as a box, that is reset, the former entity will be deleted whenever the first round starts because the latter has already been deleted (thus removing all of its children) and remade.

Solution: use a logic_measure_movement entity whenever you want entities that are and aren't reset to be in the same movement hierarchy. It's okay to use parenting among groups of entities that are all or aren't all reset.

In this FGD I've made a note in the documentations of entities that aren't reset upon newround (since there are only about 20 of them). A list of those entities is available here.

 

[Unfocused]

Thanks for the info, however I'm a newbie to mapping in Source and I don't fully understand some fuctions I have used (I didn't get the idea myself how to set this up, but saw a tutorial; one of those in the sticky topics), therefore I don't know how to use the logic_measure_movement you told me about (should I measure the movement of the rope or the box? and not only I want to measure it but also make those boxes act as if one was hanging on a rope attached to the other).

 

[Limpet]

I'll also be a guest lecturer should you ever take Introduction to CS:S's Magic Bullets That Curve Around Walls

Hahaha

Raeven0 is awesome.
Isn't that because of the lagged hitboxes?

 

[Unfocused]

Okay I think I get it now a bit more. So I've got two entities I want to have synchronized - one end of the rope (keyframe_rope "RopeEnd") and the box (func_physbox "Box"). What values should I use for "Entity to Measure", "Measure Reference, "Entity to Move" and "Move Reference"?

 

[Pesmerga]

Hahaha

Raeven0 is awesome.
Isn't that because of the lagged hitboxes?

Yes, because the client's view of the hitboxes are the correct ones, and the hitboxes are slow to catch up with the hitboxes owner.

That's why, technically, when you pop your head up out of a crate, you have a split second advantage to shoot first against the enemy because he doesn't see you until the hitboxes are there, so people don't complain about hitting air.

 

[Limpet]

Ah, so thats why people think its hacking when you get lucky on your prefire.

Sorry, about using this thread to ask my own questions

 

[Raeven0]

And if you ever ask any Valve fanboy, he'll quickly cry out "ITS LAG COMPENSATION U NOOB ITS THERE FOR A REASON." It's important, though, to remember that no matter what name you give it, and no matter what purpose it serves, the bullets still curve around corners.

Stinger, if you look at the descriptions of each property in the lower-right corner of the entity properties dialogue box, you should get it. You have an entity E1 whose movement will be measured relative to entity R1. This movement will be scaled by a certain inverse factor and applied to another entity E2, relative to a fourth entity R2. So, you want E1 and E2 to be your box and your rope. R1 and R2 should be any other entity in the map, but they must be the same entity. The scale should be 1.

 

[Unfocused]

Somethings still wrong. I've made everything as if I was making this construction for HL2DM, except that I made this logic_measure_movement entity, so as not to make a parent relation.

So I have a move_rope and keyframe_rope (both ends of the rope; former in the brush, latter in the physbox), a length_constraint (both ends placed near the ends of the rope, so the rope "knows" how long it has to be), a func_physbox (the moving, hanging box) with a brush to which it's attached and a logic_measure_movement entity that makes keyframe_rope and func_physbox move together (at least it should). That's what I get:

EDIT: BTW, as you can see I've got some strong shadows on the map, how can I make them softer?

 

[Raeven0]

Check the settings on your phys_lengthconstraint and logic_measure_movement.

For the lights, ensure that you're running VIS, and check the angle on your light_environment.

 

[Unfocused]

Check the settings on your phys_lengthconstraint and logic_measure_movement.

For the lights, ensure that you're running VIS, and check the angle on your light_environment.

well in the phys_lengthconstraint I set the moving box as entity1, I placed it inside the moving box and dragged the ball to the box that it's hanging from. logic-measure_movement is set as you have told me.

 

[Raeven0]

Phys_lengthconstraint requires two entities. Its purpose is to keep them a constant distance from each other, either by drawing an imaginary rod or an imaginary rope between them.

 

[Unfocused]

Phys_lengthconstraint requires two entities. Its purpose is to keep them a constant distance from each other, either by drawing an imaginary rod or an imaginary rope between them.

Well in the rope video tutorial, the guy defined only one entity and when I tested it in HL2DM it worked.

 

[Raeven0]

He doesn't understand the purpose of phys_lengthconstraint, then, and it working is a horrible bug/hack. Now, phys_ballsocket works fine with one entity, but lengthconstraint should always have two.