[WIP] LaserComm - optical communication system

[IO]

I had a thought: we have quite a few mods adding extra planetary systems, but even the modded antennas usually struggle to reach them. There is an existing technology that would fit that niche nicely though, but is not yet represented in the KSP: laser communication.

On the plugin side: it needs more testing, but I managed to get the basic functionality working i.e. added new kind of "antenna" and link on top of CommNet. You need 2 optical terminals to connect vessels via laser link, but you can have different kind of links along the control path e.g. rover <-radio-> probe <-laser-> relay <-radio-> KSC

I also implemented a part module for tracking commnet nodes. Laser will always attempt to point at a valid relay or a ground station:

Now I'm working on occlusion: it shouldn't be possible to communicate via laser from Eve's surface or Jool's athmosphere (assuming you're using cloud mods). I want to make it so the signal gradually degrades as you descend through an opaque atmosphere.

That leaves the most dreaded part: models and textures. I gathered quite a few references, and it's not like I have absolutely no experience with 3d modelling, but not really confident that I'll be able to make nice looking ones. So yeah, help welcome.

github source if someone's interested.

 

[KspNoobUsernameTaken]

This is great! It's a useful feature not filled by existing mods, and I like the implementation.

[BSS_Snag]

This Looks Great!

[Fizzlebop Smith]

I am trying to fine tune some of the quirks in my current interstellar mod list. This looks super exciting. 

[fatcargo]

YES AND YES !

As for "most dreaded part: models and textures" - to me coding is most dreaded part

Modeling ... not such a big issue.

Does plugin have provisions for playing animations based on state of the laser comms ? Also it would be a good idea to post some kind of demonstration mesh in FBX or blender format so anyone trying to design parts can see object hierarchy, what goes where (especially transform hierarchy - i've seen people struggle to work out animations/tracking  on new models for other mods).

That's my two cents.
 

[IO]

7 hours ago, fatcargo said:

Does plugin have provisions for playing animations based on state of the laser comms ?

Right now nothing beside tracking. Depending on what's defined in the .cfg, if the laser loses its target, it either goes back to the defined rest position or just stops moving. I thought of having a deploy animation, but after looking through some references it didn't seem like I need one:

https://imgur.com/a/x6PhHaY

shouldn't be too hard to add though.

7 hours ago, fatcargo said:

Also it would be a good idea to post some kind of demonstration mesh in FBX or blender format so anyone trying to design parts can see object hierarchy, what goes where (especially transform hierarchy - i've seen people struggle to work out animations/tracking  on new models for other mods).

Good idea although in this case it just needs a heading pivot with a pitch pivot child:

Names can be changed in part's .cfg too:

headingPivotName = headingPivot
pitchPivotName = pitchPivot

Unfortunately this won't work with a more fancy setups like:

so I might play with it some more.

Edited July 14 by IO

[fatcargo]

22 hours ago, IO said:

Right now nothing beside tracking. Depending on what's defined in the .cfg, if the laser loses its target, it either goes back to the defined rest position or just stops moving.

Ohh this reminds me : IF you are using stock module to do tracking, what are its limitations ? Target distance itself may not an issue if for example using solar panel module for track since it is designed to track sun at great distances. What i see as larger issue is precision loss due to large numerical values for interstellar target coordinates (akin to floating origin errors - well known issue for planet modders). On its own it isn't much - you'll have a targeting error and thats it. BUT, problem may arise if tracking module (stock or custom) tries to perform changes close to floating point errors - visually it may produce jerky movement, constantly yanking the mesh. You could allow for greater errors still below perceptible levels and do some kind of smoothing/integrating over time for smooth movement.

Deploy/retract may not be needed if done via some other animation module, but it'd be nice if your tracker could pay attention to deployed state and allow functions only if part is deployed [NB: deploy/retract animations may be looped].
Feature request (for general modder public) : playing animations on comm status. One for established and one for stop. Also please if this is implemented, do wait for comms on/off animations to complete prior to running anything else.

Edited July 15 by fatcargo

[IO]

31 minutes ago, fatcargo said:

Ohh this reminds me : IF you are using stock module to do tracking, what are its limitations ? Target distance itself may not an issue if for example using solar panel module for track since it is designed to track sun at great distances. What i see as larger issue is precision loss due to large numerical values for interstellar target coordinates (akin to floating origin errors - well known issue for planet modders). On its own it isn't much - you'll have a targeting error and thats it. BUT, problem may arise if tracking module (stock or custom) tries to perform changes close to floating point errors - visually it may produce jerky movement, constantly yanking the mesh. You could allow for greater errors still below perceptible levels and do some kind of smoothing/integrating over time for smooth movement.

Deploy/retract may not be needed if done via some other animation module, but it'd be nice if your tracker could pay attention to deployed state and allow functions only if part is deployed [NB: deploy/retract animations may be looped].
Feature request (for general modder public) : playing animations on comm status. One for established and one for stop. Also please if this is implemented, do wait for comms on/off animations to complete prior to running anything else.

I'm not using the stock module, IIRC it doesn't support rotation limits. IDK about rounding errors producing jerky motion: I interpolate the current and the target direction via https://docs.unity3d.com/ScriptReference/Mathf.SmoothDampAngle.html so even if the former jumps around the movement should still be smooth.

About deploy animation: I had one other person asking about it, so I'll probably add it and handle it within the module.

[IO]

AO for moving parts is tricky. Compromises were made

[fatcargo]

meh its fine