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

payonel

Developer
 View Profile  See their activity

  • Content Count

    172

  • Joined

  • Last visited

  • Days Won

    14

 Content Type 

Everything posted by payonel

  1. payonel
    yep, should always require("bit32"), it is not intended to be global (we aren't clearing it from _G in boot). I'll fix in dev. sorry
  2. payonel
    what openos bug?
  3. payonel
    1. you'll have to calculate stretching math yourself 2. our graphics are text based, not pixel based
  4. payonel
    screens drain power if chars are visible, regardless of machine state -- though note that screens are turned off when a machine poweroff occurs
  5. payonel
    These types of questions are more likely to be seen by our developer team using our github: https://github.com/MightyPirates/OpenComputers/issues To be honest, I'm fine leaving it the way it is. It's one of those things that has been that way for a long time and people have been using it. This would be a type of breaking change to anyone with existing scripts.
  6. payonel
    Over the next month or two I have hopes to migrate our gradle dependencies to a central and single server to make building the mod more reliable I'll try to remember to update this post when that work is done. I appreciate your help in translations. Remember, we push to 1.7.10, 1.10, 1.11, and 1.12 When you are ready - I would need your translations for each version. There are changes in the label capitalization between those versions
  7. payonel
    @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)
  8. payonel
    local term = require("term") term.clear() print("text")
  9. payonel
    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
  10. payonel
    also, to use term, you need to require (import, include) it ``` local term = require("term") term.clear() print("tada") ```
  11. payonel
    @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
  12. payonel
    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
  13. payonel

    scrolling text

    payonel replied to Sir_buttocks's question in Requests

    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`
  14. payonel
    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
  15. payonel
    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
  16. payonel
    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
  17. payonel
    The list of versions affected show both good and bad for oc 1.6 and 1.7, while ER >= 0.4.5.41 (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
  18. payonel
    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?
  19. payonel
    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
  20. payonel
    What yield bug?
  21. payonel
    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
  22. payonel
    I am happy to review the serialization code in openos, but not with a repro with your speciifc use case Note that the serialization library has been optimization since our last official release. Please retest with a latest dev build from: http://ci.cil.li/ for example: 1.7.10: http://ci.cil.li/job/OpenComputers-dev-MC1.7.10/ 1.10: http://ci.cil.li/job/OpenComputers-dev-MC1.10/
  23. payonel
    yes - this is a bug in openos when users try to print to the screen before boot is finished I have this fixed, you are running an older version of openos Note that if you pull the latest code, it will fix your problem and you won't get a blue screen. However, you also won't get the text printed to the screen because the terminal isn't finished loading yet. If you want to print to the screen in a script that runs automatically during boot, you need to add your programs to /home/.shrc Things that run in /boot, or autoruns, or rc scripts, may be executing before the terminal h
  24. payonel
    you have to look at your code and think -- is there anywhere in this loop that could run for more than 5 seconds without sleep/yield? If so, add a os.sleep(0), perhaps once per loop, or use a timeout yourself and sleep every 2 seconds. I have a similar sleep in the terminal code when printing out a very large file to the screen, i do this: local last_sleep = computer.uptime() while true do if uptime() - last_sleep > 1 then os.sleep(0) last_sleep = computer.uptime() end
  25. payonel
    can you link the updated code?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.

  I accept