More wireless receivers and emitters

[Byamarro]

I would like to propose 4 new logic blocks.

1. Field receiver and emitter.
Field emitter would spread invisible logic signal at frequency defined by an user.
It will not be computional resource drainign as You only need to calculate distance between receiver and sender and if it's close enough and they both are set to the same frequency, just make it receive logic signal from the sender.
If there are multiple senders at the same frequency, just make receiver receive signal from closes sender or just receive interferented logic signal.


2. Beam receiver and emitter.
It's the same, the difference is that Field emitter, emits signal everywhere, but beam one send signal in straight line so You will need to calculate if receiver lays on the same line with beam sent by emitter.


These 2 blocks would give far more possibilities to logics.

 

[TomW1605]

this would be great

 

[Comradecolonel]

It would be very cool to control multiple logic systems with a single button. I hope at least your first suggestion is noted.

 

[Megacrafter127]

It will not be computional resource drainign as You only need to calculate distance between receiver and sender and if it's close enough

That there can easily turn out to be quite some calculation, unless you make it sector based(a transmitter can only be recieved in the same sector, regardless of where it is in that sector).

If there are multiple senders at the same frequency, just make receiver receive signal from closes sender or just receive interferented logic signal.

regarding the first solution: see above
regarding the second solution, what is an "interferented logic signal"? a clock? a random signal? in either case, in which intervals does/may the signal change? In addition, the current logic operates event based. If a block's state changes, it send an update with the new state to the blocks linked to it. If those are logic blocks too, and their state changes, this continues, however, if their state doesn't change, they don't continue relaying the update, as no further change would occurr, since the input of the other block wouldn't change(DELAY blocks might be an exception), what this means is, that unless 2 transmitters within range both change their state to a state different from one-another within the same engine-tick, there is no conflict.

 

[Aynslei]

1. I could have a lot of fun with a channel based wireless block that works in the 3x3x3 sectors that load around a player.
This does not need 2 blocks, only one, it should operate just like any activation module except when you press R you select the channel it operates on. All blocks on the same channel will receive all signals each block on the channel receives.

This would actually allow for a true form of hacking. The old wireless modules stay secure until physically taken, but any logic systems that use the wireless channels can be broken into by anyone that can figure out what signals to send on what channel. It opens up a huge potential for utility , and it comes with a risk vs reward of making your system easy to use VS easy to "hack" into.

2. I think adding a new beam block for getting access to the logic beam is silly. We have cameras, lets just let them shoot the logic beam that the core can, but by logic toggle. I also think that a beam receiver is even more silly, a logic beam can already turn on and off logic bits, we don't need a new blocks to do something logic blocks already do with logic beams.

 

[TomW1605]

2. I think adding a new beam block for getting access to the logic beam is silly. We have cameras, lets just let them shoot the logic beam that the core can, but by logic toggle. I also think that a beam receiver is even more silly, a logic beam can already turn on and off logic bits, we don't need a new blocks to do something logic blocks already do with logic beams.

i agree with most of what you said except the last bit. i think the point of the OP is to have a block that shoots a logic beam in a straight line that is activated by logic. the camera can not do this.

 

[Aynslei]

i agree with most of what you said except the last bit. i think the point of the OP is to have a block that shoots a logic beam in a straight line that is activated by logic. the camera can not do this.

Did you miss this part "lets just let them shoot the logic beam that the core can, but by logic toggle"?
A camera can already act as the "origin point" of the cores logic beam. I already make use of this with cameras near docking ports and other locations for the ease of use, I am sure I am not the only one.

I think it would be a lot easier to implement and better in the long run to give this function to cameras, which are already used in those situations than to add an extra block to the game. (and yes logic triggered it would shoot straight like all logic triggered stuff)
Even if it could only send an ON signal, we have buttons and flip-flops to work around that.

 

[Byamarro]

That there can easily turn out to be quite some calculation, unless you make it sector based(a transmitter can only be recieved in the same sector, regardless of where it is in that sector).

regarding the first solution: see above
regarding the second solution, what is an "interferented logic signal"? a clock? a random signal? in either case, in which intervals does/may the signal change? In addition, the current logic operates event based. If a block's state changes, it send an update with the new state to the blocks linked to it. If those are logic blocks too, and their state changes, this continues, however, if their state doesn't change, they don't continue relaying the update, as no further change would occurr, since the input of the other block wouldn't change(DELAY blocks might be an exception), what this means is, that unless 2 transmitters within range both change their state to a state different from one-another within the same engine-tick, there is no conflict.

Regarding first one:
I could agree about 1 sector length range, but not sector based. It would cause odd effects like current planet gravity is (which is plate based).

Regarding second one:
1+1 = 1
0+1 = random
0+0 = 0
Or just as u said, make it event based.

2. I think adding a new beam block for getting access to the logic beam is silly. We have cameras, lets just let them shoot the logic beam that the core can

It would add uneccesarry mess to the game.
As You would switch to these cameras during combat accidentally even if they are part of some hidden logic deep inside ur ship modules.

 

[Megacrafter127]

Regarding first one:
I could agree about 1 sector length range, but not sector based. It would cause odd effects like current planet gravity is (which is plate based).

Regarding second one:
1+1 = 1
0+1 = random
0+0 = 0
Or just as u said, make it event based.

Would it? Unlike planet-plates, sectors are all aligned, AND 1 entity cannot be in 2 sectors at the same time(some parts may extend over the border, but they can't be interacted with, unless by other overextending parts from the sector. The only things, that might be affected would be docked entities across the border, but if those are indeed affected by this, they will likely also suffer from other issues.

 

[Byamarro]

Would it? Unlike planet-plates, sectors are all aligned, AND 1 entity cannot be in 2 sectors at the same time(some parts may extend over the border, but they can't be interacted with, unless by other overextending parts from the sector. The only things, that might be affected would be docked entities across the border, but if those are indeed affected by this, they will likely also suffer from other issues.

If there would be 2 entities 100 meters away but in different sectors then it wouldn't work.
And ba dum tsss, we have odd effect.

 

[Aynslei]

Regarding first one:
I could agree about 1 sector length range, but not sector based. It would cause odd effects like current planet gravity is (which is plate based).

Regarding second one:
1+1 = 1
0+1 = random
0+0 = 0
Or just as u said, make it event based.

It would add uneccesarry mess to the game.
As You would switch to these cameras during combat accidentally even if they are part of some hidden logic deep inside ur ship modules.

If there would be 2 entities 100 meters away but in different sectors then it wouldn't work.
And ba dum tsss, we have odd effect.

I am not the best with English, but I have no idea what point you are trying to make here.
Logic is already event based. The possibility of a clash is near 0 and wont cause issues to begin with.

So not taking a block that can already shoot a logic beam just not by logic trigger, but adding a whole new block can can do nothing but shoot a logic beam is being unnecessarily messy?

If you plan on shooting a logic beam inside your ship, I am pretty sure you should be using another logic setup.
I only see logic beams as a viable tool for inter ship or ship/station communication. We have better tools for triggering something inside our own ship.

As for the distance deal, making it some arbitrary number is something that would have to be balanced along side sector size.
A ships jump inhibitor will effect any ship within its sector and the 3x3x3 sectors around it. The same code that checks and responds to this can be used to send and receive a bit of logic on channels.
Having something that calculates the distance between the ship and any possible targets before each logic event sounds a hell of a lot more process intensive.

 

[Byamarro]

I am not the best with English, but I have no idea what point you are trying to make here.
Logic is already event based. The possibility of a clash is near 0 and wont cause issues to begin with.

So not taking a block that can already shoot a logic beam just not by logic trigger, but adding a whole new block can can do nothing but shoot a logic beam is being unnecessarily messy?

If you plan on shooting a logic beam inside your ship, I am pretty sure you should be using another logic setup.
I only see logic beams as a viable tool for inter ship or ship/station communication. We have better tools for triggering something inside our own ship.

As for the distance deal, making it some arbitrary number is something that would have to be balanced along side sector size.
A ships jump inhibitor will effect any ship within its sector and the 3x3x3 sectors around it. The same code that checks and responds to this can be used to send and receive a bit of logic on channels.
Having something that calculates the distance between the ship and any possible targets before each logic event sounds a hell of a lot more process intensive.

If that's event based then let's do that it will receiver will change on emitter's change.

 

[TomW1605]

If you plan on shooting a logic beam inside your ship, I am pretty sure you should be using another logic setup.
I only see logic beams as a viable tool for inter ship or ship/station communication. We have better tools for triggering something inside our own ship.

i disagree this could also be used to check if there is something blocking movement. presumably the beam will be blocked by other entities there for it could be used, in the situation of a door, to stop the closing sequence from starting until there is nothing blocking the beam from the activator on the other side of the passage.

 

[Byamarro]

Yep + sending info to nearby ships without connecting wireless blocks.

 

[TomW1605]

it would also make modular ships easier as you just need to make shaw the receiver is in the same place for each modual