Search the Community
Showing results for tags 'storage'.
Found 7 results
Heyo! 1M here! Soo...I made a block of raid and put drives in it, and promptly realized that I could not find raid documentation, nor could I find how to use it. My question is, how do I a.) access the raid. b.) put data onto the raid. Any help will be appreciated, as I am on my first use of this mod, and so far it looks amazing! Thank you in advance! 1M out!
OpenSolidState for Minecraft 1.12.2 ____________________________________________________ Source Code and builds can be found on Github. Note: Requires Forgelin. General Purpose (E)EPROMs? Have you ever wanted fast storage? How about wanting to boot PsychOS 2 on a uC? Well, now you can! There are two main variants: The card and the drive. The Card! The Drive! Tiers: Tier 1 - Manually erased EPROM, erased with the assembler. 64KiB Tier 2 - Electronically erased! Still 64KiB Tier 3 - Bigger EEPROM! 128KiB! But how do I craft them? Just use JEI, trust me. What else is included? A utility floppy and ROMFS boot EEPROM are included with the mod! Feel free to ask more questions! i need to make docs
Repository: https://github.com/cyb0124/OCRemote. The following is a copy of the repo's readme. OCRemote is an OpenComputers program by cyb0124 for item management and auto-crafting. Main features include: Extensive reuse of same machines for multiple recipes. Prioritization of recipes based on the current number of items stored. (e.g. deciding which crop to grow, or deciding which ore to process first.) Robust handling of multiple-input recipes to prevent clogging (e.g. for alloy furnaces). Preventing recipes from using up the last seed/sapling/etc. OCRemote is designed for survival/expert-mode gameplay in modpacks such as Enigmatica 2 and Project Ozone 3. When used correctly, it can completely replace ME-system based auto processing both in early game and in late game. It has been tested to function correctly in Sponge-based public servers. Server and clients OCRemote includes a TCP server program written in C++ that needs be run outside the minecraft world. All decision-makings happen in the server. The computers in minecraft world merely execute the commands sent by the server. Multiple clients can connect to the same server, which allows parallelization of inventory manipulation operations. Bus OCRemote requires a shared inventory to move items around. This inventory is called as the "bus" in the source code. The bus can be implemented using EnderStorage's ender chests, or using ActuallyAdditions' item lasers. Storage OCRemote currently supports 3 different types of storages: Chests OCRemote will use chests the most efficient way, i.e. coalescing item stacks to avoid wasting slots. StorageDrawers or equivalent. ME system OpenComputers' access to ME system is slow (throttled), so OCRemote is able to use multiple computers to access the same ME system to parallelize accesses. Auto Crafting OCRemote doesn't analyze any tree structure for recipe dependencies; instead it will simply start to craft an item if the amount stored of that item falls below a set point and if all ingredients are available. This will eventually propagate through all recipe dependencies. If multiple recipes use the same machine, OCRemote will prefer the recipe with the lowest percentage amount stored. All processes can also regulate the amount of items in the machine buffer to prevent bloating the machine buffers. OCRemote currently supports the following types of auto-crafting processes: ProcessSlotted This process is intended for machines that can only run 1 recipe at once and the input items need to go into specific slot with the correct ratio. OCRemote will only execute recipes that input items match the items already in the machine. ProcessCraftingRobot This process uses a single crafting robot to handle all grid crafting recipes. It also allows non-consumable items in recipes (e.g. Pam's Harvestcraft recipes that require utensils, or master infusion crystal). ProcessRFToolsControlWorkbench Same as ProcessCraftingRobot, but uses RFTools Control's Workbench as the crafter. In this case, non-consumable items are stored in a neighboring inventory. ProcessBuffered This process is intended for machines that can run multiple recipes at once, or for general buffering/pipelining of recipe inputs. In additional to recipes, it also allows items to be constantly refilled at the target inventory. Besides being able to regulate the total amount of items in the buffer, it also allows limiting each individual recipe's maximum number of items being processed. This process respects the ratio of the input items and only sends complete sets of inputs, which is useful for machines such as ExCompressum's Auto Compressor, or gear presses. ProcessScatteringWorkingSet This process is intended for machine that can run multiple recipes at once but independently for each slot. This process will try to spread out input items among slots to help with parallelization. ProcessInputless and ProcessHeterogeneousInputless These processes are for machines that passively generate outputs (e.g. cobblestone generators). ProcessReactorHysteresis This process is a simple hysteresis feedback controller for big/extreme reactors. ProcessReactorProportional This process is a simple proportional feedback controller for big/extreme reactors. ProcessPlasticMixer This process automatically sets PneumaticCraft's plastic mixer's color setting to produce the plastic that has the lowest amount stored. Usage The documentation is still WIP and there isn't a GUI for configuration yet. The storage/auto-crafting configuration is currently hardcoded in the server program's main function. It contains a sample configuration which you can adapt for your own use. To use OCRemote, you need to build and run the server program on a server that can be reached from OpenComputers' Internet Card. The server requires a C++ compiler (e.g. gcc) with C++17 support, CMake and Boost to build. For the client script, you need to edit the first 3 lines to match your server configuration. The client script is meant to run without any OS or storage medium. To run it, first compress it using Lua minifier and then flash it into an EEPROM. Alternatively, you can upload the client script to a HTTP server and flash the loader script to load the uncompressed client script from the Internet.
So I made myself a little lua script to read the inventory of my me storage system and also list the amount of bytes they require. Its my first script so I'm sure there are better ways to do all of this. The Me Network is connected to the Computer via an adapter on the me controller of the network. Pastebin here Now what it does is it uses the getItemsInNetwork function to list all items in a loop and display the name and amount of Bytes of each item in one line. A line counter goes up for each of the items added which is needed later. After all Items are listed it displays the total amount of Bytes available as well as the amount of bytes used and then the percentage of used storage. And finally at the very end a timer is displayed that counts down from 60. Once this timer is over the script refreshes and goes through the list of items again so that the item counts are updated. here is where I used the line counter so that the very last line could get cleared and replaced with the new timer that displays one second less on every loop until it hits zero and the script refreshes. This script has worked for me for quite a while and on a second me system that only holds 3 different types of items it still does. On my main me storage however this script is starting to break at the very end with the timer line no longer being overwritten and instead adding multiple lines alongside the new timer line like so: And here is how it looks on the other me system: Here the line "Time until refresh: n" is replaced the way its supposed to. The only difference between the two scripts is that the one that works uses the getFluidsInNetwork function instead. Is there a way for me to fix this or is it a problem of having too many items in storage ? Additionally tips on how to improve this script in general are welcome as its my first and could probably be improved a lot.
"FullChest" item sorting storage system This program uses a robot to sort items into simple storage system. I am using iron chests mod here. There is an input chest (golden), storage chests (iron), and an overflow chest (diamond). The robot is placed behind the input chest facing the chest and I recommend placing a charger next to it. Red blocks are always required, orange and yellow blocks are required depending on storage size (in this one, orange blocks are needed). I usually place them all to be sure. The storage chests must always be on the right from the input chest. Each storage chest must have no empty slot! If you want a chest to contain certain items, put one of these items into a slot like this: The robot then goes around in zig-zag pattern and tries to put each item into each chest. All chests have no empty slots, therefore only wanted items can be put into each chest - for all other items the chest is full. If the robot is waiting on the start, it checks the input chest for new items every 10 seconds. If an item is found it will start sorting in 1 minute (except for the first check - then it si immidiet). Program also in attachments robot = require("robot") os = require("os") computer = require("computer") totalSlots = robot.inventorySize() function dropAll(slots) for i = 1, slots, 1 do robot.select(i) robot.drop() end robot.select(1) end function suckAll() count = 0 while robot.suck() do count = count + 1 end return count end -- direction false - left -- direction true - right function next(direction) if not direction then robot.turnLeft() else robot.turnRight() end b = robot.forward() if not direction then robot.turnRight() else robot.turnLeft() end return b end while true do first = true while robot.suck() == false do print("check") first = false os.sleep(10) end robot.drop() print("Sorting is starting...") if not first then print("in 60 seconds...") os.sleep(60) end print("now!") usedSlots = suckAll() if usedSlots > totalSlots then usedSlots = totalSlots end direction = false robot.turnLeft() robot.forward() robot.forward() robot.turnRight() while true do dropAll(usedSlots) while next(direction) do dropAll(usedSlots) end print("end of row") if not robot.up() then -- last row print("end of sorting") robot.turnRight() while robot.forward() do end robot.turnLeft() dropAll(usedSlots) while robot.down() do end dropAll(totalSlots) -- just to be sure break end direction = not direction end end sorter.lua
Program for storing items in chests. The program is in development. In the future you will see autocraft and other (but I'm lazy) Everything about the program, you will see in the video. Video in rus, but all information you can understand from video. command for install program wget -q https://gitlab.com/lfreew1ndl/openCraftNet/raw/master/openCraftNet.lua openCraftNet.lua sources https://gitlab.com/lfreew1ndl/openCraftNet/tree/master/ my contacts: telegram : https://t.me/lfreew1ndl 1) put items in first slot in the chest to setting transposers. (like in video) 2) scanning chests take a min 3) showItems -> work only after scaning Selectors
I think OpenComputers is a great mod itself, but it needs more stuff and some improvements. Here's what I Think needs to be added/improved. (LOTS of Reading!) ***SERVER SYSTEM ENHANCEMENTS/CHANGES*** 1. When linking multiple servers via cable, then wiring it to a screen, numerous graphical glitches occur. This is because every server is trying to overlap eachother on the screen. I think that you should add a completely different screen, a screen that can control an entire server room in one console. For example: A terminal that, upon typing a command, turns on every server that is linked together. Or just computers in general. A system that can process commands within multiple systems without graphical gltiching/spazzing. 2. Detection of bad servers. Currently, if a server crashes (aka "Unrecoverable Error") then it just turns off. This is not very helpful as it seems like it is already off and it does not indicate that it actually failed. You should add a system that. upon a crash, instead of a shutdown, the server light goes red to indicate a failure. This is a problem because I made a server room, but for some reason, at random times, my servers will crash randomly. (I am still figuring out why) so that would help out greatly to tell me which serevers are off and which failed. 3. Large Server Racks. Nothing important, but I think it will be cool if you add large server racks. I understand you could just stack 2 server racks to make it large, but making a 2-black high server rack would ease up some issues with controlling both near eachother. ***RAM IMPROVEMENTS/ADDITIONS*** 1. Tier 4 RAM. This would be nice because it would help processing speed and load speeds of the computers. For example, when running geo2holo, on tier 1 RAM cards, it is horribly slow, but on tier 3.5 RAM cards, it is still pretty slow. Tire 4, and possibly even tier 5 would be pretty cool. 2. More RAM Slots. A normal computer today has 4 RAM slots. And just like my previous suggestion, this would increase performance of the computer. If you can't/dont make the tire 4/5 RAM cards, adding 2 extra slots would be fine too. You could double the current max RAM by doing that, greatly improving performance and flexability of memory allocation. ***STORAGE ADDITIONS*** 1. CD/ROM's. Having disks would be nice, as most computers today barely use floppy drives anymore. It would also increase the storage space that you would have. Imagine you as a super-programmer (whatever that is) and you filled up 5 floppy drives. You'd have to carry around 5 different floppy drives with different stuff in it which takes up inventory space and makes it harder to find things. With CD/ROM's, you could fit all of that into a sorted disk and only have one inventory slot allocated.