External Docking

[Cholmondely]

I've whinged on about this one at length...



Query: IS the difficulty in allowing External Docking tied in with the dock needing to be along the Z-azis of the station?

And... Are there other issues too?



Nuit station with inoperative red-lit "external docks" for liners and functioning z-azis docking tunnel at the top, hidden at the back.




Edited to add my reference for the z-axis statement (Svengali's unfinished wiki tutorial)

[Killer Wolf]

as far as my experimentation goes, you can have a dock anywhere on a model but it has to be at the origin [0, 0, 0,] point - so you could place it at the end of one of those arms, but you'd have to shift the model back to get the dock to be at the origin. this is fine for static stations but i believe would cause movement problems if, eg, you wanted an aircraft carrier type thing, at the ship's axis would not be aligned correctly. {see edit]

another issue is needing an actual dock item, so unless you can make an item invisible, the Nuit would have a box stuck at the end of the arm.

aside from that, for NPCs, i'm guess the game engine would disappear them, if it ran the dock procedure, so that mighta defeat the purpose?

EDIT - had a quick look at the Nuit, and i was misremembring; you have to model the dock at Origin, but you can shift it around using the subent placement co-ordinates in the shipdata.plist.

[Cholmondely]

Just ratiocinating about managing External Docking.



There would seem to be two different issues.

1) Docking.

2) Displaying the docked ship.




Might the first be very simply solved by projecting the docking "port" just a little in front of each of the external docks? With some sort of limitation that you have to be travelling very slowly to actually dock, and at the right angle (as for Planetfall - or maybe even Towbar - and a mistake could result in some "hull damage" to one's ship).

And one could restrict this to just one of the Nuit docks if the z-axis is a genuine limitation (but what about cim's multiple docking oxp?).


And might not the second be managed by using some of the code from Towbar OXP? I'm thinking in terms of the External Views.




Edited to add note about External Views

[cbr]

I remember something about it to have to be scripted,
I believe fuel stations use this technique, you have to be at a certain position to obtain the fuel.

[Switeck]

Proximity-checking but to make a ship look like it's docked it needs to be so close it risks math-rounding error collisions.

[phkb]

For the external docks, we’re not talking about allowing the player to dock, are we?

[Cholmondely]

Why not?

[phkb]

Why not?

Well, I was thinking that an easy way to make it look like the large ship docking ports are in use would be to add some subentities to the station model, positioned in exactly the right spot as if they had docked. Then a script could randomly turn off some of them, leaving you with the appearance that some large ships have docked. Obviously, it's a bit of handwavium "Yes these big ships docked here, totally, 100% for realz", but it would look OK. And avoid the whole collision detection thing.

[Cholmondely]

Why not?

Well, I was thinking that an easy way to make it look like the large ship docking ports are in use would be to add some subentities to the station model, positioned in exactly the right spot as if they had docked. Then a script could randomly turn off some of them, leaving you with the appearance that some large ships have docked. Obviously, it's a bit of handwavium "Yes these big ships docked here, totally, 100% for realz", but it would look OK. And avoid the whole collision detection thing.

Quite bluntly, anything is far, far better than the nothing which we have at the moment.

(Might this also involve a tweak to BigShips?)

But I'm hopeful about a number of things.

More possible activities for the player: eg. a more realistic Ooniverse. Or the ability to dock with a much more modest rock hermit than our Griffian Rolls Royce models. Or for players flying large ships (Andromedae/Behemoths/Hiranic Imperial Star Destroyers etc.) to actually dock rather than take a shuttle. Not to mention docking with Nuit and whatever else might hopefully be created.

If we can provide the tools, then others can come along and make use of them, enriching the Oolite experience for each and every one of us. It does not of course mean that it will happen. Butterflies, SOTL, Scenario.plists, Multiple Docking... all have yet to be embraced and developed. But on the other hand, many other things have been. Telescope, Bulletin Boards, MFDs, shaders and gloss/specular maps etc.

When I look around the miserable world we live in, Oolite is possibly the only area in which I've seen progress.

[cbr]

avoid the whole collision detection thing.

Eg. external 'parking'
a] Let's say 90 degrees from the line buoy -> station at a safe distance from the station would this be a difficult position to calculate?

b] Perhaps in the vicinity a docking buoy, initiate cargo/shuttle/taxi traffic between ship and station.

c] parallel parking along a]

[Switeck]

Some stations have external lights that light up the docking port's entry route...so how about a "force-field" tunnel from a ship into the station's docking bay that's only a "hologram" as far as collisions are concerned?

[Commander_X]

[...]
Query: IS the difficulty in allowing External Docking tied in with the dock needing to be along the Z-azis of the station?
[...]

A quick rant about the z-axis stuff:
- in OpenGL there is no real "camera movement"
- a whole OpenGL scene is always presented through a "camera" that's located at world's origin, and looking along Z axis, having the "up" orientation along Y axis
- "moving a camera" in OpenGL is done by moving all the entities in the scene to match the intended effect
- the ship in Oolite "follows" the camera "movement" (that is, it's stationary in the OpenGL world), thus is always aligned to the world's Z axis
This definitely simplifies the math necessary to check the docking conditions when the dock's alignment of its Z axis matches the station's Z axis (e.g. when the docking distance threshold is met, you only check for the alignment of the station's Z axis with the OpenGL world's Z axis).

[Cholmondely]

[...]
Query: IS the difficulty in allowing External Docking tied in with the dock needing to be along the Z-azis of the station?
[...]

A quick rant about the z-axis stuff:
- in OpenGL there is no real "camera movement"
- a whole OpenGL scene is always presented through a "camera" that's located at world's origin, and looking along Z axis, having the "up" orientation along Y axis
- "moving a camera" in OpenGL is done by moving all the entities in the scene to match the intended effect
- the ship in Oolite "follows" the camera "movement" (that is, it's stationary in the OpenGL world), thus is always aligned to the world's Z axis
This definitely simplifies the math necessary to check the docking conditions when the dock's alignment of its Z axis matches the station's Z axis (e.g. when the docking distance threshold is met, you only check for the alignment of the station's Z axis with the OpenGL world's Z axis).

Fair dibs. But then what about cim's multiple docking oxp?

[Commander_X]

[...]
Fair dibs. But then what about cim's multiple docking oxp?

Should be the same. As long as they are aligned with the Z axis of the station, their position doesn't really matter. When the docking is triggered, only the corresponding docking box' alignment with the ship/camera (i.e., the OpenGL origin) is checked. That's the reason a docking box is an "entity" in the Oolite's world and on the associated station/structure -- it moves around the ship/camera (suggesting the ship is moving around), but it must be aligned with it at docking time. Checking that alignment only on the Z axis makes the math simpler.
Use as much salt you need with these statements (I didn't actually went through the source code to confirm), but "camera handling" in OpenGL is one of the trickiest operations, usually handled behind a very thick wall of math. Getting any deeper than this would get us to the real "matrix" world of OpenGL, which is not nice, to say the least.

[Cholmondely]

[...]
Fair dibs. But then what about cim's multiple docking oxp?

Should be the same. As long as they are aligned with the Z axis of the station, their position doesn't really matter. When the docking is triggered, only the corresponding docking box' alignment with the ship/camera (i.e., the OpenGL origin) is checked. That's the reason a docking box is an "entity" in the Oolite's world and on the associated station/structure -- it moves around the ship/camera (suggesting the ship is moving around), but it must be aligned with it at docking time. Checking that alignment only on the Z axis makes the math simpler.
Use as much salt you need with these statements (I didn't actually go through the source code to confirm), but "camera handling" in OpenGL is one of the trickiest operations, usually handled behind a very thick wall of math. Getting any deeper than this would get us to the real "matrix" world of OpenGL, which is not nice, to say the least.

Thank you for this.

Question: I've read oodles of stuff on these bulletin boards emphasising that part of the non-player centredness of Oolite was that the ship actually moves unlike in Classic Elite where is it stationary and everything else moves towards it. Your oolite ship moves inside the Ooniverse (rather than the universe moving around your ship - as in the game coding in Elite).

What you just stated seems (to me) to contradict this.



Reference: Winston 2005:
What do I mean by player centric? Well, in the Elite universe, the player was always at the cartesian coordinate (x,y,z) of 0,0,0 and was superglued to that location. The player never actually moved. The player in fact always faced the same way. What happened was the universe revolved around the player - literally (Skip the bad jokes about the Brabster!). Roll the ship, and the entire universe rolled. Pitch and the entire universe pitched. Switch to left view, and the entire universe instantly yaws by 90 degrees. You didn't fly to the planet, the planet came to you. A player centric system like this is utterly impractical to make multi player (it COULD be done by translating the coordinates of objects before displaying them, but it would be a monumental pain in the arse).

Oolite on the other hand is not player centric. I think 0,0,0 is the witchpoint beacon (I could be wrong, I've really not looked that deeply at those bits of the code). Everyone would have a common frame of reference and a common origin. That already makes the job 100 times easier.