Eunomiac

Thank you! That's exactly what I was envisioning, I was just missing a few of the pieces to get it to work. Unfortunately, you confirmed my main concern---that I have to trigger meExportBus.exportIntoSlot() once per item. I'm fairly sure iterating on each individual item will begin to cause problems as players hook up extremely high-quantity/high-speed item inflows. One idea I'm tinkering with is to use a long-period timer that, upon firing, records a count of every item in the network, then voids the items by yanking the storage drives themselves and dumping them into a Trash Can

Bit of Background: I'm working on an adventure/building/design map that focuses on creating a balanced network of automated systems, with a few twists to spice up the challenge. One of these twists makes accumulating too much of a resource a problem the player has to address in their automation (long story short: voiding mechanics and high-capacity storage options are disabled and/or against the rules). So, if you want to automate a MFR Biofuel Generator using nine different types of crops, you'd better make sure you're generating each crop at the same rate... or you'll get a surplus, and F

When I'm testing a program, my standard "workflow" is to Ctrl-Alt-C out of the program and simply re-run it, whenever I want to test new code. I know to use package.loaded[library] = nil to unload libraries, but I'm running into two other issues after I started playing around with event.timer(): How do I cancel or purge all timers in response to a Ctrl-Alt-C interrupt? Is there something similar to package.loaded[lib] = nil; library = require(lib) that I can add to the beginning of my programs to wipe out timers from previous runs? Some elements (I'm not sure which) of my programs are pe

EDIT: Wait! It's the "local". Remove "local" from in front of comp.gpu.bind. (I'll leave my original post, in case it ends up being an issue after all, but I'm 95% sure it's the "local" ) I'm just heading to bed, so my apologies for the drive-by attempt at helping... but I used to get this error when I wrote programs in Notepad++, before I switched the encoding to "Encode in UTF-8 without BOM". Other encodings (... codings? encodes?), like ASCII, use hidden characters for things like line breaks that OC doesn't like. You can quickly check this by opening the program in OC's edit term

Yeah, I wouldn't use palette swaps for that. I'd recommend a few "nuts & bolts" functions to make working with colours easier, and have your GUI objects call those to change their colours. E.g. I made my own versions of gpu.set and gpu.fill, which use my setColor() function, which uses a custom palette that references colors by name: local palette = { Black = 0x000000, Grey1 = 0x2D2D2D, Grey2 = 0x4B4B4B, Grey3 = 0x696969, Grey4 = 0x878787, Grey5 = 0xA5A5A5, White = 0xFFFFFF, -- ... and so on, all the colours of the rainbow, till... LtPurple = 0xC

Thanks, that fits with the results I get with my testing! Here's a color table reference that I kinda... over-did (as is my way); it's indexed and includes the 240 main colors plus the 16 greys. Definitely a good resource for anyone who wants to plan color schemes in an image editor before coding them in (feel free to add it to the wiki or wherever, if you like; I happily cede it to you in delayed payment for adding remote component access to the debug card): Yes, if you change the color palette, anything you've drawn in that color will change to the new color. (It's actually

Thanks! I can't take full credit, I found some ASCII patterns on the web and just replaced the slashes and underscores with the corresponding full-width unicode versions. The main reason I browse these images rather than other sources online is because I'm usually picking symbols based on how they connect with their neighbors, or how they're positioned inside their "boxes" relative to other symbols I'm using (i.e. if one symbol in a set happens to be positioned lower than the others, it looks awful). It's impossible to get that information without seeing them rendered in OC---so before I

Yes. Or, at least, why it's not coming quickly. You're asking a question that takes a lot of time and effort to answer: to go through your custom API and figure out how it works, then apply that knowledge to your code, and debug it for you. Make it easier for people to help you: Narrow down the issue by debugging it yourself as much as you can. Try writing a very simple program, verify that it works, then slowly add functionality until something breaks. Or, try walking through your program step-by-step in the lua console. Open the lua console (type lua), and load your library

Oh yeah, two more things: I didn't include pages that were entirely Asian characters, as there were a lot of them, and I wanted to focus on symbol-type characters. (Besides, I assume anyone interested in those characters is more familiar with using them than I) I apologize for the repeats in the albums, and for the (I think) unnecessarily high code numbers---I didn't know unicode very well when I first compiled these images, and scanned codes way higher than I needed to. I believe unused high-number codes take repeat filler characters... or something... and I haven't been able to spot a cl

Moderator note: this post is really outdated, and does not represent current OC. OpenComputers has incredible support for unicode! Here's a catalogue of OC's unicode support, with each character displayed on a T3 OC monitor. You can browse these images for the symbols you need, then look up the corresponding unicode.char() value by referring to the numbers at the edges. I've divided the characters into two categories. "Single Width" characters are easy to use, since they take up the same space as a normal letter. "Double Width" codes are a bit trickier---they don't work well

I've been experimenting with color in OpenComputers, and I have a few questions relating to how the color values I code are changed into the color values I actually get. I'm trying to create six color schemes (three colors each) to distinguish six modes of a GUI. After planning a few schemes and programming in the color hex codes, I've found (using gpu.get()) that the colors I enter are very rarely the ones displayed on screen. Almost all colors are changed to some degree, and quite often (45% of the time in my last test, see spoiler tags) two different colors display as the same color.

I'm not sure if this is due to a change in more-recent versions, but you'll want to use "package.loaded", rather than packages.loaded, for this to work. This also works from within programs: Simply set the package.loaded table to nil for any libraries you frequently edit just before you require them, and any changes made to those libraries will be reflected on a soft reboot (rather than having to manually turn the computer/server off-then-on). Here's a C&P from the top of my program: --========= DECLARING TOP-SCOPE VARIABLES ====================================================

I thought about it, hadn't planned on it, and then you go ahead and suggest it. So now... yes, yes it will And I will be looking for testers for a closed alpha relatively soon---just have to finish up some of the remaining programs---so I'll save you a spot. (You see, by having a closed alpha, then an open beta, and then a release... I get to advertise three different times without it looking like I'm spamming advertisements! It's BRILLIANT! Muahahahahaha... ahem.)

It's coming I currently stand in the shadows of Agrarian Skies, Blood 'n Bones, Crash Landing and M^3... and I've got a carefully-calculated roll-out campaign to challenge 'em all once I'm ready

Whoa. With the recent changes to the Debug card in builds 142 and 143, OpenComputers has just become the mod for adventure map builders everywhere. THANK YOU! Teleporting players is so much faster using the debug card than it is using command blocks. You're telling me I can change entire areas of blocks, WorldEdit style? That's more power than the Command Block ever dreamed of! And, of course, that one feature I begged you for: The ability to grab a player's location from a remote terminal. My teleportation program works perfectly. In case you wanted to see the fruits of your la

Thanks! I'm working on a survival "build" map that, instead of having specific goals (like Skyblock) is more freeform---players find themselves in the ruins of a hexagon-shaped city named Hex (tres original, I know). It's divided into six triangular districts, each with its own themes (high/low tech, magic, agriculture, etc.). Working within a few creative constraints, they must define what each district looks like, and rebuild Hex. The floor is inside a floating hub at the very center (the Hedron); it's actually a touch-screen linked to command blocks, that will teleport players to any

I've been playing with OpenComputers for some time now, and I've come across a few issues that I'm having trouble with. I'm not sure if these are bugs (in which case I'll post them to the issue tracker; just let met know), or if they've been fixed in the most current version (I'm still on MC 1.7.2, running OC v. 1.3.1.260), or if they're just me derping 1) How to Turn Sounds Off Via Config? I've set the "soundVolume" value to "0" in config/OpenComputers.cfg, on both client and server, and yet this doesn't seem to reduce or eliminate the grinding noise whenever my computers execute a comman

You, sir, are a gentleman and a scholar and a sterling example that elevates us all as human beings Yes, OC 1.3 on MC 1.7.2. I installed the OS to the hard drive, and placed the autorun.lua in the same location. Currently, the following "autorun.lua" file almost works. My current problem is that setPrimary() apparently selects the gpu randomly from the three I have installed, despite the fact that (I think) I've properly passed a valid gpu address to setPrimary(). The weirdness happens somewhere in the section I've commented as "2) Setting Primary GPU", halfway down the code:

Well this is just getting weirder and weirder. Now, setPrimary appears to randomly select the gpu. Here is the debug output (the only change to the initial file was adding "os.sleep(0.2)" immediately after setPrimary, and adding the output of a component.list to my debug file so you can confirm I'm getting my addresses right): COMPONENTS: 7ba654c7-9a62-4221-978e-01b9e3e13ede --- computer 98aa9c50-3f18-433f-99af-93fc83b7bbe5 --- gpu 3bdd83ae-1559-42b4-98dd-09cb46a8fb16 --- gpu dc40b4b8-4663-4378-b4e5-2a4da339b42f --- screen b3f856ca-8e6c-484f-9f52-bf30448736f2 --- keyboard 1a1c197d-bf4d-4b5

Apologies for the kinda-double post, but the problem I initially described in "[OC 1.3] Inconsistent autorun.lua" seems to be something else entirely---which I only realized after several walls of text Hardware: One computer, containing 3x GPU and 1x Hard Drive, linked by Cable to 3x Screens: the "Terminal" --- a simple 1x1 with a keyboard two "Displays" --- each is a large multiblock screen on the far side of the room Software: An autorun.lua file on the hard drive attempts to: mount the hard drive, set a specific GPU to be the primary GPU, then bind the primary GPU to the "Terminal"

And things keep getting weirder. Apparently, "setPrimary" isn't working for me. Here's a test "autorun.lua" I ran after trying to figure out that "no primary gpu" error in the event.log (I used a debug file, since "print" depends on there being a primary GPU, which is the main problem): local primaryGPU = "3f5" local primaryScreen = "1a1" function db(text) -- //snip// just writes "text" to a debug file -- end local component = require("component") primaryGPU = component.get(primaryGPU) -- resolve full address -- First, check whether primary GPU was randomly assigned: db("Primary GPU Exi

Ok, I've been at this for a long while, trying all sorts of different strategies. Please forgive the lengthy post, and thanks in advance for your help! I've bolded key points as an inline TL;DR. I think the problem is that the 'init' event isn't being heard by the autorun program. The listener is being registered, but the callback function isn't being run. Here's my current autorun.lua, with a bunch of debugging "print()" messages to help see exactly what code is being run: local address = ... local primaryGPU = "3f5" local primaryScreen = "1a1" print("Mounting Drive: " .. tostri

Thanks for your quick reply (I had to wait until I had a chance to test before responding in kind)---unfortunately, I'm afraid that doesn't work Here is the autorun.lua file contained in the root directory of the only hard drive on the computer: local event = require('event') event.listen('init', function() local primaryGPU = "3f5" local primaryScreen = "1a1" local component = require("component") component.setPrimary("gpu",component.get(primaryGPU)) local gpu = component.gpu gpu.bind(component.get(primaryScreen)) local fs = require("filesystem") local proxy = ...

I have a computer with three gpu's, connected to three screens. One monitor has a keyboard attached to it, and is meant to be the main access terminal; the other two screens are display-only. I've added the following autorun.lua file to the computer's hard drive, to mount the hard drive and set the appropriate primary gpu and screen: local primaryGPUAddr = "3f5" local primaryScreenAddr = "1a1" local component = require("component") component.setPrimary("gpu",component.get(primaryGPUAddr)) local gpu = component.gpu gpu.bind(component.get(primaryScreenAddr)) local fs = require("filesyst

On the subject of UTF8 characters, I've been having trouble getting most of them to display. According to the wiki entry for the Unicode API: "Specifically all glyphs defined in code page 437 are supported." However, I'm very unfamiliar with the distinction between unicode/ascii/utf8, and wasn't sure which of the listed Wikipedia codes I should be using. Actually, I think a quick example-question might solve all my problems: Question: How would I print the "DD = U+258C : LEFT HALF BLOCK" character to the screen? (And, if I can't, how do I know which characters I can use vs. wh