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

Search the Community

Showing results for tags 'library'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • OpenComputers
    • Announcements
    • Feedback
    • IRC
  • Code Central
    • Support
    • Showcase
    • Tutorials
  • Addons & More
    • Addons Mods
    • Architectures
    • OpenEngineering Task Force
  • General
    • Lounge
    • Forum Games
    • Showcase
    • Servers
  • Archives
    • Public Archives

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Minecraft


GitHub


IRC


Fediverse ID


Location


Interests

Found 12 results

  1. There was no IRC library for OpenComputers, so I've made one. Here's a demo bot that uses it: local com = require("component") local event = require("event") local thread = require("thread") local gpu = com.gpu local irc = require("irc") local events = irc.events local env = setmetatable({ irc = irc, events = events, }, {__index = _G}) local client = irc.builder() :connection { host = "irc.esper.net:6667", throttling = { maxDelay = 2, maxThroughput = 5, }, } :auth { nickname = "oc-finger-irc", username = "fingercomp", realname = "OpenComputers IRC client library", } :bot { channels = {"#oc-finger-irc"}, tracking = { users = true, modes = true, account = true, userInfo = true, }, } :execution { threaded = true, reconnect = true, catchErrors = true, } :subscribe(events.irc.command, events.priority.high, function(self, client, evt) gpu.setForeground(0x00ff00) print("→ " .. evt.rawLine) gpu.setForeground(0xffffff) end) :subscribe(events.irc.write, events.priority.normal, function(self, client, evt) gpu.setForeground(0x00dbff) print("← " .. evt.line:gsub("[\r\n]*$", "")) gpu.setForeground(0xffffff) end) :subscribe(events.irc.message, irc.events.priority.normal, function(self, client, evt) if evt.source.nickname == "fingercomp" then if evt.message == "::quit" then evt:reply("Quitting.") evt.client:stop(("%s told me to quit."):format(evt.source.nickname)) elseif evt.message == "::spam" then evt:reply("1") evt:reply("2") evt:reply("3") evt:reply("4") evt:reply("5") elseif evt.message == "::longmsg" then local msg = {} for i = 1, 256 do if i == 128 then table.insert(msg, tostring(i) .. " ") else table.insert(msg, tostring(i)) end end evt:reply(table.concat(msg)) elseif evt.message == "::error" then (nil).test() elseif evt.message:sub(1, #"::exec ") == "::exec " then local code = evt.message:sub(#"::exec " + 1) local chunk, reason = load("return " .. code, "=irc", "t", env) if not chunk then chunk, reason = load(code, "=irc", "t", env) end if not chunk then evt:reply(("\x0304Error:\x0f %s"):format(reason)) else local result = table.pack(xpcall(chunk, debug.traceback)) local success = table.remove(result, 1) result.n = result.n - 1 for i = 1, result.n, 1 do if type(result) ~= "string" and type(result) ~= "number" and type(result) ~= "boolean" and type(result) ~= "nil" then result[i] = tostring(result[i]) else result[i] = ("%q"):format(result[i]):gsub("\\\n", "\n") end end if not success then evt:reply(("\x0304Error:\x0f %s"):format(result[1]:match("^[^\n]*"))) io.stderr:write(("%s\r\n"):format(result[1])) elseif result.n > 0 then evt:reply(table.concat(result, " ", i, result.n)) else evt:reply("\x0309Success") end end end end end) :subscribe(events.irc.ctcpRequest, irc.events.priority.normal, function(self, client, evt) if evt.ctcpCommand == "TIME" then evt:reply(os.date("%F %T")) end end) :subscribe(events.client.error, irc.events.priority.top, function(self, client, evt) print("Caught: " .. evt.traceback) evt:cancel() end) :build() local t = thread.create(function() repeat local evt = event.pull("interrupted") until evt end) env.client = client client:run() thread.waitForAny({t, client.thread}) client:stop("Quitting.") os.exit() I don't want to brag about it too much, but I think the code is pretty. Features Threaded execution. A nice API. IRCv3.2 capability negotiation. Throttling to prevent the bot from triggering anti-flood mechanisms. Tracks channel members, modes, nick changes, account names, etc. Automatically reconnects if it's disconnected from the IRC server. Splits long messages over multiple lines. The event bus can use coroutines as message handlers. Links The GitLab repository: https://gitlab.com/cc-ru/irc-oc Documentation: https://gitlab.com/cc-ru/irc-oc/-/wikis/home Demo programs: https://gitlab.com/cc-ru/irc-oc/snippets
  2. I wrote this simple library for saving and loading tables from files as I needed such functionality for my program. (Useful for saving program settings between reboots.) Requirements: OpenOS Documentation: load(string: path) Returns the table stored in given path. save(table, string: path) Saves the table in a file located in path local serialization = require("serialization") local tableToFile = {} function tableToFile.load(location) --returns a table stored in a file. local tableFile = assert(io.open(location)) return serialization.unserialize(tableFile:read("*all")) end function tableToFile.save(table, location) --saves a table to a file local tableFile = assert(io.open(location, "w")) tableFile:write(serialization.serialize(table)) tableFile:close() end return tableToFile Usage: local ttf=require("tableToFile") --Saving local data={"a","b"} ttf.save(data,"/tmp/dataTable.txt") --loading local data=ttf.load("/tmp/dataTable.txt") If you have suggestions on how to improve it, please comment. (or make a pull request/issue in the GitHub repo.) This can also be found from here: https://github.com/SpaceBeeGaming/OC-Script-Collection/blob/master/lib/tableToFile.lua
  3. Hello everyone! Direwo... eh, not quite right. Well, OpenGlasses for 1.12 is out! And I noticed there were no public button API for it, so I made one myself! I have a few functions built-in to make it easier to change stuff, but it was created with simplicity in mind. So if you simply just initialize a button and bind a function to it, it won't do any fancy stuff except for activating the function when you press it, so you have to add your own functionality to it: But with a little bit of extra code: Ok, not that big a difference, you guys are probably more creative than me! I also have a concept called "groups". When creating a button, you can specify what group it should be in. So if you want to change the color of all the buttons to the left side to pink, you can do that. Functions (in no particular order): --Needs to be called before creating any buttons, works as a reset also: gButtonAPI4.initialize() --Creating a new button element: gButtonAPI4.createNewButton(name,group,display,x,y,w,h,color: table,transparently,callback: function) --Has to be inside of your main loop: gButtonAPI4.update() --Prints all registered groups: gButtonAPI4.printGroups() --Change the visibility of the button/group: gButtonAPI4.visibility(button/group,boolean) --Change the color of the button/group: gButtonAPI4.Color(button/group[,color: table])--None for default color. --Same as color, but changes the label: gButtonAPI4.Label(button/group[,text])--None for default label. --Add a button to a group: gButtons.addToGroup(button,group) If you don't want to make a new function for each new button, you can then bind them all to the same function. And add a parameter to your function, the name of the button that was clicked will be returned: local function btniF(buttonx) gButtons.Color(buttonx,{0,255,0}) print("I am " .. buttonx .. "!") os.sleep(0.5) gButtons.Color(buttonx) end I added a Demo program that shows most of the library's functions. Oh, btw, I like the number 4. It's not like this is my fourth attempt creating this or anything! Write a reply if you have any questions, this was my first attempt to create a usable library. gButtonAPI4.lua gButtonsDemo.lua
  4. 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.
  5. While updating my WarpDrive mod preloaded LUA scripts, I've noted a few issues. Issue #1: As of OC 1.7.10-1.6.0-beta.1, autorun.lua scripts provided by my mod were automatically executed. As of OC 1.7.10-1.6.2, the same scripts are no longer loaded when starting the computer. However, they'll run if I break/place my block. From a LUA console, filesystem autorun is reported as enabled (filesystem.isAutorunEnabled() returns true). If I "install" them, they are copied in / but still won't autorun. Same goes if I copy them in /home. How are we supposed to have autorun now with OpenOS? Is there a wiki on how the boot sequence works? Issue #2: When connecting multiple version of the same block, each one will provide the same read-only filesystem from the same location. However, OC API doesn't seem to detect them as equals and create a lot of filesystem components while only one is actually necessary. Is it the intended behavior? How can I declare the filesystem as being actually the same? Here's a simplified version of my TileEntity code: Issue #3: I've added a common library to all my scripts. When placed next to the autorun.lua script, it'll only find it when I change to that folder first. It appears the autorun is called without setting current directory to it, is that intended? Using the OpenOS install command does copy some files, but the library doesn't get installed in /lib or something. How can I install my library automatically?
  6. Changelog: First and foremost, yes, this is a port of DW20's button API from ComputerCraft. Why do his? Because his is a rather simple API and it provided a challenge, at least for me, to learn more about OC. When I did the port, it is more or less a direct port, so any limitations, or bugs (if any) were present in it, are still there. The only change I made to his api is that I made the button flash delay configurable from your script so you shouldn't have to edit the API itself to change it. Now, for some of the issues I noticed from this API running on OC: 1. It does fully work, but due to how OpenComputers draws to the screen, its not a smooth transition (you can see the button being redrawn). Does not affect how it works, but it causes a minor delay, as noted below, and does not look very...pretty, if you care about that sort of thing. This has been corrected! 2. For things like switching the toggle-able button or while the flash button is...well...flashing, you can't press any other button until that button has finished its redrawing process. Again, not a huge deal, just a minor annoyance. That is why I made the flash delay easily configurable from your main script so you do not have to tinker around inside of the API itself. With the optimization that Molinko provided, this is no longer a major issue, but the button flash delay is still configurable to suite your personal tastes. 3. Do to how OC handles bundled cables, if you use this for working with redstone, be sure to include a short delay between switching multiple redstone outputs, or else it WILL become very upset, take your grandmother hostage, set fire to your house and kick your pets...in other words, it will crash in a spectacular fashion. Again, thanks to Molinko's help, this no longer seems to be the case. It is possible that it could vomit all over itself if the buttons are 'mashed' as fast as possible, but currently it seems unlikely (note, unlikely does not mean impossible, so use caution just to be sure!). 4. This is more or less a direct port of his API to OC. The only change I made was the flash delay. Yes, I am sounding like a broken record, but thanks to the help of Wuerfel_21 and Molinko, some optimizations have been added and some code changed to make it more efficient in OpenComputers. With that said, here is an 'old' demo of it in action (the button drawing issue has been fixed since this video was made): Here is the pastebin link for the 'main' demo script: http://pastebin.com/tW1AfDbA (save it as 'demo') NO LONGER RECOMMENDED! here is the pastebin link for the buttonAPI.lua script: http://pastebin.com/dP0bj3ck (save it as 'buttonAPI.lua') NO LONGER RECOMMENDED! Pastebin link for the corrected 'buttonAPI.lua' script: http://pastebin.com/YUPjgQmd (save it as 'buttonAPI.lua') Pastebin link for the corrected 'main' demo script: http://pastebin.com/N7ggD2CN (save it as 'demo') save them both and run demo to test it.
  7. Hi, I want to start coding some programs in OC but i'm facing questions i would like to solve before really writing. 1) IDE I usually write in NotePad++ for simple Lua programs, but i'm thinking, there must be a better way to do it for code completion, etc. I already checked this wiki but i want to see your personal opinions and reasons. 2) Project Management I chose to use Git/GitHub for source management and i wish to have one repo for each libraries, programs, etc. In this way, i could easily have independent releases, and this will force me to thinking in modular and reusable manner. But this will also greatly increase the amount of repo and will messed up my github account with a bunch of relative projects (OC lua) side by side with potentials other projects. So i'm searching a way to have all the pros of multiple repositories whitout the con of the spread. Like one big repo container with multiple real repo in it. The best compromise i found is the use of an organization for that. But i ask because i must miss something easier. 3) OC librairies To have access in libraries, we use 'require', ok. But how it works? Is there a specific directory on the in-game computer for libraries storage? And if not how OC knows where to search? If i want multiple instances of one library on a computer for example : myLib(v1.0.0) and myLib(v2.0.0) used by two different programs but not the same version. how can i handle this? Thanks for your answers and suggestions!
  8. The request-handler is a program to run as a main program on a PC. It holds execution commands from every program that communicates with it. That means I can run multiple programs that run their commands through the request-handler by adding their command and parameters to the request-handler. It also servers as a server for other computers that can send their requests to the server and if that request is allowed it will be processed automatically and the answer is send back. For this I programmed the modem-API that ensures that message networks are received on the target and works together with the request-handler. This way it is possible to run programs simultanious (like multithreaded), if they use the request-handler that runs in a main loop. It is also possible to simply run a client - server program, ask information from the server and similar. you find those libraries in my github under request-handler.lua and modem-handler.lua. It runs perfectly and was in use by me in several programs and it works awesome. I also used it in my shop-system. As I do not have time to continue the development, feel free to clone it and use the code as you wish.
  9. PotatoLib This will be updated as I add new things version(): Returns the version of PotatoLib writeFile(path, data): Writes data to the file located at path readFile(path): Returns the data of the file located at path encode(data): Serializes data decode(data): Unserializes data getModemAddress(): Returns the modem address of the network card in the computer
  10. Introduction We all know the problem: Users - including me - can be quite impatient. This is especially true if a busy program does not give a clue if it is actually doing something. That's where a progress bar is useful. This library - I named it 'auto_progress' - makes it easy to include a nice progress bar into your program. Apart from the progress bar itself you also get a numeric indication and a time to finish estimate. To avoid cluttering the limited screen space it is only activated if your program didn't finish the first 50% within a second. Redrawing is limited to 4 redraws per second to reduce the slowdown due to drawing operations. To use it you need a number to describe an amount of 'work'. This can be a number of bytes, a number of items or any unit you like. (You define it!) API FUNCTIONS auto_progress.new(totalWork or table or nil) -> progress_state if the parameter is a table: uses this table as the progress_state, adds methods and default values if it is a number: creates a new progress state with totalWork set to the number if it is nil: creates a new progress state with totalWork=1 progress_state.update(workAdded) adds 'workAdded' to the internal progress counter and updates the progress bar if necessary. (should be called at regular intervals) progress_state.finish() draws the final 100%-progress bar if it has been drawn before. (should be called if the program finished it's operation successfully) progress_state.draw() forces drawing the progress bar. It also cancels the initial drawing delay by setting progress_state.drawing to true. PROPERTIES progress_state.x, progress_state.y uses the given position to draw the progress bar. (recommended if you want to use the progress bar within an UI) Nil values are replaced by the corresponding term.getCursor() ordinates, unless both values are nil and the cursor isn't at the beginning of the line. Then they will be set to the beginning of the next line. progress_state.width sets the width of the progress bar; nil makes the progress bar extend to the end of the line. progress_state.drawing setting this to true cancels the drawing delay. progress_state.disabled true disables automatic drawing; manual drawing is still possible though. progress_state.doneWork the counter which is summing up all workAdded values from progress_state.update() progress_state.totalWork the amount of work that corrensponds to 100% progress_state.creationTime the computer.uptime() when the object was created progress_state.lastUpdate the computer.uptime() from the last progress_state.draw() call Example --load library local auto_progress = require 'mpm.auto_progress' --generate a list of actions local todo = {} for i=1, 30 do todo[i] = math.random() * 2 end --create progress bar: initialize it with the amount of work to do local pbar = auto_progress.new(#todo) for _, duration in pairs(todo) do --simulate an action os.sleep(duration) --update progress bar: 1 step done pbar.update(1) end --tell progress bar that the action has been finished pbar.finish() Example output: Dependencies Software This library only depends on standard OpenComputers libraries. It was tested with OpenComputers 1.4.1.14. Hardware To see a progress bar you obviously need a screen and a gpu. But the library itself should work fine without them. Anything else is a bug! Installation Just download the library and move it to the lib directory of your choice. I recommend "/home/lib". Download (last update: 07.05.15) github Ingame: wget 'https://raw.githubusercontent.com/mpmxyz/ocprograms/master/home/lib/mpm/auto_progress.lua' Update from 07.05.15: changed library name from "auto_progress" to "mpm.auto_progress" to clean up library directories Known Issues The progress bar does not move upward, if you print something on the screen that causes scrolling. If you have an idea how to fix that or any other suggestion, feel free to leave a comment below. I also added a lot of features while writing this description. If something doesn't work as expected: It's a bug in the code or in the documentation.
  11. So, from what I am understanding this "should" work but I keep getting the the following error: attempt to index local 'test' (a function value) error. here is the "test" (main) file local test = require("testAPI") local term = require("term") term.write("This is NOT from the api!") test.fred("And this is!") And here is the "testAPI.lua" file: local term = require("term") function fred(text) term.write(text) end function george() term.write("should not see this unless george was called!") end and when I run it I get: /# test This is NOT from the API! /test:5: attempt to index local 'test' (a function value) stack traceback: /test:5: in main chunk (...tail calls...) Basically, I would like to create an API/Library with various functions in them so I can call the separate functions as needed. What am I doing wrong to prevent this error? p.s., I did look at this tutorial and tried to use a table with a different error altogether.
×
×
  • Create New...

Important Information

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