Wico Antenna Network (WAN)

I posted my test world, EDIT: Script is now published.

Test/example world:
https://steamcommunity.com/sharedfiles/filedetails/?id=548885760

Script:
https://steamcommunity.com/sharedfiles/filedetails/?id=549503625

Work In Progress.

I've got two-way communication using laser antennas working.

This demo world has two seperate networks

The first has the script running on two ships/stations.
The 'base''s antenna is set as the 'master'; this means it controls the on/off timing.
The remote antenna is set to 'slave'; it just reads status.
Both grids have a timer that is injecting packets into the 'network'
The base has a text panel set up to receive the messages that the remote timer is sending.

The second network has a similiar setup, but has two ships and a 'transfer' station in the middle that just passes on packets.

Code still needs:

• lots of testing with moving ships and ranges needs to be done
• lots more testing with other edge cases
• error handling (shouldn't be able to pass it a bad command and have it 'crash')

My goal is to have this script serve as the lowest level in the network hierarchy and allow other Engineers (including myself) to add higher level functionality to it.

Currently only 'Broadcast' messages are supported.

Edit 11/06/2015: Script published and world updated with more demo networks

 

Reserved

 

Wico Antenna Network (WAN) User Manual

This script provides communication between laser antennas and allows for two-way transmission of data.
The script is meant to manage multiple antennas on a grid.

An antenna connection requires one antenna to be in 'master' mode and the other in 'slave' mode.
The 'master' is reponsible for turning on/off the antenna to cause the messages to be transmitted.

A 'master' antenna has ^ as the first character of the name. A 'slave' has v as the first character.
Right after the ^ or v should be a short name for the antenna. The name of the antenna is what is used to transmit information, so the shorter the name, the better.

An example 'master' antenna is
^A1

An example 'slave' antenna is:
vB1

The antennas need to be set up to be connected to each other by the player.

Once they are connected, the script will control them.

Blocks

• Programmable script (obviously)
• Timer named (currently tb)
• At least one Master or slave antenna (see above for naming)
• Any number of Receiver text panels (see below)

All blocks are local-grid only.

Messages
Messages are based on Internet protocols.
Each message sent has

1. Time to Live (TTL) The number of time the message will be re-transmitted
2. Protocol. A designator of the type of the message being sent
3. Source The name of the source of the message
4. Destination The name of the desitination. "B" is used to mean "Broadcast". Too allow system messages, Engineer-defined protocols should be at least 3 characters.
5. (option) Message The text of the actual message

Receiving messages
Messages are received by protocol. As a message is received, the protocl is checked and if any 'listeners' are registered for the protocol, the message is passed to them.

A 'listener' is a text/lcd panel.

Setting up receiver

1. Create a text/LCD panel.
2. Create a timer
3. add [WANR] to the name of the text panel
4. set the public title of the text panel to the name of the timer to be triggered when a message is received
5. set the private title of the text panel to the name of the protocol to be received
6. when a message is received, the message is added (appended) to PRIVATE text field and the timer is triggered
7. the script processing the receiving message is responsible for clearing out the received messages after they are processed
8. the WAN script will find the receiver on init and start processing messages for it; so if you build a new text panel, it will only be 'seen' on recompile of the WAN script or 'ini' command to the script

Sending messages

The script takes arguments to send messages

The format of the send command is:
SEND <TTL> <protocol> <src> <dest> [message]

• TTL is time to live. it is the max number of retransmissions the system will do on the message.
• protocol is the name of the user-defined protocol being sent. It determines who will receive the message (see setting up receiver).
• src should be -; it will be set in the message by the script to the name of the originating script
• dest is the destination 'grid' For now, only broadcast is supported. Broadcast is "B"
• Message is the optional text of the message.

Example messages:

Code:

SEND 5 EMERGENCY - B 23.12:45.12:56:78
SEND 20 LCDUPDATE - B LCD Name.lcd text to update
SEND 5 MASTERTICK - B

 

Script published. https://steamcommunity.com/sharedfiles/filedetails/?id=549503625

 

This.. is.. amazing..

 

I'm looking forward to seeing how this develops. what network topologies do you intend to support as far as message routing goes?

 

As a programmer myself, I've been meaning to dig in and learn how programming blocks and in-game scripting works. I have some ideas about fun things to implement should I have the time and will-power. I'd like to know: if I use this to help me work things out -- especially since anything of real, long-term use would require some inter-ship communication -- would you have problems with me using huge parts of this script in whole for my own uses? Assuming I don't completely re-write and implement for feature-specific purposes, credit would absolutely be given. I just don't want to step on anyone's toes, especially in my first forays into this.

To be fair, I probably wouldn't release anything anyway, but, y'know. The T's and I's need their crosses and tittles.

 

You shouldn't need to use parts of this script; it provides inter-ship communication services.

You should use the services in your scripts so that other scripts can also use the communication services.

If you need help using the services or are having a problems getting them to work, I'd love to help.

 

(omg, the F5 lag for the release...)

Right now Broadcast is supported.

The TTL should allow pretty much any topology for broadcast.

However, named destination may require more network topology discovery for routing of messages. One problem to solve is uniquely naming the points on the network.

 

how does it send stuff over the antennas? i mean, how do you actually transfer data?

 

When antennas connect the local antenna detailedinfo gives the name of the remote antenna it is connected to.

I parse that antenna name string into the protocol I defined. This protocol includes. Timetolive, source, destination, and protocol.

I leave the last part as a variable length message string.

Currently, only broadcast destination is supported ("B").

Scripters can define their own protocols and "register" them to receive the message text and a timer trigger when a packet with that protocol is received. The receiver should then process the received message however it likes.

Sending a message is done by calling the script with an argument.

Messages received are also passed on to other antennas in the grid.

Messages are queued to be sent.

Script is currently English only because of the parsing method for detailedinfo.

 

It seems this script is for programmers, what about puny designers? How can I use it? Does it transmit live messages? What are the applications?

 

As far as I can tell, what wico is doing is the bottom 2 layers.
There is the physical layer of the antennas themselves, which have to be set up correctly. (this is the pysical hardware of a network, the caples, hubs and routers)
then there is the network layer, which determines the header and footer blocks of a message, these are used for routing and distrobution purposes (I understand point to point routing isn't implemented yet, but I haven't seen anything so far that would disallow it) this is the protocol layer, it basically say what character in a string means what, setting a standard for all messades on the network

What data to send, in what format, what it means, how often to send it, who to send it to and the specific topology of your network is up to the end user.

 

Sinbad is correct on the network layers; except I think the script also covers transport layer. So the only layer left is 'application'.

Not sure what kind of designer you mean.

For ships:

1. Place laser antennas in pairs. One can be used by the data network, the other will be the remote-control (relay) connection that's always on.
2. Place antennas in such a way that they will always have a line-of-sight (LOS) to the next ship/station in the connection. For most ships, this will mean two sets; one on each side where the ship itself would block LOS if the ship was turned.
3. For ships/stations meant to have a relay/command capability (ie, relay satellites), you'll want multiple antenanas
4. Name the data network laser antennas using the provided naming convention

Data Network Laser Antenna Naming Convention
Starts with ^ or v
followed (no spaces) by an antenna name (cannot contain spaces). Name should be short as it is transmitted on each message.

Name Examples:
^L1
vR1
^S2

Using the data network

Connections between antennas needs to be initially set by the player.
Connections must be between two antennas of the appropriate type: ^ to V. This is called master/slave in the script code. One is the controller and toggles the connection for the data transmit; the other just waits for the connection to be toggled.

FYI: I have not done a lot of testing about what happens when connections are lost because of permanent LOS loss (such as going behind a planet), or when out of view distance.

• Messages are 'sent' using arguments to the PB containing the script.
• Messages are 'received' using a text panel that specifies a timer to trigger when the message is received.

Applications
This is the 'application' layer in the network diagram.

Simple (timer trigger)
For simple 'commands' being sent as messages, you can just use the timer being triggered to perform an action.

For example, 'enemy detected' from a remote detection system.
Example: "Request open docking bay"

Script-based
More complicated messages can contain information in the data portion. Interpreting this data will require a script to read it.

Examples include 'Enemy detected at X,Y,Z'
Example: 'Please respond with x,y,z and facing vector of available docking connector'
Example: "Here is x,y,z and facing vector of available docking connector'
Example: "Here is my current position, facing vector and velocity vector(s); Please follow me"

 

Wico: Have you run into problems with big messages? I tried to send a string of somewhere between 3k and 10k characters from a satellite to a groundbase (the satellite was transmitting scan data to the base). My game completely froze up while receiving the data in the terminal. Changing the custom name on the satellite caused no problems, but when the detailed info changed on the base antenna while I was in the terminal, my game went nuts.

I did not use your network script, just a simple setcustomname => get detailed info one-sided transmission.

EDIT: I have to add that I was sending this data repeatedly by disconnecting and connecting the base antenna, using a program and timerblock. It worked fine aside from totally freezing my game.

 

I have not tested message size limits.

I expect that there is a hard limit of some kind and maybe you found it.
It should be reported as a bug. Keen's code should not hang if the size is 'too big'; it should catch that and fail the set or clip the data.

There will also will be a soft limit of some kind on DS/multiplayer because the detailedinfo is probably getting sent to every player.

Depending on how the netcode works, they may run into the 'real' TCP/IP packet size limit and not handle it correctly..

 

Ship formations??

 

That is one of the possible applications.

A 'master' could broadcast it's location, orientation and movement vector to connected ships.

Those ships could then use that information to put themselves in a unique 'offset' from the master location and direction. The movement would be used to predict position.

I have not implemented this application; nor has anyone else that I know of..

 

I know. That's why I brought it up.

 

Update make script compile again.

And update to demo world to have text-panel explanations of what's happening in the demo.