payonel

https://github.com/MightyPirates/OpenComputers/issues/2987

`setWirelessFrequency` was a method for rednet wireless redstone, which integration was removed in and after 1.11. in 1.12 we only have redstone and bundled redstone

also, updating is a great idea a whole lot was fixed, This is a patch release intended to fix a lot of issues

@Molinkois correct that these things become complex quickly, but I think it is a LOT of fun  

things like term.write, print, and io.write call io.stdout:write. (by default) io.stdout is the tty stream, and io.stdout:write is

https://github.com/MightyPirates/OpenComputers/blob/master-MC1.7.10/src/main/resources/assets/opencomputers/loot/openos/lib/tty.lua#L76

@SpaceBeeGaming thanks for helping a fellow user I also believe 2 of us already pointed that out and the user acknowledged the mistake already (i.e. read the whole comment thread)

that is a ComputerCraft disk drive, not the OpenComputers disk drive

I need to see how your disk drive is "connected" to this computer

this is fixed in our dev builds for 1.12, btw

Here is basically everything you would ever want to know about startup scripts and such: https://ocdoc.cil.li/tutorial:autorun_options

For your needs, I would write a script in my home dir that cleared the screen, set the resolution how I wanted it, and wrote the message, and then waited for user input or something to keep it from closing the program and returning to the shell:

local term = require("term")
local gpu = require("component").gpu

term.clear()
gpu.setResolution(20, 5)
term.setCursor(5, 3)
term.write("Hello World")
term.read()

When you execute this script, it'll probably do something like what you want. To have this script when your machine is booting, just specify this script's filename in your /home/.shrc

So Let's say this script was `/home/billboard-message.lua`

I would edit `/home/.shrc`, and just write that script path in

`echo /home/billboard-message.lua > /home/.shrc`

i do want to point out that plan9k is pretty outdated, will be removed from loot disks in a future release (not the next patch, but after)

A thing microcontrollers are better at than a normal computer (built with a case) is they can house upgrades and run on very low power. World interaction upgrades, such as the tank controller, require a robot or drone. Computer cases do not have an "upgrade" slot

your comments in the tty changes are quite...passionate

why did we have such weird \r handling? because users were copying strange mixtures of part mac, part windows, part linux files where line-endings weren't always complete, or fully copied., The output wasn't what they wanted. I agree that \r should be x=1. I might make that change myself.

additionally, yes, \b i should have added

I don't have any problem ignoring the charset change code.

the version of tty and vt100 you have copied appear to be somewhat old, but i do recall making some vt100 fixes, might even be related to reverse video. In my latest dev builds the vt100 code has been improved (and is slightly faster for some workflows). But if you could point me to what you fixed, I could integrate that to our vt100 code.

All in all, i'd be happy to considering merging your changes/fixes to my tty code so that future versions of oc work with your software without users having to update openos (Which will become more of an issue once we release our next update because your modifications to these files are no longer compatible)

on another note, i've given considerable work to separate the cursor layer from the tty layer. it's not a true api yet, but close. It would be quite possible to leverage the cursor library code (in latest dev builds of oc with openos) to handle the cursor and proper blinking with your project. I might poke at that one day. ping us on oc if you want to chat about your really cool project here

oc wired and wireless modems have addresses, and when you send a message you either broadcast or send to a specific address. You can think of this as its MAC.

lua strings are technically just binary blobs, they can hold any binary data (yes, 0s included)

@Elijahlordencould you just remove the / from

local file = io.open("/InstallData")

to be

local file = io.open("InstallData")

should work just fine, for both those that think they still need to `cd /` and those that forget/don't know

io.open uses relative path from the current working directory

This isn't a bug, per se, but you are venturing into unsupported territory of openos

For performance reasons and simplicity of code, the core of openos is optimized for the most common workflow, which is 1 screen. There is caching involved in the tty layer of openos to read and write to the same screen and gpu.

Some day I'll provide a userspace api for managing multiple screens and multiple windows

You'll need to release the keyboard manually See, I just don't support this in openos

`require("tty").window.keyboard = nil`

1. This is NOT future proof. When the day comes that I build a multi-screen and multi-window api layer, I am free to change this data structure.

2. Yes this is safe to do (in openos today), the code expects that the kb can be "released" like this

3. I would do this after you switch screens on the gpu

local component = require("component")
local term = require("term")
local text = require("text")
local r = component.redstone

---- config section
local password = {["1234"] = true, ["foobar"] = true}
local delay = 5 --time the door stays open
local side = 5 --side of the door, test this
-----

local wrong = false

while true do
  term.clear()
  if wrong then
    print("Password was wrong, try again")
  else
    print("Please enter the password")
  end
  wrong = false
  local input = text.trim(term.read({pwchar='*'}) or "")
  if passwords[input] then
    r.setOutput(side, 15) -- check if this is the correct function
    os.sleep(delay)
    r.setOutput(side, 0) -- same here
  else
    wrong = true
  end
end

I read what RS devs had to say about the issue, and the problem you are running into is that you are trying to make an exact match, which requires you to specify all the tags of an item. You can't omit some you don't care about. I recommend you do a more general search for items, select the one you care about, and then reuse the search result for future exact searches.

you'll need to share all the code you are using in each side

You can use an item while "sneaking" with the robot

component.robot.use(side: number[, sneaky: boolean[, duration: number]]): boolean[, string]

see https://ocdoc.cil.li/component:robot

the `block_refinedstorage_grid_2` component is kindly provided by refined storage: https://github.com/raoulvdberge/refinedstorage

And in their integration source, they provide the `getItem` component method: https://github.com/raoulvdberge/refinedstorage/blob/mc1.12/src/main/java/com/raoulvdberge/refinedstorage/integration/oc/EnvironmentNetwork.java#L299

I don't know how their compare methods work (you can ask them for more support)

But it looks like their getItem method takes a couple extra boolean params for comparing meta and nbt. perhaps you could try `getItem({...}, true, true)` or some variation of those

also, that tutorial is super old

it still works, it appears to have valid instructions

but i would recommend just installing openos and rebooting so that your normal filesystem (your root filesystem) is readwrite

follow this tutorial: https://ocdoc.cil.li/openos

with an inventory controller, you can inspect stacks in inventories. Place an item you are curious about in a chest, then call component.inventory_controller.getStackInSlot to load data about the item you placed in the chest

see https://ocdoc.cil.li/component:inventory_controller

I suspect you tried to run your system on very low memory, and the package library crashed at some earlier point in your workflow, some evidence of this is that you are using `list`, and not `ls`

Reboot your system, use only `list` if you are running on ultra-low memory

Also, consider adding more memory please. Even 1 stick of tier 1.5 ram is far superior

well...there is plenty of magic in it reading through the source would still be quite rewarding

2 hours ago, Elijahlorden said:

it seems that Threads allow for preemptive yielding

Our OpenOS threads are not preemptive, but they are also not overtly cooperative. The primary purpose of the thread library was to provide a seamless threading api that doesn't require you to manage the threads, but just trust that they will resume and yield on their own schedule (following one basic rule [continue reading])

Here is the key to understand. There is a single common limitation to your threads (openos threads) and every other normal program you write for OpenOS (and any program on OC machines) : They must periodically make a system yield (i.e. computer.pullSignal). Note that event.pull and os.sleep also call computer.pullSignal. Even calling coroutine.yield on your bottom level coroutine is sufficient (doing so is similar in affect to calling computer.pullSignal or event.pull with no timeout argument). All of these methods are functionally equivalent to computer.pullSignal, which is the "system yield", which you must do periodically. And running code in an openos thread has the same requirement, otherwise it would continue to run and rob the cpu from running other code that would otherwise know to system-yield. The trick I built into the threading library, is that when a user thread makes a system yield call, the threads transparently yields to the threading manager and can switch between programs.

Another key design I put into the thread library was that code in a thread that is using the results of the pullSignal calls (event.pull, etc) should behave identically whether it is run in a user thread or on the main system process (where everyone is normally running all of their programs, without using the thread api). To a degree, your code shouldn't know (or shouldn't have to know) that it is running in a thread (at least from my library design point of view). Your reasons for pulling event signals, yielding, making child coroutines (or even more child threads) should all behave the same whether you're in a thread yourself, or on the main system process. Yes, this particular design feature was a tremendously complex puzzle to solve, and EXTREMELY satisfying to get working

my code sample isn't using the predefined millibucket values at all. It reads user input and tries to convert it to a number. If you want to build something more clever that does a lookup for predefined sizes, you'll have to design that yourself. Here are a couple of snippets that would do some of what you're saying.

local size = tonumber(arg)
if not size then
	if arg == "ingot" then
		size = 144
	end
end

or

local predefined_sizes = {
	ingot = 144
}

local size = predefined_sizes[arg] or tonumber(arg)

I could write the whole program, but you'll learn more if  you test your ideas yourself.

There is a good online manual for learning lua: https://www.lua.org/pil/