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

Molinko

Members
 View Profile  See their activity

  • Content Count

    451

  • Joined

  • Last visited

  • Days Won

    35

 Content Type 

Everything posted by Molinko

  1. Molinko
    Could you clarify what exactly you expect?? I showed you one option in another thread for a service that launches programs into the background. Was that not what you're looking for?
  2. Molinko
    I suspect you're looking for package.path Its is in game on the local machine. See the doc for the package api.
  3. Molinko
    I would agree with your first statement. Daemons/services are probably the route to go, but don't forget OpenOS has threads which can be handy too. Services are pretty dang simple though.. The only real requirement is that you have a start and stop method, any other method is optional. You can check out the example service in /etc/rc.d/example.lua but note that there is only a start method and the 'service' isn't very compelling as to possible uses. I think an easy mix is with services that spawn threads. i.e. A service that can manage other processes by launching and killing them with service
  4. Molinko
    This is a cool idea. I believe there are a few libs out there that might help a lot in making this. Just my thoughts.. I think you have the difficulties reversed. Keeping a terminal responsive and in sync over a network is probably the trickier part. Sending files is pretty simple all around. Adding authentication (for validating if you want this or that machine reading or writing that particular file), or encryption if you're on a server or you want to control your base from outside of MC. Those last two may be unnecessary if you're playing single player or just don't care that much about net
  5. Molinko
    The issue with your adaptation is that is doesn't yield. As in coroutine.yield() Threads from the thread lib are fancy objects based around coroutines. Coroutines, basically, are functions you can pause(yield). This means they do a little something and before they return, they yield. Yielding is basically a way to generate values before a final value is returned. More importantly threads(coroutines) pause(yield) so other routines(functions) can run(and presumably yield or return quickly), but lets not forget they resume as well, to finish their doings... In my example I use the
  6. Molinko
    Basically the api is more flexible.. local function counter(num) local i = num or 0 while i < 25 do print(i) os.sleep(1) i = i + 1 end end local threadA = thread.create(counter, 1) local threadB = thread.create(counter, 5) --# Normally these will start and continue running asap. However, you --# can block the program from exiting early by using the 'waitForAll' and 'waitForAny' methods i.e thread.waitForAny({threadA, threadB})
  7. Molinko
    You want threads. The API is better than the parallel API in my opinion. https://ocdoc.cil.li/api:thread
  8. Molinko
    Any error messages? Did the file download? Details please. Need as much info as you can provide about your issue.
  9. Molinko
    The forums are more for coding in game in Lua. At least that the most responsive part of the community in the forum. Many of the maintainers of opencomputers and companion mods hang out in the discord and irc chat regularly. Be patient with them.
  10. Molinko
    I personally have no idea but I think you can get the help you need in the #oc Discord channel.
  11. Molinko
    This is lovely! I've been waiting for you to release this standalone.. Even wrote my own port of it a while ago. Cool!
  12. Molinko
    I think the adapter is the only option unless it is used as a component in a robot.
  13. Molinko
    I'm not certain of this... But I think the database component can be placed in the adapter block.
  14. Molinko
    I believe your error is coming from updateCubeStats(). cube.stats.stored = cube.getEnergyStored() You're missing parentheses.
  15. Molinko
    That's it. Perhaps Pam doesn't want all the crops automated with robots
  16. Molinko
    You're very welcome.
  17. Molinko
    Did you try robot.use() or any of the others with the sneaky click option?
  18. Molinko
    Your program has an infinite loop. You'll need to yield either with sleep or by pulling an event. Here is a simple solution. repeat energy = toMRf(cube.getEnergyStored()) energyMax = toMRf(cube.getMaxEnergyStored()) energyJ = toJ(cube.getEnergyStored()) energyMaxJ = toJ(cube.getMaxEnergyStored()) label(1, 1, "%.2f MRf / %.2f MJ (Energia Acumulada)", colors.red, energy, energyJ ) label(1, 3, "%.2f MRf / %.2f MJ (Capacidade da bateria)", colors.lime, energyMax, energyMaxJ) until event.pull(1) == "interrupted" -- # change 1 to something smaller to refresh faster
  19. Molinko
    Perhaps the robot needs to simulate a right click?
  20. Molinko
    I believe the eeprom has 2 filesystems. One is for the script on the eeprom one is for a boot filesystem address.
  21. Molinko
    You probably needed to use require. local com = require("component") local bridge = com.openperipheral_bridge
  22. Molinko
    It should work with ctif-oc /filepath.ctif where /filepath is the full path to the image file
  23. Molinko
    I think this is why I think a 'grouping' algorithm(if thats what it's called..) would be useful. Yes, you have to iterate every 'pixel' for its data, but you dont have to draw every pixel one by one independently. If you've heard of MineOS, it has a pretty beefy double buffering library. If you inspect the draw method you can get an idea of how it does grouping for gpu draw calls from its internal buffer. Just a suggestion in case i haven't been clear..
  24. Molinko
    From what I understand term.bind just binds the window instance to a given gpu proxy. The window instance is just size info, cursor state and some other metadata. If you keep digging in the OS you might notice term.internal.open isn't used anywhere other than in the term library and windows aren't exposed anywhere to the user. That's because it's not an explicit OS feature. This is why we have to manually bind a window instance to a process' metadata ourself. As for why it's not present in the process info already has to do with that metatable trickery I warned about earlier. There is one term
  25. Molinko
    I would definitely keep looking into how OpenOS gets things done, some of it is pretty clever. The buffer API is mostly for byte streams like files and such, maybe socket streams. An idea I had was creating a double buffer API and a virtual gpu component proxy interface that could then be bound to the term library with term.bind(gpuProxy, windowInstance) I think this would be workable and easily injected. Just my thoughts.. happy coding
×
×
  • Create New...

Important Information

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

  I accept