The Docking Paradox

[RoyalWolfe]

I know the new universe it all exciting, and it just dumped over to release, so a lot of really excited people are going to probably geek out over it for a while.

That's fine I'll let y0ou do so, because I'm right there with you. Since the old docking general discussion thread is getting a bit old, I also didn't want to zombify it, because its such a hot topic, I'm starting a new one. But, this thread is mainly going to be about the subject of long debate. lets get it out of the way first, its "The Docking Paradox" the subject of much frustration for quite a while for the game.

what is the Docking Paradox? Well, its the resulting paradox issues, resulting with the current docking mechanic of the game. It's always had its shortcomings, and also its advantages. but for a long while we have been debating over how to fix it, and really no real satisfying results, have been had for some time. so that is exactly what we are going to try and discuss here. rather than argue lets try and solve the problems by figuring out the issue scientifically. I'm going to let others start to get their say in, but I'll be back later to further discuss it when I'm done exploring the new universes.

 

[Jaaskinal]

the docking paradocks

 

[Megacrafter127]

And what exactly is the paradox thou speakest of?

 

[RoyalWolfe]

the paradox is the issues with docking and ship orientation. It works well with ships docking to other ships as always the orientation is facing the front of the given vessel which is a non issue as that the most logical way ships would dock together.

But, issues happen when trying to apply this to stations. say I have a pair of symmetrical docks facing the opposite directions. and I want them to both have ships face out. well i cant do that, because the docking orientation always makes them face one direction and only one. there have been several solutions suggested, but nothing seems to solve it.

And that's only one half of the issue. the other half is the docking points issue. the docks always use the core as orientation and docking location, which works fine for small ships just trying to simply sit level on the docking surface.

The real problem is trying to dock larger vessels. they tend to need large open areas to dock, and that's the issue, if i want it to dock I need a massive space for it to sit, and that will not let me in any way shape or form let me then make a connecting walkway to the airlock without taking the docking block offline. and hope to hell nothing bumps it during boarding. the issue simply proves the current system is for lack of a better solution not plausible for big ships.

 

[Keptick]

It's not that no good solution has been come up with yet. It's just that Schema didn't get around to doing it yet because he had more important stuff to do...

Patience (I know it's been a long ass time and I badly want directional docking too, but I know that it'll be added eventually.

 

[Ithirahad]

the docking paradocks

The docking pair o' docks... Which is one of the strange things that result from the current system, and would be resolved by point-to-point clamp docking. Currently I could make a ship or station with a docking module, dock a ship with a dock facing down towards the first docking module, dock a third ship to that second dock, and it can clip through the first entity. :P

 

[Sgtwisky]

Well my solution (as simple as I can write it) would be like follows:
1. You have the Docking blocks Docking Enhancers and Docking Point blocks.

2. Docking point block is placed at the point on your ship/turret/whatever where you want it to sit on your docking block. (no more core docking yay)

3. Docking blocks would be placed in the same manor they are now BUT would have an interface to control the direction the ship would face IN that dock. up/down, left/right, forward/back.

4. Docks would use mass to calculate weather a ship is too big or small to dock. Enhancers could be used to create the default value. I would suggest that the mass could simply be calculated in a cubic format. so the standard 7x7x7 (or what ever dock) would have a mass of 343. SO the cubic space we have now would be converted into mass.

5. Lastly a check is made to see if any part of the docking ship is colliding with the entity its docking too. It would have to do a pre docking check when you try to dock and return false if you are going to collide. The collision detection is there already for entity to entity so this shouldn't be too difficult to transpose coords for ships and check if they would collide without actually having to do physics upon the collision.

There... you can dock in any orientation you want. You no longer have to worry about a bounding box stopping you from making walkways and you still have to use more blocks to allow for larger ships.

I dub this as "Omni Docking".

 

[Ithirahad]

5. Lastly a check is made to see if any part of the docking ship is colliding with the entity its docking too. It would have to do a pre docking check when you try to dock and return false if you are going to collide. The collision detection is there already for entity to entity so this shouldn't be too difficult to transpose coords for ships and check if they would collide without actually having to do physics upon the collision.

Unfortunately, this IS a problem, and is probably the main reason why we have the "no-building box" currently. The fix/workaround for this is simple, though - Docking should be accomplished with "magnetic clamps" or something similar, which have to actually make contact with one another's docking faces to attach. This way, the silly-looking "teleportation docking" and "Docking Beam" are removed, AND it no longer is it impossible to have extending ramps, tubes, or whatever else you want to use. In fact, a community-standard 3x3 docking tube configuration could be created, with the docking clamp right above it.

 

[Winterhome]

As much as I love the idea of having docking clamps, I imagine it'd be a bit difficult to code.

Could just add an indicator of direction to the texture for the docking modules, and give them the same number of orientations as corner blocks, as a temporary method.

Also: Vertical launch docking and upward facing turrets please.

 

[Ithirahad]

As much as I love the idea of having docking clamps, I imagine it'd be a bit difficult to code.

Could just add an indicator of direction to the texture for the docking modules, and give them the same number of orientations as corner blocks, as a temporary method.

Also: Vertical launch docking and upward facing turrets please.

Compared to some suggestions, no, it shouldn't actually be that hard to code (Detect collision, calculate relative position, "boop" or maybe smoothly slide into position)... But yeah, I agree with the rest of that.

 

[Winterhome]

Compared to some suggestions, no, it shouldn't actually be that hard to code (Detect collision, calculate relative position, "boop" or maybe smoothly slide into position)... But yeah, I agree with the rest of that.

It's still a form of multi-block collision detection between multiple ships.


I suppose one could theoretically do it by making a closed loop of docking ring modules that projects a detection box outwards from the directional face, and has an ID assigned based on the shape of the loop. That way it can check for collisions *only* with docking detection boxes, and then only dock with the matching detection box if it has the same ID or an inverse of the same ID (same shape but with the docking modules facing the other direction). Basically, just check to see if the modules can be somehow made to fit eachother snugly at the rotation of the ship attempting to perform the docking operation.

If the ships are moving slowly enough, then apply a gentle force in the direction of the docking modules and "snap" them together (without the derpy half block gap - if necessary, one can just set undock position a half block away from the parent object).

 

[Ithirahad]

It's still a form of multi-block collision detection between multiple ships.


I suppose one could theoretically do it by making a closed loop of docking ring modules that projects a detection box outwards from the directional face, and has an ID assigned based on the shape of the loop. That way it can check for collisions *only* with docking detection boxes, and then only dock with the matching detection box if it has the same ID or an inverse of the same ID (same shape but with the docking modules facing the other direction). Basically, just check to see if the modules can be somehow made to fit eachother snugly at the rotation of the ship attempting to perform the docking operation.

If the ships are moving slowly enough, then apply a gentle force in the direction of the docking modules and "snap" them together (without the derpy half block gap - if necessary, one can just set undock position a half block away from the parent object).

I think you're thinking too hard about this... Imagine it this way... A magnetic clamp, when active, would create a 1-block collision space in its intended connection direction, which would only detect collisions from other "collision fields". If it detects one, the two stick together according to the cardinal-directional way closest to how they're oriented.

 

[Winterhome]

I think you're thinking too hard about this... Imagine it this way... A magnetic clamp, when active, would create a 1-block collision space in its intended connection direction, which would only detect collisions from other "collision fields". If it detects one, the two stick together according to the cardinal-directional way closest to how they're oriented.

Perhaps I am.

I was thinking along the lines of how warp gates detect whether they're a closed loop or not.

 

[Sgtwisky]

Ithirahad, I may be wrong but is it not the actual physics actions that take place during a collision that cause the lag? NOT the simple checking of IF a collision exists? I am not suggesting to preform the entire collision as it is, but rather calculate if it would hit or not once in its docking position. it could easily be done with a very simple version of collision, NOT the current model. I have seen it done simply though in Non-voxel games. I am assuming that a method could be used to check if the objects would overlap. If not allow docking, if so do not allow docking (and thus no need for actual collision and the physics which is what causes most of the lag).

I am not a programer by trade but have written a few smaller programs and delved into some basic game programing. I am pretty sure it can be written similar to what I have described without much hit to CPU/GPU power. An example of this would be seeing if 2 entities are colliding when collision is off. Basically they "ghost" through each other. You would notice almost no hit to CPU power because your only checking if they overlap. NOT actually taking actions based on the overlapping. I am imagining this code being a separate thing from the "real" collision.

Then again, like I said I am not a pro when it comes to code and I can only go based off of what I have studied. It is very possible that in a voxel type game this method becomes much harder to use. But to my knowledge it is possible.... though would take quite a bit of work.

 

[Ithirahad]

Ithirahad, I may be wrong but is it not the actual physics actions that take place during a collision that cause the lag? NOT the simple checking of IF a collision exists? I am not suggesting to preform the entire collision as it is, but rather calculate if it would hit or not once in its docking position. it could easily be done with a very simple version of collision, NOT the current model. I have seen it done simply though in Non-voxel games. I am assuming that a method could be used to check if the objects would overlap. If not allow docking, if so do not allow docking (and thus no need for actual collision and the physics which is what causes most of the lag).

I am not a programer by trade but have written a few smaller programs and delved into some basic game programing. I am pretty sure it can be written similar to what I have described without much hit to CPU/GPU power. An example of this would be seeing if 2 entities are colliding when collision is off. Basically they "ghost" through each other. You would notice almost no hit to CPU power because your only checking if they overlap. NOT actually taking actions based on the overlapping. I am imagining this code being a separate thing from the "real" collision.

Then again, like I said I am not a pro when it comes to code and I can only go based off of what I have studied. It is very possible that in a voxel type game this method becomes much harder to use. But to my knowledge it is possible.... though would take quite a bit of work.

That's kind of what I was saying; it would be a (very simple) collision CHECK but the actual 'fields' wouldn't collide. I was just trying to simplify it as much as possible and I think I ended up missing the specifics of my point in the process. :P

 

[Malacodor]

It works well with ships docking to other ships as always the orientation is facing the front of the given vessel which is a non issue as that the most logical way ships would dock together.

I disagree here, sideways docking is more logical in connection with sideways facing hangar doors, which is better than front doors, since doors are a weak spot, and a ship's front is usually the most endangered part.

3. Docking blocks would be placed in the same manor they are now BUT would have an interface to control the direction the ship would face IN that dock. up/down, left/right, forward/back.

Actually there are 24 different possible orientations.

5. Lastly a check is made to see if any part of the docking ship is colliding with the entity its docking too. It would have to do a pre docking check when you try to dock and return false if you are going to collide. The collision detection is there already for entity to entity so this shouldn't be too difficult to transpose coords for ships and check if they would collide without actually having to do physics upon the collision.

The current docking boxes avoid costly calculations, but collision checks for docking needn't be done in real time. The docking process could be stretched out across several seconds to keep the amount of calculations per second low. This would be even more realistic than the current instant docking.

 

[KiloZulu]

I think the magnetic clamps idea is great and it sounds like the solution I was thinking of. Have a specific block for docking that matches up to another block of the same type from a different ship. This would allow players to locate their docking locations wherever they would like on a ship, and make it so that the pairing ships are always orientated in the way they want. It seems like all the mechanics for making this happen are already in place. That way a player can walk directly from one ship into another through a standardized docking port rather than having to spacewalk after docking.

Regarding the paradox, I don't have a big complaint about ships not being able to orientate properly with space stations. I know it isn't realistic, but at the same time I think of Star Trek where the capital ships didn't dock with the space station and instead used teleporters and shuttles to transport people and materiel.

 

[Sgtwisky]

Actually there are 24 different possible orientations.

I meant that the entity could be oriented according to the entity it is docking to in the directions I stated. You would still place the block with the docking face in the meaner you do currently. SO although there are many possibilities (I think its actually 6 directions for block and 6 for entity for total of 36) Each is a separate operation from the other. You first place the block with its docking face where you want it. THEN access it with "R" and determine the facing direction of whatever docks in relation to the front of the ship. so front would face the docking entity toward the forward portion of the ship. the player deals with 6 possibilities followed by the other 6. You would not need an interface for all 36 possibilities.

 

[aceface]

Honestly I think we do not need enhancers and you can dock as long as the ship does not collide with anything within its dimensions. The place where the ship docks should be at the center of the ship not at the core - to enable more compact docks.

 

[Malacodor]

I meant that the entity could be oriented according to the entity it is docking to in the directions I stated. You would still place the block with the docking face in the meaner you do currently. SO although there are many possibilities (I think its actually 6 directions for block and 6 for entity for total of 36) Each is a separate operation from the other. You first place the block with its docking face where you want it. THEN access it with "R" and determine the facing direction of whatever docks in relation to the front of the ship. so front would face the docking entity toward the forward portion of the ship. the player deals with 6 possibilities followed by the other 6. You would not need an interface for all 36 possibilities.

There are 24 different orientations possible, relative to the ship as well as relative to the docking block. A ship's front can point in 6 different directions, but it can be oriented normal, bottom up or on the left/right side. Two different ships could have the same orientation, but one is sitting on a docking block while the other one is hanging from the ceiling.