payonel

`io.read()` returns a string, and you want a number, there is a core lua function to convert strings to numbers: `tonumber(string): number`

so something like:

`local num = tonumber(io.read())`

would be fine

note that tonumber returns nil when the input can't be converted.

Also, I strongly recommend you get in the habbit of declaring everything local, unless you are intended to modify the global state of the operating system, and future scripts that you run, at least until the next time you boot. Thus:

local component = require("component")
local sides = require("sides")

local ingot_mb = 144
local nugget_mb = 16
local block_mb = 1296

while true do
  local arg = io.read()
  if not arg or arg == "end" then
    break
  end
  local num = tonumber(arg)
  if num then
  	component.transposer.transferFluid(sides.south, sides.north, num)
  else
    print("could not understand", arg)
  end
end

in the more recent versions of OC (check out the dev builds for 1.7.10 and 1.10, I haven't merged up to 1.11 and 1.12 with all of these fixes as of this writing, but will "soon") it is safe/reliable to run gui programs from your .shrc

the gui program for brgc is `brgc_gui`, so this should be sufficient to run the gui at start up

echo brgc_gui >> /home/.shrc

though this will probably work just fine in the version you are running, try it out. update if you have issues

You need to read that whole page I linked. It literally tells you how to do that.

13 minutes ago, payonel said:

I'm quoting from that page I linked you: "Don't forget to add brgc_reactor, brgc_turbine and brgc_grid to your /etc/rc.cfg if you want to start the controller at boot time:"

That is what I said to you in my last post. Again, "if you want to start the controller at boot time"

"start at boot time" IS literally what you are asking for, for it to "autorun"

also, if you want more information about autorunning programs on OpenOS in general, read this: https://ocdoc.cil.li/tutorial:autorun_options

But that covers all of the options, and is not specific to this program nor the service that XyFreak made for it

1 hour ago, XyFreak said:

With OC on linux servers and using Lua5.3, calling setControlRodsLevels on any reactor will cause the function to return

I think you are using this on the br_reactor, yes? I found the br code for that here: https://github.com/ZeroNoRyouki/BigReactors/blob/master/src/main/java/erogenousbeef/bigreactors/common/multiblock/tileentity/TileEntityReactorComputerPort.java

Strangely, there is no setControlRodsLevels method on that component. There is a setAllControlRodLevels. I searched the commit history on the component and there never was a setControlRodsLevels, nor a get*. I also checked the original BR code, same story there. So I"m confused what method this was calling. Searching the entire code base of ER also came up empty. Is @ZeroNoRyouki available to discuss this?

1 hour ago, XyFreak said:

the function in question takes an array/table with keys starting at 0 instead of 1. There is also getControlRodsLevels which returns a table you can pass to setControlRodsLevels. Doing so is the easiest way to trigger the issue on any reactor

I'd be happy to test this and review the related ER code, but as I stated above, I couldn't trace it.

Thanks

@Sindor Nex

I'm quoting from that page I linked you: "Don't forget to add brgc_reactor, brgc_turbine and brgc_grid to your /etc/rc.cfg if you want to start the controller at boot time:"

If that sounds like what you asked for:

9 minutes ago, Sindor Nex said:

Im looking to get your program to auto start on its own every time my server restarts

Then read more of that page: https://tenyx.de/brgc/index.html#setup

If that isn't what you're asking for, you'll need to explain yourself a bit more.

@Sindor Nex

It is well documented here: https://tenyx.de/brgc/index.html#setup

18 hours ago, XyFreak said:

bug with OpenComputers and Extreme Reactors when using Lua 5.3.

what bug?

our screen resolutions are not exposed in the config. you can make a multi-block of screens though, if that helps. they auto connect, and I think they have a 6x8 max grouping, or something like that

2 hours ago, Crayven said:

Changing resolution results in less detailed...

If you increase your font size, you are reducing the number of lines you can print to

If you decrease your resolution, your font appears larger, and you reduce the number of lines you can print to

It is effectively the same

nothing has changed in the term api, and there was never a way to change font size, only ever could you change the resolution, via the gpu

require("component").gpu.setResolution(newWidth, newHeight)

5 hours ago, standinonstilts said:

 

local t1 = thread.create(handleMessage()) 

This is definitely not a bug in the thread library, but instead you misunderstand what this code is doing -- having nothing to do with threads, but in the logic of the code you have written

You are attempting to store the thread.create result in your local variable, t1 -- nothing wrong there

thread.create takes a single parameter, a FUNCTION. `handleMessage` is a function, but `handleMessage()` is the invocation of that function. Thus, you are attempting to pass the RESULT of `handleMessage` (i.e. the value returned by `handleMessage`) as the argument to `thread.create`. Thus, `handleMessage()` executes, and must complete and return a value before thread.create is called

What do you think this code would do?

local function a()
	return "foobar"
end

local function b(value)
	print(value)
end

b(a())

compared to if instead of calling `b(a())`, you were to call `b(a)`

To fix your code, you need to pass the function, not the result of the function:

local t1 = thread.create(handleMessage)

Your code is stuck executing handleMessage(), and never returns to thread.create

OpenOS has absolutely proper pipes now, such as those  you invoke with `cat file | grep foobar`, and a kick butt threading library (read https://ocdoc.cil.li/api:thread )

As for virtual components? No, there is nothing built into OpenOS for virtual components, but gamax92 has written a nice vcomponent library you can add via oppm, `oppm install vcomponent`

Plan9k is retired, to be honest. It was ahead of its time, but is now outdated. OpenOS is faster, lower memory, has gobs of great libraries, super awesome command line parsing, and is ACTIVELY developed. I might be biased....

> I want to create a server that pulls the modem_message event and prints to the console

Cool, you can `listen` or `pull` for that event

> but I also want the computer to be able to send messages (based on io.read()) while waiting for a message.

`listen` works well for background handling, while in the foreground you are doing other work (such as io.read). However, you want your background to also print to the console? That'll obscure/interfere (visually) with the io.read getting user input. But okay

> I tried using threads

Sure, threads can do this job too. With threads, your event handling can be designed in a more selfish manner. You can `event.pull` and such without worrying about blocking the rest of the system

> but I think I am using them wrong.

Feel free to share some code!

> As far as I know there is no thread.sleep() so I'm not sure how to suspend a thread for a short period of time

No, there isn't. But, calling `os.sleep` from inside the thread is identical to what you would expect from `thread.sleep`. **HOWEVER** (please keep reading)

> so that you can still type messages, but still have that thread automatically continue. How would I go about doing this?

I wouldn't call `os.sleep` in THIS program because you want your thread to handle specific messages. `os.sleep` is a RUDE sleep, it DROPS events in the garbage. If any modem_messages occur during the sleep, you missed them. Instead, just pull with a timeout, `event.pull(.5, "modem_message")` in fact, I don't see the point of giving a timeout at all. Is your modem_message thread doing anything else or just waiting for modem_messages? Just call `event.pull("modem_message")` in your thread, done

local thread = require("thread")
local event = require("event")

local t = thread.create(function()
	while true do
		local pack = table.pack(event.pull("modem_message"))
		print(table.unpack(pack))
	end
end)

while true do
	local command = io.read()
	if command == "quit" then
		break
	end
end

t:kill()

BTW: os.sleep *does not* rob events from any other thread or process, it only throws away events of its own process

From the screen shot, it actually appears that the `getPlayers()` function is returning an array (a type of table), so while _Jacques is being helpful, the code sample they provided won't work. However, I do highly recommend you read the lua.org links _Jacques provided. Those will definitely be good to read

try this

local component = require("component")
for _, player in ipairs(component.radar.getPlayers()) do
	print(player.name, player.distance)
end

Our `components` command line program can help too. It lists components attached to the system, but you can pass an argument to filter the results to components that match the name you ask for, and that can be a partial match too

`components file`

will list all `filesystem` components. Also, you can get the "long" output, which prints the methods and method documentation string

`component robot -l`

Which prints the robot component and its methods

Now, this can fill up more than a screen's worth of output, you can pipe to `less` and scroll up and down to read the text

`component robot -l | less`

On older versions of OpenOS, our `less` program was a bit buggy. Sorry about that.  Update if you can, it works very well now. If you are unable to update, you can also redirect the output of commands to a file for reading with `edit`

`component robot -l > /tmp/robot-methods.lua`

And then open the file for reading:

`edit /tmp/robot-methods.lua`

Let me try to explain it in a general way

Our default Lua EEPROM has been programmed to do one simple job => Run `init.lua` on the attached filesystem

A "filesystem" is a a component that provides a filesystem, such as hard drives, floppies, etc

It tries to be smart about this:

1. Check all filesystems, one by one

2. Remember the last filesystem that had init.lua, and try it first

Enough about Lua EEPROM. When we hear about this failure to boot a computer "no bootable medium found", that tells us that the EEPROM was unable to find any filesystem with an init.lua

Hard drives in the game start out EMPTY, no files. No init.lua.

There is a special "loot disk" (a floppy disk) you can craft, that has OpenOS on it. OpenOS has an init.lua, which is why the Lua EEPROM can boot it. You can boot from the floppy, and you can run `install` to install OpenOS to a hard drive. read this wiki page for some more info: https://ocdoc.cil.li/openos

As a side note, always make your functions and variables `local`, that's the very first thing I noticed when reading your code. You'll want it to be `local checkAuthPlayer = function(p)`

Also, and it makes no operational difference, you could declare your functions: `local function checkAuthPlayer(p)` instead, if you like that style more

I'm not sure why this code doesn't work, but one thing to consider is that `io.open` uses relative paths if you don't use `/....` paths for files. Thus, `authPlayers` is searched in your current directory. Are you executing this script from a different directory?.

Does it throw an exception that the file was not found? [ I assume this is true  ]

Also, `r` is the default for `io.open`. It is totally fine to specify it, just thought I'd let you know

I'm not sure what you mean by the startup log, or are  you referring to the boot messages about what is loading? If so, those screen prints are done here: https://github.com/MightyPirates/OpenComputers/blob/master-MC1.7.10/src/main/resources/assets/opencomputers/loot/openos/lib/core/boot.lua#L51

Just remove all the code in `status()` in the `if gpu ... ` section. The `gpu.set` is printing the boot messages

read about the gpu and the color system here: https://ocdoc.cil.li/api:gpu

It has a nice color table at the bottom

Tier 2 max bit depth is 4, thus 2^4 colors, ie 16

WIth Tier 2 color, you can set palette colors as well. You aren't locked into the 16 we provide by default

we saw a bug report I think was about this program: https://github.com/MightyPirates/OpenComputers/issues/2908

you should always include bit32 in your scripts, and not assume it is in _G: `local bit32 = require("bit32")`

I recommend using `/usr/bin` for your personal programs

share your code, if you would

thanks

i can do that later tonight

understood.

again (for others reading here), http://ci.cil.li/job/OpenComputers-MC1.7.10/1178/

will they need that for other mc versions?

@XyFreak you can hack-fix this if your users don't want to update OC (again, sorry) by `_G.bit32 = require("bit32")`

http://ci.cil.li/job/OpenComputers-MC1.7.10/1178/