User Tools
the_tech_manual
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
the_tech_manual [2019/11/21 16:54] lverona |
the_tech_manual [2024/05/15 08:52] (current) |
||
|---|---|---|---|
| Line 15: | Line 15: | ||
| ==== Ortpond ==== | ==== Ortpond ==== | ||
| - | Ortpond is the space between systems. The term is necessary, because most of the decentralized communication happens through the ortpond, by means of various **actors** which are ingested into the ortpond. | + | Ortpond is the space between modules of the system. The term is necessary, because most of the decentralized communication happens through the ortpond, by means of various **actors** which are ingested into the ortpond. |
| - | The ortpond contains rare packets of plasma. Those are called **voyflens** and always travel in counter-clockwise direction around the **Central Unit** due to its magnetic field. | + | The Tech Manual does not specify if the ortpond is filled with anything (like gas or liquid), or if it's a vacuum, but does specify that it contains rare packets of plasma. Those are called **voyflens** and always travel in counter-clockwise direction around the **Central Unit** due to its magnetic field. |
| ==== Actors ==== | ==== Actors ==== | ||
| Line 80: | Line 80: | ||
| === Naperon === | === Naperon === | ||
| + | |||
| + | [{{:wiki:naperon.png?nolink&200 |A nano-photo of a naperon}}] | ||
| Naperons are copies of the current STAR. Naperons are lower tier actors. They consist of 6 arms with nanoscopic links which allow standard tier to grab them. Their configuration makes them look like a star, which might explain the abbreviation for the manifest. | Naperons are copies of the current STAR. Naperons are lower tier actors. They consist of 6 arms with nanoscopic links which allow standard tier to grab them. Their configuration makes them look like a star, which might explain the abbreviation for the manifest. | ||
| - | Naperons contain no moving parts, and instead contain a hardware storage with a minimal operating system **clomdeut 3.2** which gives access to two files: the manifest and the log. | + | Naperons contain no moving parts, and instead contain a hardware storage with a minimal operating system **clomdeut 3.2**, which gives access to two files: the manifest and the log. |
| The manifest is in GLON format. The log file is in NLON format, which no standard tier actors have access to. Standard actors' operating system is also incompatible with the NLON format due to the way read/write operations are implemented. This secures the log from the manipulation by standard tier. A naperon will update the log each time someone accesses the system, as well as each time they sign off, noting the id of the actor and the timestamp. **Raiders** are able to read NLON files, although most of their readers will also corrupt the file upon signing off due to incompatible hardware parts. | The manifest is in GLON format. The log file is in NLON format, which no standard tier actors have access to. Standard actors' operating system is also incompatible with the NLON format due to the way read/write operations are implemented. This secures the log from the manipulation by standard tier. A naperon will update the log each time someone accesses the system, as well as each time they sign off, noting the id of the actor and the timestamp. **Raiders** are able to read NLON files, although most of their readers will also corrupt the file upon signing off due to incompatible hardware parts. | ||
| Line 107: | Line 109: | ||
| LTAR (Lower Tier Actor Roster) is mentioned in earlier versions of the manual, but was later dropped. It is commonly understood that lower tier actors have no manifest. They can be tracked by sensors, but their origin will usually be unknown. | LTAR (Lower Tier Actor Roster) is mentioned in earlier versions of the manual, but was later dropped. It is commonly understood that lower tier actors have no manifest. They can be tracked by sensors, but their origin will usually be unknown. | ||
| - | ==== Shorogyt ==== | + | === Shorogyt === |
| + | |||
| + | [{{ :wiki:shorogyt.png?nolink&200|Shorogyt}}] | ||
| A **shorogyt** is a standard tier actor which is designed to perform garbage collection, which includes collecting aboutlings, dead lower tier actors and debris, which is defined as any object within a certain size range which a shorogyt cannot identify as an aboutling or any actor. | A **shorogyt** is a standard tier actor which is designed to perform garbage collection, which includes collecting aboutlings, dead lower tier actors and debris, which is defined as any object within a certain size range which a shorogyt cannot identify as an aboutling or any actor. | ||
| Line 114: | Line 118: | ||
| Shorogyts are one of the messier standard tier actors and exhibit more of the evolutionary design, as opposed to the more thought through clean design of other standard tier actors. | Shorogyts are one of the messier standard tier actors and exhibit more of the evolutionary design, as opposed to the more thought through clean design of other standard tier actors. | ||
| + | |||
| + | === Drouscob === | ||
| + | |||
| + | [{{ :wiki:drouscob_photo.png?nolink&200|Drouscob cloud}}] | ||
| + | |||
| + | Drouscobs are standard tier actors. Their purpose is to store and deliver Engine instructions to parts of the system, external to the Engine itself. They tend to gather together, forming drouscob clouds and attempting to get into the Engine. The Engine, however, will require only a limited amount of drouscobs at any moment in time, as well as having an upper limit on the amount of drouscobs present within the Engine. Therefore, the Engine's gate will let through only a small amount of drouscobs at any given time. A special sub-routine is dedicated to drouscob selection in Dezque, the Engine's own processing unit, which involves some basic logic that checks whether a drouscob is functional, as well as a randomizer which might reject even an eligible drouscob. This mechanism is used to loosely regulate the amount of drouscobs in the Engine. | ||
| + | |||
| + | Once let inside, a drouscob is programmed to begin approaching various modules of the Engine at random in the hopes of being useful. But this rarely happens, as the lower tier actors, generated by the Engine, will immediately begin interfacing with the drouscob. Their exact mechanism and programming is poorly understood, but the end result is that a drouscob is almost immediately directed to the module that requires its services, thus saving time and increasing Engine efficiency. | ||
| + | |||
| + | The drouscob will then copy the message, as well as the address of the recipient and leave the Engine through one of the two one-way tunnels. | ||
| ==== Busyglide ==== | ==== Busyglide ==== | ||
| Line 123: | Line 137: | ||
| The Engine provides energy to most of the moving parts of the system. It is a large container with a liquid called **taybyl**, which is a mix of doubly ionized oxygen (O2+) and liquid plasma. | The Engine provides energy to most of the moving parts of the system. It is a large container with a liquid called **taybyl**, which is a mix of doubly ionized oxygen (O2+) and liquid plasma. | ||
| - | The Engine has its own independent central processing unit **Dezque**, which consists of a network of daughter units called **bipchivs**. There are exactly 133 identical bipchivs, which are being constantly rotated through the system, and their function depends on their position relative to Dezque. | + | The Engine has its own independent central processing unit **Dezque**, which consists of a network of daughter units called **bonderons**. There are exactly 133 identical bonderons, which are being constantly rotated through the system, and their function depends on their position relative to Dezque. |
| === Trenduction and Afghtfal === | === Trenduction and Afghtfal === | ||
| Line 129: | Line 143: | ||
| Trenduction and afghtfal are key concepts to understand about how the Engine works. | Trenduction and afghtfal are key concepts to understand about how the Engine works. | ||
| - | Trenduction is the process of moving bipchives through the Engine subsystems, whereas afghtfal is the Engine tick (different from the Dezque tick, which is orders of magnitudes faster). | + | Trenduction is the process of moving bonderons through the Engine subsystems, whereas afghtfal is the Engine tick (different from the Dezque tick, which is orders of magnitudes faster). |
| + | |||
| + | Mechanically, each bonderon has a hole, through which it is attached to a soft metal cord. Interestingly enough, neither the bonderon hole, nor the Engine's metal cord have a formal name. Bonderons are being slid through the system on the cord, which occasionally dips into pools of oil for the purposes of lubrication. | ||
| + | |||
| + | The Engine tick, afghtfal, is issued by the Dezque and bonderon speeds are being calculated. Dezque can increase the afghtfal ratio, so that bonderons travel faster, but trenduction is implemented in such a way that the relationship between afghtfal and actual physical speed is not linear. This is done to prevent physical stress to the system, which becomes critical at higher speeds: while many Engine systems are serviced by numerous processes and actors, if the cord breaks, there is no way to fix the Engine without external intervention. | ||
| + | |||
| + | === Drouscob acceptance ratio === | ||
| + | |||
| + | The Engine will require a different amount of drouscobs during its cycle, so the Dezque drouscob subroutine will modulate the randomizer. The most drouscobs are required closer to the end of the cycle, when the Engine requires more information about the system in order to set up a new cycle. However, drouscobs have no routines that take that into account, thus they are constantly queuing in front of the Engine, as if desperately trying to get in. The space in front of the Engine's gate is abundant, and drouscob clouds are easily dispersed if other actors are trying to get through, thus this is never a problem. | ||
| + | |||
| + | ===== Operating systems ===== | ||
| + | |||
| + | ==== clomdeut 3.2 ==== | ||
| + | |||
| + | [{{ :wiki:clomdeut.png?nolink&200|Contents of a naperon as displayed by clomdeut 3.2}}] | ||
| + | |||
| + | **clomdeut 3.2** is a naperon operating system. It contains only the minimal logic of providing access to the only two files: manifest.glog and log.nlog. clomdeut 3.2 was specifically designed to be able to handle only these two specific files, the format schemas of which are hardcoded in the pre-compiled kernel. | ||
| + | |||
| + | clomdeut's kernel contains a graphical interface which allows to actually see both files in a simple table. The interface does not provide functionality to actually inspect the files themselves. | ||
| + | |||
| + | ==== shorogyt os ==== | ||
| + | |||
| + | [{{:wiki:shorogyt_os.png?nolink&200 |shorogyt os root directory}}] | ||
| + | |||
| + | **shorogyt os** is shorogyt firmware. It contains the boot sequence, as well as a "manager" module, which is a set of scripts that handle the behavior of a shorogyt. | ||
| - | Mechanically, each bipchiv has a hole, through which it is attached to a soft metal cord. Interestingly enough, neither the bipchiv hole, nor the Engine's metal cord have a formal name. | + | A "manager" module is completely event-based and will perform actions as a response to incoming data. Nevertheless, the response tree is very detailed and shorogyts will exhibit complex behavior. |
the_tech_manual.1574373294.txt.gz · Last modified: 2019/11/21 16:54 by lverona
Page Tools
