Zen1th

This is a working clone of Super Mario Bros. (with some missing features ). It was made thanks to the VRAM buffers feature (only available in experimental builds), the game runs quite smoothly and uses the Computronics Sound Card to play music on the same computer. It loads sprites from .bmp files, levels from Tiled (a free level editor) .json file and music is in some custom format that can be converted from MIDI files. This makes the game quite easily moddable.
Source code
 

In September of 2021 I started investigating what it would take to write a LuaPosix compatibility layer for the original ULOS.  While it is indeed possible, ULOS's Cynosure kernel simply wasn't designed around that sort of API—it would at best have required a large amount of work and been difficult to accurately reproduce LuaPosix's behavior.  There were also a few idiosyncrasies with the system as a whole, and it doesn't work on 256KB of memory, which is unfortunate.
Cynosure 2 is my answer to this problem.  Its features include, but are not limited to:
 - Fully pre-emptive multitasking without requiring the `debug` API
 - Full, secure kernel-user separation, complete with removal of the `component` API.
 - Support for full POSIX file permissions, even on regular managed filesystems!
 - System calls performed through `coroutine.yield("syscall", "name", ...)` with no performance overhead.
 - A subset of POSIX standard system calls, some with slightly different behavior to account for Lua's advantages (`ioctl`, `open`) and limitations (`fork`).
 - The fastest VT100 emulator ever written for OpenComputers - comparable in speed to the original Cynosure's, and not limited by a poorly-written buffering library, Cynosure 2's VT100 emulation leaves its competition in the dust.  It's accurate, too - with (almost) all the features of Linux's VT100 emulator!
 - Sessions, process groups, character devices, line disciplines, VT100, oh my!  All the features you'd expect from a Unix-like kernel, implemented the right way.  System calls follow the Linux manual pages as closely as is reasonably possible.
 - True Unix-like multiuser support, with real and effective user and group IDs as well as saved-set-user-and-group-IDs.
DIsclaimer: Cynosure 2 is still in heavy development and not all of these features are fully implemented yet. Please contribute!  Also, yes, just writing the LuaPosix compatibility layer would have been less work, but ULOS 1 had some other idiosyncrasies / weak points - and this was the more fun route
You can find Cynosure 2's source code at https://github.com/oc-ulos/oc-cynosure-2.  I'm looking for bug-testers, contributors, and userspace developers.  Join my Discord server for development updates and for any questions/comments/concerns you may have!

This is a working clone of Super Mario Bros. (with some missing features ). It was made thanks to the VRAM buffers feature (only available in experimental builds), the game runs quite smoothly and uses the Computronics Sound Card to play music on the same computer. It loads sprites from .bmp files, levels from Tiled (a free level editor) .json file and music is in some custom format that can be converted from MIDI files. This makes the game quite easily moddable.
Source code
 

Hi all! I mentioned this in IRC but realized I should probably post it here as well. I made a new architecture that runs WebAssembly. It’s available here on CurseForge.

This is a working clone of Super Mario Bros. (with some missing features ). It was made thanks to the VRAM buffers feature (only available in experimental builds), the game runs quite smoothly and uses the Computronics Sound Card to play music on the same computer. It loads sprites from .bmp files, levels from Tiled (a free level editor) .json file and music is in some custom format that can be converted from MIDI files. This makes the game quite easily moddable.
Source code
 

This is a working clone of Super Mario Bros. (with some missing features ). It was made thanks to the VRAM buffers feature (only available in experimental builds), the game runs quite smoothly and uses the Computronics Sound Card to play music on the same computer. It loads sprites from .bmp files, levels from Tiled (a free level editor) .json file and music is in some custom format that can be converted from MIDI files. This makes the game quite easily moddable.
Source code
 

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 -

You can use the port that is not 80. since i said "SHOULD" and not "MUST". But i'll try to change this for better clarity

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.

Program and library for building GPS network.
https://github.com/DOOBW/OC-GPS
Download:
wget https://raw.githubusercontent.com/DOOBW/OC-GPS/master/usr/bin/gps.lua /bin/gps.lua
wget https://raw.githubusercontent.com/DOOBW/OC-GPS/master/usr/lib/gps.lua /lib/gps.lua
The functionality is the same as in the ComputerCraft.
Additional command "flash" allows to upload firmware to EEPROM.
When the coordinates are precisely determined, when flashing the position of the microcontroller can be omitted - at the first start it will determine its position from neighboring satellites and save on EEPROM.
GPS network startup example.
 

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)

Say hello to liburf's 2nd URF!

Thanks for the review. I will make a version 2 (on same post) to add the changes you suggested and some others changes. I will also soon make a more presentable form of the specification.

Fuchas
One of the best OSes (as said by me)
Fuchas in a Nutshell
Fuchas is revolutionnary in that it uses drivers instead of component access and support UAC (with separate permissions!) ! It's the end of the era where the program needs to maintain integration with different components, the OS now does it! The driver library will try automatically choosing the best driver, but it can be configured by user. Meaning programs adapt to components with no effort (e.g. Computronics cards)
A feature of Fuchas is security. If you do not trust a program, you can control permissions. Each account can have its own set of permissions. Allow one to have free access on a specific drive? You can do that!. Security is useful for computers on big servers with competivity. Although remember that without disk encryption, data can be accessed simply by using another operating system. Fuchas doesn’t hide files starting with ".", it uses attributes, filesystem’s one if supported on unmanaged drives, or with a .dir file at file’s parent directory.
Fuchas is also fast at startup, around 2x faster than OpenOS down like memory usage. And graphical features are optional, so you can use command-line on your T1 computer, and a graphical interface on T3, all on the same OS! And since the UI is compatible with 40x16 and doesn't uses a lot of memory, you can use both on a T1 computer!
Extra Features
For example, the GUI interface of Fuchas (named "Concert") uses the newly added GPU buffers when available in a way that is transparent to programs and user.
Interfaces
Here are the interfaces included: Fushell (a command-line shell) and Concert.
For example here is Fushell (warn: old version [4 major releases ago], but still a little representative):

and Concert as of Fuchas 0.7:

Install It
OpenOS:
Just type the following:
pastebin run EbHYvEE8 MineOS:
Search for the application 'Fuchas Installer'. Install it, launch it, and press Install.
Fuchas:
You’re on Fuchas 
(Note that all comments about broken installation below are outdated, and installers has been fixed!)
Links: GitHub, Wiki, Progress to next version, And here is how to break the whole Fuchas security system

Fuchas
One of the best OSes (as said by me)
Fuchas in a Nutshell
Fuchas is revolutionnary in that it uses drivers instead of component access and support UAC (with separate permissions!) ! It's the end of the era where the program needs to maintain integration with different components, the OS now does it! The driver library will try automatically choosing the best driver, but it can be configured by user. Meaning programs adapt to components with no effort (e.g. Computronics cards)
A feature of Fuchas is security. If you do not trust a program, you can control permissions. Each account can have its own set of permissions. Allow one to have free access on a specific drive? You can do that!. Security is useful for computers on big servers with competivity. Although remember that without disk encryption, data can be accessed simply by using another operating system. Fuchas doesn’t hide files starting with ".", it uses attributes, filesystem’s one if supported on unmanaged drives, or with a .dir file at file’s parent directory.
Fuchas is also fast at startup, around 2x faster than OpenOS down like memory usage. And graphical features are optional, so you can use command-line on your T1 computer, and a graphical interface on T3, all on the same OS! And since the UI is compatible with 40x16 and doesn't uses a lot of memory, you can use both on a T1 computer!
Extra Features
For example, the GUI interface of Fuchas (named "Concert") uses the newly added GPU buffers when available in a way that is transparent to programs and user.
Interfaces
Here are the interfaces included: Fushell (a command-line shell) and Concert.
For example here is Fushell (warn: old version [4 major releases ago], but still a little representative):

and Concert as of Fuchas 0.7:

Install It
OpenOS:
Just type the following:
pastebin run EbHYvEE8 MineOS:
Search for the application 'Fuchas Installer'. Install it, launch it, and press Install.
Fuchas:
You’re on Fuchas 
(Note that all comments about broken installation below are outdated, and installers has been fixed!)
Links: GitHub, Wiki, Progress to next version, And here is how to break the whole Fuchas security system

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

this is just a draft, feel free to suggest whatever.
URF v1.1
Abstract
This document describes the URF, intended to make mass file exchange easier.
Rationale
There are many competing methods of exchanging large amounts of files, and many are incomplete, such as TAR implementations, or proprietary, such as NeoPAKv1. With this in mind, a standard format will make file exchange less error prone.
Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
All strings are encoded with UTF-8, prepended with an ALI corresponding to the length of the string in bytes.
Character specifications such as NULL and DC1 are part of US ASCII, unless otherwise specified.
Concepts
Signature: Data at the beginning of the File, marking the File as a URF format archive, and specifying the version. File Table: Data structure containing all file information. Entry: Any data sub-structure in the File Table. Entry Specifier byte: A byte describing how to decode the data contained in an Entry. Object: A filesystem structure, i.e.. "file" or "directory". Attributes: Data describing the size, offset, parent Object, and Object ID of an Object. Extended Attributes: Data describing non-core attributes such as Permissions, Owner, Security, etc. Producer: A program or process that generates data in this format. Consumer: A program or process that consumes data in this format. Arbitrary length integers
Arbitrary length integers (ALIs) MAY be over 64-bits in precision. ALIs are little endian. For each byte, add the value of the first seven bits, shifted by 7 times the number of characters currently read bits, to the the read value and repeat until the 8th bit is 0.
Signature
The Signature MUST be URF (US-ASCII) followed by a DC1 character, or an unsigned 32-bit little endian integer equal to 1431455249. The next two bytes MUST be the version number, the first being the major version, the second being the minor version. The next two bytes MUST be DC2 followed by a NULL character.
File Table
The File Table MUST start after the Signature. This MUST contain all Entries, and MUST end with an EOH Entry. See EOH Entry.
Entry
An Entry MUST start with an Entry Specifier byte. The Entry Specifier byte MUST be followed with an ALI specifying the length. Data contained SHOULD be skipped if the Entry Specifier byte allows and the Entry Type is not understood.
Entry Specifier byte
An Entry Specifier byte MUST have the 7th bit set to 1. If the Consumer comes across an entry with the 7th bit not set to 1, the Consumer MUST stop reading the file and raise a fatal error. The 6th byte specifies if the entry is critical. The entry is critical if the 6th bit is set to 0. If the entry is critical and not understood, the Consumer should raise a fatal error; if the entry is non-critical, the Consumer SHOULD skip the entry and continue reading the file. If the 8th byte is set to 1, the Entry is a non-standard extension. Vendors MAY use this range for vendor-specific data.
Filesystem Structure
Any Object MUST have a Parent ID and an Object ID. Object ID 0 is reserved for the root directory.
File naming conventions
Object names MUST NOT contain any type of slash. Object names must also be of the 8.3 format, though the full name MAY be specified with Extended Attributes. Full names in Attributes MUST NOT contain any type of slash.
File offsets
File offsets are relative to the end of the File Table.
Entry Type: File
The Entry Specifier byte MUST be F, and the data contained MUST be the name as a string, followed by the file offset and file size represented as an ALI, then followed by the Object ID, then Parent ID.
Entry type: Directory
The Entry Specifier byte MUST be D, and the data contained MUST be the name as a string, followed by the Object ID, then Parent ID.
Entry type: Extended Attributes
The Entry Specifier byte MUST be x, and the data contained MUST be the Object ID of the Entry the Entry is describing, followed by a four byte Attribute and the value.
Currently recognized attributes include, names in US-ASCII:
NAME: The long name of the Object (String) PERM: The POSIX-compatible permissions of the Object (Unsigned 16-bit integer) W32P: Win32-compatible permissions of the Object, which override POSIX permissions (Unsigned 8-bit Integer, Read-Only [0x01], Hidden [0x02], System [0x04]) OTIM: Creation time of the Object (Unsigned 64-bit Integer) MTIM: Modification time of the Object (Unsigned 64-bit Integer) CTIM: Metadata update time of the Object (Unsigned 64-bit Integer ATIM: Access time of the Object (Unsigned 64-bit Integer) SCOS: Source OS of the Object (String) Entry type: EOH
The Entry Specifier byte MUST be Z, and the data contained MUST be the offset required to reach the end of the file.
Compressed URF naming convention
In an environment with long names, the file extension SHOULD be urf followed by a period (.) and the compression method (i.e. gz, lzma, xz, deflate) In an environment with 8.3 names, the file extension MUST be one of the following:
UMA for LZMA UXZ for XZ UGZ for Gzip UL4 for LZ4 UB2 for BZip2 TODO
Document is incomplete. Document should outline how to build the Filesystem structure, etc. Document should be checked for clarity and rewritten if needed.

THIS MOD IS NO LONGER SERVICED, PLEASE DOWNLOAD THIS INSTEAD!!!
 
 
A while ago there was a post on here about someone making custom cases, I am not that person but I do have a release.  This may be improved upon in the future but as of right now it is in a completely usable state.
This is a client side replacement for opencomputers. Do not use with normal opencomputers. This will be updated to release versions of OC and will not be for 1.7.10
Theoretically this should be usable as a client connecting to a server with normal opencomputers, this was not tested.
To use this install this modified version of opencomputers, it includes a custom case with it. If you want a different case you can choose to install a resource pack, I have made 2 so far. If a resource pack says it is incompatible for any reason ignore it, it's a single number in the pack.mcmeta that has to be different for certain minecraft versions, it will not effect the pack.
The default case that comes with the mod:

1.10, OC version 1.7.3
1.11, OC version 1.7.3
1.12, OC version 1.7.3
NZXT Case: download

IBM 5150 Case: download

 
Let me know of any issues, or any suggestions for future cases.
 
 

OHML v1.0.3
OHML is a markup language based on the eXtensible Markup Language (XML), it is a simpler and OC-graphics adapted version of HTML.
Why OHML?
It all started when i noticed that most network programs/libraries were either DNS system, or Website system.
However it is very important to maintain an universal language for webpages. It is the first step of having
a stable and universal "OCranet", which will follow with server and client implementations. Protocols, etc..
Concepts
HRef: Shortcut for Hyperlink Reference Document Versions
OHML patch versions (1.0.1, 1.0.5, etc.) minor changes (more understandable descriptions, new optional arguments) can be asked in comments section, might get accepted, and when features are froze, set as a new minor version of OHML specifications.
OHML minor versions (1.2, 1.1, 1.42) OHML major versions (2, 4, 5) are to be proposed in comments sections and feature froze. Once released they will replace the outdated data in this post.
Tags
Table about all tags and their (XML) arguments is available in png format, attached to this topic.
h1-h5
6-2 sized OC character font title, each letter must be made from the number of character both in width and height. The font can be any font, as long as it respects the size rule. This would usually be made using a big font library.
text
This tag allows to display a text line. If putting the text in the plain document, due to the XML nature line breaks wouldn't be counted. In the text tag they aren't counted neither, but at each tag end, a line is skipped.
script
This contains any script made for any scripting language supported by the Browser. The attribute "lang" defines the scripting language, it defaults to "application/lua" for LuaWeb, however it remains an XML tag and will not work well with multi lines, the solution is CDATA, simply add a comment and add <![[CDATA, then at the end of script do another command and put ]]> , this will effectively allow the use of multi-line scripts.
link
Displays inline text, it haves, by default, a blue color. When it is clicked the page jumps to the hyperlink reference defined by "href" attribute.
image
Contains one attribute: "file". This is the path of the image treated as an Hyperlink reference.
br
Breaks a line, which mean that a text line is skipped, this act the same as <text></text> but cannot contains any text.
button
Clickable button with text being inside the tag. The text doesn't support OHML but will still be parsed as XML (a CDATA section is then recommended).
Any <script> tag can set a listener on the button.
"onclick" listener
Arguments: mouseButton
mouseButton is "left" for left button, "middle" for middle button and "right" for right button.
box
Container. It can contains any possible tags in OHML. It can be used for styling the element's bounds are fully customizable using Positioning, and while by default it is transparent, using Styling this can be used as a resizable background color.
Tags Attributes
Positioning
Introduced in OHML v1.0.2, Positioning allows to position tags in an absolute or relative way.
Tags have optional arguments "x", "y", "width", "height" and "relative"
The "relative" argument is for using relative positions, vertical at first, and horizontal at last, we can use "up" (default) or "bottom", put a ";" for splitting, and add the horizontal value that can be "left" or "right".
Relative positions works that if for example the value is "bottom;right", and if x = -5 and y = -5, the element Y will be at the most bottom point of the page (meaning that bottom for a page with elements not going after 10 for y, the bottom would be 10), added -5, which is equivalent of minus 5, and the element X will be at most-right point (generally viewport width) and will have minus 5.
Meaning that for a page sizing 80;25, it would go at 75;20
Styling
Introduced in OHML v1.0.3, this allows elements to be stylized in little ways. This should eventually be superseded by a dedicated styling language.
The styling addition introduces many attributes, these attributes are also by default transmitted to the element's childs
bgcolor
This attribute takes an hexadecimal RGB value and sets the background color of an element. The background is effective on the bounds of the element, which are its absolute x, y, width and height.
color
This attribute takes an hexadecimal RGB value and sets the foreground color of an element. Like bgcolor, the background is effective on the bounds of the element.
Hyperlink Reference
An hyperlink reference can be relative or absolute.
If a HRef starts with any supported protocol name followed by "://" (ex: ohtp://), the link is fully absolute and will replace the current address. It must be an URI.
Otherwise, if an HRef starts with "/", it is relative to the website host (e.g: ohtp://test.com), so, the full path is: {WEBSITE HOST} + {HREF}
Finally, starts with nothing above, it is relative and should be appended to the actual URL
URI are in the same format than real ones which is "protocol://host(/page)"
OHML, being a markup language, will not support any kind of dynamic coding like <if> statements, <print> statements, etc., dynamic coding is handled by <script> tags and scripts languages supported by the browser. (Currently no script language has been made, it's coming).
For now one implementation has been made and it is the reference one called Minescape.
 
 

Oh my god! The cases are so much amazing, way better than the ugly and blocky ones that had 2 textures. I can't wait for more cases. Good job!

I am working on something similar, it will only be available for 1.8+ and I'm doing this in my free time so it may never get released. However it's almost ready, I will make a post once I get finished!