Transmitting Display module content between entities

[Lone_Puppy]

Today I was thinking about an Elevator project I've been working on for ages that has a wireless destinatio selector. I know people avoid using Wireless because of connection issues that occur, but logically this is the best way to go when dealing with entities on rails that you want to have controls on.

The basic idea is to have the ability to send copies of Display modules between entities the same way we do on a single entity.

I thought of two different methods that I would like. One using Wireless and the other using the Docker and Rail relationship.

Wireless
Use the Wireless module the same way we do buttons and other logic to copy the content from one module to another. The difference being, the Wireless module copies the content over the wireless connection to it's companion receiver wireless module.

This would allow us to do a ton of cool things between entities, e.g.;

• Elevator controls in cars become smaller and simpler.
• Relay controls can incorporate Display module based command systems.
• Ship to ship communications using Display modules
• ... no doubt there are more ideas I haven't thought of.

Examples

• Destination selector for elevators, busses, trams and trains. Since all the rail controls are all on the parent entity.
• Stock management system for cargo transported/transferring by rail based entities. Good for cargo pod systems on ships and stations. Would actually give purpose to the cargo containers you often see as decorations on various stations and ships.

Docker and Rail
This method is more direct like the early version of Storage transfer. It would be great to have rails and dockers transmit/receive Display module content.

The kind of things I can see it useful for is;

• Child to Parent docking identification, requests, coded access for approved docking
• Parent to Child docking instructions, welcome, warnings, whatever
• Cargo management systems
• Factory management
• ...many more I suspect

The ideas above would require a good understanding of how to build the logic systems and machines to pass info across these mediums.

These a just a few ideas I can think of right now. I'm sure the community has tons of ideas, wish lists, machines that could use or benefit from these features.

 

[NeonSturm]

I have thought of it also and came to a more compact/refined solution:

​

Ships have an unique ID, a name for the blueprint folder, ..., but what if we can read it's description tags via logic?
Description-Tags:

1. shipname (unique)
   
2. broadcast (128 chars, from a display module connected to the core)
   
3. targettype (non-unique: turret, ship, reactor, etc; maybe from system-detection or manual overwrite)

You could access the message from:

1. rail-docked ships (display module and rail)
   
2. docking station/ship (display mod and rail-docker)
   
3. your marked target (dm and camera)

Now you just need individual targeting selection per camera with logic!.

1. search target via REGEX
2. fallback regex
3. read tags with something like "[pipe]*(shipname)*[tag]broadcast[value]..." on your display block connected to camera

 

[Lone_Puppy]

@NeonStrum if I understand your idea correctly, this is using the targeting system to transfer information between entities. Seems to focus mainly on ship/entity information transfer.

All I'm asking for is the ability to copy display module content either using the wireless connection of a wireless activation module or over the docker/rail relationship the way storage use to work. Ultimately allowing for anything on a display module to be used across entities. I personally want it for turbo lifts and elevators, but could see it would be useful for all kinds of applications.

Display content copying example.

 

[NeonSturm]

You can make wireless modules by creating extra-tags and hook on to these even remotely once you get information about the tag-name.
Unlike wireless modules, you can hook all elevator-levels at once to the same pipe when floors are dockable entities.

Like browsing on a webserver, you could access different "urls" or "pipes" via console commands and attach new commands.
Actually you separate by pipe/tag name like a regex-selection of specific messages.
This info can be in the ship's broadcast or be hidden like a password.
You could even make: follow URL 1, 2 or 3, etc (everything else done by some 8x8x8 dockable community-content "webbrowser")

Try to guess-hack into "[pipe]Sentry90[tag]?port=80&pw=ARDS§[value]DropShieldsForTP"
And if someone does, you may need to react on unwanted changes by:
1. changing it back in a logic-reaction on the command module before shields react,
2. alerting of hack-attempts and
3. re-set the delay through a change from command module before your shield acts on foreign command.

It would solve at least 4 suggestions at once.

1. Transferable display content (Yours)
   
2. Hacking
3. Targeting via logic
4. Ship-to-ship communication with logic