How can I lock objects together to be one object?

[MisterGravity]

So let's say I've made a primitive elevator that has 3 walls and a floor. That's 4 pieces. I can of course use my trigger to move all four pieces at once, but how can I lock all 4 peices together to be forever one piece?

 

I wouldn't bother asking this, but it seems that sometimes the pieces get out of sync when being used in it's "sliding door" movement. A wall will get stuck there on the way down, a floor will stop halfway, it's beyond comprehension. Seems it'd be easier if it were one piece.

 

 

Feel free to continue reading this forum thread, it will teach you how to make an elevator with several pieces work perfectly. Here is a video of the elevator in action:

 

[DudeAwesome]

you can drag and drop your boxes into the mainbox in the scene tab. If an object have more parts you see a tree structure

[MisterGravity]

you can drag and drop your boxes into the mainbox in the scene tab. If an object have more parts you see a tree structure

 

I did that, but now I can't see the 3 pieces I made subitems of the other piece when I run the map. So let's say I have:

 

leverControlledBox1, and also 2, 3, and 4.

When I drag 2, 3 and 4 under leverControlledBox1, I do in fact get the 3 subitems.

And when I click any part of it in the Perspective frame, I see it is now 1 item as I hoped for.

Unfortunately, when you run the program, only leverControlledBox1 is visible.

 

What did I do?

 

 

 

 

EDIT:

 

So I figured out that only the main item in the list can have mass. Once I made the mass of all subitems = 0, then the items once again appeared in the game when I tested it.

 

However, only the main item reacts to the SlidingDoor.lua. So I've run into a contradiction:

 

If I can't make the elevator move by moving just the main item, which should theoretically move all the subitems, then I'm forced to add the SlidingDoor.lua to each subitem as well, but that script requires mass, which makes the subitems invisible.

 

This seems to be a contradiction. What is the solution?

[Admin]

I suggest posting your map so other people can try it. The AI and Events map shows an elevator with several pieces parented to it, and it works as expected.

[MisterGravity]

I suggest posting your map so other people can try it. The AI and Events map shows an elevator with several pieces parented to it, and it works as expected.

 

Indeed. I will start doing this from now on.

 

Edit: This area contained my map file to be downloaded, but it has been fixed now so I've removed it.

[Josh]

First off, your map is really cool. I'm really super happy to see this level of interactivity so early, it's really encouraging.

 

When bushes are loaded in a map, the engine collapses them down into merged static geometry, if certain conditions are met. If the brush has 0 mass, no script attached, and some other things, it is assumed the user wants it collapsed. In your case, of course, this was wrong.

 

Rather than keep guessing, and having to add more and more conditions in the future, I should probably add a checkbox in the editor so the user can control whether it gets merged or not. I'm sorry this slowed you down. Your map is pretty interesting to explore already.

 

One thing you could do immediately is add an empty script to each child brush. This will prevent the brushes from being merged, but won't add any behavior to them.

[MisterGravity]

First off, your map is really cool. I'm really super happy to see this level of interactivity so early, it's really encouraging.

 

When bushes are loaded in a map, the engine collapses them down into merged static geometry, if certain conditions are met. If the brush has 0 mass, no script attached, and some other things, it is assumed the user wants it collapsed. In your case, of course, this was wrong.

 

Rather than keep guessing, and having to add more and more conditions in the future, I should probably add a checkbox in the editor so the user can control whether it gets merged or not. I'm sorry this slowed you down. Your map is pretty interesting to explore already.

 

One thing you could do immediately is add an empty script to each child brush. This will prevent the brushes from being merged, but won't add any behavior to them.

 

First, thanks for responding Josh.

 

But, that was kind of clear as mud. Let me see if I even have a vague idea of what you mean. What I did was, under Assets, Scripts, I created a new script called "Nothingness", and deleted all the base code out of it. Then, I attached Nothingness.lua to each of the pieces of the elevator, and gave them mass. Of course since they are still child objects of the original object, they're script isn't "sliding door" so they should just slide WITH the parent object. But, they don't. In fact when I run the map, they vanish off the screen. They're there for a split second, but they then vanish.

 

One thing I really loved about Hammer was it's "Group" function. Grab any number of objects in a scene, hit Group, and BAM, done. They're all one item now. I have been fighting for HOURS to simulate that in Leadwerks, and even after your response, I don't know how to fix it.

 

Bottom line, how do you get multiple objects to move at the same time? I see it happening one of three ways.

1. You draw several objects, and your trigger activates ALL those objects separately, but at the same time. This is what I was doing before I had this problem, but as indicated above, they get out of sync. Literally, they move at the same speed and do the same things, but if you watch them, this wall is faster than that wall. It defies comprehension.
    
   
2. You draw one object, like the floor of your elevator, then you add 3 walls as children to the parent (floor). The children have no mass, they have no script, and behave just like the parent because they're attached. This seems simple to me, and yet this is the idea I've fought with all day.
    
   
3. You grab several objects and click "Group", (just like Hammer), and then that single glued-together item has a script attached to it. Unfortunately, this does not seem to be possible.
   

Maybe I'm making it harder than it really is?

 

Maybe I'm oversimplifying it so much it's not clicking. I just... don't... get it.

 

By the way... thanks for complimenting the map. While I was waiting on a response to the elevator issue, I added something completely useless to the map. Without further adieu...

 

[flachdrache]

Traditionally this is done by just moving one, non collider, brush along an origin - the lift etc. is then added as a sub model e.g. the model itself which does contain collision's.

[flachdrache]

PS: keep going - you just missing the background course your younger .. I pretty much rebuild all this basic functionality based on what I learned from quake2 ... and hammer is based on quake functionality AFAIK.

[MisterGravity]

Traditionally this is done by just moving one, non collider, brush along an origin - the lift etc. is then added as a sub model e.g. the model itself which does contain collision's.

 

Sorry, let me see if I can break that sentence down for someone who's only had Leadwerks for 3 days...

 

Traditionally, this is done by just moving one "non collider", (as in the floor of the elevator which has no collision? [even though it needs collision?]), brush along an origin (what is an origin?), the lift etc. is then added as a sub model (parent/children in the Scene layout,), e.g. the model itself which does contain collisions (the parts of the elevator.)

 

So what I'm hearing is that aside from the 4 pieces of the elevator, (the floor, the 3 walls,), I need a fourth piece that has the collision of NONE, and each of the pieces of the elevator are children of that? And that fourth piece with colllision of NONE is the one with SlidingDoor.lua script attached to it, but nothing else is?

 

If that is true, does the no collision piece wrap around the other four pieces like a box, or can it be just a little 1x1 block doing the "parenting"?

[Josh]

Your brushes don't move because they are being merged into the static scene and deleted. I need to add a checkbox to let you prevent this from happening.

 

I worked around this by adding the noise script to each brush so the brushes don't get collapsed. No sound file is specified so it won't have any other effect.

01_testing-2.rar

[MisterGravity]

Your brushes don't move because they are being merged into the static scene and deleted. I need to add a checkbox to let you prevent this from happening.

 

That sounds brilliant to solve this issue. In the end though, should I be building elevators like Moving Platforms with waypoints, or like SlidingDoors.lua with a distance to travel?

[Josh]

I think the door script is more convenient, if they are just going between two points.

[flachdrache]

That's correct - its just about interaction and defining rules. The mover just follows a path along an origin = the axis center point. The mover does not need collisions because the lift comes in as complete, extern, model with parent child relation.

 

However - You ask for and josh suggests so called "brush models" ... which is valid too.

 

PS: such mover is just a point in space like 1x1 or how small you can go ... but in such case the extern model needs to be positioned to such point correctly and might have an offset.

[Kavex]

I love your little elevator switch. I don't know what the second one did,

 

So I took the elevator to the outer part of the map and jumped off the map (more like flew off) when jumping to the other room. I looked at your jump force and it was at 28. It made me giggle.

 

I wasn't expecting that

[MisterGravity]

I think the door script is more convenient, if they are just going between two points.

 

That's what I was thinking too, I just wondered what most people did. Thanks for the clarification.

 

 

I love your little elevator switch. I don't know what the second one did,

 

So I took the elevator to the outer part of the map and jumped off the map (more like flew off) when jumping to the other room. I looked at your jump force and it was at 28. It made me giggle.

 

I wasn't expecting that

 

Lol, glad you had fun. Actually, the high jump rate and "take no damage from fall" was so I could quickly jump around and look at things. The second switch pushes the barrel out of the way of the elevator to get rid of the "trash" entirely. I added a lot more to that switch, and through a series of "pushes", well... you can see what happens.

 

[MisterGravity]

In case anyone was wondering how it was finally accomplished, here it is for future reference:

• You can use the elevator floor itself as the "parent" object in the Scene tab, so choose these options once you've drawn the elevator floor.
  
  • Physics Tab:
    
    • Physics Mode: Rigid Body
      
    • Shape: Box
      
    • Mass: 10.0 (or greater than 0)
      
    • Collision type: Scene
      
    • Swept collision: False
      
    • Nav obstacle: True
      

    [*]Script Tab:

    • File: SlidingDoor.lua
      
    • Enabled: True
      
    • Move speed: 2.0 (or greater than 0)
      
    • Manual activate: False
      

  [*]For the walls of the elevator, (or anything else attached to it,) the trick is to give it a script, even an unimportant one, so it does not become "part of the scene" when the game is run, therefore causing it to become invisible.

  • Physics Tab:
    
    • Physics Mode: Rigid Body
      
    • Shape: None
      
    • Mass: 0.0
      
    • Collision type: Scene
      
    • Swept collision: False
      
    • Nav obstacle: False
      

    [*]Script Tab:

    • File: Noise.lua <-- This is giving it any script at all to work properly