Archive: 29 posts

---

When designing lift systems involving multiple stops (floors), most people rely on 3-way switches for manual elevator control. This solution is crude at best, because its very easy to over- or undershoot your destination for stops occurring in between the absolute top and bottom floors. Furthermore, sackboy has to continue to hold the 3-way switch for the duration of the trip, which, for some people (like me), is not fun. So I've designed a lift system that upon sackboys input, automatically moves the elevator to the next floor, arriving at a precise stop location (this looks nice, since the elevator floor always lines up with the stop's floor). Once the elevator is in motion, you can let go of the control switch and the elevator continues to move to the next floor in the specified direction. The logic for a problem like this is potentially very ugly, however, I've designed an elegant and simple solution that involves the innovative use of paintballs as a method of logic control. Workshop prototype (basic idea) http://farm4.static.flickr.com/3365/3216945720_fb6b7dcba6_o.jpg On the floor, we have a 3-way control switch for direction located inside the elevator. The red button represents a switch that sends a "pause" signal and overrides lift motion when activated. I use this to stop the elevator at each floor. The 3-way switch in the elevator is set to directional and controls the position of an emitter. The emitter is positioned over one of two troughs at any given time. The emitted block causes the elevator to move, and direction is determined by which trough it is emitted into. The pause button is connected to the emitter on the left, which emits paintballs. The motion-controlling emitted blocks are made of dissolve and wired with a paint switch. Pressing the red button shoots the paintball, destroying the motion block and stopping the elevator. Final implementation http://farm4.static.flickr.com/3436/3216945774_36a84b53d2.jpg?v=0 The final implementation shown above fixes a flaw with the prototype. In the prototype, the motion block is emitted when the positioning block reaches the "other" trough (essentially acting like a 2-input toggle). The problem with this is that if the next user command sends the elevator in the same direction as the previous command, there is no re-emission of the motion block. I solved this by redesigning the motion block emitter control. The master control 3-way switch is set to directional, and we want to build a relay that acts like a 3-way set to 1-shot. For this, I built a cylinder with a mag key on it. It's speedy motor bolt is connected to the elevator's master switch. So, regardless of master switch input direction, the key inevitably reactivates the motion block emitter. In the final implementation, the red pause button is replaced by a mag switch activated by mag keys carefully positioned at the stops on each floor. I hope you like my design. If anyone wants me to publish these controls in a copyable level, please let me know.

2009-01-22 18:24:00 Author: Thegide Posts: 1465

---

I can help you make it look prettier if I had a better understanding off what you are doing. I know it doesn't need to look pretty because it is behind the scenes but I like making things in one simple package. All those things I could wrap up into a nice square box object that you could just paste into any level anywhere making it easier for use. I'm not sure I understand the idea behind the pause emitter and such. Edit: Nevermind there was a section in the prototype that I didn't read but I understand now lol. The offer is still on the table if you want it to look prettier and portable.

2009-01-22 18:55:00 Author: LordCanti07 Posts: 106

---

These controls are positioned off-screen as you suspected. Yes, it would be very easy to wrap them up into a box, but what's the point if the player never sees it anyways? My personal style is that I don't like to hide switches and such in my level unless it's integral to the gameplay, because like the Mm levels, I like to give players the opportunity to see "how I did that". Ok, I'll try to explain the pause emitter better: The directional control emitter (top) dumps a control block into a trough, which causes the elevator to move. Without intervention, the elevator would move to its maximum or minimum height automatically. The pause control sends a STOP signal to the elevator, and the mag keys that cause stop signals are located on each floor. The elevator's motion is controlled by 2 inputs attached to a remote 3-way switch via winch. When no motion blocks are in the system, the remote switch is neutral (elevator stopped). In the up or down troughs, the remote 3-way position is left or right, directly controlling the elevator's pistons. To stop the elevator, you need to get rid of the motion control block out of the up or down trough. So, how do you do this? Well, you could re-emit it in a 3rd location (since its lifetime is infinite and its max emitted at once is 1). But, trying to get a piston to stop at 3 specific places is ugly logic, and I have yet to see an easy way to do this. Another option is physically destroy the motion block, so that both up and down troughs are empty. This is what the paintball (pause) emitter is doing. It shoots horizontally to the right, hitting anything sitting in either trough. With a paint switch on the motion block, the block is dissolved, and the elevator's remote 3-way controller is returned to neutral (stop) position.

2009-01-22 19:12:00 Author: Thegide Posts: 1465

---

Well if you are not gonna hide the switches and stuff then you should make them look pretty otherwise if someone sees it they will be all like GROSS! lol

2009-01-22 19:40:00 Author: LordCanti07 Posts: 106

---

Well thought out, it's not that complex for what it does. I'll think of this whenever I make a lift, thanks.

2009-01-22 20:29:00 Author: Dynashock Posts: 69

---

This level is now freely copyable as a tech demo. The level is called "AMECS: Intelligent Elevator Control"

2009-01-23 14:17:00 Author: Thegide Posts: 1465

---

lol I posted in your LBW thread but are you sure emitting paintballs is less thermometer than a full-blown, flawless implementation with 2 SR latches and 2 AND gates? To sum up my implementation, it's a total of 6 mag switches and 6 mag sensors, plus one more mag switch (to detect STOP) and a sensor per STOP (per floor).

2009-01-26 17:53:00 Author: snowflakecat Posts: 102

---

It might be more thermometer than your setup, it's hard to say given that my implementation doesn't budge the thermo. One potential caveat of my design is that the paint stickers would pile up and could overheat the level mid-play. To be honest, I can't envision your implementation (while at work anyways). I understand the concept of the SR latch (as a 2-input toggle) and obviously AND gates are trivial. The fundamental idea is largely what I was trying to do with my design (one set of inputs for on/off, and one for direction). The big factor that complicated implementation was sequential input. The elevator switch must be 3-way directional in order to get 3 output types (up/down/stop). Setting to 1-shot gives only binary output since it ignores which direction the switch is pulled, although for the case of SET, 1-shot is the type of behavior we want. If you can build a relay that converts 3-way directional to 1-shot, then this elevator problem is trivial, and my hat is off to you if you can build a simpler version than mine. I'm certainly not an expert in logic, but I'm getting better. If you're up for it, I'd like to see your build. If there is a better way of doing this, I'm happy to upconvert.

2009-01-26 18:47:00 Author: Thegide Posts: 1465

---

I was planning a level to demonstrate it but I can show you how it works. Just add me on PSN and I'll invite you to a demo level. My psn is snowflakecat

2009-01-26 19:23:00 Author: snowflakecat Posts: 102

---

That is wayyyy simpler than the ridiculous solution I came up with lol... I am definitely going to use this idea down the line.

2009-01-26 19:24:00 Author: Unknown User

---

Nice guide! However, it seems overly complicated to me. I have a question... Why not have your 3 way switch just pull on the elevator winch for a defined amount of time (of course the amount of time to travel between floors)? It seems like it would be dramatically easier. Thoughts?

2009-01-26 19:28:00 Author: Inspectigater Posts: 126

---

@inspectigater wouldn't work. LBP uses physics; the item that is dragged by the piston has mass and momentum, so it's possible for the platform to overshoot.

2009-01-26 19:37:00 Author: snowflakecat Posts: 102

---

oh I forgot to say something: in both my implementation and Thegide's implementation, mag keys and switches are used to detect the platform. This means that the elevator cannot be too fast. A mechanical elevator with locking systems per floor would probably be far superior in speed, but I haven't really thought about it.

2009-01-26 19:42:00 Author: snowflakecat Posts: 102

---

wouldn't work. LBP uses physics; the item that is dragged by the piston has mass and momentum, so it's possible for the platform to overshoot. How so? If you're always factoring the elevator moving at the same speed (which I assume it would due to that being defined by the speed of movement of the winch). why would the results change?

2009-01-26 19:46:00 Author: Inspectigater Posts: 126

---

@ inspectigater it's not always moving at the same speed. Due to mass the response of a piston is non-linear (ramps up then reaches a peak velocity; when the three way switch goes back center it slows down to a stop)

2009-01-26 19:49:00 Author: snowflakecat Posts: 102

---

@ inspectigater it's not always moving at the same speed. Due to mass the response of a piston is non-linear (ramps up then reaches a peak velocity; when the three way switch goes back center it slows down to a stop) But wouldn't these things still be constants in the situation outlined here? Also, does this happen to a winch as well? Would you be able to just use a winch instead of a piston to move the elevator? (I'm not trying to be difficult, honest! I'm just trying to understand ) The way I see it is the 3 way activates a delay switch to push the mag switch and key together (with a .1s travel time), then the piston has a delay of <amount of time it takes to travel between floors> and retracts, effectively shutting off the winch again.

2009-01-26 20:00:00 Author: Inspectigater Posts: 126

---

@ inspectigater I understand what you're trying to say (no need to describe it ;-). Just try implementing and testing it, and you will understand why the response of winches/pistons are nonlinear in LBP.

2009-01-26 20:03:00 Author: snowflakecat Posts: 102

---

I suppose my question is... is the acceleration and deceleration of the moving parts predictable?

2009-01-26 20:25:00 Author: Inspectigater Posts: 126

---

it might be; I don't know if anybody has tried to quantify the physics system in LBP (ie what type of integrator do they use? RK4 (Runge Kutta to the 4th order) is my bet but it would be something else? What is the effect of material weight?). Sure, you can have material weights relative to other weights and come up with units, but what's the precise formula for determining the stop and start distances given the piston speed, platform material and size? I wouldn't bother to find these things out but kudos to the people that do.

2009-01-26 20:38:00 Author: snowflakecat Posts: 102

---

I'll play with it a bit tonight and let you know how things turn out.

2009-01-26 21:06:00 Author: Inspectigater Posts: 126

---

The big problem with the physics engine in LBP is that it's too lively. What should be constants in a system can be thrown off by very minor things, like added weight, inertia, etc. So for example, having 4 sackpeople on an elevator produces more stress on the winch which in turn makes it operate at slower speed. I don't believe pistons are entirely immune to stress, but certainly other fasteners are more susceptible (wobble bolts being the worst) On paper your idea sounds like it would work, but I can almost guarantee that you would not achieve consistent predictable behavior. Furthermore, winches are not desirable in this case, since we don't want the elevator car swinging around in the shaft (giggle if you must). For the stop detection, a faster moving elevator requires more advance placement of the mag keys - since the piston "brakes" have a longer stopping distance. For my elevator, a realistic speed requires two mag keys placed close together. Because the elevator tends to overshoot the mag key (inertia), I have to place separate mag keys depending on which direction the elevator approaches from. @snowflake... ill add you when i get home tonight. your menu system level alone tells me you're a hell of a lot better with logic than I haha.

2009-01-26 21:18:00 Author: Thegide Posts: 1465

---

I think I understand what you're saying now. Despite the fact that the piston will still complete a full rotation in <4s seconds> (just throwing it out there), the piston will be forced to generate more power in order to move 4x sackperson weight in the defined timeframe. Pausing the movement process in the middle of a rotation will interfere with the speed of the elevator. This, in return, causes the deceleration times to be extended or shortened depending on your direction. So the timed elevator switches would be short or too far depending on how many sackpeople are in the elevator. Is that what you're saying?

2009-01-26 21:36:00 Author: Inspectigater Posts: 126

---

Hmm I don't want to say too much given that I haven't empirically tested all of the connectors. But let me talk about the wobble bolt phenomenon again, to illustrate at least the kind of visible effects you might notice. A wobble with a too-heavy object attached to it will not complete its entire rotation. In the same way you can physically stretch apart objects connected with bolts and the like so much so that the connected pieces are no longer even touching each other (make a belt-driven conveyor if you ever want to see how messed up this can be) Presumably the same types of physics issues affect winches, rods, string, and possibly pistons. "Stiff" pistons can bend and behave like loose pistons when overloaded. Pistons connected in succession will sometimes not provide any lift. This is what I mean about "lively". In the elevator example, I would envision it being slow and undershooting while rising, and overshooting on descent if overloaded. Then again I wouldnt be surprised to see the opposite too, since sometimes LBP physics seem to fall in place with an alternative reality, and stressed objects often simply behave erroneously.

2009-01-26 23:49:00 Author: Thegide Posts: 1465

---

they injected too much entropy in it

2009-01-27 02:11:00 Author: snowflakecat Posts: 102

---

Okay, yeah that makes sense... it's really too bad, though. It could be a much simpler way to accomplish the same thing. But again, let me reiterate. Nice work on the switch.

2009-01-27 16:20:00 Author: Inspectigater Posts: 126

---

^ Thanks man. Ok, while I was really stoked about using paintballs to solve my logic problems, I realize they are potentially less than ideal, but this isn't a problem since there is a very simple alternative. Instead of emitting paint, emit a block with a mag switch. Swap the paint switch on the motion control blocks with the matching mag key. I can't believe I didn't think of this before. Anyways, its just a bit more robust now, and won't contribute to thermo heating since there's nothing to accumulate (such as paint stickers).

2009-02-06 19:53:00 Author: Thegide Posts: 1465

---

Thegide, I've optimized my elevator system. My SR latch uses only one mag sensor, one mag switch, and two pistons now. You can checkout the elevator system in-action in my new level. The top two AND gates and OR gates are completely optional for a bare-bones version, bringing the total thermometer to: 4 pistons + 1 for moving the platform 3 mag switches, 2 mag sensors + 1 mag sensor per level I can't think of any way to optimize it further without delaying the elevator response. Have a look at it and let us know if you find a way to optimize it. It's not available as a prize yet because I'm certain there's a better way to do it (don't want to release a crappy product) and also because I'm working on a tutorial.

2009-02-16 09:51:00 Author: snowflakecat Posts: 102

---

Ok I'll have a look later. I'm still trying to think of how I can amend mine to work will call buttons as well.

2009-02-16 20:02:00 Author: Thegide Posts: 1465

---

I just realized floor buttons are easy and don't take much overhead (you just need a latch per level, meaning two pistons per level). Might implement them in the future. You can reduce the number of pistons per level to one if multiple floor selections are not allowed.

2009-02-17 01:16:00 Author: snowflakecat Posts: 102

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.