[Dev Asks] Brainstorming: Ship to Ship logical link and messaging

[tsunamayo]

So I have quite a few things on my bucket list, being able to link ship logically and trigger command by distance being one of them.

So lets brainstorm a bit!

Typically what is not clear for me is the User Interface, basically how to interact with the thing! Like if you have several command actionable from remote on a ship, how do you pick which command to activate?

1) First I would like to hear what you guys needs this system for. On my side as I will tackle ship mag-lock soon I would say this: => Activate or desactivate a mag-lock built on the master ship from the children ship. 2) How other game are doing that. 3) Then me your proposed solution! => for example I think we would need a gate similar to the hotkey with:

• a range setting
• friendly only toggle or code of some sort
• maybe a tag system of some sort?
• a name Then to activate it remotely a button or terminal. A terminal with UI windows will be easier to pick what to activate. In case of a button we could pick the closest gate matching the gate criteria (matching the tag define in the other gate). It seems harder to implement compared to simple UI one.

Thanks!

[EndoSkull]

Not sure what you're exactly going for - as in is this a one off kind of thing - or is it to be super flexible?

For example Stormworks (have you dove into it? if not just watch a few tutorials on t he logic system) The initial system was logic gates - but has evolved into microcontrollers that use logic and lua scripting - pretty much can do anything you want - for interactions between vehicles you have to create a chip that uses composite channels and send data via ingame antenna

If you're looking to do a one off easy to use drop in component - to me it seems like a block that has easy to use settings - I assume each entity in the game has an id - you could set an id on the chip - the chip would read logic on the entity when it comes to hotkeys door buttons etc - and you could possibly map that to your main ship (I'm assuming we trying to control secondary ships from a main one?)

You could then have nodes on the chip that you have set defaults to - and these nodes are labeled and drag out to various buttons - sliders or even a yoke.

Not sure if this helps - just off the top of my head I'm sure you've had more thought and insight to your goal.

[tsunamayo]

So yes the big question is do you want to make a system where you need to preset things in advance, or something generic, ie you approach a new ship and you are able to interact with any of its remote logic input?

[Drillz007]

I think something like an AOE radio signal would be good say you have a sender block and a receiver block the sender pings all receivers in X radius with a code and the receivers after receiving the correct code will activate or deactivate mag locks

with this you could set up a chain of actions all tied to what ever you decide to send via your radio transmitter (or is it transponder?) this can potentially be tied into AI commands even

thing is we have a very direct and not menu orientated logic and control system so it would be a bit strange to be able to use the functions on a ship through a menu all of a sudden

[BrickMacklin]

I wouldn't want to be able to approach any ship and remotely use its logic. I thank that is something that should be setup with the user's ship

[tsunamayo]

@BrickMacklin of course you could setup some privacy setting for sensitive settings. Like you need a special code, or ship needs to be on the same faction ect.

[talrey]

Two things I think would be good:

• a remote joystick, for taking command of an "entered" system like a camera or yoke remotely.
• a remote hotkey, for triggering generic logic remotely.

Maybe a third brick to be the actual "remote transceiver" where you would link the joystick and hotkey as inputs if you wanted them sent to the remote ship, and linked as outputs if you wanted them to be received from the remote ship.

As for actually configuring the channels / security / privacy, I'm reminded of a really clever mod for Minecraft called "Create", which includes remote redstone transmitters. They had "frequency settings" in the form of two displayed items - you right click on the transmitter with an item or block and the transmitter would show that item or block, using that as the "channel" it would communicate on. Only other transmitter / receivers with the same item or block interact. Here's a pic of them I grabbed from the mod's issue github: Redstone Link

I'm not saying we need to be quite so simplistic in Starship EVO, it is the future after all. Still, I like how easy the mod makes it to set up a channel, or identify what channel something is set to. Maybe our version of that could be painting the transceiver?!

It does limit the number of channels, but in Create there's two item displays on a Redstone Link to make a unique channel, so given how many items and blocks are in Minecraft... that's a lot of combinations!

[talrey]

Oh, I forgot to say what I would use this for, I suppose. One word: Drones!

Mining drones for gathering resources to a central processing rig, combat drones with a carrier, exploration drones like they use in deep-sea missions today... so much is possible.

Also, I would definitely set up hangar controls on a carrier or station, so that docking ships could "tune in" and tell the station to open a hangar bay door or light up the landing pad.

[Crimix]

I would use it to build a hyperdrive ring. to use with fighters. Like the Delta 7 Jedi Starfighter.

Could it be something like you have buttons on your ship which will only be active if you are docked or close to another ship.

My idea of course also has the idea for the galaxy map to interact with the warp system on the ring

[fellow-starmadian]

Introduction:

Starmade had a very simplistic and robust wireless logic system. It was a single block akin to an OR gate, that could be selected, and then connected to any other wireless block on any other ship you had build permissions on. that solves any issues with security and means the only issue would be that the ships have to be close enough for you to connect the wireless blocks. Im finding it hard to understand the idea that these will transmit wireless data instead of a simple 1 / 0. But I understand that the confusion comes from how you have implemented "logic" meaning that there is both simple 1 / 0 boolean logic and what is essentially serial cables that transmit complex data for implementations like the yoke system.

Basic idea:

My TLDR idea would be to create a simple boolean wireless block that acts like an OR gate, then create a more complex one that can be used more generally, for things like remote control or for the 0.0 to 1.0 values things like the sliders use.

How boolean logic worked in Starmade with relation to ship systems:

As for ways these systems can be used, it all depends to me on what boolean logic can actually have access to. To use Starmade as an example again for what boolean logic could interact with: -Boolean logic was capable of converting ASCII using regex modifiers embedded in display modules to modify other display modules. -Could use sensors to detect system levels (including cargo) on a ship and return a 0/1 pulse if a certain threshold was reached (EG shields >=49% returns 0, but shields >=50% returns a 1 if the system was set to look for 50% shield level). Used a sensor block that was connected to an array of switches that could be toggled manually or through logic connections to change what percentage it looked for. -Controlled the speed and direction of rails and rotors by using a rail speed controller connected to an array of switches to control percentages similar to the sensor mentioned above. -Control the firing of any systems controllable by the player by just triggering the firing cycle.

How a wireless block increased this functionality:

The wireless system in the game could control and get data from all of these types of things, and transfer them to other systems on other ships. Some examples for things that were possible and utilizable by the wireless block: -Turrets that activate a sensor when they move to track an enemy and therefore created a warning system. -Squad system levels such as shield, hull, energy and the like, visible by all other squad-mates utilizing sensors, regex displays, and wireless blocks. -Automated teller systems that could communicate their values for resources through a network utilizing sensors connected to storage silos. -Ship communication networks for homebrew HUD communications that can be placed anywhere in the cockpit and be completely secure compared to a global chat, or have any type of info that isnt compatible with global chat. also safe from moderators snooping on private conversations XD.

Conclusion:

These are just the ways I could think of off the top of my head, but if all you added a sensor block and a "quantum tunneling" wireless block, most of this would be possible for this game as well.

Apologies:

I have no idea how to structure this so please excuse the wall of text lol

[talrey]

Huh, I'd never seen those expandable bullet point things before, that's cool tech.

Something that hit me while reading the other dev-ask: if we could link "docking connectors" like yokes, then a ship that's docking to transfer fuel or cargo could also transmit logic or control signals through that same connector.

Ex: a small mining ship enters a carrier's hangar and docks to offload the ores it's collected. The mining ship has a "remote hotkey" linked from the pilot yoke to the "docking connector". The carrier has a "remote hotkey" linked from its own "docking connector" to a rotor underneath the docking platform.

The pilot lands and initiates the ore transfer to the carrier, and activates the hotkey. This signal passes through the docking connectors and activates the rotor, causing the platform to turn 180 degrees. When the ore transfer is finished, the mining ship has been turned around and is now facing back out of the hangar, ready to take off.

[captain828]

Something that hit me while reading the other dev-ask: if we could link "docking connectors" like yokes, then a ship that's docking to transfer fuel or cargo could also transmit logic or control signals through that same connector.

SE does this well and it's all seamless: when you dock a ship to a station or another ship it essentially exposes the docked ship as a child entity to the parent.

From my POV, what I find important is to be able to detect when another entity becomes docked and this should work both ways: so both the parent and the child should know when this happens so we can do cool logic stuff like closing a bay door when a ship docks and opening when it undocks etc.

For being able to interact with a ship remotely, simple is best: just allow a yoke to be linked to a remote entity and then you just get the exact same controls that you've set up for that ship. So if you've set up a camera on that ship, then you would essentially have a drone feed. If no camera is set up then you can think of it as an RC plane. This approach would be very simple to set up (compared to SE) as well as feel like a direct extension of an existing system, the yoke, so there would be no extra learning curve.

I will say though that for remoting ships it would be great if we had a bit more control with the cameras, like being able to assign cameras to hotkeys so we can switch from different perspectives. That would work well with this IMO.

Mining drones for gathering resources to a central processing rig, combat drones with a carrier, exploration drones like they use in deep-sea missions today... so much is possible.

I too want to see this but I think we would also need some AI automation (like in SE or Satisfactory) to really make this interesting.

[Garrett-C]

It would also add a cool option for gameplay where you could try to hack the frequency on someone else's ship to try and disable them without destroying them, good for pirates.

[tsunamayo]

Something that hit me while reading the other dev-ask: if we could link "docking connectors" SE does this well and it's all seamless: when you dock a ship to a station or another ship it essentially exposes the docked ship as a child entity to the parent.

From my POV, what I find important is to be able to detect when another entity becomes docked and this should work both ways: so both the parent and the child should know when this happens so we can do cool logic stuff like closing a bay door when a ship docks and opening when it undocks etc.

So yes I could also have a docked logic but it dont change the problematic: say you have three doors that are remote activable. How on the docked ship do you trigger those three door? What is the UI for the user, how do you pick each door ect ect. If I could get some info on how this works in SE that would be cool. There must be some kind of mapping to do at one point.

[TripleHelixxx]

I would probably use this for something like remote door opening for hangers, or docking and pump controls for refueling stations if those ever became a thing.

As to how you could handle the UI, I think having something like a network node gate that you could add to any existing circuit as an input method would work well. You could give it a name and maybe some security code. As far as how to control it remotely, if you just had a antenna and a terminal, you could see a list of available networks, and connect to one if you have the right code. You could then perhaps see A panel of buttons or switches labeled with the names of the notes in that network.

[Garrett-C]

Hmm the screens that exist and maybe some way to name logic could help. Not sure how you could cycle between different ones though.

[captain828]

So yes I could also have a docked logic but it dont change the problematic: say you have three doors that are remote activable. How on the docked ship do you trigger those three door? What is the UI for the user, how do you pick each door ect ect. If I could get some info on how this works in SE that would be cool. There must be some kind of mapping to do at one point.

Since you are not that acquainted with SE, let me first explain how logic works there:

• once you create an entity (could be on small voxel grid or large voxel grid), all the interactable blocks you add there get added to the entity network
• child entities, like in Starship EVO, are created when a rotor, piston or merge block is used - these appear with a different color if you access the parent entity but any interactables added to a child entity can be accessed by the parent
• when two entities dock with one another, they can now both be accessed from each other and are treated as child entities
• activators can trigger logic - these are buttons (for manual triggers), sensors (for proximity-based), timers (every X timespan) or via the programmable block (C# scripts)
• for actual UI and how they do it, I would recommend checking out https://youtu.be/r29eQkru-F4 (a simple logic tutorial)
• for scripts, you basically just have a textbox where you put the code in and compile it

So how would you do it in SE? The only way to communicate via logic with a remote entity that docks is via scripting. There is no real UI for this, just a textbox where you place the script.

For manual remoting of ships or accessing the controls of a remote ship you need to have an antenna to access the remote entity.

How I think it could be done in SEVO: One elegant option would be to have a remote block that would allow communication between two or more remote blocks that are linked together (or you can just keep it 1:1 if this would be too complicated). For security, the linking could be something similar to bluetooth pairing:

• let's say we have two remote blocks: A and B, on separate ships
• from A's UI, you can see B (there could be a range limit here, like 1km) and can send a pairing request
• at B's UI, when you open the block you will see that A requested to be paired with the option to approve/reject (maybe you can also give a prompt for people on the ship as well?)
• if B rejects A, then A can no longer send pairing requests and the pairing can only be started from B
• if B approves A, then the connection will now act as a pass-through logic system
• to prevent spam, an A->B pairing request can only be sent once - you can show "sent", "approved", "rejected" status on the sender
• so if you give A signal 1, B also gets it and vice-versa, so bidirectional
• since this can tie in with the usual logic blocks the sky is the limit
• also, from either A or B you can now unpair from one another
• A and B should be renameable as you could have several remote logic blocks on a ship

[talrey]

So yes I could also have a docked logic but it dont change the problematic: say you have three doors that are remote activable. How on the docked ship do you trigger those three door? What is the UI for the user, how do you pick each door ect ect. If I could get some info on how this works in SE that would be cool. There must be some kind of mapping to do at one point.

We used to be able to give buttons and hotkeys a name from the wheel menu, right? That would make it easy: when a player grabs a yoke or screen that's linked to wireless logic via whatever transceiver method you settle on, they could have a list displayed on the player's UI. Here's a mockup I put together in five minutes:

[fellow-starmadian]

This is my personal theory on what would work best. It seems to have all the functionality people want, with ways to specify specific for certain functions, the ability to control things like yokes or turrets, and the ability to transfer cargo (or at least give the command to). All without the need for an antennae and wireless security codes. Consider this a combination of some of my ideas, Talrey's mentioning of hotkeys and other such things, and the rest of the posts here. My idea would be to implement a tag system that gives players the ability to control either a Tsuna supported action for things like remote turret control or cargo, or a custom action for things like rails and logic: (allegiance) | Tag Name | Allow: action 1, action n | Disallow: action 2, action etc

| Possible flags or tags |

- Allegiance modifier: faction, friend, neutral, enemy (perturbations include: &higher &lower &only) - Cargo tag with sub tags such as (cargoSiphon, cargoGive) and the allegiance mod - Turret tag with sub tags such as (TurretChangeTarget TurretEnable TurretDisable) along with allegiance - A general logic tag that works as a more specific connection to act as a go between for more specific things that can't be easily chosen from, such as rotors and rails or choosing any specific thing. examples included in image. can be anything ASCII 128 and works with allegiance tag. The general tag could also replace all the other tags I suppose, but I believe it would be easier for people to be able to specify one tag to do a large task like mentioned above.

| Picture explanation (lose all hope ye who enter here) |

The picture SHOULD be understandable, if you read through it, but it essentially adds two blocks to the game: a TAG BRICK (SEND and RECEIVE) and an ACTION BRICK. The TAG BRICK allows for certain tags to be associated with it, and for Tsuna supported tags adds complete remote control in some fashion to the other system. For a simple example, if the tag "Cargo | Allow: siphon, give" was entered as an active tag in a TAG BRICK set to SEND, it would search for a TAG BRICK set to RECEIVE with an active tag that matches. (The search also accounts for faction ties, and if a certain tag has been modified with the "Disallow:" action set. If an action is disallowed, then the action is over ruled and can not occur.) Since the action is Tsuna supported, it allows the cargo system of the SEND ship to control the actions of "siphon" and "give" meaning it has access to add or remove cargo from the RECEIVE ship. Tags that are custom must be added and do not show up globally, but tags that are Tsuna supported DO exist globally, and can be accessed from any TAG BRICK. The ACTION BRICK is a special block I added to replace my recommendation for a wireless block, as it would make the wireless block obsolete if the ships are connected. It essentially acts like a RECEIVE TAG BRICK, except it looks for only one action, and only connects to the target ship system with a standard logical link. this means it accepts binary logic signals and / or values ranging from 0 to 1 like a slider would give. This enables pretty much anything to be done that Tsuna does not choose to support, but just through a more round about fashion.

I aim for this system to be a combination of the system in SpaceEngineers where every system was visible through a drop down list, and the more direct method from starmade of having cargo connect directly through a docking block and transfer everything as long as there was a positive logic signal from the controller connected to the cargo.

One last note about wireless blocks, they would still be required for when a ship is NOT connected, but perhaps when they are connected to another of their kind, they can also utilize this system of tag bricks so as to reduce the total number of wireless connections needed. turn it in to a serial encoder with multi channel input and output!

[Crimix]

This is my personal theory on what would work best. It seems to have all the functionality people want, with ways to specify specific for certain functions, the ability to control things like yokes or turrets, and the ability to transfer cargo (or at least give the command to). All without the need for an antennae and wireless security codes. Consider this a combination of some of my ideas, Talrey's mentioning of hotkeys and other such things, and the rest of the posts here. My idea would be to implement a tag system that gives players the ability to control either a Tsuna supported action for things like remote turret control or cargo, or a custom action for things like rails and logic: (allegiance) | Tag Name | Allow: action 1, action n | Disallow: action 2, action etc

| Possible flags or tags |

- Allegiance modifier: faction, friend, neutral, enemy (perturbations include: &higher &lower &only) - Cargo tag with sub tags such as (cargoSiphon, cargoGive) and the allegiance mod - Turret tag with sub tags such as (TurretChangeTarget TurretEnable TurretDisable) along with allegiance - A general logic tag that works as a more specific connection to act as a go between for more specific things that can't be easily chosen from, such as rotors and rails or choosing any specific thing. examples included in image. can be anything ASCII 128 and works with allegiance tag. The general tag could also replace all the other tags I suppose, but I believe it would be easier for people to be able to specify one tag to do a large task like mentioned above.

| Picture explanation (lose all hope ye who enter here) |

The picture SHOULD be understandable, if you read through it, but it essentially adds two blocks to the game: a TAG BRICK (SEND and RECEIVE) and an ACTION BRICK. The TAG BRICK allows for certain tags to be associated with it, and for Tsuna supported tags adds complete remote control in some fashion to the other system. For a simple example, if the tag "Cargo | Allow: siphon, give" was entered as an active tag in a TAG BRICK set to SEND, it would search for a TAG BRICK set to RECEIVE with an active tag that matches. (The search also accounts for faction ties, and if a certain tag has been modified with the "Disallow:" action set. If an action is disallowed, then the action is over ruled and can not occur.) Since the action is Tsuna supported, it allows the cargo system of the SEND ship to control the actions of "siphon" and "give" meaning it has access to add or remove cargo from the RECEIVE ship. Tags that are custom must be added and do not show up globally, but tags that are Tsuna supported DO exist globally, and can be accessed from any TAG BRICK. The ACTION BRICK is a special block I added to replace my recommendation for a wireless block, as it would make the wireless block obsolete if the ships are connected. It essentially acts like a RECEIVE TAG BRICK, except it looks for only one action, and only connects to the target ship system with a standard logical link. this means it accepts binary logic signals and / or values ranging from 0 to 1 like a slider would give. This enables pretty much anything to be done that Tsuna does not choose to support, but just through a more round about fashion.

I aim for this system to be a combination of the system in SpaceEngineers where every system was visible through a drop down list, and the more direct method from starmade of having cargo connect directly through a docking block and transfer everything as long as there was a positive logic signal from the controller connected to the cargo.

One last note about wireless blocks, they would still be required for when a ship is NOT connected, but perhaps when they are connected to another of their kind, they can also utilize this system of tag bricks so as to reduce the total number of wireless connections needed. turn it in to a serial encoder with multi channel input and output!

Could this tag system work with something like the galaxy map? Sorry if I did not read your post enough to understand it

[JRL101]

How about 32 character messages using the numpad hooked to a screen, hooked to a antenna,

Larger antennas can receive further, but to transmit further you need more overall power. That would be short range communication.

Long range galaxy wide communication would need a "laxer dish" and the laser dish requires coordinates to aim at and a ship name. in reality the coordinates are just to check the ship is close to that location before sending a message directly to the ship entity ID

It would be cool to have a "reader" brick that can read incoming messages and respond by activating to a specific phrase.

bit like a password match: Ship Transmit "Open" Other ship Receive "Open" "Open" = ON

connect to appropriate logic.

[DioTheCreative]

Maybe something like a request docking?

[fellow-starmadian]

Crimix said: Could this tag system work with something like the galaxy map? Sorry if I did not read your post enough to understand it.

Considering the logic system tsuna already appears to have, it should be doable as long as tsuna wants it to be doable. There seems to be some precedent for the system I want at least, considering what already seems to be implemented. If he thinks you should be able to control or get info from the galaxy map like the camera and turret can be controlled from yokes and screens, then it will be possible. And by extension, if Tsuna decides to support an official tag for the TAG BRICK that lets you perform this function through a docked block or a wireless block, then it will be doable.

JRL101 said: How about 32 character messages using the numpad hooked to a screen, hooked to a antenna (...) It would be cool to have a "reader" brick that can read incoming messages and respond by activating to a specific phrase. Bit like a password match: (...)

That would be pretty inline with what I would want so I totally agree, though I'm not sure about the wireless relay idea, locking players in to an infrastructure that they have to build seems a bit restrictive and hard to maintain.

Talrey said: We used to be able to give buttons and hotkeys a name from the wheel menu, right? That would make it easy: when a player grabs a yoke or screen that's linked to wireless logic via whatever transceiver method you settle on, they could have a list displayed on the player's UI.

I think that would be really useful to have too, and possibly easier to implement since it was already existant to some degree, I Just think it may have some issues with security if you dock to a neutral party's ship that you can't trust. Unless that's covered in the "whatever wireless transceiver method you use" part of your suggestion? that would probably work.

[Crimix]

Considering the logic system tsuna already appears to have, it should be doable as long as tsuna wants it to be doable. There seems to be some precedent for the system I want at least, considering what already seems to be implemented. If he thinks you should be able to control or get info from the galaxy map like the camera and turret can be controlled from yokes and screens, then it will be possible. And by extension, if Tsuna decides to support an official tag for the TAG BRICK that lets you perform this function through a docked block or a wireless block, then it will be doable.

I hope so, it would make it possible for the ships and docking warpdrive rings I would like to make

[JRL101]

JRL101 said: How about 32 character messages using the numpad hooked to a screen, hooked to a antenna (...) It would be cool to have a "reader" brick that can read incoming messages and respond by activating to a specific phrase. Bit like a password match: (...)

That would be pretty inline with what I would want so I totally agree, though I'm not sure about the wireless relay idea, locking players in to an infrastructure that they have to build seems a bit restrictive and hard to maintain.

I mean the more i can build the better personally, you're right about locking people into an infrastructure that isnt that what happens with any games world? But its an idea, personally a regular chat system with public and team and a black list or white list would work fine for communication.

[tsunamayo]

@talrey So that would mean the ship would have a hotkey linked to a transmitter brick right?

[tsunamayo]

@Crimix I am not sure to understand it all, but I think it is the same as what I had in mind I guess. The tag could enforce auto-link while tag on the transmitter and the receiver are match (and the permission allows it). Hence no need for a specific UI that needs to be toggled on each time an action is wanted. Am I correct.

[Crimix]

@Crimix I am not sure to understand it all, but I think it is the same as what I had in mind I guess. The tag could enforce auto-link while tag on the transmitter and the receiver are match (and the permission allows it). Hence no need for a specific UI that needs to be toggled on each time an action is wanted. Am I correct.

@tsunamayo I guess. My only question is would you make it work with all the different systems or only logic gates etc.

[talrey]

@talrey So that would mean the ship would have a hotkey linked to a transmitter brick right?

Possibly, though my concept was something closer to the below, where the transmitter would be an "entry-link" that, when connected to a receiver, exposes hotkeys linked to it just like a chain of Yokes do.

Yoke -> Transmitter ~ ~ ~ Receiver -> Hotkey -> Logic Things

However, I wouldn't mind hotkeys on the transmitter side. It only changes which builder decides what hotkeys control what output, really.

[tsunamayo]

@talrey I see, the problem being hotkey conflict. What do you do if some hotkey is already doing something on the player side? @Crimix so you would have receiver plugged into what you want. So you could control anything, simple boolean logic or control logic.

[Crimix]

@tsunamayo Yes, exactly any system block or brick. So it's more like an extension of a link which can be present or not depending on docked status, maglocked or range

[talrey]

Tsunamayo - You mean like if a ship's already bound Landing Gear, for example, and the wireless link exposes a Landing Gear bind? Seems like that's a problem for the builder, not the system. Activate both and let the player sort it out, just like what happens already with hotkeys. If a player's concerned about that happening, maybe they'll put an override switch in their cockpit!

[tsunamayo]

@talrey yes so that would be for the pre-defined hard link. I see two different use case: Same builder (or same faction at least), making direct link assignment. You active the button and it trigger the action on the remote ship. A discoverable system, for ship that were not made compatible before. Here I can only a solution with UI, with a description of things you can active on the remote ship.

[Asnro]

For the sake of immersion and building I would suggest making multiple different wireless transmitters instead of a small logic chip, similar to Space Engineers:

• Stretchable antenna block, where scale × stretch = range. Short range, multiple targets.
• Laser antenna, placeable on a turret to establish long-range links. Long range, single target.

The UI for the antenna could simply be an interface for inputting a desired channel, plus an option to limit signals to same faction only, while the laser antenna has a name box and dropdown menu of available receivers.

The antennae could transmit complex logic signals (eg. drone control: yoke -> antenna -> antenna -> ship computer), perhaps with the antenna UI showing what it connects to?

This way ships would have functional reasons to have antennae, and builds like aircraft carriers' "forests" of masts would not only be there for aesthetic purposes but would have functional uses as well.