max_height rednet laser communication

So this would add 2 items: Laser Pulser, Laser Receiver
both items only work when placed on the highest block in the map. The laser pulser has 4 directions. Both blocks act as "baseplates" and render their actual things 1 block above max height, this means that there will always be a clear LoS between a receiver and a pulser that have either thier X or Z coordinate aligned.

Pulser would be used as
send(side,channel,replychannel,message) side determines which of the 4 sides the pulser pulses at

Receivers get a normal rednet event

So a pulser pulses on the north side, the code will look if there is a receiver with matching coordinates that way and then trigger the event for that if there is.
This would introduce a feasible way to make long-range communications without chunkloading 200+ chunks, using http hacks, passing disks about in ender chests or similary quirky ways to go about it.

Could use nether-stars as lenses and emeralds if you want it to be expensive. Caveat also being that it has to be at max_height and can only pulse in straight lines, plus ofc you'd need 2 sets for two-sided communication.

This would actually involve having more chunks loaded to confirm a clear line of sight, as opposed to current setups where only the two chunks containing two computers with wireless modems need to be loaded. The next version of ComputerCraft will include more networking features.

No it does not, as said they are put at max height and render their actual transmission parts 1 block above that, meaning no chunks would need to be loaded (well other than the one with the pulser and the one with the receiver) as there cant be any blocks in the way

Pinkishu, on 25 January 2014 - 03:33 PM said:

No it does not, as said they are put at max height and render their actual transmission parts 1 block above that, meaning no chunks would need to be loaded (well other than the one with the pulser and the one with the receiver) as there cant be any blocks in the way

But what if there are other laser/pulsers in the way?

Symmetryc, on 25 January 2014 - 04:21 PM said:

Pinkishu, on 25 January 2014 - 03:33 PM said:

No it does not, as said they are put at max height and render their actual transmission parts 1 block above that, meaning no chunks would need to be loaded (well other than the one with the pulser and the one with the receiver) as there cant be any blocks in the way

But what if there are other laser/pulsers in the way?

Then thats easy to find when checking the laser/pulsers?

Can you do that without loading the chunks? And what purpose does this serve, exactly?

awsmazinggenius, on 25 January 2014 - 06:50 PM said:

Can you do that without loading the chunks? And what purpose does this serve, exactly?

Only chunks that would need to be loaded are the ones the sender and receiver are in. And it serves the purpose of having long-distance communication without needing quirky workarounds (like loading 50 chunks to relay soem rednet signals or having to send disks with enderchests or having to use http)

So instead you have to build a network cable up to your laser from your base, if you have one at ground level and not floating in the air. Doesn't make much sense to me.

I think that having to relay signals is a good balancing factor. And if you didn't want it, you could just set the modem distance to some arbitrarily high number in the config so that you don't have to worry about it :)/>.

awsmazinggenius, on 25 January 2014 - 07:40 PM said:

So instead you have to build a network cable up to your laser from your base, if you have one at ground level and not floating in the air. Doesn't make much sense to me.

Erm. Wouldn't you just stick a computer with a regular wireless modem next to the pulser/receiver peripherals? Which you're doing anyway if you make use of GPS / regular relays?

The practical side of the idea is purely that you'd need to load less chunks in order to run a relay across a very large distance. You're still running a relay.

Personally I rather the idea of people having to implement "quirky" solutions, rather then "build this block to circumvent the current rules". Which is why I'm still scratching my head over the coming repeater code.

awsmazinggenius, on 25 January 2014 - 07:40 PM said:

So instead you have to build a network cable up to your laser from your base, if you have one at ground level and not floating in the air. Doesn't make much sense to me.

Either use wireless or well you could build cables upwards, upwards = 1same chunk = no additional chunks need loading

Bomb Bloke, on 26 January 2014 - 12:03 AM said:

Personally I rather the idea of people having to implement "quirky" solutions, rather then "build this block to circumvent the current rules". Which is why I'm still scratching my head over the coming repeater code.

Sure, but quirky solutions are slow, need lots of chunks loaded or other unfeasible things if you want to make a server-wide network without pulling 50 http calls every 0.1 seconds or other strange "solutions"
Besides the repeater code is a quirky solution due to chunkloading. I see it more as expanding feasible possibilities than circumventing current rules. Like peripheral cables, you could do that crap before by using a second PC that would receive wireless signals and then do something and send something back and such, but it was laggy and slow.

Symmetryc, on 25 January 2014 - 10:14 PM said:

I think that having to relay signals is a good balancing factor. And if you didn't want it, you could just set the modem distance to some arbitrarily high number in the config so that you don't have to worry about it :)/>.

Except that I play on a server and nope, that isn't really a solution :P/>