Leaderboard

What is STEM? Did you ever want to have a linked card, but without this pair-to-pair limitations? Well, you have internet card. And that is already half of the solution. The other half is to use Stem. Stem is a message transmitter for your OpenComputers devices with internet cards. Using a small OpenOS library you can use Stem to send and receive messages. Unlike the standard `modem` component, Stem-messaging uses not addresses, but `channels`. You can send messages to any channels, and you can subscribe to any number of channels to listen for messages from them. Installation The best way is to use HPM: hpm install stem If you do not have HPM, install it like this: pastebin run vf6upeAN If you do not want to use HPM repository, you can just use wget: wget https://gitlab.com/UnicornFreedom/stem/raw/master/stem.lua Example of a program using STEM local event = require('event') -- use STEM client library local stem = require('stem') -- open a connection to a STEM server -- the `stem.fomalhaut.me` is a default one local server = stem.connect('stem.fomalhaut.me') -- subscribe for messages from the channel with ID 'my-channel-id' server:subscribe('my-channel-id') -- then listen for events in a loop... while true do local name, channel_id, message = event.pull('stem_message') if name ~= nil then print(channel_id, message) end end -- ...or register an event listener event.listen('stem_message', function(_, _, channel_id, message) print(channel_id, message) end) -- you can also send message to the channel -- (you do not need to be subscribed to this channel, to send a message) server:send('my-channel-id', 'hello there') -- unsubscribe from channel server:unsubscribe('my-channel-id') -- completely close the connection to the STEM server server:disconnect() That is all. But there is more. Web client If you open the link to Stem server in your browser: https://stem.fomalhaut.me/ You will see some statistics and the web client. Enter your channel ID into the form, and you can send messages to your robot in real time, right from your phone, without even starting Minecraft. The web client is limited with UTF-8 encoding, though. (Using OpenOS you can send literally anything, as long as the message fits in 64kb of data.) Security Questions The channels by default do not have any special security measures applied. They do not have any authentication mechanisms, the do not have any encryption. Anyone who knows the ID of a channel can send a message to it and can listen for responses. But. The length of ID is 256 bytes. And that can be any bytes - from 0 to 255. That means, that you have 256^256 possible combinations for your ID. And that is a giant number. If you need to secure your channel - just use something long and incomprehensible as your ID. As an additional measure you can use end-to-end encryption, or anything else - this is up to you. Default STEM server uses HTTPS, and does not store any information - message in, message out. Self-hosted STEM solution For those of you who are strong in spirit and computer knowledge - there is a self-hosted option. You can build Stem server from sources and run it on your machine. This is also pretty easy. Additional instructions can be found on GitLab. Useful links GitLab repository: https://gitlab.com/UnicornFreedom/stem Protocol description: https://gitlab.com/UnicornFreedom/stem/wikis/protocol Default server: https://stem.fomalhaut.me/ HPM package: https://hel.fomalhaut.me/#packages/stem If I forgot something - feel free to ask here, or in IRC (my nickname is Totoro there). Also the project contains at least one "Easter egg" feature, that can offer some interesting options if you know HTML/CSS/JS. The Stem protocol is open - you can modify it, you can create your own clients in any programming language, etc.

No spoiler in the title. Just watch the video.

You can use the port that is not 80. since i said "SHOULD" and not "MUST". But i'll try to change this for better clarity

Program and library for building GPS network. https://github.com/DOOBW/OC-GPS Download: wget https://raw.githubusercontent.com/DOOBW/OC-GPS/master/usr/bin/gps.lua /bin/gps.lua wget https://raw.githubusercontent.com/DOOBW/OC-GPS/master/usr/lib/gps.lua /lib/gps.lua The functionality is the same as in the ComputerCraft. Additional command "flash" allows to upload firmware to EEPROM. When the coordinates are precisely determined, when flashing the position of the microcontroller can be omitted - at the first start it will determine its position from neighboring satellites and save on EEPROM. GPS network startup example.

This program enables you to make servers useful like IRL web servers. Client Minimum requirements relay network card internet card apu Server Minimum Requirements; Wireless network card Configured serverside program Put your paste code in the server program or else it will say Hello. I did this cause nobody else had and I thought it would be useful Server paste code: B7b27pc2 Browser paste code: vkL422Sz I am new to OC and this is my first program

In OpenComputers we currently have a simple highly abstracted networking model. We do have ports, thankfully, but besides that the model is highly abstracted and thusly underpowered. The first suggestion, is remove the abstraction on network communication in the first place. Allow this to be configured in the mod preferences file, but have it enabled by default. By default, there is no “hardware addresses”. A cable is just that, a cable. The only API by the mod is “broadcast and receive”. In the OS provided by the game by default could still have the same API as now. The different is it’d behave like broadcast, with packets being what are broadcasted. The new network card API (excluding any OS-level abstraction would look like this: - card:up() - card:down() - card:listen() - card:transmit(raw) Already, we now have a lot of extra things. It encourages crafting an encryption card (or whatever it’s called) because users can now snoop and preform MITM attacks on these packets, since there is no game mechanic (provides by the mod itself) preventing posing as somebody else. That also means you can simulate multiple networks cards in software while crafting only one. Second, something that kinda complements the idea of the first suggestion. Cable bandwidth limits. Just like normal cables, there is a limit to the amount of data we can cram into a single cable. Since the last suggestion removed the magic of hardware addresses, we actually need to listen to packets on the cable. We can only process so many packets so often. Now, us developers have an actual NEED to work on more complex softwares. We need to design things like intelligent multiplexing algorithms and routing softwares to efficiently receive, decode, process, bundle, re-encode, and transmit packets. There will also now be tiered network cards, that change things like the maximum number of packets a second the card can receive and transmit. It could also limit what kinds of cables the system can connect to. For example, you might need a tier four to connect to fibreglass. Keeping on the same note, Radio Frequencies. Just like cables, we can only send so much data through the air at once. One way we allow for more people talking wirelessly, besides just having everybody wait their turn in a long que to talk, is Frequency Multiplexing (FM). This also adds a new unique challenge, but powerful tool, to busy areas. You can allow a lot of people to talk at once using multiple frequencies, but you need to develop systems to send data to users on the right frequency to have them actually receive it. Radio Frequencies would have different reasons to use it. Higher frequencies can transmit farther, but they use more power and they can be affected by things like weather (If I understand correctly some RF wavelengths can experience interference due to the size of the droplets). Lower frequencies would use less energy, but have lower range, but less susceptible to interference from things like weather (however, if memory serves right, lower frequencies are more noisy; translates in-game to possibly more failed packets and corruption). In the game, tiered wireless cards have been added. The higher tiers have the capability for wider bandwidth (meaning the range of RFs the card can use), multiple antennas (allowing use of multiple frequencies at once), and higher bandwidth (packets/second it can receive and transmit). To craft these, one good way could be like how you setup server racks. You can open a GUI where there are slots. You need better processor for higher throughput (packets/second) and higher memory for higher throughout volume capacity. All my suggestion make the game more difficult, sure. That’s why I use it over ComputerCraft. I like having my computers be complex and expensive, they should be! They’re freaking computers. This adds the ability to design a lot of new things, and new challenges. However, they won’t really effect new players. On your small one or Teo computer network running the default OS, everything will work perfectly fine. Only large-scale complex systems have these issues.

It is possible this was implemented elsewhere and I failed to notice it, but I did this as an exercise as exploring OpenComputers. My son and I play The 1.7.10 Pack for our sandbox fun (in survival mode though), and I wanted to see if I could easily use OpenComputers to replace the typical-and-complex nest of level emitters and crafting cards to maintain minimum amounts of certain items in the AE2 ME network. This is not terribly sophisticated, and is just "fire-and-forget" with respects to requesting the crafting operations from the ME Network. As I continue to dabble I may add in checking on the status of the requested jobs and bound the looping to when all requested jobs per loop-pass have been completed. Edited to include versions (Minecraft 1.7.10) and remove a couple of potentially confusing commented-out lines: OpenComputers 1.6.2.12 AE2 rv3 beta6 Lots of other stuff outside the scope of this program Here is what I wrote: local component = require("component") local meController = component.proxy(component.me_controller.address) local gpu = component.gpu -- Each element of the array is "item", "damage", "number wanted", "max craft size" -- Damage value should be zero for base items items = { { "minecraft:iron_ingot", 0, 512, 32 }, { "minecraft:gold_ingot", 0, 256, 32 }, { "IC2:itemIngot", 0, 512, 32 }, -- Copper { "IC2:itemIngot", 1, 256, 32 }, -- Tin { "IC2:itemIngot", 2, 512, 32 }, -- Bronze { "IC2:itemIngot", 3, 256, 64 }, -- Refined Iron { "appliedenergistics2:item.ItemMultiMaterial", 8, 128, 32 }, -- Fluix Dust { "appliedenergistics2:item.ItemMultiMaterial", 10, 128, 32 }, -- Pure Certus { "appliedenergistics2:item.ItemMultiMaterial", 11, 128, 32 }, -- Pure Nether { "appliedenergistics2:item.ItemMultiMaterial", 12, 128, 32 }, -- Pure Fluix { "appliedenergistics2:item.ItemMultiMaterial", 22, 128, 32 }, -- Logic Processor { "appliedenergistics2:item.ItemMultiMaterial", 23, 128, 32 }, -- Calculation Processor { "appliedenergistics2:item.ItemMultiMaterial", 24, 128, 32 }, -- Engineering Processor { "appliedenergistics2:item.ItemMultiMaterial", 52, 32, 32 }, -- Blank Pattern { "appliedenergistics2:item.ItemMultiPart", 16, 128, 32 }, -- Glass Cable - Fluix { "appliedenergistics2:item.ItemMultiPart", 21, 64, 32 }, -- ME Covered Cable - Orange { "appliedenergistics2:item.ItemMultiPart", 22, 64, 32 }, -- ME Covered Cable - Magenta { "appliedenergistics2:item.ItemMultiPart", 24, 64, 32 }, -- ME Covered Cable - Yellow { "appliedenergistics2:item.ItemMultiPart", 25, 64, 32 }, -- ME Covered Cable - Lime { "appliedenergistics2:item.ItemMultiPart", 29, 64, 32 }, -- ME Covered Cable - Cyan { "appliedenergistics2:item.ItemMultiPart", 30, 64, 32 }, -- ME Covered Cable - Purple { "appliedenergistics2:item.ItemMultiPart", 31, 64, 32 }, -- ME Covered Cable - Blue { "appliedenergistics2:item.ItemMultiPart", 34, 64, 32 }, -- ME Covered Cable - Red { "appliedenergistics2:item.ItemMultiPart", 36, 64, 32 }, -- ME Covered Cable - Fluix { "appliedenergistics2:item.ItemMultiPart", 140, 64, 32 }, -- Quartz Fiber { "appliedenergistics2:tile.BlockQuartzGlass", 0, 64, 32 }, -- Quartz Glass { "minecraft:glass", 0, 512, 256 }, { "minecraft:sand", 0, 512, 256 } } loopDelay = 60 -- Seconds between runs while true do for curIdx = 1, #items do curName = items[curIdx][1] curDamage = items[curIdx][2] curMinValue = items[curIdx][3] curMaxRequest = items[curIdx][4] -- io.write("Checking for " .. curMinValue .. " of " .. curName .. "\n") storedItem = meController.getItemsInNetwork({ name = curName, damage = curDamage }) io.write("Network contains ") gpu.setForeground(0xCC24C0) -- Purple-ish io.write(storedItem[1].size) gpu.setForeground(0xFFFFFF) -- White io.write(" items with label ") gpu.setForeground(0x00FF00) -- Green io.write(storedItem[1].label .. "\n") gpu.setForeground(0xFFFFFF) -- White if storedItem[1].size < curMinValue then delta = curMinValue - storedItem[1].size craftAmount = delta if delta > curMaxRequest then craftAmount = curMaxRequest end io.write(" Need to craft ") gpu.setForeground(0xFF0000) -- Red io.write(delta) gpu.setForeground(0xFFFFFF) -- White io.write(", requesting ") gpu.setForeground(0xCC24C0) -- Purple-ish io.write(craftAmount .. "... ") gpu.setForeground(0xFFFFFF) -- White craftables = meController.getCraftables({ name = curName, damage = curDamage }) if craftables.n >= 1 then cItem = craftables[1] retval = cItem.request(craftAmount) gpu.setForeground(0x00FF00) -- Green io.write("OK\n") gpu.setForeground(0xFFFFFF) -- White else gpu.setForeground(0xFF0000) -- Red io.write(" Unable to locate craftable for " .. storedItem[1].name .. "\n") gpu.setForeground(0xFFFFFF) -- White end end end io.write("Sleeping for " .. loopDelay .. " seconds...\n\n") os.sleep(loopDelay) end I have also attached a cropped screenshot of it running and the output. Naturally one will want to turn knobs on the crafting amounts and frequency. I find the 60 minute cycle to be more than enough for the crafting backlog to be cleared.

do you want to make an ass out or yourself? this is how you make an ass out of yourself. Also, what? Like, what do you mean you want people to teach you but you don't want to look at videos? If videos are a problem, then google is your friend. Lua ain't too hard to learn. also holy duck it's hard to decipher what the hell you're saying

OEFI v2.1 FOR LUA ARCHITECTURE, OEFI PRESENTS LITTLE TO NO ADVANTAGES! Lua BIOSes that implements OEFI must allow using conventional booting. Note that OEFI has been made to be more architecture-independent and will support ANY architecture able to read files and CPIO (basically any architecture with basic access to component and bitwise operations). Concepts Application: Executable code booting using OEFI in the EFI1 or EFI2 format. Conventional Booting: OpenComputers default booting method. Often called "BIOS" Operating System (OS) : Complex Application with user interaction and/or providing an environment for programs. Concept only used in this document for Conventional Booting OC: Shortcut for "Open Computers" Rationale Due to the limitation of current OC booting method which basically searches for an init.lua file, the most big problem is that this only work for Lua architecture, and what should other architectures use, init.asm? init.test? init.o? What happens if we want one drive to contains multiple inits for multiple architectures? Well that's where Open Extensible FiUsing CPIO instdead of URF rmware Interface comes handy. The limitation OEFI fix in Conventional Booting in OC is: In Conventional Booting, there is only one init script per filesystem, while in OEFI there can be multiple applications per filesystem. Conventional Booting doesn't have any native support for multiple applications. An OS that want to boot another one need to manually check for init.lua files in all filesystems, OEFI has oefi.getApplications() method for it, this is even worse for Applications booting on unmanaged drives Conventional Booting isn't made for any other architecture than Lua. And with it, like addressed below, it's impossible to have multiple applications for multiple architectures, while OEFI allows in theory to have one same drive to boot on all architectures it support, without tweaks needed from the user! 2.1 Changelog Changed EFI2 format into a properties file for easier parsing Using CPIO instdead of URF for same reason: easier parsing Added OEFI Extensions, oefi.loadInternalFile(path) and oefi.setApplications(appTable) Fixed having put AwesomeCatgirl instdead of AdorableCatgirl as username for CAP conntribution Application Table Format The application table must contains tables as entries. The tables must contains the drive address with "drive" key and the path (from drive) with "path" key Example: { { drive = "af58dbe2-ff8c-433a-a871-c08723e01f25", path = ".efi/sampleos.efi" }, { drive = "af58dbe2-ff8c-433a-a871-c08723e01f25", path = ".efi/osOnSameDrive.efi2" }, { drive = "015f9d4c-cdfb-4686-91cb-bc8cf997f4ec", path = ".efi/another_os.efi" } } For architectures not supporting tables, "drive" is index 0 and "path" is index 1 For architectures not supporting arrays inside arrays (2D arrays), the arrays should be appended in such a way it look like that: drive, path, drive, path, drive, path, ... Application Finding OEFI Applications can be found on any sort of drives, from disk drives to floppy, with raids, only if they contains a ".efi" directory. The OEFI should search files in ".efi" directory: If the file ends with .efi, then check if it contains CPIO signature, if no, boot in compatibility mode (OEFI1, which is not described anymore on this document). However if the same file contains that signature, then boot as normal. .efi2 will ALWAYS be in standard EFI2 format, unlike .efi which can be EFI or EFI2. .efi can be EFI1 or EFI2 to keep compatibility with old OEFI Applications, and to allow 8.3 filesystems to still support OEFI (would be problematic otherwise) Standard Methods Methods are same as in Version 1, of course API version is now 2 (logic), and some new methods are being added, so here is the new list of methods: oefi.loadfile(path) - Loads file from boot drive oefi.loadInternalFile(path) - Loads file from current archive - new in OEFI 2.1 oefi.getBootAddress() - replaces computer.getBootAddress() oefi.getApplications() - Return an application table as described above oefi.setApplications(appTable) - Set the application table (as described above) to appTable. - new in OEFI 2.1 oefi.getAPIVersion() - Return API version number. Returns float, double or any decimal 2.1 for this version oefi.getImplementationName() - Returns implementation name oefi.getImplementationVersion() - Returns implementation version number oefi.returnToOEFI() - Recalls the OEFI program, the expected behavior is that the implementation will try to re-execute itself. oefi.execOEFIApp(drive, path) - Boot another OEFI app by using the implementation's routine oefi.getExtensions() - OEFI EXTensions is for non-standard features from implementation. This should always be used for implementation methods. The way this work is described below - new in OEFI 2.1 For architectures supporting tables (and global), API must be available in Global Else, API must be available as a pointer/struct/class/anything like that available as argument to the code OEFI Extensions work in the following way: If the architecture supports entries with keys, then a entry should be created containing the function (or its pointer), and the key should be equals to ImplementationName_MethodName_MethodVersion, ImplementationName should be same as in oefi.getImplementationName(), MethodVersion should be the revision number of a method, starts at 1. And MethodName is the name of the method. Example: SuperOEFI_DrawHandSpinner_2, which could be called (in Lua) via oefi.getExtensions().SuperOEFI_DrawHandSpinner_2() If tables are not supported, then the array (returned by oefi.getExtensions()) should contain all the methods as other arrays. So oefi_ext will be a 2D array. Each array should contain the name (see above) at the first index (0 or 1, depends on architecture), and a pointer to the function (or the function itself, if possible) at second index. If 2D array too aren't supported, then like Application Table, the array should act like if they are appended to each other. Please also note that if possible, computer.getBootAddress() and computer.setBootAddress(addr) should be REMOVED! This is due to that Applications supporting OEFI doesn't need any compatibility methods as thoses conventional booting methods are only kept when booting a OS that only support conventional booting. Implementation can create their own methods, however it should ALWAYS BE INSIDE oefi.getExtensions(). (see above) EFI2 EFI2 is a new format for Applications, it replaces EFI(1) in , it is a CPIO archive. All files in that archive must be placed at root and are listed here: app.cfg app.exe app.exe is only the Application, it contains the code designed for target architecture, and will be launched by the OEFI . app.cfg is a configuration file using "key = value" scheme. The file should look like this: name = Application Name version = 1.0 oefiVersion = 2.1 arch = Lua archMinVer = 5.2 archMaxVer = 5.3 "name" is equals to the name of the Application. Will always be a text "version" is equals to the version of the Application, if you don't want to fill it, just make it stay to 1.0. Will always be a decimal "arch" is a string with the name of supported architecture, "archMinVer" and "archMaxVer" are self-explanatory and will always be a decimal. Note that for archMinVer and archMaxVer, -1 can be used if a version doesn't make sense to the architecture to have a version. (example: a 6502 architecture) "oefiVersion" is equals to the OEFI version the Application has been designed to run with, if the "oefiVersion" field have a version incompatible with the current API version or if it's higher than the current one (ex. it's equals to 3 but we're on API v2.1, or it's equals to 1 but we're on API v2). This will also always be a decimal With all thoses fields in mind, the EFI2 was designed to be durable, with only changes being to app.lon and URF version. Configuration Data Everything is explained in that image: Component Address Packing To shrink down components to 16 bytes, since components address (and UUIDv4 in general) are just hexadecimal numbers converted to string, we can re-convert the string to a byte array and vice-versa. To do it, the lines (-) must be ignored, and each group of 2 characters must be interpreted as a hexadecimal string, this should be easy with architecture supporting string to number with optional base (in our case base is equals to 16) For example it turns: 68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b into: {0x68, 0xCA, 0x0F, 0x59, 0xAC, 0x2C, 0x49, 0xF8, 0xBA, 0x6A, 0x3C, 0x4C, 0x7E, 0x5F, 0x06, 0x9B} Here is a code sample submitted by AdorableCatgirl to encode and decode the addresses: function binToHex(id) local f, r = string.format, string.rep return f(f("%s-%s%s", r("%.2x", 4), r("%.2x%.2x-", 3), r("%.2x", 6)), id:byte(1, 16)) end function hexToBin(addr) addr = addr:gsub("%-", "") local result = "" for i=1, #addr, 2 do baddr = result .. string.char(tonumber(addr:sub(i, i+1), 16)) end return baddr end -- example: hexToBin("68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b") == {0x68, 0xCA, 0x0F, 0x59, 0xAC, 0x2C, 0x49, 0xF8, 0xBA, 0x6A, 0x3C, 0x4C, 0x7E, 0x5F, 0x06, 0x9B} -- "68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b" == binToHex(the array below) Back to EEPROM data, implementation name and custom configuration are very easy to understand what they're about.

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") Draconic Evolution Energy Storage multiblocks. RFTools Energy Cells Thermal Expansion Energy Cells Mekanism Induction Matrices 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

MineOS is half the operating system and half the graphical environment for OpenOS, which comes in OpenComputers mod by default. Oringinally it was developed in Russian, but it supports several languages. MineOS has following features: Multitasking Windowed interface with double buffered graphics context Animations, wallpapers, screensavers and color schemes Language packs and software localization User authorization by password and biometrics Support for file sharing over the local network via modems Support for client connection to real FTP servers Error reporting system with the possibility to send information to developers App Market with enormous amount of wonderful applications and possibility to publish your own programs for every MineOS user An internal IDE with syntax highlighting and debugger Open source system API and detailed illustrated documentations Custom EEPROM firmware with the possibility to select/format the boot volume and Internet recovery Almost complete compatibility with OpenOS software How to install? First, you need to install OpenOS from floppy disk to your HDD. After that you'll be able to run MineOS installer via single command: pastebin run 0nm5b1ju System requirements: Internet Card OpenOS installed on Tier 3 HDD Tier 3 GPU 2x Tier 3 RAM Tier 3 CPU (not really matters, just speed up) Troubleshooting: Are there any problems, suggestions? I'll be glad to see you on the operating system repository: https://github.com/IgorTimofeev/MineOS

This is a simple Applied Energistics 2 Stock AutoCrafting monitor. With this programm you can say that you want to keep certain items and amounts in stock. You can specify how many processors you want the program to use. If ingredients are missing the program will tell you in the message column, but not which ingredients. If you want to change or delete an item you have to check the box infront of the item name and the press the change or delete button. The program creates automatically 2 config files, 1 for the items and the other one for some other values (at this time only max cpu usage is stored in this file). V1.3: https://pastebin.com/326Sh9Xe << Installer for AutoCrafting and GUI Lib (pastebin get 326Sh9Xe AE2AutoStockInstaller.lua) Changelog: Completely overwritten Code Added GUI for better editing of Crafting List Added Installer (Installer will set Startup to AE2 Auto Stock tool) V1.2: not Published V1.1: https://pastebin.com/wDup161T Changelog: Added more errors: No Recipe (if recipe is not in network) and All Cpus busy (if players/programs request/s occupied all cpus) V1.0: https://pastebin.com/JC3WewzK Have fun and enjoy... Sorry for my bad english...

This is an object-oriented library, the main priority of which is the maximum possible performance. It works on the double buffering concept, it has a lot of widgets, animations and custom event handlers support. All programs from the screenshots above are implemented with its help. If you want to develop a fast and beautiful program in just a few lines of code without butthurt - then this library is made for you. Detailed illustrated documentation, installation methods and tons of practical examples are available at: https://github.com/IgorTimofeev/GUI

Minitel is a simple, efficient networking protocol implementing layers 3, 4 and 5 of the OSI model. It supports automatic configuration and routing over large and small networks. This topic contains links to all known Minitel protocols. Core protocols (OSI layers 3 through 5): protocol-3.md - describes the format of Minitel packets and basic behavior of each node. protocol-4.md - describes how ordered sequences of packets should be handled. protocol-5.md - describes how Minitel's bidirectional streams work Application layer protocols: FRequest - a simple file retrieval protocol MMail - simple mail delivery protocol If you wish to have a protocol added to this list, post it here.

Well i wanna make a program witch is a os that is more better than openos So... i wanna say that i don't really know how to program so i need your help... Questions of mine How can i make startup programs/alias. Can i use custom apis? Or just better ones? Could i change the edit program? (How?) How can i add buttons? (Guis, Desktops, etc.) How can i make a installer? -------------------------------------------------------------------------------- Please submit your answers in *Submit Here* I hope you will enjoy my os. still going on with the aternos server. I buyed a server a long time but people still not buying for my stock so i needed to shutdown untill i make enough money to pay to the server. Submit your vote! Help me with those questions please

Hello guys i am Symbo i know this is a simple tutorial but the fact that idk programming well let's talk about it! Now the programming language as named LUA is a programming language that is very easy to learn! Let's get start with an explication of what you sould start with. Now whos like me that dosen't know programming well your here to learn some. You sould go ahead and get ComputerCraft and learn CC's lua because it's the same but some apis are modified because OC uses direct lua. This is the most inpersive concept of learning lua without learning the apis. First of all i am not a programmer i will not teach you lua, it's your opinion if you want to learn lua or not. Now the fact that lua is easy to learn you sould first learn ComputerCraft... well heres some apis that will actualy help you programming some programs term.clear() term.setCursorPos(X, Y) print("STRING") Now those are some basic stuff. CC has basic lua so you will learn much much basics from CC, If you do that then you can learn OC because if you know CC already then it wil lbe 5x more easier to learn because only some apis are changed from the basic lua. The stuff you don't need at CC is components, components are the basic stuff you start with and they are optional for OC (Open Computers) Now you sould learn CC first and then OC because it will be very very easy to learn DIRECT LUA I recommend lua 5.3 because lua 5.2 is not even doing good anymore. Now if you wanna change the cpu to lua 5.3 then just brick right click in air and you will see in chat what type of lua you changed. Now replay if you want i will try replaying to the replay you did so if this makes no sense then i will call your replays comments. Now let's start with some basic stuff that people are very lazy to do Well the first stuff is learning, people whos lazy dosen't even have time to learn but they have to make thier programs. But what if programming languages was about explaining what the program does Like While the program is open then Open the other program. end Well this is not how it works. People stop being lazy reading and start learning! - Post end -