Jump to content

Lateral movement inside a construct?


Kurock

Recommended Posts

Will there be elements that provide lateral movement (up and down movement) inside a construct?

 

I know many people on the forums and discord channels are dreaming up their massive ships and buildings.  But how will we move around inside these ships and buildings, specifically up and down?

 

Are we relegated to ramps and jet-packs or can we do better?

 

Some examples include:

  • Ladder elements
  • Elevator elements
  • Teleporter elements

Can you think of more?

 

Link to comment
Share on other sites

That is a good question!

Because in the case of a ship being boarded by an enemy factions, and if said ship that is under attack does have something like an "Elevator element" would there also be control systems to allow the crew to shut down solely that element to slow the boarding parties progress through the ship? or will there be nothing but... Doors at the top of free walking vertical paths  :huh:

Link to comment
Share on other sites

How about stairs and escalators? I think that could add a pretty neat effect to the larger ships.

Maybe lift platforms? They would be kind of like elevators only with no physical lift mechanism, more of an energy booster deal. They could also function as mini, pre-programmed transport within the ship, moving both vertically and horizontally. Just select a destination and it will get you there.

Link to comment
Share on other sites

Couldn't you make a small square and program it to move up or down with LUA ? Make a box structure with square as floor. Have set of doors at top range to open, with doors at lower range as well. Have call buttons outside door edges and up/down buttons on inside of box?

Link to comment
Share on other sites

With the creative use of gravity generators you could make omnidirectional dropshafts.

True, but it depends on how/if they decide to implement those. If they make them really hard to build or very expensive, it might not be feasible.

 

Still, it would be neat to have it work that way, you could make the equivilant of vacuum tubes like the ones they use in bank drive-throughs, but with gravity!

Link to comment
Share on other sites

I'd enjoy seeing a variety of mechanical parts. Motors, pistons, sliding surfaces, perhaps later on ropes/chains/cables with pulleys. Or sprocket and chain. It would be easy enough to make a simple elevator using a sliding surface+propulsion device.

I believe a more friendly way of making elevators is putting micro thrusters on a plane of blocks. You'd have buttons making the thrusters going up and down.

 

Possibly add a "tracks" element (similar to roller coaster ones). Boom! People can make pistons, sliding surfaces with JUST that. Add a rotor, BOOM, rope, chains, and motors.

Link to comment
Share on other sites

  • 3 months later...

Unless the devs add a really weird restriction, creating elevators will be as simple as creating a vehicle that is scripted to move at certain ranges up and down, given a numerical imput and waging its distance in certain periodic units to it.

Why I ?make this part up" some would ask?

Because if you can't have a moving construct like an elevator within a building, then it's pretty much impossible to have carrier ships - ships that carry other ships. And since JC has explained that planets and ships are the  same for the game's code. If you can park a craft on a planet, then log out, log back in and take off in it, same thing can be done with an elevator.

Likewise, two sets of sliding doors can added and you got a legit looking elevator. Now, just script that thing and you got a spiffy elevator.

Link to comment
Share on other sites

1. Ease of use aka convenience. Sure, we could build a construct that acts like an elevator. And we probably will for custom jobs, like for ship elevators that could be any size or shape. But for normal avatar use, an element that carries a few people is much the same as using a door element instead of having to create a construct for every moving part.

 

2. Optimization. A single generic model for the elevator can be loaded once and used over and over again seems like a pretty good idea. Within a city, that will already be high construct and player density, every little optimization helps.

 

3. Security. A normal construct with thrusters can go anywhere. People could blow a hole in a building and fly away with your public access elevator. That is an extreme example but it is possible and honestly not something we should have to worry about for a generic, every day, elevator for avatars.

 

4. Power concerns. If constructs run on fuel and there is no way to automatically top them up while they are "docked", we have a conundrum that custom door and elevator needs to be refueled manually instead of, more ideally, pulling power from the construct it is "attached" to. This will be an issue regardless, but without the elevator element, this problem rises to whole new levels. Imagine every elevator in a city has to be manually refueled or it gets stuck somewhere.

 

If NQ comes back to us and says, whelp, we want the players to create their own elevators, there is no additional optimization that could be had, RDMS will allow you to set in which area a construct can operate in, and a refueling element that works over a few meters is a thing, well, then I will be as pleased as pudding and leave it at that.

Link to comment
Share on other sites

1. Ease of use aka convenience. Sure, we could build a construct that acts like an elevator. And we probably will for custom jobs, like for ship elevators that could be any size or shape. But for normal avatar use, an element that carries a few people is much the same as using a door element instead of having to create a construct for every moving part.

 

2. Optimization. A single generic model for the elevator can be loaded once and used over and over again seems like a pretty good idea. Within a city, that will already be high construct and player density, every little optimization helps.

 

3. Security. A normal construct with thrusters can go anywhere. People could blow a hole in a building and fly away with your public access elevator. That is an extreme example but it is possible and honestly not something we should have to worry about for a generic, every day, elevator for avatars.

 

4. Power concerns. If constructs run on fuel and there is no way to automatically top them up while they are "docked", we have a conundrum that custom door and elevator needs to be refueled manually instead of, more ideally, pulling power from the construct it is "attached" to. This will be an issue regardless, but without the elevator element, this problem rises to whole new levels. Imagine every elevator in a city has to be manually refueled or it gets stuck somewhere.

 

If NQ comes back to us and says, whelp, we want the players to create their own elevators, there is no additional optimization that could be had, RDMS will allow you to set in which area a construct can operate in, and a refueling element that works over a few meters is a thing, well, then I will be as pleased as pudding and leave it at that.

Adjustors need no fuel and provide thrust. Minute thrust,  but thrust nonetheless. Sprinkle them on roof and the bottom of an elevator and you got an up and down moving elevator. Watch the "building a spaceship" video, JC says adjustors need no fuel - as they are meant for star-fighters that can't afford the extra fuel cost for maneuvering, but the adjustors themselves have a very little Newton umph to them, so tehey can't be used for Battleship-level maneuvering. Ah, physics. Gotta love them.

 

Also, given the elevator will be on certain "voxel rail slots", it's safe to say it won't be possible to stir it. If a building has 10 floors, the elevator has scripted keybinds for going to all those 10 floors, by waging certain distances. Nobody will fly that elevator off a builing, because the elevator CAN'T navigate past the 10th floor. It's an elevator, not a starfighter. It's job is to go up and down on a certain length from the ground floor.

 

Elements should be machinery that can be interconnected to make vehicles, not vehicles themselves.

 

 

Cheers!

Link to comment
Share on other sites

Adjustors need no fuel and provide thrust. Minute thrust,  but thrust nonetheless. Sprinkle them on roof and the bottom of an elevator and you got an up and down moving elevator. Watch the "building a spaceship" video, JC says adjustors need no fuel - as they are meant for star-fighters that can't afford the extra fuel cost for maneuvering, but the adjustors themselves have a very little Newton umph to them, so tehey can't be used for Battleship-level maneuvering. Ah, physics. Gotta love them.

Also, given the elevator will be on certain "voxel rail slots", it's safe to say it won't be possible to stir it. If a building has 10 floors, the elevator has scripted keybinds for going to all those 10 floors, by waging certain distances. Nobody will fly that elevator off a builing, because the elevator CAN'T navigate past the 10th floor. It's an elevator, not a starfighter. It's job is to go up and down on a certain length from the ground floor.

Elements should be machinery that can be interconnected to make vehicles, not vehicles themselves.

Cheers!

Cheers!

I will be more than happy with just rail elements. Though I do still see the merit of having a generic box that runs on said rails.

Also if there are rails, then there is no need for maneuver thrusters which imo are a workaround.

Link to comment
Share on other sites

Cheers!

I will be more than happy with just rail elements. Though I do still see the merit of having a generic box that runs on said rails.

Also if there are rails, then there is no need for maneuver thrusters which imo are a workaround.

"voxel rails" means a set of tracks made for the ease of calculating distances and a way for the Elevator to "dock". Not actual rails. Engineering, quite complicated.

Link to comment
Share on other sites

"voxel rails" means a set of tracks made for the ease of calculating distances and a way for the Elevator to "dock". Not actual rails. Engineering, quite complicated.

There is no guarantee this will work. How do two flat planes of two different constructs interact with each other? Do they slide past? Is there friction? What about collision So? If there is even a little then the entire elevator will be in for a bumpy ride. Surely we can over engineer and add sensors to detect how far away each elevator wall is away from the shaft. But that takes processing power. Now multiply these bumpy sensor driven elevators by the 10000 that will be required for a city. That is a lot of needless work that a simple rail element can fix.

 

Could we build our own? Probably. I don't think I ever said we couldn't.

Will they be scalable so that 10000 of them can be used in a city? I doubt it.

 

Elements are something that should add function to a construct. Being able to easily move between different floors on that same construct sounds like a very handy function to me.

 

I will reiterate, again, that the elevator element is just for the simplest case. We can still build crazy contraptions that retracts entire buildings underground, or a lift that can raise a very specifically shaped craft, spin it around and flick it into the air like a flapjack.

 

The elevator business: easy to get into, difficult to master. Sound familiar?

 

I don't have anything more to say on the subject. If NQ decide to implement any of these ideas, great. If not, also great.

Link to comment
Share on other sites

There is no guarantee this will work. How do two flat planes of two different constructs interact with each other? Do they slide past? Is there friction? What about collision So? If there is even a little then the entire elevator will be in for a bumpy ride. Surely we can over engineer and add sensors to detect how far away each elevator wall is away from the shaft. But that takes processing power. Now multiply these bumpy sensor driven elevators by the 10000 that will be required for a city. That is a lot of needless work that a simple rail element can fix.

 

Could we build our own? Probably. I don't think I ever said we couldn't.

Will they be scalable so that 10000 of them can be used in a city? I doubt it.

 

Elements are something that should add function to a construct. Being able to easily move between different floors on that same construct sounds like a very handy function to me.

 

I will reiterate, again, that the elevator element is just for the simplest case. We can still build crazy contraptions that retracts entire buildings underground, or a lift that can raise a very specifically shaped craft, spin it around and flick it into the air like a flapjack.

 

The elevator business: easy to get into, difficult to master. Sound familiar?

 

I don't have anything more to say on the subject. If NQ decide to implement any of these ideas, great. If not, also great.

You think too one dimensionally. You think "i want one element that serves no other purpose".

 

Think of it this way. 

 

1. Voxel Box (Elevator) is built iwth two vertical lines, four voxels apart from one another and parallel to each other.

 

2. On those rails, we attach "voxel hooks" that will keep the elevator box in place when we want it to be parked on a floor.

 

3. We design a mounting rail on the back, with slots for when the elevator is about to dock, and people are not in it, so, for the Eevaltor to not drop back to the ground floor and be "held there".

 

 

4. Now, you got a tube for an elevator, that goes up to the tenth floor. Each floor, is apprxomiately 5 meters, 5.5 meters with the ceiling and floor included.

 

4. If your elevator needs to get to floor 5 from groudn floor, the script is told "move to (0, 27,5, 0) " which is the 5th floor.

 

5. The elevator then executes an "unmounting" maneuver (the only other action it can perform other than moving up and down.The maneuver eexecutes a " 0, 0, -0.25" movement (which is going "back" from where the elevator's door is facing) then it calculates distances, and wages how much it needs to add or substract to get the Y value of 0, 27.5, 0 from the floor it is at, given you pressed the 5 input on the pad by the door

 

6. The elevator climbs to 5th floor, and then it reverts the action of 0, 0, 0.25 and "docks" on the rail that the elevator is mounted on.

 

This is a rough example of a cosntruct, moving within a construct. Planets and Cosntructs are the smae in-engine. IF yo ucan move on a planet, an elevator can move inside antoher construct.

 

Multiple parts were combined, no development time was wasted on a One Use element like an "elevator element" that has no otehr use thatn being an elevator element.

 

As a bonus, you can have one door on a each floor that only opens when the elevator is mounted and an internal box door, for when the elevator is moving up and down. 

 

This design can be adjusted for loading bays on ships, or having a vehicle that is "two parter", i.e. two constructs, joined in one control Unit, like a clark (loader) machinery.

 

 

Collision, has NOTHING to do with this. If the engine couldn't handle voxels touching each other, that ship JC has shown landig on planets would not be possible.

 

Cheers.

 

 

P.S. : Same trick can be used for moving walls. Constructs within Constructs.

Link to comment
Share on other sites

  • 1 month later...

Interesting ideas.  I hope there are moving parts as I'm looking forward to using them on the planet surface, such as in a city, mining facility, spaceport, transportation, etc.

 

Give me a hinge and I can move Alioth.

Link to comment
Share on other sites

Give me a hinge and I can move Alioth.

 

Hinges are too expensive, first, lets see what you can do with this bar of chocolate...

 

On a separate tangent here, one elevator I formerly used would have a voice-over that would give the floor number it was currently at and the direction it would be going for its next call. I wonder if we'd have the option for such for elevators we create here?

 

It then spirals into the another idea, can we have player controlled intercoms (with a text to speech system or that uses an actual player voice), perhaps radio, satellite communications that could be terrestrial or between ships etc.

Link to comment
Share on other sites

I was thinking about elevators and imagine an elevator shaft from one floor to the next. Place a fuel source on the bottom of a round plate. On either side there are engines, so it would be a mini ship that could raise up and down. Place a controller and link 2 keys, one for up, and one for down. If done correctly, you could have a working elevator that can travel any vertical distance as long as it has power.

Link to comment
Share on other sites

I was thinking about elevators and imagine an elevator shaft from one floor to the next. Place a fuel source on the bottom of a round plate. On either side there are engines, so it would be a mini ship that could raise up and down. Place a controller and link 2 keys, one for up, and one for down. If done correctly, you could have a working elevator that can travel any vertical distance as long as it has power.

Actually, that's what I described earlier on. Have one of those Hover-engines below a box and rig it to push on a certain range vertically.

 

However, in order to call it down, NQ has to add "remote control", so we can call an elevator from a floor as well, without tee pad being a part of the elevator's construct.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...