New parts

[ChrisViral]

So, to bring this mod back from the grave, many things need to change. First off, those parts need to leave.

That's why I'm asking you, @sumghai :P Wouldn't trust anyone else with this but you.

The parts I would need are:

• [x] Radial attached docking camera
• [x] Radial attached docking target
• [x] Docking ring (w/ camera and target) - 0.625m, 1.25m, 2.5m
• [x] Radial autopilot unit
• [x] On screen target decal
• [x] AppLauncher icons
• [x] Flags/Agency
• [ ] Part descriptions

Optional

• Docking ring with integrated docking port

As you can see in this thread, in the video, this mod is very old, and the parts are...... I guess 'basic' would be the word.

Of course this is entirely optional, you don't have to accept. Not only that, but we are speaking of very long term, I would plan a release somewhere this summer, there's a shitton of work to do here, and I can currently test with the parts I have. Not only that, but I don't even know yet the specific things parts need to make the camera and targets work, although you could probably reverse engineer it yourself by looking at the parts in Unity.

So, if you accept, I'd be glad to partner with you for yet another mod :)

[sumghai]

The docking camera and target look intriguing, but I've got mixed feelings about the docking port and autopilot unit.

Can I get back to you on this one?

[ChrisViral]

Theres no proper dockingport. The docking ring is basically like a stack chute, with a camera on one side and a target on the other. Makes it easy to stack it just under a dockingport.

But sure, as I said Im very very far from being in any kind of rush, this is gonna take a while. I appreciate your help, as always :)

[sumghai]

Theres no proper dockingport. The docking ring is basically like a stack chute, with a camera on one side and a target on the other. Makes it easy to stack it just under a dockingport.

Oh, I see!

I was looking at some examples of docking targets last night, including any existing KSP mods. I know that tg626 made one designed to be retrofitted to the stock Clamp-O-Tron via MM, but the target is located right in the middle of the hatch.

Further research suggests that docking targets/cameras don't necessarily need to be aligned with the docking port axis - examples of offset designs include the Apollo LM modules.

As for the autopilot, have you considered just using an MM patch to add the corresponding PartModule to command pods, instead of dedicated autopilot units?

[ChrisViral]

@sumghai yes, but basically it's like a mechjeb unit. It comes with various tools and autopilot units, and it feels kinda weird to make this MM patch forced, I'd rather have it as an option.

As for the targets, yeah sure. Basically how the autopilot works is by aligning a target and a camera. You select a target on the other vessel, than a camera on your vessel, and it aligns both, moves into place, and docks. This is why its such a strong autopilot compared to MechJebs. MechJeb just sticks two dockinports together, and can't control if the rotation is correct, compared to this. This is why you usually want to have them around your dockingport so that you know the offset is right. It still works regardless however :p As long as a camera and target exists, it will try to join them together.

[sumghai]

@sumghai yes, but basically it's like a mechjeb unit. It comes with various tools and autopilot units, and it feels kinda weird to make this MM patch forced, I'd rather have it as an option.

I see - okay, I'll see what I can do.

As for the targets, yeah sure. Basically how the autopilot works is by aligning a target and a camera. You select a target on the other vessel, than a camera on your vessel, and it aligns both, moves into place, and docks. This is why its such a strong autopilot compared to MechJebs. MechJeb just sticks two dockinports together, and can't control if the rotation is correct, compared to this. This is why you usually want to have them around your dockingport so that you know the offset is right. It still works regardless however :p As long as a camera and target exists, it will try to join them together.

I believe the most recent versions of MechJeb Docking Autopilot now allows you to specify roll alignment - it's how I've been precisely aligning station parts.

[ChrisViral]

Which works, but needs to be manually inputted, unlike preset direct targeting of an in place target, which means no guesstimating :p

[sumghai]

I think I get it now:

• MJ requires you to manually specify the roll alignment
• HydroTech automates this process depending on where one physically placed the camera and docking target parts

[ChrisViral]

Yep exactly, this is part of the advantage. It can also draw a line between the camera and target, show the placement on the ships, and do a lot of things with those, reason why they're useful. Thats why having them radial attached or on a ring is better than having them in the dockingport.

I suggest you take a quick peak at the video on the mod page. It's really old (0.18), but it shows the way it works quite well.

[ChrisViral]

The old part surprisingly still work, but are unsurprisingly still... meh looking :P

[ChrisViral]

Also: I made a placeholder AppLauncher icon

That literally took me around 15mins of messing with Gimp to figure it out :/ I'm fairly sure you can come up with something much better so if you want to give it a shot, that'd be great. Could be a logo, I know you like to create fictitious KSP companies so :P

[ChrisViral]

Okay, @sumghai, here are the details:

Those lines represent the camera position and orientation. The place where all three lines meet is the position of the camera. The blue line is the forward vector, the green the up vector, and the red the right vector. Essentially, for this to work, the camera needs to have a Transform at the right location on the part, a bit like an engine's ThrustTransform. In this case, the forward, up, and right vectors must all be oriented that way. This indicates which direction the camera is facing and orients it when in camera view. It's important that the transform isn't in the part, else the camera will be obstructed.

Additionally...

The "lense" has a small cross in the middle of it (might need to zoom in to see it). I know it's referred in the PartModule, but I do not know how or why it is important to the plugin, as it seems merely as a visual aid while in camera mode. If you are absolutely certain you can integrate a similar feature while making the part look good, do it. Else, omit it, I'll figure a way to do something similar through some code.

For the targets:

It's nearly exactly the same thing except for the forward (blue). vector of the transform: it needs to point into the cross. This is important, as the mot tries to put the forward transform of the camera in the same orientation and the target's. This is what aligns the docking. No other features are needed on targets.

For both parts, there also needs a "preview" camera. I don't know if you can add random empty transforms completely outside of the part, but if so, this would be idea. The transform's location would be the location of the camera when previewing which part will be selected. Basically, in the autopilot menu, you can see all the cameras on your vessel/targets on nearby vessels, and when selecting them, the flight camera switches to this preview location, and lets you see exactly which camera/target you are selecting. This is useful for selecting, say, a docking location on a station with multiple targets. Basically, this transform needs to be "outside" of the part, have it's forward vector point towards the camera/target, and the up vector pointing in the direction that would be the top of the screen while viewing it. If this isn't possible to achieve this via a transform, it's relatively easy to manually write the position and direction vectors in the config manually, but having it done with a transform would be much easier.

As for the autopilot units, I'm thinking that only radial version would be needed, inline is superfluous.

So to sum:

• Radial autopilot unit
• Radial docking target
• Radial docking camera
• Inline docking camera+target (will be resized to all docking port diameters)
• [Optional]Docking camera+target with integrated docking port.

For the last one, I've had multiple suggestions of doing such a part, but with the other parts, is not entirely necessary. It can come in a later release without problem (like the RealChute double chutes).

Things went much more smoothly than I expected, so I'm thinking of an early/mid May release. Though again, I'm not in a rushing mood, so please take your time and go at your own pace for this :)

Let me know if you have any comments/suggestions/questions!

[sumghai]

Thanks for the notes, @StupidChris - most comprehensive.

Now that I've seen what the original part looked like and gained a rudimentary understanding of how they work(ed), I'm more determined to tackle the task of improving them, especially as the garish colors and models look really out of place in a semi-realistic space sim.

[ChrisViral]

They were alright in the days, where a lot of mods had some odd looking parts, but the modeling quality of the community work (and of the game) went up very significantly since that, so yeah, they really look out of place for now. They still work for testing purposes, but I don't think that's release worthy material.

If you want to make some form of logo/flag, whatever while you're at it, that could come in handy. Said logo could be used for the icon. For the said icon, there needs three versions: one with a transparent background, one with a red semi-transparent background, and one with a green semi-transparent background.

Like for the part, I'm letting you go free on that, you don't have to use the same colour palette or the same design idea, however, the previous owner allowed me to use previous assets, so you can inspire yourself if you want to.

Thank you again, can't wait to see what you come up with again :)

[ChrisViral]

@sumghai okay, small update, having thought of the issue with the camera's cross. Integrating it to the part will forcefully look weird in my opinion, and I know a way it could be done through code easily: A transparent texture with a crosshair design on it. Rendering that over the screen would work as an in game overlay.

I'm thinking something around the likes of this

Found this here. Don't know how it's been done in this particular case, but I have a strong feeling it must be similar.

Again, I'm letting you free with the design. Impress me :P

[sumghai]

Now that SDHI SMS and SDHI Strobe-O-Matic are out of the way, I can start working on this properly.

• I imported some of the old Hydrotech models and textures into Blender, to get a rough idea of how they worked. I think it would be best for me to add empty GameObjects representing the transforms used for guidance/docking.
• I also started researching what real-life docking cameras and targets looked like, although surprisingly there was very little reference material regarding this.
• Finally, I played around with some stock fuselages and science sensors, which would give me some ideas as to what form factor the surface-attached camera and target should be.

[ChrisViral]

Awesome, as mentioned in your thread, take your time for whatever you are doing, there is still a very large amount of code work to do before this becomes into a releasable state.

As for the old parts, they didnt even have GOs to indicate the position of the camera, this was entered manually in the config.... which is why I'm suggesting an automated way to do this.

[sumghai]

A couple of days ago I started modelling and texturing the new parts, aiming for a stockalike aesthetic so that the new parts would fit seamlessly with most KSP crafts.

First up is the new docking camera, which is based on the new STORRM system developed by Ball Aerospace for the ISS and NASA's Orion MPCV. It is the same overall size and shape as the stock Gravimeter science experiment, and is surfaced attached in a similar manner.

The slot next to the main camera lens is the 3D laser scanner array, which creates a virtual point cloud model of the target vessel to help with collision avoidance and docking. Needless to say, I've slapped on the appropriate laser warning label.

The GameObject you'll be interested in is cameraTransform, which is located just in front of the camera lens mesh, and so should not be obstructed.

[ChrisViral]

Looks very good, awesome work as usual!

Any success with creating an "outside" GameObject which could be use as an anchor for previewing the part? As mentioned, if that reveals to be complex this can be manually inputted without too much problem.

[sumghai]

Any success with creating an "outside" GameObject which could be use as an anchor for previewing the part? As mentioned, if that reveals to be complex this can be manually inputted without too much problem.

Just went back up and re-read your notes - I think I can easily add a new GO for this.

[ChrisViral]

Awesome! Make sure it's forward transform points towards the part!

[sumghai]

As requested, I've added an additional empty GO named previewCamTransform, with the blue (forward) vector pointing towards the part, and the green (up) vector pointing towards the top of the screen.

I had to futz around with some position/rotation values, but with the help of a dummy Unity camera object set to the same orientation, I was able to double-check my work:

[ChrisViral]

Looks good! I'll start testing out with this part :)

[ChrisViral]

Good news, that seems to work pretty well :) Much simpler to handle now, thank you!

[sumghai]

Next up is the docking target part, which was based on the docking target used on the ISS's PMA-2. The docking pattern is actually made up of precisely-modelled meshes, and so the quality will remain consistent even at low graphics settings. No screws or other little fixtures since we're aiming for stockalike:

As usual, the transforms you'll be interested in are targetTransform and previewTgtTransform

[ChrisViral]

Those, once more, look really awesome. Great work as usual :)

[sumghai]

Righto - for the next set of parts, I have some questions/comments:

• On the 1.25m and 2.5m docking rings, are the docking camera and target located 180 degrees apart?
• For the autopilot, would just the surface-attached box be okay? I'm wondering if it is otherwise too small to also justify having a stack version.

[ChrisViral]

1. Yes, the cameras and targets are 180 degrees apart, meaning whichever target/camera pair is docking, the orientation stays the same
2. Yeah, stack seems superfluous, so I've removed it from the list in the first post of this issue.

[sumghai]

Oh, one other thing:

Given certain rumors regarding a possible revamp of the stock rocket parts, we should bear in mind that whatever I put out, we may need to revise the art style at some stage. But we can worry about that later.

Just a heads-up.

[ChrisViral]

@sumghai well, doubt it would require us to revisit these parts seriously, but aye.

[sumghai]

Here's the new surface-attached autopilot unit:

[ChrisViral]

Consistently awesome, as usual :)

A question, though: do you plan to reuse textures/decals as done with RealChute, or is it safe for me to move the parts into their own folder?

[sumghai]

All of the parts (so far) use their own textures, but the upcoming 1.25m and 2.5m docking rings will probably share a common texture, and reuse the camera and target parts via MODEL{} nodes - so don't move them.

[ChrisViral]

Aye, I'll leave things as is for now.

[sumghai]

On the home stretch now!

I've added the 1.25m and 2.5m docking ring parts, which reuse the camera and target parts via MODEL{} nodes - the relative positioning of the latter two may need tweaking, which I will leave to your discretion.

I also tweaked the shaders on all the parts to better match the stock ones:

[sumghai]

By the way - I'll also leave part stat balancing up to you.

I'll try thinking up some funny descriptions later this weekend.

[sumghai]

Apologies for the triple-post!

I've been doing some further thinking about the docking reticle overlay, and had a look at how @TedThompson did his - I have a feeling that the ring of tick marks might not fit the design of the target used for HydroTech, but I'm at a loss for more creative ideas.

The simplest solution would be to do what is currently done on the ISS - a simple crosshair made up of alternating black and white dashes. Any indications of rotational misalignment is already otherwise handled by the patterns on the HydroTech target itself.

Thoughts?

[ChrisViral]

Again, those parts are looking great, thank you very much :)

For the reticle, yes, this is what the previous crosshair did more or less. Sounds good to me!

EDIT: Oh, also, do you think a 0.625m version would be possible? Perhaps a resize would be enough in this case.

[sumghai]

There's barely enough room in the combined docking ring texture for a 0.625m part - I'll see what I can do.

[sumghai]

...and done:

Trivia: the stock Mk0 fuselage end cap UV maps are actually only 1 pixel wide ;)

[ChrisViral]

I should give you an award. I'll check everything in game and see there's no problems then close this. If you're actually interested to do an integrated camera/target/dockingport mashup a bit like you did for your service module, with a light and whatnot, please do so and feel free to make another issue for it :) Other than that, I believe your work here is done for the forseeable future. Amazing work as usual, thank you dear friend!

[ChrisViral]

@sumghai everything looks spendid, thank you again :) Only have to work out the descriptions and ill close this

[sumghai]

Part descriptions are done! I went for a mix of KSP-style silliness and marketing mumbo-jumbo.