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

Negi

Members
  • Content Count

    23
  • Joined

  • Last visited

  • Days Won

    5

Negi last won the day on May 10 2016

Negi had the most liked content!

About Negi

  • Rank
    Junior Member
  • Birthday 06/14/1999

Profile Information

  • Gender
    Male
  • Location
    Hon.
  • Interests
    Music, drawing, webcomics, memetic absurdity, memes, Tumblr, computers, networks, programming, CHARACTER DEVELOPMENT and WORLD BUILDING, subtile graphical patterns, and a lot of stuff.

Contact Methods

  • Minecraft
    N16HT5T0RM
  • GitHub
    NegiSpringfield
  1. The Open Engineering Task Force is a bit like its real world counterpart, the IETF, if I recall correctly. This place is basically to discuss protocols and standards defined for communication between computers in OpenComputers, I'm guessing. If I recall (I think it was) Lizzy's words, we can submit new RFCs here, comment and expand already existing ones, things like that.
  2. The only way to use another language (unless you write the whole interpreter in Lua and use it as a boot script) as the core of OpenComputers is to make it yourself with Java or Scala, using this: http://ocdoc.cil.li/tutorial:modding_architecture (And wow I noticed it got easier). Implementing an OS directly through this mechanism has little interest, and I'm not sure it can be done (Hint: It probably can.). Someone had wrote a JavaScript architecture (Look in Addon Mods), and there were projects to implement both ARM and x86 architectures. (ARM has been dropped, and I'm not sure about x86 b
  3. What you're thinking about here is mistakenly called an "internet". You don't need any protocol creation, OC manages transmission between computers fairly well. And addresses already are unique over every component. What you're describing is an abstraction layer. You'd basically have access to multiple networks as if they were one. I'd say it's the place of services to handle this. (I still doubt it would be useful, though, since most of network interfaces use APIs that look alike.)
  4. Are you using a computer in the overworld or a tablet you are carrying with you to communicate with the nanomachines? In the first case, this would be normal, wireless communication can't go through multiple dimensions.
  5. You can't mount multiple devices at the same mountpoint, no. What you can do is be smart about it, like have them named floppy-<three first characters of address>/ or anything like that.
  6. If things are done correctly, which I believe is the case, haven't tested it myself, it's in /bin. So you just need to write "xerox <number of copies>" as Michiyo explained.
  7. Have you tried with an already-existing file ? And are you sure that your program is at the right work directory ? Programs start at the work directory of the shell, which by default is the root.
  8. I'll add that ALL rc.d services aren't started on boot, only those in the enabled table. You wouldn't enable a service which you aren't sure works as expected, right ? Well that's why you should test the state of things with rc <service> start before enabling it for automatic starting at boot. What I've wrote here is only a quick solution, so I didn't bother with details.
  9. Isn't autorun.lua reserved to when a disk is mounted? You could also use RC, you just have to take the aforementionned code, and throw it in a start function, then save the thing as /etc/rc.d/filename.lua. -- /etc/rc.d/filename.lua local gpu = require("component").gpu function start(config) gpu.setResolution(10, 10) end And you could then enable this that way (just add the filename in "enabled", you don't have to touch anything else) : -- /etc/rc.conf enabled = {"filename"}
  10. The wireless redstone IO is usable when you have WR-CBE (maybe some other mod works too?) installed. The Tier 2 redstone card then becomes able to use WR-CBE's channels to transmit a redstone signal. You'd just need to put an emitter/receiver near your sensors, tune them to the right channel, and regularly switch between their channels to check input/set output.
  11. Ta liste n'est pas à jour. Ça c'est pour les anciennes versions d'OC. Si je me trompes pas, maintenant, OC supporte tout le jeu de caractères Unicode, ou du moins une grande partie. Your list isn't up to date. That one is for older OC versions. If I recall correctly, OC now supports the whole Unicode set, or at least a major part of it.
  12. The Computronics EEPROM reader is actually for Nedo Computers EEPROMs. To read an EEPROM in a microcontroller you can just temporarily swap it out with another. (iirc that can be done, but I'm not sure). Also, you're mixing up microcontrollers and development cards. Arduino are development cards with a specific language that is then compiled to AVR executables. The microcontroller which powers the Arduino is an ATMega, and if it were to be stripped from the card, it'd require some kind of adapter and some wiring to program. In-game microcontrollers are meant to be sort-of that way. As fo
  13. Someone on the forums made a converter to convert MagicaVoxel ".vox" files to 3dm templates for the 3D Printer. Please check it out and see if it fits your needs. http://oc.cil.li/index.php?/topic/599-magicavoxel-vox-converter-for-print3d
  14. If you're using the component.setPrimary() way, you'll also need to tell the gpu to draw on the right screen, i.e. component.gpu.bind("<Screen's address"), your final code would look like that : local component = require("component") local screen = "<screen address>" component.setPrimary("screen", screen) component.gpu.bind(screen) You can also enclose the two last lines in a function named start, and save that in the /etc/rc.d directory. Then edit rc.conf and add the file's name (minus the .lua) to the "enabled" table (Yes, rc.conf is a Lua file).
  15. Hello ! 1 ) You'll want to use driver mode (aka event.listen, a look in the event api's documentation will help you). 2 ) Well, your non-foreground program is still a program, so you define your callback function (it takes all the arguments of the signal, look in the signals page of the doc), and register it with event.listen("event_type", yourfunction). 3 ) Driver mode is a way for OpenOS to handle events, it uses event.listen(event, function) and event.ignore(event, function), the whole thing runs in background. 4 ) rc is just like a daemon manager...Or rather it starts thin
×
×
  • Create New...

Important Information

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