Molinko

I would recommend using strictly local variables. Your problem is coming from the fact that the variables _rpx and _rpy are expected to be global but are only initialized in the 'printBack' function.

This is a problem for the definition of 'readUrl' above that which expects _rpx and _rpy to be able to do its job. I believe a simple fix would be this....

I think this is your issue... Im afraid i haven't had the chance to test. Good luck

I was stupid.. Your problem is on line #52.

term.setCursor(rpx, rpy)

should be

term.setCursor(_rpx, _rpy) -- you named the variables with underscores

Hope that helps... :/

The component lib must be loaded with the require statement. In CC you would call global fn peripheral.wrap. In OC...

local component = require 'component'
local modem = component.getPrimary 'modem'
--...

Post you code. All of it. Then I can help you

I would recommend not executing strings sent down a network.. If you're just in a SP world then fine, have at it. But, if you're on multiplayer then this is a big security problem. Just saying..

A better solution would be to design commands / responses with parameters that can be sent between the client and server. i.e.

-- # On the server

-- # Other code implied up hurr...

local commands = {
	openIris = function()
		if s.irisState() ~= 'offline' then
			m.send( f1, 20, 'Opening Iris.' )
		end
	end,
	dial = function( address )
		if s.irisState() == 'idle' then
			m.send( f1, 20, string.format( 'Dialing %s', address )
		end
	end
	-- ... more commands go here
}

-- # on message...
-- # cmd should look like: { 'dial', 'kjai2sdiwdSOME_ADDRESSksjdlaks' }
local cmd = { string.match( message1, '(%a%d_)' ) }

local command, args = table.remove( cmd, 1 ), { table.unpack( cmd ) }

-- # This calls our command with any args sent with it. This is safer than load('msg') because 'msg' could be malicious.
commands[ command ]( table.unpack( args ) )

-- # DISCLAIMER: I haven't run this code. Could have bugs. But this is generally how I handle commands over the net.

Let me know if I need to clarify anything...

I think this is what you mean...?

local term = require 'term'
local component = require 'component'
local gpu = component.getPrimary 'gpu'

--          text                   color          palette color? (true or false) (optional)
-- Takes ( 'some string to color', number_color, [isPaletteColor] )
local function cWrite( text, fgc, pIndex )
	local old_fgc, isPalette = gpu.getForeground()
	pIndex = ( type( pIndex ) == 'boolean' ) and pIndex or false
	gpu.setForeground( fgc, pIndex )
	write( text )
	gpu.setForeground( old_fgc, isPalette )
end

-- Usage:
cWrite( 'Hello colorfully', 0x2E86C1 )

-- Or with a palette color..
cWrite( 'Hello colorfully', 1, true )

event.listen works like this.... 

-- your handler
local function doOnEvent(event, ...)
	print( event, ... )
end

-- pass handler to event.listen to be called when there is a 'key' event.
-- It will recieve the event and any other pertinent parameters like which key was pressed.
event.listen( 'key', doOnEvent )

-- Pass event.ignore your previously registered handler to stop it from passing any future event when we're done.
event.ignore( 'key', doOnEvent )

My point is that event.listen( 'someEvent', handler ) will be called even after your program has ended. So, if you were experimenting with it and registered a handler that prints an event

then perhaps that is the result you're seeing printed to the screen. The wiki says that if your program registers a handler and your program calls event.pull, both will get the relevant event.

Hence why your program may still be printing although you're only pulling an event... I hope this helps... If not.. kill it with fire and make a new one

A. Have you called event.listen with a handler that prints in a previous program or the lua prompt??

B. Can I see your code for the program if your problem doesn't extend from A?

I'm fairly sure the relay will interface with cc network cable and reciece wired messeges. I don't think its meant to be a modem for cc. Hook up a cc wired modem to a cc computer and run cc network cable to a relay on an oc network.

For your first question, you're spot on.

Var args are passed like a function to a program. I'm not sure if they're all strings and/or numbers.. You might have to parse em.. Try something like this..

local args, opts = shell.parse(...)

Put eeprom in eeprom slot with 'luabios' eeprom.

The receiving computer must specify a port to open. It can the get messages over that port.

Line 64 "::settingsentrence::" <-no.

The next line is term.clear()....

When prototyping libs its helpful to put this at the top of your script to reload a specific library loaded with require.

_G.packages.loaded["myLibFileName"] = nil

-note the file name is extension less,

And should be used before your call to require your lib.

Event.listen runs above your program. Every time you 'touch' the os calls the function passed to event.listen. no need for the while loop. At the end of you program remove the listener so it doesn't continue after your program exits

This would be my implementation of my suggestion... Just for shits..

local players = {}
for _, name in pairs(acceptableEntities) do
  players[name] = name
end

local function isValid(name)
  return players[name] and true or false
end

while true do
  local _,_,x,y,z,entity = event.pull("motion")
  if math.abs(x)<= tonumber(range) and math.abs(y)<= tonumber(range) and math.abs(z)<= tonumber(range) then --if recieved motion was within range
      if isValid(entity) then -- entity will always be a string. So will program arguments
        redstone.setOutput(side,15)
        os.sleep(stayOpen)
        redstone.setOutput(side,0)
        break --no need to continue testing if one is valid
      end
  end
end 

I just saw that you made an update while i was mid-post. Almost what I was thinking..

Its a nice program. A suggestion of mine would be to use a lookup list to speed up the indexing of vaild players. i.e

local players = {

Sangar = true,

Gangsir = true

}

Then...

if players[player.name] then ...

This will be faster than looping the ordered list.

Hope this is helpful

Go to the root directory '/' by typing 'cd /' and hitting 'enter' key.

run this program 'wget' like so... "wget https://raw.githubusercontent.com/OpenPrograms/Sangar-Programs/master/geo2holo.lua geo2holo.lua"

You don't need the quotes when you run wget. The program will be saved as "geo2holo.lua". Run "geo2holo.lua" to start the program.

Take a look at this example program Sangar made that does just what you're looking for.

function textTools.centerText(_str, x1, x2)
    term.write( text.padLeft(_str, x1 + math.floor((x2 - x1) / 2) - math.floor(#_str / 2)) )
end

I think that'll do what you need bud.

component.inventory_controller.address

*remember lua is case sensitive.

Thank you!

Now one more question. To refer to the inventory controller by address I would replace

"component.inventory_controller" with "component.Address" ?

As I understand it, it is used to run multiple *.lua scripts at the same time, what I need is running multiple functions at the same time.

I might consider just porting the parallel api from cc if that's what you want.. Its not that big of a lib and fairly strait forward

I have an idea to get you started on porting this to OC. There are a few libraries that aren't available globally like their CC counterparts.

I.E. the term library isn't global and yadda.... This is a step to get you on your way.

-- Component lib for access to the gpu
local component = require "component"

-- Put term lib into local space..
local term = require "term"

-- Other libs we need as well
local colors = require "colors"
local textutils = require "serialization" -- CC to OC. The 'serialize' method is used the same here i think....
local gpu = component.getPrimary('gpu')
local fs = require "filesystem"

-- 'term' Compatibility. These libs are similar in interface but OC lib has shorter method names. 
term.setCursorPos, term.getCursorPos = term.setCursor, term.getCursor
term.setTextColor, term.setBackgroundColor = gpu.setForeground, gpu.setBackground

This should solve a decent portion of compatibility. Hope this helps.. Post back if you have questions..

If you have autorun.lua enabled by default in OpenOs, which I believe it is by default, the easiest way is create a new file in / dir named 'autorun.lua' and save this text...

<CODE>

os.execute("resolution Xwidth Yheight")

xwidth and height are strings of the number width and height you want

<\CODE>

FYI you can put some upgrades in the adapter block I.E. an inventory_controller

To see chest contents and I believe manipulate them.