Elevator blocks

[Wildcat8787]

I was thinking it would be very simple to standardize the whole elevator process by adding 2 new blocks: elevator controller and elevator stop.
The elevator control would be placed inside the elevator and linked to the various stops, and could be used to designate which floor to move to in a similar fashion to the transporters. It could also be used as a call button outside of the elevator.
The elevator stops would be attached to the rail and work like a combination of an AND gate and an activation block, in that it only activates when the elevator is set to move to that stop and the elevator reaches it, stopping the elevator at that point.
This would also help with npcs as they wouldn't have to understand and deal with the various ways people build elevators (and there's a lot of different designs out there) and instead just be programmed to deal with the elevator blocks.
It could also be used for other purposes like moving turrets across a ship to stop at certain points, or partially opening hangar doors.
Plus it would seriously cut down on logic on big ships and the lag that comes with extremely complicated logic systems. And the logic beams going every which way.

 

[Lecic]

This is completely unnecessary.

Also, most standard logic doesn't cause any server lag whatsoever. Only semi-exploity fast clocks cause lag.

 

[Wildcat8787]

This is completely unnecessary.

Also, most standard logic doesn't cause any server lag whatsoever. Only semi-exploity fast clocks cause lag.

Maybe not server lag but I believe rendering all those logic beams causes some fps lag. Or at least it does for me whenever i'm around a lot of logic.
Still though - it would be easier to tell npcs to go to elevator 2 and take it to floor 3 to get to their station.

 

[GRHayes]

I was thinking it would be very simple to standardize the whole elevator process by adding 2 new blocks: elevator controller and elevator stop.
The elevator control would be placed inside the elevator and linked to the various stops, and could be used to designate which floor to move to in a similar fashion to the transporters. It could also be used as a call button outside of the elevator.
The elevator stops would be attached to the rail and work like a combination of an AND gate and an activation block, in that it only activates when the elevator is set to move to that stop and the elevator reaches it, stopping the elevator at that point.
This would also help with npcs as they wouldn't have to understand and deal with the various ways people build elevators (and there's a lot of different designs out there) and instead just be programmed to deal with the elevator blocks.
It could also be used for other purposes like moving turrets across a ship to stop at certain points, or partially opening hangar doors.
Plus it would seriously cut down on logic on big ships and the lag that comes with extremely complicated logic systems. And the logic beams going every which way.

From what I understand they are planning on putting controllers in the game. Which if they act like a PLC then would make this pointless.
You'll find that listed in the following link under "balance changes"
https://star-made.org/news/starmade-v0-19519-cargo-more

 

[Valck]

Plus it would seriously cut down on logic on big ships

More importantly, it would cut down on logic for smaller ships too where you don't have the luxury of dedicating an entire deck to logic...

And the logic beams going every which way.

Say what you will, I do like them. But don't worry, I seem to remember that it has been announced that they're going away or become an optional graphics setting.

From what I understand they are planning on putting controllers in the game. Which if they act like a PLC then would make this pointless.
You'll find that listed in the following link under "balance changes"
https://star-made.org/news/starmade-v0-19519-cargo-more

PLCs would be nice, but I'm afraid you misunderstood. Now that they have added grouping for lights and rods, the thing they are going to add next is grouping for controllers and their modules, as in weapon controllers, effect controllers, etc.
That is not to say they're not going to add PLCs as well at some point, just not in the next update...

 

[GRHayes]

More importantly, it would cut down on logic for smaller ships too where you don't have the luxury of dedicating an entire deck to logic...


Say what you will, I do like them. But don't worry, I seem to remember that it has been announced that they're going away or become an optional graphics setting.


PLCs would be nice, but I'm afraid you misunderstood. Now that they have added grouping for lights and rods, the thing they are going to add next is grouping for controllers and their modules, as in weapon controllers, effect controllers, etc.
That is not to say they're not going to add PLCs as well at some point, just not in the next update...

Thanks for letting me know. They could have been a hell of a lot more clear. When I hear controllers I tend to think PLC (Programmable logic controllers) which are often used to control things like elevators. It would certainly solve the job you want and about 800 other issues people have on here.

 

[Wildcat8787]

Thanks for letting me know. They could have been a hell of a lot more clear. When I hear controllers I tend to think PLC (Programmable logic controllers) which are often used to control things like elevators. It would certainly solve the job you want and about 800 other issues people have on here.

Yeah, those would solve a lot of problems, but i'm not sure how they would be implemented with elevators. Not the best at coding here.

 

[GRHayes]

Yeah, those would solve a lot of problems, but i'm not sure how they would be implemented with elevators. Not the best at coding here.

If you can use logic blocks you can use a PLC. It coded using logic not a programming language. They call them programmable because they aren't hardwired to be one way or another. Usually people use a laptop to connect to them and it has a program on the laptop that lets you set it up using the logic system. There are some programs people can use if they want to do it in C but the vast majority use the ladder logic to program them.

 

[Wildcat8787]

If you can use logic blocks you can use a PLC. It coded using logic not a programming language. They call them programmable because they aren't hardwired to be one way or another. Usually people use a laptop to connect to them and it has a program on the laptop that lets you set it up using the logic system. There are some programs people can use if they want to do it in C but the vast majority use the ladder logic to program them.

Yeah, i could see that being handy, but still, the issue of how easily npcs would be able to follow your code and designating which rails to turn and which direction, plus if it would even be able to designate targets between entities.

 

[GRHayes]

Yeah, i could see that being handy, but still, the issue of how easily npcs would be able to follow your code and designating which rails to turn and which direction, plus if it would even be able to designate targets between entities.

NPCs don't need to understand how people build elevators and so on. NPCs interaction with things like elevators depends on the way the AI is written. A good method would be the AI can cue in on tags that will have to be assigned items and objects the NPC will need to interact with. Example: a switch that goes to the first floor would have a tag as 1st floor. It works on the same principle as the path node system.

What this allows is the NPC to follow the nodes to go from location to location or to complete various tasks.

Example: NPC is on 3rd floor needs to eat mess hall is on 1st floor.
NPC follows nodes to elevator. Node at elevator tells NPC to push call button if elevator is not there already. NPC once elevator is there goes into elevator to next node. Which tells gives a hint list of destinations. It says mess hall is on 1st floor to push button 1. NPC AI matches destination with current task pushes button 1. Elevator goes down to first floor NPC exits to next node connection and heads toward mess hall.

 

[NeonSturm]

It is easy with wireless logic, as you don't need separate buttons in every stage anymore now.

Each button can put upper/lower rails on up / down / sidewards=stop.

 

[GRHayes]

It is easy with wireless logic, as you don't need separate buttons in every stage anymore now.

Each button can put upper/lower rails on up / down / sidewards=stop.

Maybe I am confused by what you are saying. I still end up with this even with wireless logic on the elevator. This is an 8 floor elevator.
Its simple and fast to setup once you understand the pattern of connections. Doing this in a PLC would be a million times easier though.
https://starmadedock.net/threads/my-rail-elevator-circuit-very-fast-to-wire.21444/

The elevator has to know if it is at the right floor or if it is above or below the floor it needs to go to. If it is above it needs to go down.
If it is below it needs to go up. It then stops when reaching its floor. The of course you might want door controls to open the elevator at the right floor and close them at all others. All of which is built in this circuit.

Its also better to use rail speed to turn it off.

 

[NeonSturm]

1. The elevator rail has 3 states:

1. stop (facing sidewards)
2. up (facing upward)
3. down (facing downward)

Therefore you need 3 additional rails + 3 activators to change directions.
​

2. The elevator continues travelling up/down until it reached the top/bottom or top-most / bottom-most rail segment that is in stop-state.

Once it reaches a stop-state floor, it stops until the doors are closed again (2-3 seconds without one triggering an area trigger nearby doors).
Here you need 1 single last-up/down-(state|activation-module) +1 NOT for it, to check topmost/bottommost stop-state vs current position to flip direction.

2 And blocks per floor should be sufficient (not stop-state), (up+not upmost), (down+not bottommost)
​

3. Activating a wireless-logic button for a floor should put a floor into stop-state.

Requires 2 wireless blocks per floor at most.
Removing stop-state could simply deactivate the wireless in the elevator.​

I guess 9-11 blocks per floor, depending on how advanced you build binary floor destination input controls.

 

[kiraen]

1. The elevator rail has 3 states:

1. stop (facing sidewards)
2. up (facing upward)
3. down (facing downward)

Therefore you need 3 additional rails + 3 activators to change directions.
​

Actually, it's better to use a speed controller to cause a stop. Just set it up with 1 off-state activator. The activator triggers for one cycle (0.5s) when you want the elevator to move. You can use the same speed controller for every stop on the line/shaft. This also has the benefit of reducing lag since the elevator will no longer do collision checks when it's speed is set to 0.​

 

[Wildcat8787]

Well, if elevator blocks aren't going to be a thing then we need to develop a universal elevator design, like the universal dock.
Preferably one without buttons for every single floor as I have seen and am currently building elevators with quite a few floors. The one I have right now has 15 floors, and that won't exactly be easy to fit into a single elevator. Same if anyone wants to build an even bigger elevator in, for example, a tower like space station.

 

[GRHayes]

Well, if elevator blocks aren't going to be a thing then we need to develop a universal elevator design, like the universal dock.
Preferably one without buttons for every single floor as I have seen and am currently building elevators with quite a few floors. The one I have right now has 15 floors, and that won't exactly be easy to fit into a single elevator. Same if anyone wants to build an even bigger elevator in, for example, a tower like space station.

You see that 8 floor elevator it takes less than 10 minutes to setup.
The reason is simple its built by understanding the pattern of how it works.
It saves you tracing up and down or trying to build a cluster on each floor near as much.
It could be expanded to any size elevator you could turn those two modules on the right and left to go up and down to reduce room.
I did it this way simply so people who down load it could figure out the pattern and use it themselves.
But in truth standard is needed. Like I said AI wont care to licks about it.

 

[NeonSturm]

Actually, it's better to use a speed controller to cause a stop. Just set it up with 1 off-state activator. The activator triggers for one cycle (0.5s) when you want the elevator to move. You can use the same speed controller for every stop on the line/shaft. This also has the benefit of reducing lag since the elevator will no longer do collision checks when it's speed is set to 0.​

Both should work.

Getting at the end of a rail should cause speed=0 until a new rail appears adjacent (check adjacent having something docked on creation) or the rail itself changes directions.​

Speed and direction both needs 2 blocks I think.
[DOUBLEPOST=1451738737,1451738358][/DOUBLEPOST]

You see that 8 floor elevator it takes less than 10 minutes to setup.
The reason is simple its built by understanding the pattern of how it works.
It saves you tracing up and down or trying to build a cluster on each floor near as much.
It could be expanded to any size elevator you could turn those two modules on the right and left to go up and down to reduce room.
I did it this way simply so people who down load it could figure out the pattern and use it themselves.
But in truth standard is needed. Like I said AI wont care to licks about it.

For some it's easier to figure out a pattern if blocks that belong to a floor are at the floor (that's why object-orientated Java is so famous). Peoples are different.
And sometimes it saves you from wires showing up in rooms that don't belong to the elevator.

An integer-comparison or it's math could save a lot of blocks.

The AI pathfinder needs to know that the elevator-blocks switch in t-time (=cost) between locations (way-points, rooms).
The AI needs to know how to trigger the change and get from the trigger to the elevator.

Needs reverse logic (final state, changes required (initial→final), required sets that are most desirable, following that order, notice changes on required elements - blocks, logic edit, …)

 

[GRHayes]

Both should work.

Getting at the end of a rail should cause speed=0 until a new rail appears adjacent (check adjacent having something docked on creation) or the rail itself changes directions.​

Speed and direction both needs 2 blocks I think.
[DOUBLEPOST=1451738737,1451738358][/DOUBLEPOST]
For some it's easier to figure out a pattern if blocks that belong to a floor are at the floor (that's why object-orientated Java is so famous). Peoples are different.
And sometimes it saves you from wires showing up in rooms that don't belong to the elevator.

An integer-comparison or it's math could save a lot of blocks.

The AI pathfinder needs to know that the elevator-blocks switch in t-time (=cost) between locations (way-points, rooms).
The AI needs to know how to trigger the change and get from the trigger to the elevator.

Needs reverse logic (final state, changes required (initial→final), required sets that are most desirable, following that order, notice changes on required elements - blocks, logic edit, …)

I've been over this already. It isn't relevant to AI at all.
All the AI needs is a path node at each CALL button. A node inside the elevator that will give an active signal when attached to the path node that is at the CALL button they are at. What that means is when the elevator reaches the call location that node only becomes active and connected to that floors node network when and only when the elevator is there. There is no need to worry about time or any other garbage. The AI will simply stand at or near the call button until the node is connected. IF you make your AI anyways reasonable. Its one of the simplest AI systems to implement. Once the AI is in the Elevator that node provides it a list of actions to reach a list of destinations. The AI says it wants to go to engineering or the mess hall it then looks at the list and goes Okie dokie push this button. It then activates the routine activate that button. Button is activated. The node it is on becomes a stationary. Telling the AI to stand still. The elevator moves. Connects to the floor it is going to and then node connects to that floors node network. AI is then able to see the path to where it is going and proceeds.

The nodes don't become active for movement till the doors are open and so on and the path is complete. Thus you have no timing issues at all.

You don't need a path finder like A* for this type of issue its overly complex for this type of system. Unless you have multiple paths to the same location it has no benefit. And if you do have multiple paths to the same location using something like A* will end up with NPCs always taking the same path rather than something more realistic and they will simply avoid the elevator all together.

The only place A* might be viable in this game is on a single plate. But because planets use plates and aren't a unified connected object it won't work well for traversing the planet without points being made for AIs to go from plate to plate such as maybe the transporters. Even then you are going back to a primary node network system.