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

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:

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:

Except that I play on a server and nope, that isn't really a solution

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

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)

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

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

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

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.

local tAPIsLoading = {}
function os.loadAPI( _sPath )
local sName = fs.getName( _sPath )
if tAPIsLoading[sName] == true then
printError( "API "..sName.." is already being loaded" )
return false
end
tAPIsLoading[sName] = true

local tEnv = {}
setmetatable( tEnv, { __index = _G } )
local fnAPI, err = loadfile( _sPath )
if fnAPI then
setfenv( fnAPI, tEnv )
fnAPI()
else
printError( err )
		tAPIsLoading[sName] = nil
return false
end

local tAPI = {}
for k,v in pairs( tEnv ) do
tAPI[k] =  v
end

_G[sName] = tAPI
tAPIsLoading[sName] = nil
return true
end

as seen a tEnv is created, and the function that will create the functions of the API is placed into it, then run, now all the functions have been created in tEnv, now all the functions are copied over to another table, tAPI, then that is set to the _G key (which is the api name).
A bit of a weird thing to copy them over into another table, why was that done? The result is that any "global" variable create by the functions in the API will neither be in _G nor in the api table but in the fenv of the function

so if a function in the loaded API was

function foo()
  bar = "foo"
end

bar would neither be _G.bar nor in the _G,apitable.bar but getfenv(_G.apitable.foo).bar

(and why does this forum make my topic title weirdly capitalized..)

This bug seems to fit into a collection of bugs happening around startup
(also tested with 1.5.2 direwolf20 1.1.3 pack)

rs.setOutput("front",true)
print(rs.getOutput("front"))

will output "false", even though it should output true.
No, the delay between the 2 doesn't matter, if the program is run as a normal program it works without any issue, it just fails if it is the startup file and ran when you restart the computer (also ofc things started by the startup file)

So while

rs.setOutput("front",true)
sleep(0)
print(rs.getOutput("front"))

fixes it

sleep(0)
rs.setOutput("front",true)
print(rs.getOutput("front"))

does too, or running it from shell instead of from startup

(Note: this is a simplified version, the full example used bundled cables and a function to add or remove colors from the cable, uisng bit.band/bit.bor/bit.band and rs.getBundledOutput to work, ofc since getBundledOutput passed back 0 even though it was set to something else previously, it screwed up the process)

Well it doesn't with the code I posted, what is improper about it?

theoriginalbit, on 22 September 2013 - 12:58 PM, said:

Yeah you can create files, but why not follow Lua Reference Manual standards?

Uh, this isn't "Ask a Pro", it's a suggestion to make CC create a file when trying to open a non-existent file in "a" mode

f = fs.open("blahhh","a")
if f then f.close() else print("no file") end

will print "no file" if "blahhh" doesn't exist; but if you use "w" mode, it will create the file
"a" should create the file too though

Supported by

Lua 5.1 Reference Manual said:

Various Sources said:

Lux, on 30 August 2013 - 05:11 AM, said:

That would be a word behavior... why would the chunk be unloaded and reloaded Oo

Same with MFFS.

MFFS people say CC has to fix it because of computers being a complex block or so
Not sure about RiM, but for MFFS i think it doesnt actually "restart" the PC but move it without moving the PC tileentity or state or something, causing the PC to startup again after the move with a new tileentity/state

I put a chat box thingy (from misc peripherals) on top of a PC and moved both with MFFS, the PC would read the chat event from the chat box and respond using the chat box, after moving now you got 2 responses though, after moving it again you got 3, etc; which hints to what i explained before

you're basically spamming rednet by broadcasting a function ID every 0.05s, i wouldn't be surprised if it gets laggy/freezes
i guess you wanted to do rednet.broadcast(io.read()) ?

Also, you're never pulling any events in your coroutines and sleep() will eat a couple events, so it never clears the screen because theres never any reason for it, because event doesnt become "key" and such

Also if you want to keep the code that way, you'll probably have to remove the local from the rednet.receive line

Or at least I think the way it currently is, the select function wouldn't even know about the msg received?

I remember someone doing that with rp2 magtubes xD ofc with teleportation its even better

So yeah, something I always wanted and it should be quite possible.

If i put programs into my resource pack, I should be able to access them on PCs that I access in SMP. Maybe not run them but at least do like cp res/blah.lua blah.lua
and then run it or something like that, saves the whole hassle of going through pastebin, writing down the code, etc

now i can't overwrite programs that are already in ROM or such

(yeah, the client would have to send the program to the server)
(no, there are no security issues as i could just enter the program anyway)


doubt this will get implemented, partly because the serverside lua probably doesnt know who started it, but eh thought i'd post it

Mads, on 20 July 2013 - 02:56 AM, said:

Assembly is too easy, do it in notepad

Not exactly programming jokes i guess but:
What does the “B” in Benoit B Mandelbrot stand for? Answer: Benoit B Mandelbrot.

and

A TCP packet walks into a bar, and says to the barman: “Hello, I’d like a beer.” The barman replies: “Hello, you’d like a beer?” “Yes,” replies the TCP packet, “I’d like a beer.”


A bit more about programming but not exactly a joke:

Random point: I think the only time i'd start liking ingame editing is when CC displays get bigger and the lag would be gone

Freack100, on 08 July 2013 - 09:47 AM, said:

Wow, people sure got paranoid over that stuff

And doesn't look very similar even to me

jesusthekiller, on 25 July 2013 - 10:10 AM, said:

What makes you believe it isnt?

Well you told me to look at the code, the only available code is the small program that you posted that 1lann made, so I commented on that

Which code? 1lann's? Isn't IRC

I mean IRC in CC using rednet nothing more nothing less

PixelToast, on 23 July 2013 - 11:30 AM, said:

A "real" IRC client is any client that implements the IRC protocol.

The RFC just specifies: A client is anything connecting to a server that is not another server.
thus even a "rednet based" client would be a "real" one