How do doors and lifts work?
Thanks for all of the help! Also, I've got a few general questions about the engine and how some of the pieces go together but I'm not sure what the best way is to ask them so I'll just stick one of them here; How does that example door prefab work?
I'm looking to create an elevator that the player can use so I checked out the door prefab, but I'm left a little bit confused as to what actually triggers it. I can already tell I'm going to be asking a tonne of questions that might seem a bit simple, but I can't figure out what's making the door open in the first place when you get near.
I'm looking to create an elevator that the player can use so I checked out the door prefab, but I'm left a little bit confused as to what actually triggers it. I can already tell I'm going to be asking a tonne of questions that might seem a bit simple, but I can't figure out what's making the door open in the first place when you get near.
Last edited by Runi on 2017-02-18, 22:16, edited 1 time in total.
Re: How do doors and lifts work?
Hi Runi,
please note that I've split your post, creating a new, standalone topic from it. That keeps discussions with different topics easier to follow.
I guess it's best if you check out some of the example lifts and doors in the maps: Simple doors are in map Kidney, a simple lift is in AEonsCube. A complex lift (and also teleporters and smaller lifts) are in BpWxBeta (the one shown in the image at http://www.cafu.de/news/client-features-revisited/).
Generally speaking, you need an entity that has a Mover component and a Script component. An entity that provides the "move destination point" can be a sub-entity of the main entity. Finally, you need something that triggers the Mover. Such triggers can be brushes that are part of the main entity (invisible in the maps unless you change the render mode in the 3D view using the TAB key) or a GUI. The trigger or GUI causes the main entity's script to be called, which in turn moves the door or lift.
Don't hesitate to ask if you've more questions!![Thumb Up :up:](./images/smilies/thumbup.gif)
please note that I've split your post, creating a new, standalone topic from it. That keeps discussions with different topics easier to follow.
I guess it's best if you check out some of the example lifts and doors in the maps: Simple doors are in map Kidney, a simple lift is in AEonsCube. A complex lift (and also teleporters and smaller lifts) are in BpWxBeta (the one shown in the image at http://www.cafu.de/news/client-features-revisited/).
Generally speaking, you need an entity that has a Mover component and a Script component. An entity that provides the "move destination point" can be a sub-entity of the main entity. Finally, you need something that triggers the Mover. Such triggers can be brushes that are part of the main entity (invisible in the maps unless you change the render mode in the 3D view using the TAB key) or a GUI. The trigger or GUI causes the main entity's script to be called, which in turn moves the door or lift.
Don't hesitate to ask if you've more questions!
![Thumb Up :up:](./images/smilies/thumbup.gif)
Best regards,
Carsten
Carsten
Re: How do doors and lifts work?
Okay so I get the gist of it, but say I've got a segment of an arc generated with CaWE and I want to make a single segment of that activate the lift. What do I actually do to connect the two?
The segment I want to use is already assigned to an entity called "tzone" and I've whacked the "trigger" meta texture on it just because I saw that in another map. But for whatever reason, this entire system doesn't feel at all intuitive to me. I know it will soon enough, but even while digging through scripts with the maps open in the game and CaWE I can't make much sense of the "which in turn"'s.
All it needs to do is toggle from upstairs, to downstairs when I walk into the triggerzone, but I've only been able to figure out how to "set the table" so to speak. Is there something incredibly glaringly obvious that I'm missing, or is it just a niche usecase so it's quite obtuse?
The segment I want to use is already assigned to an entity called "tzone" and I've whacked the "trigger" meta texture on it just because I saw that in another map. But for whatever reason, this entire system doesn't feel at all intuitive to me. I know it will soon enough, but even while digging through scripts with the maps open in the game and CaWE I can't make much sense of the "which in turn"'s.
All it needs to do is toggle from upstairs, to downstairs when I walk into the triggerzone, but I've only been able to figure out how to "set the table" so to speak. Is there something incredibly glaringly obvious that I'm missing, or is it just a niche usecase so it's quite obtuse?
Last edited by Runi on 2017-02-19, 09:48, edited 1 time in total.
Re: How do doors and lifts work?
Ok, sorry, I've been too brief above.
Let's break it into steps:
(I'm not sure what you mean by segment of an arc. Do you want the segment to initiate some action when it is touched, shot, clicked, ...?)
Let's just assume that the segment is a solid piece of wall or floor and you want an action to occur when someone walks near it.
You would create a new brush next to the segment, assign the "Trigger" material to it and move and shape it so that it encloses the volume that later should, when touched, trigger the action. That is, players are supposed to walk "into" this newly created brush (this is why it is rendered invisible in some of the CaWE render modes). It is the "Trigger" material that causes it to attain that special behavior. Such a brush is called a "trigger volume".
Next, when the player walks into such a trigger volume, what happens?
Note that trigger volume brushes are supposed to be part of a dedicated entity that has a Script component.
That is, the minimal setup is an entity that contains a trigger volume and a Script component. At this point, nothing else is needed.
Whenever something walks into the trigger volume, the script's
That is, the Script component must either point to a script file that defines this method, or you can enter the code into the ScriptCode field directly. For example:
(Well, I know, this may seem cumbersome, but it actually provides a huge deal of flexibility!)
Ohh, it just comes to mind: Make sure to check out the two trigger volumes in TestPatches.cmap! These provide really good examples of the technique described so far!
Next, the door or lift (that is for now an entirely different entity from the above) must be addressed as mentioned in the above code comment. For example:
The doors in turn are well implemented as entities with Mover components that help with collision detection and generally implement the move. See the comment at the top of Scripts/MoverBinary.lua for additional details.
Finally, note the trick that we use with the doors that you see in map Kidney (and elsewhere): The entity that keeps the trigger volume and the entity that keeps the Mover component are just one, which in turn simplifies the script setup, because you only need one script file, not two. It is a consequence of this two-in-one setup that the script in Scripts/MoverBinary.lua contains this code:
which establishes the connection between the trigger volume and the Mover.
Let's break it into steps:
(I'm not sure what you mean by segment of an arc. Do you want the segment to initiate some action when it is touched, shot, clicked, ...?)
Let's just assume that the segment is a solid piece of wall or floor and you want an action to occur when someone walks near it.
You would create a new brush next to the segment, assign the "Trigger" material to it and move and shape it so that it encloses the volume that later should, when touched, trigger the action. That is, players are supposed to walk "into" this newly created brush (this is why it is rendered invisible in some of the CaWE render modes). It is the "Trigger" material that causes it to attain that special behavior. Such a brush is called a "trigger volume".
Next, when the player walks into such a trigger volume, what happens?
Note that trigger volume brushes are supposed to be part of a dedicated entity that has a Script component.
That is, the minimal setup is an entity that contains a trigger volume and a Script component. At this point, nothing else is needed.
Whenever something walks into the trigger volume, the script's
OnTrigger()
method is called.That is, the Script component must either point to a script file that defines this method, or you can enter the code into the ScriptCode field directly. For example:
Code: Select all
local Trigger = ...
function Trigger:OnTrigger(Other)
-- Add your code here.
-- Here is typically a call to the door or lift
-- that tells it to run it's action (open/close/move/...).
end
Ohh, it just comes to mind: Make sure to check out the two trigger volumes in TestPatches.cmap! These provide really good examples of the technique described so far!
Next, the door or lift (that is for now an entirely different entity from the above) must be addressed as mentioned in the above code comment. For example:
Code: Select all
local Trigger = ...
function Trigger:OnTrigger(Other)
-- For more detail about this, see Games/DeathMatch/GUIs/Activate_main.cgui
local DoorEnt = world:GetRootEntity():FindByName("my_door")
local DoorScript = DoorEnt:GetComponent("Script")
DoorScript:OnActivate(Other)
end
Finally, note the trick that we use with the doors that you see in map Kidney (and elsewhere): The entity that keeps the trigger volume and the entity that keeps the Mover component are just one, which in turn simplifies the script setup, because you only need one script file, not two. It is a consequence of this two-in-one setup that the script in Scripts/MoverBinary.lua contains this code:
Code: Select all
function Script:OnTrigger(OtherEnt)
self:OnActivate(OtherEnt)
end
Best regards,
Carsten
Carsten
-
- Posts:11
- Joined:2019-07-23, 08:28
Re: How do doors and lifts work?
I know this is an old post, but but I am seeking information related to the subject.
Is it possible to restrict movement to only 1 axis? Such as in the case of a door rotating on its hinges?
Re: How do doors and lifts work?
I'm not sure what you mean with 1 axis?TheWhiteLion wrote: ↑2019-07-27, 02:40Is it possible to restrict movement to only 1 axis? Such as in the case of a door rotating on its hinges?
At this time, we can only linearly translate mover entities. Rotation, unfortunately, it not yet possible (this should be added to class
ComponentMoverT
).Best regards,
Carsten
Carsten
-
- Posts:11
- Joined:2019-07-23, 08:28
Re: How do doors and lifts work?
Let's assume that I want to use a solid brush as a door that can rotate in two directions, I create another brush that defines the axis that this door rotates by at one of its sides. The door will be able to move 90 degrees in either direction when activated by the player either by a switch or by contact. This is what I want to achieve in the editor, to transform solid brushes into entities that can rotate on an axis I define in the game-world.Carsten wrote: ↑2019-07-28, 10:00I'm not sure what you mean with 1 axis?TheWhiteLion wrote: ↑2019-07-27, 02:40Is it possible to restrict movement to only 1 axis? Such as in the case of a door rotating on its hinges?
At this time, we can only linearly translate mover entities. Rotation, unfortunately, it not yet possible (this should be added to classComponentMoverT
).
I am capable and willing to add this functionality to the source code, I have a strong foundation in the C programming language and I know some C++, although I have never done game engine programming before. I am aware of the C++ documentation but I am concerned that it is not up to date.
Re: How do doors and lifts work?
A problem with rotating objects is their interaction with other objects, such as players or physics objects: It is difficult to determine what should happen if a rotating door pushes another object or if the object rides on a rotating platform.
It's a while since I was last deeply familiar with the related code, but
For specifying the axis and amount of rotation, the simplest approach might be to specify the desired angles in the related scripts as numeric values, e.g. (0, 0, 90) for a rotation about 90 degrees about the z-axis.
It's a while since I was last deeply familiar with the related code, but
ComponentMoverT::HandleMove()
could certainly be augmented with code that supports rotation.For specifying the axis and amount of rotation, the simplest approach might be to specify the desired angles in the related scripts as numeric values, e.g. (0, 0, 90) for a rotation about 90 degrees about the z-axis.
Best regards,
Carsten
Carsten
Who is online
Users browsing this forum: No registered users and 100 guests