• Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal
Welcome to OpenComputers

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more!

This message will be removed once you have signed in.

  • Announcements

    • Lizzy Trickster

      Latest Stable OpenComputers Version   11/26/16

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

Leaderboard


Popular Content

Showing content with the highest reputation since 06/27/17 in all areas

  1. 4 points
    Nexarius

    Tank Display Program

    This program can display the contents of tanks on a big screen with a colored bar that can dynamically change its size. It can show up to 64 different liquids which are sorted from highest amount to lowest. 5x8 is the optimal size for the screen. Multiple tanks with the same liquids are automatically added together and empty tanks are ignored. This display is split into 2 programs. 1) Server - this receives the tank information and displays it 2) Client - this has the adapter with the tank controller (you can have as many as you like) pastebin run -f cyF0yhXZ installation guide: https://www.youtube.com/watch?v=avvYO2xSxGw github: https://github.com/Nex4rius/Nex4rius-Programme/tree/master/Tank#start server / display components: Internet Card (to install) Network Card Graphics Card T3 Screen T3 client / adapter + tank components: Internet Card (to install) Network Card Adapter + Tank Controller Upgrade
  2. 3 points
    XyFreak

    Big Reactors Grid Control

    Hi everyone. A while back I promised more releases, so here you go: Big Reactors Grid Control is a multi reactor/turbine controller for Big Reactors and Extreme Reactors. Mission goal: Be the best big reactors controller there is. Nothing more, nothing less. First things first - here's the website: https://tenyx.de/brgc/ Main features Active and passive reactor support Support for multiple reactors and turbines at the same time (n:m) Control active and passive reactors with the same controller Automatic configuration of everything (EVERYTHING!) Setup instructions wget the installer from here: http://xypm.tenyx.de/standalone/brgc_installer.lua Run it Done Big Reactors Grid Control comes with three rc.d files: /etc/rc.d/brgc_reactor.lua /etc/rc.d/brgc_turbine.lua /etc/rc.d/brgc_grid.lua If you want the controller to run at boot time, you can just use OpenOS' rc.d schema. There's a GUI as well as a command line utility for advanced users. To start the gui, simply run "brgc_gui" and watch the magic happen. The gui scales the screen resolution to match the screens ratio and should scale with basically all screen setups. I recommend 3x2 or 4x3 screens. As of now the command line utility allows you to do (almost) everything you can do with the GUI and also allows you to change the controllers configuration at runtime (if you so desire). Check out "brgcctrl help" for further information. How to set up the grid In a basic setup you just interconnect everything: All active reactors can output steam to all turbines. All passive reactors and turbines output energy to the same grid. You CAN have passive reactors and turbines output energy to different energy grids. While this poses absolutely NO problem for passive reactors, you will have to set some turbines to "independent"-mode (more on that below). If you want your reactors and turbines to properly cooperate, you'll also need to connect at least one energy storage block to your energy grid. Currently supported storage "blocks" are EnderIO Capacitors (requires the mod "Computronics") and Draconic Evolution Energy Storage multiblocks. You can connect them using OpenComputers Adapters. Discovering new components As mentioned before the controller tries to autoconfigure everything: Passive Reactors When a new passive reactor is connected to the controller, the controller will first try to measure its maximum energy output. The reactor will have its output increased step by step and the average (interpolated) maximum will be used for that value (CALIBRATING). After calibration has been completed, the controller calculates the most efficient energy output of the reactor. Active Reactors When a new active reactor is connected to the controller, the controller will first try to measure its maximum steam output (CALIBRATING). For this to work correctly the reactor must be able to output at least SOME steam (read: you need a consumer) and you will need to provide sufficient ammounts of water. The controller will detect reactors with a potential steam output greater than 50 B/t and limit its energy accordingly. Turbines When a new turbine is connected to the controller, the controller will first try to measure its maximum energy output (CALIBRATING). For this to work, make sure your turbine is built correctly. This means your turbine can be run at maximum supported steam (25mb/t per blade) without exceeding 1950 RPM. Should your turbine exceed 1950 RPM at any stage, the controller will shut down the turbine and flag it as failed. Note: Your turbine is NOT required to be able to process 2000 mB/t. Smaller turbines work perfectly fine. Screenshots After this wall of text, here're some screenshots (pre 4.2). Setup: Main view: Passive reactor details: Active reactor details: Turbine details: Let's go in order: When you start up the GUI you will be presented with the main view. Here a combined overview of passive reactors, active reactors and turbines will be presented. You can click (or touch) on any of these items to open up a detailed view of the component. Here you can enable/disable the component or change its behaviour. What behaviour? This is where it gets interesting. Passive Reactors You will notice that passive reactors have two modes and an "auto" mode. PWM This is the behaviour everyone knows: The reactor gets turned on when its internal energy storage drops below 10% and gets turned off when the energy storage exceeds 90% of it's maximum capacity. In PWM mode the reactor will generate energy at its most efficient rod level. Overall this mode allows the reactor to generate energy as efficiently as possible as long as your actual energy consumption is below or equal to its optimal energy output. But sometimes you need just a bit more energy and you don't want to upgrade your reactor or build a new one. "Classic" controllers will fail to produce sufficient ammounts of energy here. This leads me to the second behaviour: Load In "Load"-mode the reactor will always aim to produce energy at the same rate as it's consumed. Maybe some people already suspect what that mode is all about: It's a PD-like regulator. While "Load"-mode is not as efficient as PWM-mode in situations where the energy consumption is below the optimal energy output, it will guarantee you're never running into energy shortages - provided you're not exceeding the reactors maximal capacity. Auto "Auto"-mode aims to eliminate the disadvantages of both modes by combining them: If the energy consumption can be satisfied with PWM-mode, PWM will be used. If the energy consumption is above optimal levels, "Load"-mode will be used instead. As a result, "auto"-mode generates energy as efficient as possible while always saturating your energy demands. Active Reactors As of now, active reactors only operate in "load" mode. Steam is consumed and produced way too fast and the reactors internal steam storage does not allow for anything else. Turbines Turbines controlled similar to reactors in "load" mode: The controller will always try to balance the turbines internal energy storage out to 50% by using a PD-like regulator. Turbines can be operated in "ganged"-mode or in "independent"-mode, with "ganged"-mode being the default. The only difference between these two modes is that turbines in "ganged"-mode can be shut down by the controller, while "independent" turbines will always be active, even if they overproduce energy at the lowest RPM allowed. This is handy if one (or more) of your turbines produces energy for a seperate (dedicated) energy grid but has to be controlled by the same controller. If such a turbine is not in "independent"-mode it may be shut down which will lead to energy failure in that grid. That's it for now. If you have any questions, want to report bugs, etc., feel free to drop a message here. Also: Do you want an indepth tutorial on how to use the command line utility? Need a description on what the GUI is actually showing? Have fun XyFreak
  3. 3 points
    Fingercomp

    TLS Sockets

    The RFC 5246 describes the TLS 1.2 protocol that's very heavily used today to encrypt the traffic sent over regular sockets. Have you noticed the "https" part of this page's URL? It means that a HTTP server listens, generally, on the 443 port for HTTP requests sent over a TLS connection. Currently you can only send HTTPS requests, there's no built-in solution for establishing TLS sockets to send arbitrary data. An issue on GitHub asks exactly for this feature to be added. Now, look at the date of posting. After 1.5 years, we still don't have TLS socket support. Oh, maybe, not really now. Yes, I have a fully working TLS 1.2 implementation (without certificate validation, though). It uses the tier 2 data card (it provides the secure random and hashing functions), and the Computronics's advanced cipher block (RSA encryption). And it isn't even incredibly slow! It only takes 4 seconds to connect. I've tried to connect to some https servers, and all of them worked perfectly. The library is hosted on my OpenPrograms repository, and can be installed via OPPM: oppm install libtls. Here's my another creation that uses the library: a simple and dumb (yet working, huh) HTTP 1.1 library. It's solely purpose is to allow to specify the request method (which also has its own issue, that, unfortunately, is still open), like PUT or PATCH. It uses raw sockets or TLS sockets to do so. It's also hosted on my repository, and can be downloaded via OPPM (oppm install libhttp), too. Hopefully you'll make use of these two libraries I've written.
  4. 2 points
    dunstad

    Control robots remotely from a website

    The Roboserver is a program which lets you control OpenComputers robots remotely, without writing any Lua code, either from your web browser or from a desktop application. You can have your robots dig tunnels, build houses, craft items, and just about anything else a player can do, from any distance! I've got many interesting ideas for how to improve it still, such as adding support for ComputerCraft turtles, allowing robots to save and place structure blueprints, and controlling them from AR glasses added by other mods. If you're as excited about this as I am, help me get there by becoming a patron here! The code for this project will always be open source, and can be found here.
  5. 2 points
    Dustpuppy

    Security system for opensecurity

    Hi, now i'am getting complicated :-) Here's my security system. It's based on opensecurity and oc. ------------------------------------------------------------------------------------------------------------------------------- What's needed? The server Start it before starting any door computer or the card writer system. The server will handle all user accesses. The card writer This is the main system. It's with gui to setup all users. It needs an opensecurity card writer connected. You can setup new user, edit user or delete user. A user can be blocked to stop him using a mag card and a level can give to grant access on different doors. Data will be encrypted on the card. The door systems This will be used for the door it self. The computer needs a door controller and a card reader connected. You can use as much of this systems, as you want. It's important, that a door computer is started after the server, because it sends his access level to server during start. The level can be changed in the code. It's this line on the top : local accessLevel = 2 ------------------------------------------------------------------------------------------------------------------------------- All data will be send encrypted over network on port 199. The port and the crypting key can be changed in the source codes on top. Easy to find. :-) Downloads The server http://pastebin.com/Entk3KX5 The card writer http://pastebin.com/156Np04X - main program http://pastebin.com/Dfgc6z0T - the gui system (save it as gui.lua) The door computer http://pastebin.com/KwQjiQPD Hope u get it setup :-) If not, let me know. If i don't answer...good luck ;-)
  6. 2 points
    I haven't been here in a long while, mostly because life, the universe, and everything has been getting in the way of fun. Also, I'm usually an eternal lurker, but hey today I have a small contribution, As I have been playing I wanted a gui interface to easily turn on and off the different nanomachine flags. So I built a small application to do it. Right now it is super basic, but I hope to flesh it out a bit more and give it proper displays ect, so I dont have to do things as janky as I did here. Long story short, I'm bad at lua/coding/scripting in general, so its a little hamfisted and could prolly be streamlined a lot, As some basic prerequisites, it needs a computer or tablet with a teir 2 graphics card, and a wireless card. I used Dustpuppies gui api found here: It was really helpful, and made setting up an interface really simple. Screenshot below~ Pastebinlink: https://pastebin.com/wrxi0726 Buttons that say on, turn flags on, buttons that say off turn flags off. super simple nonsense. arguments~ you can launch the file with the argument '-s' and this will skip a 'loading' screen I coded into it. The loading screen, is just a visual representation of the program turn off all nanomachine flags one by one. since nanomachines will only respond to commands once every second or so. I did this as I am still learning and figureing things out with network messages, and sending is easier than receiving for me, lol and telling the nanos to turn everything off was easier than asking the nanos whats turned on, and setting the buttons up to match it at launch. Mainly because I am dense, and it's going to take a little time to work things out and hammer it into my mind how to do this. Thanks for taking a look at my nonsense. If you have any suggestions, or contributions, please, speak up. D: seriously I wont learn exactly how terrible I am at this without your help, and in turn wont get any better. I made this because I wanted to, and the only nanomachine control app I was able to find was just a text based type thigns application. [though that application has been helpful in setting this up and will likely be helpful in continuing work on this program. As I believe every nanomachine function is in use by it. https://www.youtube.com/watch?v=gl3zGcTh67w that's the program. I picked apart to learn how to do this and stuff. D
  7. 1 point
    XyFreak

    Big Reactors Grid Control

    Ok - again for everyone here. BRGC does NOT work with your CPU set to Lua 5.3 right now. I have to at least change all my string.format uses throught the entire code for that to work. So unless I release an update: Do not attempt to use Lua 5.3 if you want to use the GUI. The controller itself works perfectly fine on 5.3 though.
  8. 1 point
    corbanj6534

    Big Reactors Grid Control

    This normally happens when the file thats trying to be run is empty, happened to me a couple of times earlier with a different program as the files weren't downloading from pastebin. Try redownloading the installer as @XyFreak said.
  9. 1 point
    XyFreak

    Big Reactors Grid Control

    @mcshadowdrag I've never seen this kind of issue before. Maybe try to reinstall OpenOS? You can redownload the installer by doing rm /home/brgc_installer.lua and then wget it again.
  10. 1 point
    XyFreak

    Server Racks

    In order to use more than 16 components with a server you need to insert "Component Bus" Cards into the server. Each T3 card allows you to connect 16 more components to the server. In the rack GUI you can/have to connect the server to one side of your rack. Afterwards the server can access all components connected to this side and this side only so make sure to connect everything properly If you want to use the terminal server (doesn't work very good with the GUI btw) you also have to connect the terminal server to that side in the rack GUI. Monitors can of course be connected to said side of the rack as well. Side node: If you have more than one GPU and monitor in your server the GUI will pop up on your OTHER monitor and will give you back your shell on your primary monitor.
  11. 1 point
    BrisingrAerowing

    Is there anything like Market/Vending Machine?

    @Log There is a third party driver for OC-RS compat for 1.10.2, found here. The system in RS is actually based on the third party API (copied and pasted, as a matter of fact).
  12. 1 point
    Fingercomp

    Charts library

    Suppose you are creating some monitoring program: tank monitor, energy monitor or whatever. It should print how much energy (or fluid) is stored, draw a progress bar and a few histograms with different update intervals (1 second, 30 seconds, 1 minute and 10 minutes). I don't think printing will cause any programs, so I'll skip it. But what about progress bars and histograms? Well, it isn't not rocket science, of course. But not a really easy thing either. Anyway, a few months ago I've written a small library that makes it easy to draw histograms and progress bars, called "charts". Install the library from OpenPrograms using oppm (oppm install charts), or from the Hel Repository using hpm (hpm install charts). I can't insert images directly because the editor is broken. So here's the link to the album. As you can see, progress bars and histograms have the precision up to 1/8 of character. API The library exports Container, Histogram, ProgressBar and sides. Container Contains child objects (histograms or progress bars) and provides some common options like width, height, top-left corner coordinates and so on. Container(), Container{...} — create a container object. When called as Container{...}, you can set object parameters on the fly: Container{x = 2, y = 3, payload=Histogram()}. Properties container.gpu — the proxy of the gpu to use when drawing. Uses the primary gpu by default. container.fg — default foreground color. Default: 0xFFFFFF. container.bg — default background color. Default: 0x000000. container.x, container.y — coordinates of the top-left corner of container. Default: 1, 1. container.payloadX, container.payloadY — coordinates of payload, relative to the top-left corner of container. Default: 1, 1. container.width, container.height — width and height of container. Default: 80, 25. container.payload — histogram or progress bar object. Methods container:draw() — draw the chart. Histogram Histogram(), Histogram{...} — constuct a histogram object. The second way of initialization works the same as Container{...}. Properties histogram.values — table that contains numeric values. Default: {}. histogram.align defines the alignment of the chart (one of sides.LEFT or sides.RIGHT, see sides below). Default: sides.LEFT. histogram.colorFunc — the function that returns a foreground color and a background color for each bin of histogram. Arguments passed to the function are: an index of bin (in histogram.values), a normalized value (from 0 to 1), a value itself, a histogram object, a container object. Default: function() end. histogram.min — the minimum value of chart. Default: 0. histogram.max — the maximum value of chart. Default: 1. histogram.level.y — the height of histogram level. If level is in range (0; 1), it's treated as the relative height (e.g., 0 is the bottom, 0.5 is the middle). If it's less than 0, it's treated as the absolute offset from the top (with -1 meaning the top, -2 — one character under the top, and so on). Otherwise it's treated as the absolute offset from the bottom (for example, 1 is one character above the bottom). Default: 0. histogram.level.value — the value that corresponds the chart. Values less than this will be drawn below the level, values greater than this will be drawn above the level. If set to nil, it defaults to histogram.min. Default: nil. Progress bar ProgressBar(), ProgressBar{...} — construct a progress bar object. Properties progressBar.direction — the direction of progress bar (sides.TOP, sides.BOTTOM, sides.LEFT, sides.RIGHT). Default: sides.RIGHT. progressBar.min — the minimum value of progress bar. Default: 0. progressBar.max — the maximum value of progress bar. Default: 1. progressBar.value — the current value of progress bar. Default: 0. progressBar.colorFunc — the function that returns a foreground color and a background color of progress bar. Arguments passed to the function are: a value, a normalized value (from 0 to 1), a progress bar object, a container object. Examples local charts = require("charts") local container = charts.Container() local payload = charts.Histogram { max = 80, align = charts.sides.RIGHT, colorFunc = function(index, norm, value, self, container) return 0x20ff20 end } container.payload = payload for i = 1, 400, 1 do table.insert(payload.values, math.random(0, 80)) container:draw() os.sleep(.05) end local charts = require("charts") local term = require("term") local event = require("event") local cleft = charts.Container { x = 1, y = 1, width = 50, height = 2, payload = charts.ProgressBar { direction = charts.sides.LEFT, value = 0, colorFunc = function(_, perc) if perc >= .9 then return 0x20afff elseif perc >= .75 then return 0x20ff20 elseif perc >= .5 then return 0xafff20 elseif perc >= .25 then return 0xffff20 elseif perc >= .1 then return 0xffaf20 else return 0xff2020 end end } } local cright = charts.Container { x = 1, y = 4, width = 50, height = 2, payload = charts.ProgressBar { direction = charts.sides.RIGHT, value = 0, colorFunc = cleft.payload.colorFunc } } local ctop = charts.Container { x = 55, y = 1, width = 2, height = 20, payload = charts.ProgressBar { direction = charts.sides.TOP, value = 0, colorFunc = cleft.payload.colorFunc } } local cbottom = charts.Container { x = 59, y = 1, width = 2, height = 20, payload = charts.ProgressBar { direction = charts.sides.BOTTOM, value = 0, colorFunc = cleft.payload.colorFunc } } for i = 0, 100, 1 do term.clear() cleft.gpu.set(5, 10, "Value: " .. ("%.2f"):format(i / 100) .. " [" .. ("%3d"):format(i) .. "%]") cleft.gpu.set(5, 11, "Max: " .. cleft.payload.min) cleft.gpu.set(5, 12, "Min: " .. cleft.payload.max) cleft.payload.value, cright.payload.value, ctop.payload.value, cbottom.payload.value = i / 100, i / 100, i / 100, i / 100 cleft:draw() ctop:draw() cright:draw() cbottom:draw() if event.pull(0.05, "interrupted") then term.clear() os.exit() end end event.pull("interrupted") term.clear() My EU monitor is available here. See the Hel Repository's package page for the up-to-date documentation and changelog.
  13. 1 point
    Dustpuppy

    Security system for opensecurity

    It's because ur using MC 1.10.2 The names of the blocks are changed in Open security, compared to MC 1.7.10. I will redo the programs with the new names for MC 1.20.2 if i find the time. At the moment i am working on my gui.
  14. 1 point
    payonel

    BIOS equivalent of 'require'

    In this response when I say "In EERPROM" I am referring to any code that is running without or before OpenOS. It doesn't necessarily have to be literally in EEPROM code. It could be your own custom OS, it could be literally code in an EEPROM. So.... require("filesystem") ~= require("component").filesystem We are dealing with some confusion here. I should make a wiki page specifically about the two weird+confusing things here We need to understand what is a library and what is a proxy require() returns libraries component.proxy() and component[component_type_name] provide access to component proxies Let's first talk about what is true BEFORE OpenOS boots, or in other words, what is true in EEPROM. Keep in mind, OpenOS doesn't do anything you can't do. OpenOS fully runs in the game environment In EEPROM, The `component` object is available globally, in _G. From here on, let's refer to this component that is in _G in EEPROM as _G.component. The docs really need clarification on this object. This is partially true http://ocdoc.cil.li/api:component The problem with the "api:component" page is that it describes OpenOS' version of component which is almost the same, but OpenOS adds a few methods and helpers. ocdoc pages that are named "api:" are referring to libraries. And like all other libraries, you need to call require("component") to use that api. So it looks like a library, and it has a library ocdoc page, BUT .. _G.component is available to your EEPROM code (i.e. before OpenOS loads). In truth _G.component and require("component") are the SAME object, but OpenOS adds a few methods to component and OpenOS removes it from _G, thus requiring that you require it. Every filesystem component (e.g. hdds, floppies) have a GUID (let's call it fs_addr). As for other component types, you can acquire a proxy to that component by calling _G.component.proxy(fs_addr) (or require("component").proxy(fs_addr) when in OpenOS) local fs_proxy = _G.component.proxy(fs_addr) Yes I know it is not necessary to use _G but I am trying to make it clear I am referring to the _G.component that is available In EEPROM (or, before OpenOS loads or in any custom boot) This fs_proxy is a proxy to the actual hdd or the actual floppy in your computer. See http://ocdoc.cil.li/component:filesystem fs_proxy is a proxy to the component, in linux terms, it is the filesystem DEVICE. ## Libraries ## OpenOS adds libraries. OpenOS provides a library named filesystem. It has been debated whether this was a good name, given that there is also a component with the SAME NAME. require("filesystem") is the "filesystem" library api require(lib_name) returns apis, code from /lib/${lib_name}.lua and require("filesystem") loads the code from /lib/filesystem.lua, see http://ocdoc.cil.li/api:filesystem This, the OpenOS filesystem library, can create mounts, can create symbolic links, can open/create/read/write files across all mounted filesystem components (devices). Lastly, I want to mention that once inside OpenOS, you have NEW methods of acquiring the component proxies. For example, component.filesystem is a proxy to the "primary" filesystem. This is NOT the rootfs, it is simply the first filesystem component that is detected during boot. Read more about primary components on the api:component page: http://ocdoc.cil.li/api:component "primary" is an OpenOS idea. Because generally there are multiple filesystem components (even the tmp filesystem is its own filesystem), it is unclear which filesystem you are accessing when you use component.filesystem. I advice you DO NOT use component.filesystem unless you are certain there is only one filesystem. The same argument can be made against using component.proxy(component.list("filesystem")()) -- this is a simple way to get some random filesystem, but you don't know which filesystem.
  15. 1 point
    Molinko

    BIOS equivalent of 'require'

    You could think about loading libraries remotely into memory from a network... As TYKUHN2 said.. With an extra step of requesting a file... require could be switched with a call to load or loadfile. -- # pseudo code.. this might work but isn't tested or even run... function require(module) -- # do some checks n shit.. local file, chunk = nil, "" modem.send(address, port, "get[file] " .. module) while true do local e, la, ra, p, d, ch, status = computer.pullSignal(2) if e == "modem_message" then if status:match("error") then -- # request failed somehow return nil, status elseif st == "chunk" or st == "start" then -- # first and subsequent chunks chunk = chunk .. ch elseif st == "done" then -- # we haz all the chunkz. time to load ze chunkz. file = chunk .. (#ch > 0 and ch or "") break end end end if file then local ret = {pcall(load, file, "=" .. module)} if not ret[1] then return nil, ret[2] end -- # ret[2] here is an error msg ret = {pcall(f)} return ret[1] and ret[2] or nil, ret[2] end return nil, "failed because reasons..." end
  16. 0 points
    You can do this by overriding event.shouldInterrupt function event.shouldInterrupt() return false end