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

Adorable-Catgirl

Members
  • Content Count

    44
  • Joined

  • Last visited

  • Days Won

    9

Reputation Activity

  1. Like
    Adorable-Catgirl got a reaction from Fingercomp in uncpio - A simple CPIO extraction utility   
    uncpio is a rather simple binary CPIO extractor (File begins with 0x71C7 or 0xC771, made with cpio -oHbin). To acquire uncpio, run
    pastebin get YbrVjRwa /bin/uncpio.lua To use, make the directory you'll be extracting your CPIO archive to, cd into it, then run
    uncpio path/to/your/file.cpio And it will extract to the current directory. Currently only works in OpenOS, as far as I know.


  2. Like
    Adorable-Catgirl reacted to Izaya in vTunnel - TCP-based Linked Card Emulator   
    Bumping because it's basically been re-written; we're on 2.0 now, and it has some big improvements:
    Better re-connect logic Multiple connections pcap capture support for the vTunnel bridge with a wireshark plugin for dissecting Minitel packets Additionally, this post will contain a list of known public relays:
    lain.church, port 4096 luna.nosafe.space, port 4096 (thanks @Adorable-Catgirl )
  3. Like
    Adorable-Catgirl reacted to Izaya in vTunnel - TCP-based Linked Card Emulator   
    vTunnel can be used to add bridging over the internet to any existing OpenOS software that uses linked cards.
    Despite originally being written for Minitel, vTunnel implements a fully-functional linked card emulator and a server that will run under most unix-likes (OpenBSD is currently somewhat flaky, Linux is recommended).
    You can peruse the page on Github, for documentation and protocol information.
    Install it with oppm:
    oppm install vtunnel Additionally, you can read the documentation in-game with
    man vtunnel  
  4. Like
    Adorable-Catgirl got a reaction from Izaya in LuaComp - Includes, macros, and more!   
    Wow, isn't it annoying to write EEPROMs? Don't you hate how messy they are?
    Well, I have the utility for you! LuaComp!
    LuaComp
    A general purpose Lua preprocessor and minifier.

    Building
    To build, either execute luapreproc or luacomp on src/init.lua

    luapreproc
    Execute luapreproc init.lua ../luacomp.lua

    luacomp
    Execute luacomp init.lua -xO ../luacomp.lua
    NOTE: Do not use a minifier, it breaks argparse!

    How-To

    Merging Lua source files
    -- myfile.lua local my_lib = {} function my_lib.hello_world() print("Hello, world!") end -- main.lua --#include "my_file.lua" my_lib.hello_world()
    Getting enviroment variables
    print("This was compiled in the shell "..$(SHELL))
    Macros
    @[[function my_macro(a, b)]] print("Hello, @[{a}]. Your lucky number is @[{b}].") @[[end]] @[[my_macro("world", 7)]] @[[my_macro("user", 42)]] @[[my_macro("Earth", 0)]] @[[my_macro("Satna", 666)]] @[[my_macro(os.getenv("USER"), os.getenv("UID")]]
  5. Like
    Adorable-Catgirl got a reaction from Totoro in OpenSolidState   
    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
  6. Like
    Adorable-Catgirl reacted to Izaya in portinfo - Network port database   
    OC-ports
    OC-ports provides a database and library for using said database to cross-reference between protocol names and network port numbers. The database also contains the entity that registered the port(s) and, if applicable, a link to more information.
    API
    The portinfo API provides one function:
    portinfo.search(*query*, [*database*]) table: result The search() function takes your query - either a string or a port number - and searches the database, defaulting to the OC ports database, for your query, returning the first result as a table in the format:
    name port registered by more information This is more than enough to use for simple port lookups and generating tables.
    Reserving ports
    To reserve a port in the database, please submit an issue on the GitHub repository.
    Download
    portinfo can be installed via oppm from the Minitel repository, using the command
    oppm install portinfo Additionally, to install manually, place portinfo.lua into /usr/lib/, and both oc.db and minitel.db into /usr/lib/ports/.
  7. Upvote
    Adorable-Catgirl reacted to Izaya in realtime - Real world time in OpenComputers   
    Ever needed real-world time in OpenComputers? I did today, so I did something about it.
    realtime
    realtime is a set of libraries and protocols designed to let you synchronise your computers with the real world, and includes:
    The realtime library, for taking and keeping time. The realtime-sync daemon, for synchronising your realtime library with the real world The realtime-relay daemon, for synchronising your realtime across the local network. All of these can be downloaded via oppm, or from the Minitel GitHub repository.
    Additionally, all of these come with manual pages describing their functionality and usage, all of which can be found here.
  8. Like
    Adorable-Catgirl got a reaction from Izaya in OpenSolidState   
    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
  9. Upvote
    Adorable-Catgirl reacted to coderboy14 in RF and Cable Bandwidth and Further Abstraction of Networking   
    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.
  10. Downvote
    Adorable-Catgirl reacted to OC Best fan ever in Get Started With Lua!   
    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 -
  11. Upvote
    Adorable-Catgirl reacted to Izaya in OETF #12: Minitel Protocol Family   
    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.
  12. Upvote
    Adorable-Catgirl reacted to EliteClubSessions in GUI: extremely fast advanced interface library   
    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
  13. Like
    Adorable-Catgirl reacted to Zoidbert in AE2 Stock Auto Crafting V1.3 /w Installer   
    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...


     
  14. Downvote
    Adorable-Catgirl reacted to OC Best fan ever in OC Programs - Share programs   
    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
  15. Upvote
    Adorable-Catgirl reacted to asie in Introducing "Lunatic"   
    No spoiler in the title. Just watch the video.
    EDIT: Apparently someone's ComputerCraft fork is more findable on Google than the original OpenComputers repository, so here's the official source code: https://github.com/asiekierka/lunatic86
     
     
  16. Upvote
    Adorable-Catgirl reacted to XyFreak in Big Reactors Grid Control   
    Hi everyone.     A while back I promised more releases, so here you go: Big Reactors Grid Control is a multi reactor/turbine controller for Big Reactors and Extreme Reactors. Mission goal: Be the best big reactors controller there is. Nothing more, nothing less.
    First things first - here's the website: https://tenyx.de/brgc/
    NOTE: Due to a bug with OpenOS 1.7.4, BRGC will not work with that version. Please update to 1.7.5.
    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  
  17. Upvote
    Adorable-Catgirl reacted to Zen1th in OETF #16 - Open Extensible Firmware Interface   
    Open Extensible Firmware Interface 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 Firmware Interface comes handy. Using . The limitations OEFI fix in Conventional Booting in OC are:
    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! OEFI is basically a much more extensible version of OETF #1, « Standardized booting of nonstandard architectures » and Conventional booting.
    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 as « drive » entry and the path (from drive) as « path » entry
    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 hash maps / dictionnaries, "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, ... . This is the default standard used by C for multi-dimensional arrays. If the language supports multi-dimensional arrays then the arrays of the language must be used.
    Finding Applications
    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)
    API 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 Space after key or before name is parsed as it and aren't ignored, be careful!
    "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.
  18. Upvote
    Adorable-Catgirl reacted to Palagius in AE2 Level / Auto-crafting   
    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.
     

  19. Upvote
    Adorable-Catgirl got a reaction from Molinko in OC Programs - Share programs   
    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
  20. Upvote
    Adorable-Catgirl got a reaction from Izaya in IceKey and Igloo - Pure Lua encryption!   
    Have you ever wanted to encrypt something but couldn't afford a T2 data card? Well, look no further than icekey-lua and Igloo!
    Low Level: IceKey
    IceKey is the low level library. It's no RSA, but it should work for most purposes in OC. If you want to learn more about ICE, click here. Useful if you want to do more with the block cipher, rather than just encrypting files or whatnot. It can be found here.
    High Level: Igloo
    Igloo is the high level library, great for encrypting/decrypting files. Automatically uses a CBC and padding. It can be found here.
     
    PRs welcome!
  21. Like
    Adorable-Catgirl reacted to Izaya in Minitel   
    Minitel
    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.
    Currently supported platforms include OpenOS, KittenOS NEO (via this package), and embedded devices.
    Features include:
    Flood routing with route caching Reliable packet delivery Packet segmentation Ordered delivery Bidirectional, ordered, reliable streams Installation instructions and API documentation can be found in the Github repo, though they can be summarised as "oppm install minitel".
    Demos:
    Minitel and the net API Mail over Minitel FRequest in action
  22. Upvote
    Adorable-Catgirl reacted to Zen1th in Fuchas, a powerful operating system   
    Fuchas 0.4.0 is almost done 
    The new features are:
    MineOS installer: AVAILABLE Multi-user: AVAILABLE Dualboot (arleady used for 0.3.0): AVAILABLE CPIO-based installer (very very stable installation and allow updates): AVAILABLE Security! (permissions): AVAILABLE Default unicode support: AVAILABLE Virtual components: AVAILABLE (updated 06/30/2019)
  23. Like
    Adorable-Catgirl reacted to its_meow in OpenScreens   
    OpenScreens
    for Minecraft Forge 1.12 to 1.12.2
                                                                                                        

     
    OpenScreens adds more display options for OpenComputers.
    Curse Link: https://minecraft.curseforge.com/projects/openscreens
     
    Holo Screens
    Holo screens are floating displays with adjustable size and color.
     

    Hologram projector model and texture by ZefTheFox
    Right clicking a holo screen with a dye will change the background color. Right clicking the sides with an empty hand while crouching adjusts the size of the display.
     
    Flatscreens
    Flatscreens are simple displays that are... flat! There's two types, one on the front of the block and one on the back to allow more freedom.

     
    I have questions/need support! Where can I get help?
    You can always ask in my Discord server. If your issue is related to OpenComputers, you can read the OpenComputers Wiki. Report bugs here.
     
    My website: https://itsmeow.dev/
    Discord Server: https://discord.gg/zrjXjP5
     
    Curse Link: https://minecraft.curseforge.com/projects/openscreens
  24. Like
    Adorable-Catgirl got a reaction from Izaya in uncpio - A simple CPIO extraction utility   
    uncpio is a rather simple binary CPIO extractor (File begins with 0x71C7 or 0xC771, made with cpio -oHbin). To acquire uncpio, run
    pastebin get YbrVjRwa /bin/uncpio.lua To use, make the directory you'll be extracting your CPIO archive to, cd into it, then run
    uncpio path/to/your/file.cpio And it will extract to the current directory. Currently only works in OpenOS, as far as I know.


  25. Like
    Adorable-Catgirl reacted to Zen1th in Fuchas, a powerful operating system   
    Say hello to liburf's 2nd URF!

×
×
  • Create New...

Important Information

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