Point to Point Docking

[Jegan Reavus]

The problem is that you only get one "core proxy." Perhaps it should be linked via cameras instead, so that way you can have a proxy by your docking ports on each side.

In my imagining of this, you could have multiple core proxies. In the 6th paragraph of my text wall, I describe the docking system behavior if multiple proxies are defined.

The idea with multiple proxies is that the closest one on your ship to the dock you are trying to attach to is the one that gets attached. If you had multiple proxies on your ship (say one on each side, as I do on many of my vessels) you are going to probably try to align one or the other to the dock a little bit prior to attaching. This is even easier if your using a cockpit to help align the docking port on a particular site. It happens naturally.

You could also have one on the bottom of your ship to allow it to land on a pad or some kind of you wanted to.

 

[DivineEvil]

I'll be the one who doesn't think this is a good idea. I feel docking area method a feasible one as it is now, with three exceptions:

1. Ship docking must be performed based on ship's dimensional centers, and not tightened to ship's core in any way.
2. In case of turrets, core indeed should be used as a turning pivot, thus being placed exactly above the turret docking port, but there's no point to restricting any blocks placed below it. Turret dimensions can be used to determine turret's area of freedom to avoid excessive clipping.
3. Both ship and turret docking port has to be changed to increase their 6-directional rotation up to 24-directional margin (same margin used by Corner hull blocks), which would allow to determine the direction of turret/ship facing direction when docked.

If these points are satisfied, I see no reason for any additional changes.

 

[Ithirahad]

I'll be the one who doesn't think this is a good idea. I feel docking area method a feasible one as it is now, with three exceptions:

1. Ship docking must be performed based on ship's dimensional centers, and not tightened to ship's core in any way.
2. In case of turrets, core indeed should be used as a turning pivot, thus being placed exactly above the turret docking port, but there's no point to restricting any blocks placed below it. Turret dimensions can be used to determine turret's area of freedom to avoid excessive clipping.
3. Both ship and turret docking port has to be changed to increase their 6-directional rotation up to 24-directional margin (same margin used by Corner hull blocks), which would allow to determine the direction of turret/ship facing direction when docked.

If these points are satisfied, I see no reason for any additional changes.

...Do you not want to be able to extend docking bridges to and from your ship? Do you not want to be able to dock to the side of a station and walk between the two without having to have a complicated, special setup to do so? And do you not want a docking system that doesn't require fiddling with enhancers trying to get the exact right dock size?

 

[Jegan Reavus]

If these points are satisfied, I see no reason for any additional changes.

I agree that your suggestions would greatly improve docking as it is currently, and would gladly take those changes over what we have now.

The downside is it would provide nothing extra/no added benefit over just fixing what's currently there. The reasoning behind the meat of my suggestion was to add an extra dimension to docking to open up new gameplay possibilities.

Actually, I think best case scenario would be to apply your suggested changes to the base system to fix what's already there, then add the extra functionality to make docking more flexible/useful

 

[DivineEvil]

...Do you not want to be able to extend docking bridges to and from your ship?

Don't think its worth the effort. At least it isn't something that should be suggested at the given time.

Do you not want to be able to dock to the side of a station and walk between the two without having to have a complicated, special setup to do so?

I just don't need it. All my ships has their gateways at the edge of the shortest dimension a ship has (usually). Im already building docking areas for specific ship classes of specific dimensions and has hallways directly connecting to their hatch. The only problem for me is that I can't change the facing. There's no complications here, unless you have a sausage with thingies protruding in every direction, and you can solve it with doors, sine they are undestructible when open. In practice barely anyone would use conventional walking to get into the ship anyway.

And do you not want a docking system that doesn't require fiddling with enhancers trying to get the exact right dock size?

Somehow I don't see an ordinary math as a problem. Lets say your ship's width is 89m, height is 43m and length is 347m. You take each figure, subtract 9 and then divide by two. (89-9)/2=40. (43-9)/2=17. (347-9)/2=169. So, you place first block of docking enchancer and add 40 blocks to direction representing width, 17 blocks in one representing height and 169 blocks in one representing length relative to the direction your ship faces when it is docked.

That makes you a perfect match docking area for your ship. It can be 3D cross, corner, randomly joined rods, diagonal line, curve - whatever works for your station, as long as the cluster (similar to power reactors) occupies a given dimension as a whole. It can be hidden in walls and floors, decorated as antennae or tubes. Where is complexity in it that I don't see?

The downside is it would provide nothing extra/no added benefit over just fixing what's currently there. The reasoning behind the meat of my suggestion was to add an extra dimension to docking to open up new gameplay possibilities.

Actually, I think best case scenario would be to apply your suggested changes to the base system to fix what's already there, then add the extra functionality to make docking more flexible/useful

I'm judging on a basis of required resources and technical difficulties placed against said 'extra benefits'. Developing a system that would allow to dock a ship of any size and proportions on a single block, which also makes ships easy to handle without additional expenses, that would calculate every block of a station or planet against every block of a given ship including its turrets, which alone can produce terrible lag spikes, just for a benefit to allow people to board a ship on-foot with no difficulties or concerns, from my imagination and common sense is not a fair trade.

 

[ltmauve]

All my ships has their gateways at the edge of the shortest dimension a ship has (usually)

That's nice that you limit your designs like that. The rest of use would like to dock our ships to the side of our stations.

In practice barely anyone would use conventional walking to get into the ship anyway.

And how would they get to the ship, admin powers? Are you a singleplayer or server type of person?

that would calculate every block

That's certainly an exaggeration. You can start out by checking to see which chunks overlap and have data, and then compare the blocks in those. Much simpler and faster.


BTW, another change I'd like to see to docking: Ships dock snug (no gap between them) and then when they undock they teleport up half a block.

Also, can we get it so that we can freely place nonphysical blocks inside docking areas, and we can place doors in docking areas as well?

 

[DivineEvil]

That's nice that you limit your designs like that. The rest of use would like to dock our ships to the side of our stations.

Then use the doors. Or place docking port in a small sphere/cube below the desired area and make a bridge coming to the side of the ship. It's not like enchancers has to be anywhere near the parent docking block.

And how would they get to the ship, admin powers? Are you a singleplayer or server type of person?

Get in the core, fly it to the ship, open the blast door with a docking beam and fly trough to the ship's core.

That's certainly an exaggeration. You can start out by checking to see which chunks overlap and have data, and then compare the blocks in those. Much simpler and faster.

Yeah, and any idiot can keep firing at docking port with random large ship and lag the server to oblivion in repetetive calculations. And it will be funny to see people's raging when someone places their ship on docking port for smaller ships obstructing stuff.

 

[Jegan Reavus]

Yeah, and any idiot can keep firing at docking port with random large ship and lag the server to oblivion in repetetive calculations. And it will be funny to see people's raging when someone places their ship on docking port for smaller ships obstructing stuff.

You do make a good point here. This could potentially be an issue. By the same token though, I don't think the potential for abuse is a good enough reason by itself to just dismiss an idea completely. For example, if the dock really was intended for smaller ships, you could still use a dock with a fixed size, so that ships larger than that would not be able to dock there.

The lag spikes are really the killer issue here... While I think it's a solvable issue, if it could not be handled, then my idea doesn't work. However, I don't think this operation would actually be all that expensive. I'm not sure how Schema is currently handling collisions, but if it were me, I would probably approach it like this:

1. Determine dock points and orientation
2. Take max dimensions of both dock targets, corrected for new position and orientation.
3. Get a list of the chunks each would occupy, based on max dimensions
4. Remove any chunks with no data in them from the list.
5. Intersect the lists to find chunks where intersection is possible
6. Iterate through the remaining chunks to find any instances where both ships occupy the same space. The first instance of this that is found stops the process and cancels the dock.

Based on what I understand of the Schine engine, steps 1-4 are all basically free because this information is already tracked. For step 5, if there is no collision then the intersection is fast and produces an empty result, the ships don't intersect, and the dock is successful.

If the ships do intersect, the intersection list contains the smallest number of chunks where intersection would possibly occur. The iteration would be the most expensive part, but there are algorithms out there to make the search faster. Even so, I don't think it would be all that expensive, but it's an open question.

Worst case scenario is an oddly shaped ship with an equally oddly shaped dock (like intersecting loops, or figure-8s or something) that require checking a large number of chunks. Even so, performing an intersection check between the chunks themselves should be decently quick.

It's important to note that most of the lag we currently see from collisions comes not from the actual collision calculation, but from the result of that calculation. Namely because:

1. Collision results (I.e. applied forces, motion etc) are currently 100% elastic. This means that there's no loss of inertia during collision between the two bodies, which results in lots of 'bouncing' and secondary collisions. These increase the number of calculations and thus lag, especially at high speed.
2. The collision calculation is probably being redone at least every frame, and if a collision is detected again, the whole frame basically gets trashed, and needs to be re-rendered, which leads to...
3. Ship collisions must also be rendered, in real time. Rendering is almost always the most expensive operation in any graphical application, especially a game like this.

Since docking calculations wouldn't need to care about most of those last three items, I think we would be in the clear.

 

[Malacodor]

I'm not sure how Schema is currently handling collisions, but if it were me, I would probably approach it like this:

1. Determine dock points and orientation
2. Take max dimensions of both dock targets, corrected for new position and orientation.
3. Get a list of the chunks each would occupy, based on max dimensions
4. Remove any chunks with no data in them from the list.
5. Intersect the lists to find chunks where intersection is possible
6. Iterate through the remaining chunks to find any instances where both ships occupy the same space. The first instance of this that is found stops the process and cancels the dock.

I say it doesn't really matter how much CPU power docking calculations require, simply limit calculations per time, and there won't be any lag. The only downside would be docking not being instant anymore, but that's unrealistic anyway.

 

[Jegan Reavus]

I say it doesn't really matter how much CPU power docking calculations require, simply limit calculations per time, and there won't be any lag. The only downside would be docking not being instant anymore, but that's unrealistic anyway.

Not sure why, but your quote attribution is incorrect...

Anyway, yes calculations can be broken up, but whether or not that's even needed is an open question. I'm making a LOT of assumptions on how collision calculations might work, so I'll leave it up to many more knowledgeable people as to how/if something like this might work.

Actually implementing this site of system might even get us more efficient and realistic collisions in the game as a side effect... That might be nice!

 

[Malacodor]

Anyway, yes calculations can be broken up, but whether or not that's even needed is an open question.

I think it's the best way to safely prevent lag and abuse.

Not sure why, but your quote attribution is incorrect...

I blame the forums. :p