Wire Socket Radio Documentation

[Free Fall]

I noticed that the use of WSR was always kind of low. After some friends suggested that it was due to lack of some docs i used my time and wrote some. And here they are:

WSR Documentation for Rev2


-> Overview

In this Documentation I will explain how to do the basic setup of a simple WSR link
and add some more explanations about how it works and how to use it.


-> 1. Configuring a basic WSR Setup

Setting up a WSR isn't a hard task, as there are only a very few things to configure.
Those are:

1) Model (Modelview)
2) The local Port ("Own Port" - Slider)
3) The Target's IP-Address ("Target IP" - Textfield)
4) The Target's Port ("Target Port" - Slider)
5) The Type of Data to send (Dropdown box)

Now what each one is:

1) The model should be self explaining by looking at what you can choose in the Modelviewer.
It has no effect on the workflow of the WSR.

2) The local port is only important if you use more than one WSR. You don't need to know what exactly a port is
to use the WSR, you just have to look out if the Target's Port on your side and the local Port on the Target's
side are equal, I.e. Player1 -> Target Port: 27101 Player2 -> Local Port: 27101
One thing to add: Your own local Port and Target Port don't have to equal, as they have no effect on each other.

3) The Target's IP specifies the other computer or machine you want to establish the link to. It is a number in the format
AAA.BBB.CCC.DDD (Maybe less of each one, maybe only A.B.C.D but that is the minimum, you always have 3 dots).
You can usually find it in your network config or in the configuration of your Router, depends on what you use.
If you just cannot find it, open a webbrowser and call a page like whatismyipaddress.com where your IP is shown.

4) As said above, you have to look out, that the target's local port and your own target port are equal, and that is it.

5) The type of data is what you want to send over the wires. Usually you might want to send numbers,
which is the default setup, but WSR also supports sending of strings (text). But to do that you probably need Killburn's
String Gates, as there are pretty much no other gates that give String wires. The E2 gate is another device that can
handle string aswell, so that could be used too.


-> 2. Using it

Now, having all those set, you can spawn a WSR with those options. You can also update an already existing one by
simply clicking on it, that works fine too. After it's placement the WSR will be red for a moment. If the other player on the
other computer finished setup as well, it should turn green, indicating a working connection. If it should remain
red you should either go back to step 1 or to the troubleshooting section.

If you have a working connection you can just go and use it like a normal Two-Way Radio. I guess everybody knows those;
you put in a value on A on the one side, and you get that value on the other side on Output A. The WSR works exactly the same,
but over the distance of another server. For example, on one server you spawn a WSR and wire a screen to output A, and on
the other server you spawn a WSR and wire a constant of 50 to input A. The screen on server one will show a 50.

Now to the Label on the WSR:

It shows some information about the connection after placement, including your own Port, the Target's Port and IP the current
Data outputs ("Rates") and the current delay of the connection ("Ping"). There is an additional point called
"CalcAverage", but it is more for debugging purposes than actual use.

And the additional wire-ports on it:

Next to the value port A-H there are some more ports on the WSR. Those are:

Input: On, ResetIP
Output: Connected, Bytes/sIn, Bytes/sOut, Ping

The On input activates or deactivates the WSR when set to 0 or 1. When it's deactivated it won't build a connection, and so,
both sides remain red. It's usefull for debugging or to reduce packet spam when it isn't used.
The ResetIP input sets the target IP to 0.0.0.0, which is basicly no target at all. This prefents a non-existing target
of being spammed after having a connection to some kind of WSR server.

The Connected output gives a 1 when the device is connected and else a 0. The Bytes/sIn and -Out inputs give the actual amount
of Bytes sent or received per second. Ping, as last Output, outputs the ping of the connection. Could be used for
lag-compensation.

Having said all this, it is pretty self explaining that I cannot explain WHAT to do with it, it's all up to your own
imagination and creativity.


-> 3. Side notes

1) A WSR link can be established between:
-> Server <-> Server
-> Singleplayer <-> Server
-> Singleplayer <-> Singleplayer

2) There is a maximum amount of data to be send on the network of 4 Kilobytes per second. You can look on the label
on the WSR to see how much is already used. But don't worry about losing data due to too much data to send. The sending
will just be delayed and sent later, so nothing gets lost.

3) Currently the FailSave of the WSR is deactivated as it caused more problems than stability, so data loss can indeed occure.

4) For Lua-errors / console-spam look under Troubleshooting

5) If you configured ONE side correctly and one side only with Local Port, the connection will still be
established. This is because the second WSR then takes the source of the message as new target. You can save a little
configuring time by only configuring one side. But you still have to configure the local port.

6) You need the LuaSocket DLL for GMod. Look in this thread on how to obtain it.


-> Troubleshooting

1) Network connection doesn't work, even though we set everything right:

The WSR, as something that uses normal web access through your network, it can be blocked by all kinds of Firewall,
Routers, etc.. So what you have to do is to open those port in your Firewall and do some Port-Forwaring in your Router.
I cannot explain how to do that, as it depends on the Router / Firewall and it's configuration.

2) I get Lua-Errors when spawning / using the WSR

Those errors occure sometimes due to bad coding. If you get one, try to post it on the forums or PM me or something, so
that I know about it and actually can do something about it. Just saying "Bah, WSR is buggy, damn this shitz!" doesn't help
anybody and won't improve the situation.

3) I have another problem / question

Do the same as with Lua errors and post it or PM me. NOT asking makes the situation NOT better, or does it?

-> Appendix A

Hi-Speed WSR:

The Hi-Speed WSR is the Hi-Speed variant of the normal WSR and is so only accessible via CPU or E2 functions, but still
kept as easy as possible. There are yet 2 modes: Shared and Packet. Shared mode is working like a normal RAM.
You write a value into it, and it is transmitted to the other side, so both sides have it. The problem with that is, that it is not a 100% save.
If two clients write in the same second into the same cell it could happen, that both sides have different value in the same cell.

The Packet mode is a little different. There you write your values into the cells, which aren't transmitted instantly. You have to trigger a
send command by writing into a specific cell. On the other side, you can then check if packets are available, and trigger a command cell
to set the current content of the WSR buffer to the data of the Packet.

Now to the Special Cells:

Cell 0:
Read -> Returns if the WSR is connected or not
Write -> Disables the WSR on a 0 and enables it on a 1
Cell 1:
Read -> Returns the current Ping of the connection or 0 if disconnected
Write -> Resets the current Target IP and Port to 0.0.0.0:27100 to avoid spam of unavailable targets (like ResetIP on normal WSR)
Cell 2:
Read -> Returns the current amount of Bytes In per second
Write -> None (Memory Fault)
Cell 3:
Read -> Returns the current amount of Bytes Out per second
Write -> None (Memory Fault)
Cell 4
Read -> (Packet Mode only) returns the amount of packets in the input buffer
Write -> On 1: Puts the current content of the WSR into a packet, send it, and clears current WSR RAM
-------> On 2: Gets a packet from the input stack and replaces the current WSR RAM with it.

[Grocel]

The WSR Documentation can be helpful.

[Chefs brian]

So, With this, its equally possible to commuticate and transmit signals to other servers? so i could get my friend to take some advance dupe files into a second server, and then he deploys them there (im rigging up remote control ships atm) and henceforth, be a presense in two servers? and also, does it work if two players are in single-player?

[Free Fall]

Basicly the WSR is a Wire-Bridge between two GMod sessions. And if you can send Adv. Dupe. Data over a Wire, you can send it to another server, yes.

And about the question SP<->SP, there was a small part in the docs:

1) A WSR link can be established between:
-> Server <-> Server
-> Singleplayer <-> Server
-> Singleplayer <-> Singleplayer

[Lyinginbedmon]

Suddenly the Admin Radio and such from War of the Servers seems significantly more likely.

This would be fantastic.

On that note, how difficult would it be to implement player transportation? As in, moving from server to server via the radio, rather than the server lists?

[Pyroclastic]

Suddenly the Admin Radio and such from War of the Servers seems significantly more likely.

This would be fantastic.

On that note, how difficult would it be to implement player transportation? As in, moving from server to server via the radio, rather than the server lists?

You can do this via E2 already.

@N ServerJoiner
@I IP:string Connect
 
if (Connect) {
    concommand("connect " + IP)
}

You'll still have to load in, but the seamless transition you may be looking for is not possible in the source engine.

[Free Fall]

Yea, the closest to player transportation what you could get would be reconnecting the player and placing him on the correct position on spawn. But that is about it, I guess.

[Lyinginbedmon]

Okay, here's an idea then: Server-to-Server Nukes

As in, you make a nuke with an Expression chip to that detonates it when it's spawned (Precisely how you do that without killing yourself I'm not sure, maybe a proximity failsafe based on your SteamID), and then send it over to another server. Upon spawning, the chip detonates the nuke.

This could be prevented if there were some way to look at what you're receiving before spawning it. Hmm...maybe if we combined it with the E2 holograms...

[Free Fall]

Small Update:

I just finished the Hi-Speed WSR, and so I added a small Appendix to the documentation, so that everybody can work with that too.

PS: As the system (yea, I mean my LuaSocketLib, whichs FailSave I threw out because of too many bugs) is not fully stable, it is easily possible to cause a stack overflow with a too big amount of data sent over the WSR. So I ask everybody who want's to try not to report this over and over again. It will just need a rewrite of the part, and that is it; no instant solution right now.

PSS: That doesn't mean you shouldn't atleast try it

[-=Fox=-]

I got Minibox working again for the Hamachi Group WSR Server.

You can test connectivity with the Highspeed WSR via port 27110.

When I get a system to mirror what you sent to it I'll let you know, at the moment you can only test connectivity with it