Molinko

From what I understand you're on the right path. What I think* you're missing is a grouping algorithm. Iterate the table for like-pixels chunks by fore/background color and character to draw together. This should result in less gpu calls overall. I'm working on something similar

No, not that I've seen. You can use the Lua interpreter and call process.info(lvl) to explore the returned process. Beware some of the metadata is linked with metatables and so may not appear directly* on the process handle.

Here's a little demo to get you started.. But, the warning I received using this method is that it's an 'internal' method and so subject to possible change in the future. Just FYI.

local process = require "process"
local term = require "term"

local function window(program, dx, dy, width, height)
  local _window = term.internal.open(dx, dy, width, height) -- # Create a new window
  term.bind(term.gpu(), _window)                            -- # derp
  process.info().data.window = _window                      -- # Get current process, tack _window unto ...data.window
  os.execute(program)                                       -- # exec program as child process. It inherits our term window via process magic*
  term.clear()                                              -- # clean your fuckin' room
end

window('/bin/dmesg.lua', 10, 5, 65, 20)	-- # Do the dew

Let me know if this need clarification. I'll try to help  

That library part is for delay loading and shouldn't be something you need to touch. Just require the keyboard library like normal. To check for key presses other than printable chars use keyboard.isControl(char:number)  or catch the key event and compare char codes with entries in the keyboard.keys table.

Both the modem card and the Redstone card have wake methods. See the docs specifically for the mentioned component APIs. I believe they're redstone.setWakeThreshold(level:number) and modem.setWakeMessage(message:string). See http://ocdoc.cil.li/component:modem. Also, pretty sure the modem will still need to have a port open to receive the wake message but don't trust me on that. Test it out

Good suggestion Cpt. I'd also like to suggest table.concat as well.

local input = io.read()
if not tonumber(input) then
  -- input is not a number
end

This is working great, although I have some questions. I have read the docs, man, and readme files.

Is there a way to route the LAN traffic of a local Relay with a Linked card to a server with the matching linked card?

This is the current network diagram.

c1---r1--c2         c:computer#n, --:wired connection, r1:relay(with link to s1)

s1--back--s2     s1 wired via internal 'back' bus to s2 (s1 has link to r1 | s2 has link to r2)('link' is a linked card)

c3--r2--c4          c:computer#n, --:wired, r2:relay (with link to s2)

I hope my diagram makes sense. Am I routing all wrong? Does minitel just not support routing via linked cards? Or is it just Links via switches? I'm a bit lost

Thanks in advance for your input.

@CptMercury nice detective work. Helpful and informative response. A+

@RGB_Leader You can try this program from the forums by @Nexarius. You can download it from pastebin or github using an internet card and the pastebin or wget program. This has worked for me in the past although I cant speak as to how far back compatibility will be possible. Anywho, it's worth a shot as I have had similar issues before with a version of OpenOS not having the thread library and this worked great for me. Good luck  

@BrisingrAerowing, Thanks for the clarification. I was under the impression that the only issue was the OpenOS thread library, which could be downloaded with the latest OpenOS version and without actually needing to update the OC mod itself. My misunderstanding.

@RGB_Leader, XyFreak is referring to OpenOS, the open source OS of Opencomputers. Not the mod or mod pack. You can find it on GitHub.

This is working great for me! Really sweet and tiny too! Although the link to your demo is down.. I'd like to see some examples thank you very mucho.

The problem with your code on the left is that you never define the value of the variable 'message', so when you try to print it you get 'nil' which in lua is a value for nothing. When calling the function event.pull you must capture the return values and store them for use at a later point in the program such as printing or whatever. Here's an example.

-- # your code above. this is just in the loop
while true do
  -- # event.pull 'modem_message' return multiple values the fifth being the message data.
  local laddress, saddress, port, dist, message = event.pull("modem_message")
  print(message)
  if message == "test" then
    computer.beep()
  end
end

Hope this helps. Feel free to ask anymore questions  

The first line 'clear' should be 'term.clear()'. That's what's throwing the error.

Threads are just fancy coroutines. This means that they still have to obey and yield like any other process, coroutine, or block of code. All blocks must yield or finish execution in a 5 seconds or they are terminated. Looking into your code as it's arranged now I would suggest yielding once or perhaps several times throughout the checkDmg function depending on the drawing performance. Here would be my two suggested alterations..

function checkDmg()
  local dmg=0
  for i=1,li-1,1 do
    if inv.getStackInSlot(2,lzhs[i][3]) then
      dmg=inv.getStackInSlot(2,lzhs[i][3]).customDamage
      fillDmg(lzhs[i][1],lzhs[i][2],"LZH",dmg)
    else
      fillDmg(lzhs[i][1],lzhs[i][2],"LZH",100000)
    end
    coroutine.yield()
  end  
  local r
  for i=1,ri-1,1 do
    r=inv.getStackInSlot(2,rods[i][3])
    if r and not string.match(r.label,"Depleted") then
      dmg=inv.getStackInSlot(2,rods[i][3]).customDamage
      fillDmg(rods[i][1],rods[i][2],"Rod",dmg)
    else
      fillDmg(rods[i][1],rods[i][2],"Rod",20000)
    end
    coroutine.yield()
  end  
  for i=1,vi-1,1 do
    if inv.getStackInSlot(2,vents[i][3]) then
      dmg=inv.getStackInSlot(2,vents[i][3]).customDamage
      fillDmg(vents[i][1],vents[i][2],"Vent",dmg)
    else
      fillDmg(vents[i][1],vents[i][2],"Vent",1000)
    end
    coroutine.yield()
  end  
end

td=thread.create(function()
  while true do
    checkDmg()
    os.sleep(0) --# sleep will yield this process/thread and resume asap allowing the 'following block' to begin execution.
  end
end) -- # no need to detach unless you really want this to continue after your program is dead..

-- # the 'folowing block'
print "Now executing main block..."
while true do
  local _continue = handleEvent(event.pull())
  -- # do shit
end

The first example yields the 'td' thread once for every cycle of each inner loop. Mostly because of the drawing and the inv component calls. This costs time! So we yield and allow the event loop below to begin. This is my recommended solution although untested. The second example will yield the 'td' thread once after each call to checkDmg. This could work fine but I suspect the first option will perform better / be more responsive to events.

Lemme know how it goes and if I can help anymore.

You can mock events with computer.pushSignal or event.push.

The mouse position is only available through the aforementioned touch event. It's a client server lag thing.

The OpenOS operating system is itself a program. It needs ram too. It's the most complex program likely to be running on most OC computers. Also, it's a program that runs and controls 0 or more programs, so it uses a bit of ram. However things like the microcontroller don't load an operating system and so 1 tier 1 stick is usually quite enough for most things.

The error is no bootable medium. You needed something to boot. An OS. Stuck an OpenOS floppy in there and run the install program.

It could perhaps be an out of memory error? The getting started tutorial says to use a 1 tier 1 memory stick. Though technically OpenOS has been optimized to run on one it could help to add more memory to the computer. If I'm going to be able to continue to be any help I'm going to need an error message or at least some pictures to let me know where to start looking.

Have you run the install program for OpenOS? Do you get any errors?

@payonel Howdy! About the term lib documentation; I was specifically referring to the doc for term.bind. The optional [screen & keyboard] parameters suggested in the doc dont seem to have an actual implementation in the current OpenOS( although at the time of this response i havent bothered to double check that. Just referring to previous hair pulling encounters ). Ill add a ticket tomorrow if I dont totally space.

You did warn me about messing with anything under the .internal space of an OpenOS lib, but I like dancing on sharp edges  . Love what you're doing with the place too! (OpenOS)

Third. Yup. I want a full tty pty abstraction layer for programs but after looking into how to pull it off myself I figured I'd wait for you to do it  , lol.

8 hours ago, payonel said:

The idea is this: term doesn't bind to a gpu, and tty doesn't bind to a gpu, the PROCESS is bound to a gpu.

This is definitely illuminating for me as, for me at least, this wasn't straight forward to grok just peeping the source. Thanks for that. OpenOS is my first use of any linux like OS arch and I'm learning a lot.

I really like the dev system. I want to learn to exploit it a lot more. That example is actually the first use i've personally thought of for it and that only happened because looping several type of components and binding screens, gpus, and keyboards can be quite tedious  .

Thanks for the input. Always a pleasure.

If you had installed then this shouldn't be your issue as (newer versions of) OpenOS caches the boot drive in the eeprom upon installation. Successive boots should boot from the hdd with the os installed. Though the fact that the autostock program itself is running from /tmp and looking for the config in the /autostock dir, which is in root dir (barf), is a sign of either improper installation or perhaps just poor software quality in the port to OC. Preferably user level programs should be installed somewhere above /home or /usr or even /home/usr. Likewise their libraries or configs probably shouldn't be in the root folder. If you're still having issues later then hit me back up here(this thread or PM), and you can walk me through how you're installing the program.. good luck bud

Have you installed OpenOS to the hdd with the install command? It looks like the program is installed to /tmp and the directory /autostock indeed doesnt exist because you booted OpenOS from the floppy? Just a guess.