Zen1th

i didn't understood? Ok thanks you.

Thanks for the reply, some days after asking the question i also found out that no, that's why for absolutely no reason at all i started OCCity to change this.

The mod is not even yet updated for forge 1.13.X, so a version for 1.14 will maybe be in months or even year, since 1.12 and 1.13 have lot of technical changes. However i'm not a official developer of OpenComputers, so that's just guessings.

I didn't finished the installer. However i added a VERY IMPORTANT FEATURE, before events were handled by programs and blocking. Now events are handled by the task manager. Meaning A process can pull event while another does something else. Which is very close to multi-tasking. However this feature is buggy and some events are skipped, this should be fixed by optimizing. Alongside this i might make a GUI soon to show the benefits of multi-tasking V.S. single-tasking (used by MineOS and tactiOS). Which would allow programs to be active (doing something without blocking GUI) rather than passive (waiting for GUI event)!

OHML being complete, it just needed something next so the OHML specification is complete. And this thing is what is here: OHTP Definitions: Host - Any computer or machine with a OC-compatible modem attached to it Server - Host sending OHTP-valid data when an user attemps to connect Client - Host receiving OHTP-valid data from a Server OHTP - Open Hyper Text Protocol - Protocol used to transmit OHML - Open Hypertext Markup Language between Hosts. Specifications: The OHTP protocol doesn't take care of what is transporting it. Either it is using a socket API, going through modem, minitel or GERT. It assumes the API or transport layer you utilize supports sockets. Arguments in URLs: To put arguments inside URL, the url must end like normal, but have "?" at end, followed by "property=value" entry. If wanting to add more entries, add "&" after last entry Example: ohtp://1001.1002:1003.1004/index.html?username=admin&password=admin Client-Side: Once the socket is opened, the Client can ask data to Server The Client will send first a Request Header looking like it: OHML/MAJOR.MINOR REQUEST PAGE Example, if the REQUEST is GET, and the version 1.0, with a request page equals to /index.html (the PAGE entry CANNOT BE EMPTY, if wanting to access default file of server, use /): OHML/1.0 GET /index.html Currently the valid REQUEST values are: GET (just receive the file) There are also request bodies, which just include "Property: Value" entries. For now, request body is unused, however, there can be non-standard properties, but they must start with "X-" So a request is constructed like that: Request Header( + Request Body) The client, even after having received the Response from Server can still send new requests. All that until socket is closed. Server-Side: Once the Server receives a Request from a client. It must replies with a Response. A Response is contructed like this: Response Header + Response Content The Response Header is constructed like this: ERRORCODE Yep, i know it's really small, making it simple to implement. Currently there are thoses error codes: 200: OK 201: Moved permanently + new URL after ERRORCODE 300: Temporaly moved + new URL after ERRORCODE 301: Switch protocol + approved protocol name after ERRORCODE 404: Page not found 500: Server error 501: Internal error sending the the fetched page (e.g. file found but not accessible from server). 502: Server-side language is errored (Detailled version of 500, optional) 503: Service temporaly down The Response Content is just the content of the fetched file (if found).

For the signature, is the current version of this document is 1.0 (1 as major and 0 as minor) or is it something else? Because it's not written inside the document.. Also, the document says all string are encoded in UTF-8, ok, but must have their length at first, does it applies for the "URF" string part of the signature? There is also a lot of oddities in the entries, you say that if the entry is a file, the specifier byte must be "F", well it's ok because ASCII F byte have 6th and 7th bits equals to 1. However if the entry is a directory you say the specifier byte must be "D", but in ASCII, D equals 68 in decimal, in binary the 7th bit is 0. Also you say a entry should contains Object ID and Parent ID, but where, is parent id first or last? And is it written with 32-bit unsigned integer? Is it an ALI? You're not saying it which makes hard to make a standard implementation! P.S.: Even if document is unprecise, i managed to make an implementation of it, the first URF file is born

I finished the 2nd stage installer, i'll do the 1st stage (installing from OpenOS/MineOS) when i will have more time

Is there any video games for OpenComputers? As this would be cool, and no, i'm not speaking about a chip8 emulator or lunatic86. By that i mean games targetting OpenComputers Lua architecture. If no, that would be interesting to create some. After all almost all the programs i saw on the Showcase are OSes, #### control programs, drone managers, etc.

Fuchas One of the best multitask OS How Fuchas Works Fuchas is a true multitask OS for OpenComputers. By true multitask, i mean it is based on a task manager. To do it simple, the task manager cycle through all the active processes. It also pulls signal with a timeout of 0.05 seconds! (Speed is best). Fuchas is also modular and based on a driver system, the driver library will try automatically choosing the best driver, but it can be configured by user. Meaning programs can easily adapt to addons hardware (e.g. Computronics cards), however for now this aspect of Fuchas isn't really well used, a re-overhaul of it is planned soon. If you don't understand all that just retain something: Unlike OpenOS, it can run tasks at same time. (Technically it's not correct, since there is like a ~0.05s delay between tasks, due to Lua nature) The major "sellpoint" of the OS is booting and being in general VERY VERY FAST I'll do proper metrics soon, but Fuchas on a full T3 (T3 CPU, 2x 3.5 memory, T3 GPU) starts almost instantly (less than ~0.3 sec), compared to ~1sec for OpenOS and ~2sec for MineOS Dedicated. On a machine where call budget is always 0 (using an emulator), MineOS is unusable, OpenOS takes literally ~5sec to write a letter, and Fuchas still seems okay. Again, metrics comin g soon. If you don't believe me just try it Interfaces Fuchas, being modular, is about not fair to have 1 interface. That's why there can be multiple interfaces. Currently only one is included: Fushell (basically like OpenOS shell). Soon to come will be "Concert", which is a GUI interface, better suited for multi-tasking. Currently, the only interface to show, Fushell: You might as well as spotted the "pl" and "kill" command. Yep! Thoses are multitask commands I'm not doing a whole documentation here, but basically "pl" lists tasks (called processes internally) and "kill", well, it kill tasks Installing Whatever from what OS you're installing it. OpenOS: Just type the following: pastebin run s2YZJ0T6 MineOS: Coming soon.

I understand some people might just dislike another booting method, even if implementations should be compatible with original one. And as the document might seem "empty", any criticisms (good or bad) and/or suggestions are welcomed. Note: "Application" refers as init scripts for OEFI booting. Why: Due to the limitation of current OC booting method which basically searches for an init.lua file, a new and open specification has been made: Open Extensible Firmware Interface. The limitation OEFI fix in BIOS booting in OC is: - In BIOS booting, there is only one init script per filesystem, while in OEFI there can be multiple applications per filesystem. - The operating system, once launched, cannot return back to the BIOS (or here, the OEFI), while OEFI have oefi.returnToOEFI()! - Since BIOS 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 Specification: Every OEFI should be backward-compatible with OC original booting method which is basically booting init.lua. OEFI must also create a standard API available to the OEFI program as the first argument (of "..."), the API must implement at minimum the following: oefi.getApplications() - Return an application table as described below oefi.getAPIVersion() - Return API version number, current = 1 oefi.getImplementationName() - Returns implementation name oefi.getImplementationVersion() - Returns implementation version number oefi.returnToOEFI() - Recalls the OEFI program, most of _G structure should remain as it was at boot. Meaning that if for example, component API needs "require(...)" function, this will just crash. oefi.execOEFIApp(drive, path) - Boot another OEFI app by using the implementation routine computer.getBootAddress() - Return the filesystem address from which the application booted computer.setBootAddress(addr) - Provided for compatibility, does nothing Implementations can create implementation-specific methods that can be used by applications and OSes launched by them. Application Table: The application table must contains tables as entries. The tables must contains the drive address with "drive" key and the path (from drive) with "path" key Example: { { "drive": "af58dbe2-ff8c-433a-a871-c08723e01f25", "path": ".efi/sampleos.lua" }, { "drive": "af58dbe2-ff8c-433a-a871-c08723e01f25", "path": ".efi/osOnSameDrive.lua" }, { "drive": "015f9d4c-cdfb-4686-91cb-bc8cf997f4ec", "path": ".efi/another_os.efi" } } Application Finding: OEFI Applications can be found on any sort of drives, from disk drives to floppy, with raids, only if they contains a ".efi" directory. The OEFI should search in that ".efi" directory, and add every .lua or .efi files to its application table. ".efi" directory name has been chosen for being hidden by default on POSIX systems. (EEPROM) Data Format: Booleans are a single character value, they are equals to "T" if true, or "F" if false 1-Byte Numbers are also single character values, they are corresponding to the ASCII character of the number (use string.char(number)), these are limited to 255 as maximum value As of API version 1: The data (512 bytes) should be written in the following format (in the same order!) : - 1-byte number, equals to the API version of the implementation (current is 1), having it at start will allow for config conversion in case of new version - Last booted application filesystem component id (always 36 bytes) (like 68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b) - 1-byte number, equals to the length of the last booted application path (next value) - Last booted application path - 1 boolean for weither it should allow the OS to return back to OEFI or not Example (line breaks should NOT be included): (ASCII character 1) 68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b (ASCII character 15) .efi/fuchas.efi T

As far as i know, no, i'm not a OpenComputers developer, however i have some knowledge in Forge modding, one problem they will have to encounter is that making OC compatible with 1.13.x would need changing most of the code (mostly because it makes usage of metadata, and some other things). So it will probably be hard and long to do, since it will be long, i think it will probably be in beta (or something like that) for 1.13, and finished when 1.14 However, this is only what i'm saying, it isn't approved by any of OpenComputers active developers, so considerate what i said as a possible option

Due to how computers, in real life, so also in Lua works, it's logical, the number of bits to store on the number being also finite

uhmm.. can't we have more information on it? Like version, modpack (if needed) ? edit: nevermind, i just didn't looked the title, it's using all the mods 3

Yes i have discord, anyways if i mentionned GERT it's because i find interesting the idea of connecting minecraft servers each other. It allows for a OC "internet", since oc servers can now technically be acessed from any minecraft server having a GERT address. Which allows for endless possibilities in oc web.