Suggested Optimizing Wireless Logic

[Endal]

(Disclaimer: I do not seek to replace the current block, I only wish to add on to improve wireless logic as a whole)
Wireless logic is nice, it can be cross-entity and it doesn't have an obnoxious pipe sticking out (atleast for cross-entity). However, the current Wireless block is still Wired in a sense. They require manual linking, and sometimes this link is severed by metadeta corruptions and such.
So there's been a solution going around which is "Logic Beams!", well, I wanted to suggest that but it has been around since logic was a thing, so I'll skip that and go to another concept
Wireless Logic Radio
This system will comprise of two blocks, a Logic radio transmitter, and a Logic radio receiver.
The idea is similar to IRL radios, you send out electromagnetic waves from the transmitter, and the receiver picks them up. But then only two can be used at one time! Frequencies. The transmitter and receiver when "R"ed will open up a small GUI with a text box, the text on top will probably say something like "Type in the frequency the transmitter/receiver will listen to" Then you'd enter in a number from 1-(2^32), which is a lot of frequencies, plenty to go around. If possible, only possible frequencies are allowed since negative frequencies don't make much sense, but I am not a certified radio operator so negative frequencies are fine too.

The blocks would work something like this, when the transmitter receives an on signal, it sends out a "pulse"(with a limited range). Not sure how the "pulse" would contain the information but it will have to, since when the "pulse" reaches the receiver, the receiver checks if the it has the same frequency as the "pulse". If so, it will acknowledge the on signal and send it to other logic blocks it is linked to. If not, it simply ignores the "pulse". The off signal will also apply.

I am not sure how the "Pulse" will be implemented, it might even not be a pulse and simply be some programming magic. But the main features are this
-No wiring required
-Multiple Frequencies to tune to
-Limited range

I hope this feature will be implemented, it will definitely be received warmly by those who use Logic!

 

[Sven_The_Slayer]

I've seen this suggestion before, including from myself. I really do want this type of wireless block.

Standard Transmitter and Receiver: These blocks would run on a specific code and when a transmitter is activated it would activate any receivers with the matching code, this way you can build hangers or warp gates that any shuttle with a matching code can operate. When you press R on these blocks a text window opens allowing you to enter the "frequency"

 

[Endal]

Ah, I guess I haven't done enough forum surfing, sorry about that ._.||

 

[GalactusX]

A Radio transmitter/receiver would be great .. but ... i see 3 mayor problems here i found in other game use the same mechanism ( some mods of minecraft)

1. The frecuency of each player´block must be save on one data base ( more blocks per player, more big data base neded )
2. If one player enter a "frecuency" other player use, it can be enter on conflict with others stored.
3. If one player load a ship / station use a certain number of "radio blocks", server need "detect" all the frecuencys and add all to the actual server data base... and more work for server side ...

Thrust me, if this 3 points can easy be solved .. i will be happy if that kind of wireless / radio blocks can be included ... but i prefeer StarMade team first fix all the actual bugs with the present blocks, and no add other news, and add more bugs ...

 

[Endal]

i see 3 mayor problems here i found in other game use the same mechanism ( some mods of minecraft)

1. The frecuency of each player´block must be save on one data base ( more blocks per player, more big data base neded )
2. If one player enter a "frecuency" other player use, it can be enter on conflict with others stored.
3. If one player load a ship / station use a certain number of "radio blocks", server need "detect" all the frecuencys and add all to the actual server data base... and more work for server side ...

1. and 3. > The frequency will be saved as block metadata, the only thing that the server needs to store is the metadata, heck the block stores the metadata and since it is a number that is no issue. I don't see why the server needs a database to store all the frequencies as mentioned:

The blocks would work something like this, when the transmitter receives an on signal, it sends out a "pulse"(with a limited range). Not sure how the "pulse" would contain the information but it will have to, since when the "pulse" reaches the receiver, the receiver checks if the it has the same frequency as the "pulse". If so, it will acknowledge the on signal and send it to other logic blocks it is linked to. If not, it simply ignores the "pulse". The off signal will also apply.

None of these steps need the server to "Store" anything per-say, as the blocks will be doing all the storing and interaction.

2. > Well IRL if two parties' radios use the same frequency then they probably will find out and change it ASAP, hell one party might intentionally conflict another's frequency to disable their systems, its a real problem which has real solutions. This also allows two parties to communicate with each other even if they have not even met each other before, as long as they have their "Radio"s tuned to the same frequency.

 

[Olxinos]

I voted "current wireless block" because I don't want it to be replaced (and I'd prefer having only the current wireless block, than only the suggested radio block). I believe it will eventually be fixed anyway.
Hence, it's the "best wireless medium" for me.

Still, the wireless radio is interesting, and if possible, I'd like something like that to be implemented (in addition to the current wireless block).

 

[jayman38]

If wireless radio were implemented, the dev team would probably maintain the current wireless blocks also, if only to avoid breaking existing designs.

 

[therimmer96]

As I stated in chat, I disagree with this.

The base of the idea being transmitters and recievers seems pointless when the logic block we have already does both of that in one.

Frequencies making it easier to tie systems together? that I can sort of agree with. But it would mean that any newly spawned blueprint would need all of it's codes randomizing when it spawns so that you can park 2 of them next to each other, an important thing in a faction game. In chat, you're only real reason for wanting this was the long astronaut walk between the 2 wireless blocks. A better solution would be an advanced build mode option for selecting wireless logic on other structures.

This suggestion would mean there's 2 wireless logic systems that don't work together. This would only confuse new players when it's completely pointless.

 

[Sven_The_Slayer]

2. > Well IRL if two parties' radios use the same frequency then they probably will find out and change it ASAP, hell one party might intentionally conflict another's frequency to disable their systems, its a real problem which has real solutions. This also allows two parties to communicate with each other even if they have not even met each other before, as long as they have their "Radio"s tuned to the same frequency.

This is a point I made specifically in my version of this, it opens up some kind of hacking counter-play where you try to figure out the frequency your enemy use to their hanger doors.

As I stated in chat, I disagree with this.

The base of the idea being transmitters and recievers seems pointless when the logic block we have already does both of that in one.

Frequencies making it easier to tie systems together? that I can sort of agree with. But it would mean that any newly spawned blueprint would need all of it's codes randomizing when it spawns so that you can park 2 of them next to each other, an important thing in a faction game. In chat, you're only real reason for wanting this was the long astronaut walk between the 2 wireless blocks. A better solution would be an advanced build mode option for selecting wireless logic on other structures.

This suggestion would mean there's 2 wireless logic systems that don't work together. This would only confuse new players when it's completely pointless.

This is not a replacement for the current wireless block. The current wireless system is great in internal structures where A always goes to B (assuming the bugs get fixed). I think ultimately the point of the transmitter -> receiver block is primarily is to pass logic signals between multiple entities that are not in a hierarchy. I am currently constructing a logic freighter but I have no way to pass a signal to the station I am docked to simply because there is no 1:1 correlation of that ship to that dock. It's a ship that is designed specifically to move cargo from one station to another and with this system I could just put the transmitter on the ship and a receiver on every station station and be able to tell the station when the ship is in the mode it needs to be in order to transfer cargo.

Just think of it as having any ship in your fleet with a garage door opener.

 

[therimmer96]

This is a point I made specifically in my version of this, it opens up some kind of hacking counter-play where you try to figure out the frequency your enemy use to their hanger doors.



This is not a replacement for the current wireless block. The current wireless system is great in internal structures where A always goes to B (assuming the bugs get fixed). I think ultimately the point of the transmitter -> receiver block is primarily is to pass logic signals between multiple entities that are not in a hierarchy. I am currently constructing a logic freighter but I have no way to pass a signal to the station I am docked to simply because there is no 1:1 correlation of that ship to that dock. It's a ship that is designed specifically to move cargo from one station to another and with this system I could just put the transmitter on the ship and a receiver on every station station and be able to tell the station when the ship is in the mode it needs to be in order to transfer cargo.

Just think of it as having any ship in your fleet with a garage door opener.

I understand it. And as I said, I get adding frequencies to the current one. I just think a seperate system like this is a bit silly.

IMO, the better solution to your situation would be a proper computer system.

 

[Nickizzy]

(Disclaimer: I do not seek to replace the current block, I only wish to add on to improve wireless logic as a whole)
Wireless logic is nice, it can be cross-entity and it doesn't have an obnoxious pipe sticking out (atleast for cross-entity). However, the current Wireless block is still Wired in a sense. They require manual linking, and sometimes this link is severed by metadeta corruptions and such.
So there's been a solution going around which is "Logic Beams!", well, I wanted to suggest that but it has been around since logic was a thing, so I'll skip that and go to another concept
Wireless Logic Radio
This system will comprise of two blocks, a Logic radio transmitter, and a Logic radio receiver.
The idea is similar to IRL radios, you send out electromagnetic waves from the transmitter, and the receiver picks them up. But then only two can be used at one time! Frequencies. The transmitter and receiver when "R"ed will open up a small GUI with a text box, the text on top will probably say something like "Type in the frequency the transmitter/receiver will listen to" Then you'd enter in a number from 1-(2^32), which is a lot of frequencies, plenty to go around. If possible, only possible frequencies are allowed since negative frequencies don't make much sense, but I am not a certified radio operator so negative frequencies are fine too.

The blocks would work something like this, when the transmitter receives an on signal, it sends out a "pulse"(with a limited range). Not sure how the "pulse" would contain the information but it will have to, since when the "pulse" reaches the receiver, the receiver checks if the it has the same frequency as the "pulse". If so, it will acknowledge the on signal and send it to other logic blocks it is linked to. If not, it simply ignores the "pulse". The off signal will also apply.

I am not sure how the "Pulse" will be implemented, it might even not be a pulse and simply be some programming magic. But the main features are this
-No wiring required
-Multiple Frequencies to tune to
-Limited range

I hope this feature will be implemented, it will definitely be received warmly by those who use Logic!

Just call it something else, I think calling it a radio just makes people think of it as some sound device or more complicated than it is. It's just an on/off button that can affect everything without complicated linking and stuff. Best if you could save frequences like waypoints.

 

[Endal]

Just call it something else, I think calling it a radio just makes people think of it as some sound device or more complicated than it is. It's just an on/off button that can affect everything without complicated linking and stuff. Best if you could save frequences like waypoints.

1. Well, I could just call them a "Wireless transmitter" and "Wireless receiver", but then that would confuse players that they might work with the current wireless blocks, but (refer to 2 for greater detail) I don't intend to. However...

2. As what rimmer said, a simple transceiver would work as well, the problem is that while its an easy Every-way connection, an Every-way connection is... well... every-way, it can not be converted to one-way, but one-way can be converted to every-way. Every-way signals would go in both directions, and you end up with having to do things walkie-talkie style, ie Transmit and Receive at different times, which is an inconvenience for some situations and extra extra logic wiring for others.

 

[therimmer96]

1. Well, I could just call them a "Wireless transmitter" and "Wireless receiver", but then that would confuse players that they might work with the current wireless blocks, but (refer to 2 for greater detail) I don't intend to. However...

2. As what rimmer said, a simple transceiver would work as well, the problem is that while its an easy Every-way connection, an Every-way connection is... well... every-way, it can not be converted to one-way, but one-way can be converted to every-way. Every-way signals would go in both directions, and you end up with having to do things walkie-talkie style, ie Transmit and Receive at different times, which is an inconvenience for some situations and extra extra logic wiring for others.

I explained this to you yesterday. everyway communications can work in one direction aswell, if you have half a brain cell

button 1 > wireless 1 > wireless 2 > button 2.

Press button 1, turns on button 2, spam the fuck out of button 2, button 1 won't change. Simply have a second circuit going in the reverse direction for the other way. No need for new blocks.

 

[Endal]

I explained this to you yesterday. everyway communications can work in one direction aswell, if you have half a brain cell

button 1 > wireless 1 > wireless 2 > button 2.

Press button 1, turns on button 2, spam the fuck out of button 2, button 1 won't change. Simply have a second circuit going in the reverse direction for the other way. No need for new blocks.

Well... One problem...

when the transmitter transceiver receives an on signal, it sends out a "pulse"

So a transceiver on frequency 406MHz sends out an on signal, another transceiver on frequency 406MHz picks up the on signal and receives the on signal. Wait, lets look at that quote again,
"when the transmitter transceiver receives an on signal, it sends out a "pulse""
hold on, so if the transceiver receives an on signal from another transceiver, won't it also send out a pulse? Won't the whole thing loop back on it self?

 

[therimmer96]

Well... One problem...

So a transceiver on frequency 406MHz sends out an on signal, another transceiver on frequency 406MHz picks up the on signal and receives the on signal. Wait, lets look at that quote again,
"when the transmitter transceiver receives an on signal, it sends out a "pulse""
hold on, so if the transceiver receives an on signal from another transceiver, won't it also send out a pulse? Won't the whole thing loop back on it self?

What? I don't follow? What?!

 

[Endal]

What? I don't follow? What?!

Please read the original post

The blocks would work something like this, when the transmitter receives an on signal, it sends out a "pulse"(with a limited range). Not sure how the "pulse" would contain the information but it will have to, since when the "pulse" reaches the receiver, the receiver checks if the it has the same frequency as the "pulse". If so, it will acknowledge the on signal and send it to other logic blocks it is linked to. If not, it simply ignores the "pulse". The off signal will also apply.

 

[therimmer96]

That sounds stupid CPU intensive, having each receiver have to do something for each and every pulse, whereas the current version will only send the signal direct to the block it's paired to.

A better way to handle frequencies is that when ever an transceiver is toggled, have it loop through an array and toggle each one to the new status.

 

[Endal]

I am not sure how limited range could be achieved with that, the whole reason for limited range is that it reduces the chances of frequency overlap across a server, load distance of player doesn't count.

 

[therimmer96]

I am not sure how limited range could be achieved with that, the whole reason for limited range is that it reduces the chances of frequency overlap across a server, load distance of player doesn't count.

Same way transporter range is done, just only toggle if they are within 2 sectors/nav range

 

[Endal]

Same way transporter range is done, just only toggle if they are within 2 sectors/nav range

Ah, then

simply be some programming magic

would work too, I'll edit the suggestion once I am done with my current projects