Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal
  • Announcements

    • Lizzy Trickster

      Latest Stable OpenComputers Version   11/26/16

      The latest released version of OpenComputers is version 1.7.2 for MC 1.7.10, 1.10.2, 1.11.2 & 1.12.2. See more information here! Beta/Dev builds can be found at the Jenkins Build Server (ci.cil.li)


  • Content count

  • Joined

  • Last visited

  • Days Won


payonel last won the day on January 26

payonel had the most liked content!

About payonel

  • Rank
    Junior Member

Contact Methods

  • Minecraft
  • GitHub
  • IRC
    payonel on esper.net

Profile Information

  • Gender
  • Location
    Portland, Oregon
  • Interests
    Coding and Gaming

Recent Profile Visitors

465 profile views
  1. Big Reactors Grid Control

    @XyFreak what were you wanting from the thread library that it isn't doing? @hron84I haven't tested the openos updater myself, but we haven't had a incompatibility change between the base mod and the OS for quite a while (some time in the 1.5 -> 1.6 time frame is the last time that happened)
  2. Noobs need help too!

    local term = require("term") term.clear() print("text")
  3. Noobs need help too!

    after you build a computer that can boot with the openos floopy in the disk drive, run `install` so that your rootfs isn't read only, it'll reboot, then you can write scripts edit - a simple tool for editing files simple script: ``` print("hello what is your name?") local name = io.read() print("hello", name) ``` we're on OC 1.7 these days, but the 1.4 tutorials are still helpful
  4. This code isn't working, I don't know why

    also, to use term, you need to require (import, include) it ``` local term = require("term") term.clear() print("tada") ```
  5. Create infinite thread in background and continue

    @thearhar Please, if you have specific feedback for ocdoc, add your suggestion to https://github.com/MightyPirates/OpenComputers/issues/2686 As for detach I can see that its explanation was a bit short. It would have been easier to understand if you read the entire doc. I have updated the explanation for detach in the docs From the docs, it is explained that a thread is attached to the current process when created. An attached thread blocks the parent process from closing until that thread dies. A parent process can abort, which kills all attached threads.A detached thread blocks no process (technically, the init process is its parent, but it does not block reboot/shutdown)
  6. Create infinite thread in background and continue

    great advice and explanation @Molinko thank you for supporting the community! One small change I would recommend: When working with user programs or threads (as opposed to custom coroutines) don't use coroutine.yield() unless you SPECIFICALLY want your process to block until a SIGNAL is raised (e.g. key_down) coroutine.yield() blocks until it receives a signal, even in threads os.sleep(0) might be better
  7. scrolling text

    You would need a program that buffers the text and scrolls and redraws for you. /bin/more can be used scroll down, but it doesn't scroll back /bin/less does back scrolling example `cat large_file | less`
  8. Big Reactors Grid Control

    XyFreak: btw, if your setup docs, "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:" You can also ask the user to run `rc brgc_reactor enable` to add it to the configs
  9. Big Reactors Grid Control

    Read, "where the call takes at least one server tick" Here: https://github.com/MightyPirates/OpenComputers/blob/f5c19e9e7e0006d3403c7bf0b44dfb970cee8a2f/src/main/java/li/cil/oc/api/machine/Callback.java#L43-L59
  10. Big Reactors Grid Control

    As to the delay in the shell, please see my comment in the github ticket -edit- I'll post here for those that don't want to open more tabs: First of all, if you are sleeping ( os.sleep ) in a service, that is going to block your shell. Use threads instead if you want to sleep without blocking other coroutines http://ocdoc.cil.li/api:thread
  11. Big Reactors Grid Control

    The list of versions affected show both good and bad for oc 1.6 and 1.7, while ER >= (thus, including 44) is bad in both cases So from that list alone it seems to be an issue with ER, and not a regression in oc 1.6 -> 1.7 Also, I had not realized the event handling delay with keyboard hits was so intense. Curious, when that is occurring, is the cursor blinking normally? (.5 second blink) -edit- It isn't by design to have such a delay in typing. The delay by design is to limit the number of direct api calls you can make within a tick
  12. Big Reactors Grid Control

    I've read the entire post. I've read your review of the system yielding longer than you'd like, but I haven't read about a yield bug. Read my response to this github ticket: https://github.com/MightyPirates/OpenComputers/issues/2632 Is there something I'm missing?
  13. Can't make new program

    There definitely isn't enough memory on 1 stick of tier 1 ram to run edit The minimal amount of ram is enough to do some basic shell commands, but most things are going to fail 2 sticks of tier 1 ram is probably enough for most built in functions and tools
  14. Big Reactors Grid Control

    What yield bug?
  15. How do I print to a second monitor?

    This post gives me a few things to think about First - @Molinko what is wrong about the documentation and the term library? I have a ticket on github to clean up the docs and I do plan to give the term doc page another review. But are there things specifically that you know to be wrong or confusing? If you do, please add your feedback to the github ticket: https://github.com/MightyPirates/OpenComputers/issues/2686 Second - I should have known that even if I put things in an `internal` sub table, people would still use them. Feel free to use the `term.internal.open` and `term.internal.run_in_window`, but you should also know these are not api - and can change without warning. They've now been around for a long time, but I may refactor them later. Third - OpenOS does not have multiple window support. Our internal (again, internal) structures have future support built in to support multiple windows, but we do not have an API for this yet. Thus, the solution you build is going to feel a bit complex or hacked, and you'll likely be making internal calls. Because again, this is not officially supported. 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. And the gpu is bound to a window. Child processes inherit their parent gpu and such. The internal workings of how this happens (in the term lib and in the tty lib) should not affect your user code. If you want to switch between screens, rebind the gpu. If you want to leave a gpu bound to a screen, and switch between gpus, then set the term gpu between the two. But I understand that this doesn't work with cursor positions and input buffers Fourth - @Molinko holy crap, someone is using the devfs! Ha! I'm pretty excited by that nice. And yes, you have the code correct. The first ( /0 ) will be the primary. Fifth - @joserobjr Changing the component primary device will not affect the kernel in any way. That only affects user code that is using the convenience method on the `component` library for quick access to the primary component of a type: `component[type]` In other words, for example changing the primary gpu changes the object returned by `component.gpu` but the kernel does not use this anywhere