GRAPHIC: New Entity Operations™ Alpha Logo



C.ORE™ Standard linked-Library and Scripts can be utilized in parts or meta-structures. Parts are released in a rolling-release model, while meta-structures can be swapped out entirely with your builds or those from the community.

All of these files-types are able to be interacted with utilizing EntityScript™ and the initial version of the program released in 2020 had very basic uses attached. Even so, the program is functional. Since, the versions have been extended and tightened even more and the version 2.0 release is consumer-grade.

Each open source file will be available here soon too. Python 3.8 was used as the implementation language for version 1 and the full package has been tested on various systems capable of running the language.

Note* - This section does not include the needed folder structure, log variables, or initializer scripts. The folder structure eventually will be available to download from CORE.HOST: Download Portal. The intializers, log variable startup scripts, and other items will be able to be downloaded from by the end of the 2023. Enterprise customers will have tailored access to each of the required parts to run the system in the latest branch. Until more people are using EntityScript™ those customers will get exclusive support. The technology that's being presented is for general-purpose computing, but enterprise customers can benefit from more specific services.

Property Table

The default script is named the same thing as the parent first-position meta-structure, CORE.

.CORE/CORE is the default script start position and allows you to work with and from the start. The reason these containers exist in the first place is to store on the fly information in a log specific format that's intended for archiving activity. All of the other scripts don't rely on this script but are able to work with it when storing structured-data on disk in long-term archives. These .es files can be branched into a traditional database if that's what you want/need. We don't want to write any kind of data to disk that hasn't been processed into a storage format that's defined and moved out of temporary containers. We also will want access to the underlying sub-system itself but don't want to call to it directly without some convention or reasoning in mind beforehand. The default script doesn't provide system-level functions at setup, but if you need them in various situations the best place to store their linkage would be in the default script. C.ORE™ as a grouping of scripts is a interface extension methodology that's not meant to rely on the rest of the program at all. C.ORE™ has many parts that can be setup to access system-linked resources running here - or primarily through a middlelayer. There needed to be one point in the system where links between the host and the software running in C.ORE™ could be made. The default script C.ORE™ is where that happens. It can be extedned as needed.

There are also several other areas to work with too. Here is a list:

ID name of part type of part description of part
1all_packagespartThe exact packages running within the virtual environment at this time
2build_listpartThe general packages running within the virtual environment at this time
3core_addpartcore_add is a module to make, create, alter, and reseed both 'LOCAL', 'SYSTEM', and 'GLOBAL' communication attributes, including 'logs of last resort'.
4core_alertspartcore_alerts is a module to establish alert markers and related behavior
5core_architectpartcore_architect is a module to establish a handlers for various digital groupings. You can either account for those groupings or use them to make quantified/qualifying output according to base example methods.
6core_buildpartcore_build reads system resources and makes determinations about build or system choice made by the operator.
7core_configpartcore_config allows you to turn certain system modules on or off at setup
8core_countpartcore_count counts entries in your quick context-file and checks to see if the system is currently counting time
9 core_creator part core_creator allows you to create a .entity/.ds relationship in text-mode and system routines for modules running within C.ORE that rely on add/edit/delete methodology
10core_FRONTENDpartcore_FRONTEND holds human-to-machine interaction code in a user-defined interface
11core_gatekeeperpartcore_gatekeeper handles default authentication tasks and will permit or kick members according to set definitions
12 core_gather part core_gather gives the operator methods for locating .entity/.ds relationships with dlist_drill()
13core_graphicspartcore_graphics gives basic X, Y, Z coordinate systems for use within C.ORE
14core_hashpartcore_hash provides setup routines that can be extended into useful communication methods in C.ORE
15core_interfacepartcore_interface is the call logic to system interaction scripts and other 'system resources' such as audio, visual, or bus programs
16core_languagepartcore_language can serve as a language check script and enforcement mechanism.
17core_middlelayerpartcore_middlelayer lets you extend your core_settings file into manageable write protected sections
18core_modifypartcore_modify allows you to perform basic read/write operations in C.ORE
19core_navigatorpartcore_navigator lets you connect your interface into various parts of the underlying machine
20core_openpackagerpartcore_openpackager manages package meta-data and system package inspections
21core_operationspartcore_operations is the default helper stack for C.ORE containing useful classes and methods
22core_RUNpartTie a system routine to the C.ORE activation method
23core_seekerpartcore_seeker gives a basic seek system for text-mode
24core_serverpartcore_server manages your personal server instance
25core_settingspartcore_settings is the default configurations reader and read/write configurations slug_maker
26core_START_SERVERpartTie startup routines to the server startup instance method
27core_transmitterpartcore_transmitter takes I/O tasks and turns them into phase based threads
28core_urlpartcore_url holds retrieval methods for URL and other network based operations
29core_viewpartcore_view allows you to view various objects in C.ORE
30MANIFESTpartFile add manifest
31setuppartSetup the program and view base package meta-data
32.CORE/meta-structureOrigin directory structure
33ACCESS/meta-structureHolds security slugs generated on startup and your default key files
34CONFIG/meta-structureHolds configuration files needed to operate various parts of the system
35DATA/meta-structureHolds event-data of various types
36DOCUMENTATION/meta-structureHolds basic documentation for the system and various interfacing languages
37FILTER/meta-structureHolds single use explorer entities and filter code for various public processes such as web browsing
38HARDWARE/meta-structureHolds the basic system hardware specs needed by C.ORE
39IDENTITY/meta-structureHolds operator specific system data
40LICENSE/meta-structureHolds licenses in use on the System
41OPENPACKAGER/meta-structureHolds OpenPackager related data, including both internal, external, and corehost program types
42RING/meta-structureHolds formatted personal data
43core-env/meta-structureVirtual-environment Holds the virtual environment setup code
44corehost/meta-structureHolds programs and scripts derived from CORE.HOST
45external/meta-structureHolds programs and scripts derived externally through other code repository sites
46internal/meta-structureHolds programs derived as standards within the system
47ResourcePoolpartCreate local resource pools
48StandardOutput01partCreate a input processor fork
49StandardVisualBuild02partCreate interface components as fork-able objects
50StandardExtension03partCreate package meta-structures as fork-able objects
51StandardDocumentViewer04partCreate a document-viewing standard that can be added on to allow for various desired formats
52op_BROWSEMEHpartView system visual resources
53op_EVENTLOLLIpartAd serving and interactive display writer
54op_REMINDMEpartTime-keeping mechanism for C.ORE
55COGNITIVEOREmeta-structurePersonal Record of Last Resort Ledger
56constructed_classpartTo build compliant meta-structures
57fetch_OREpartTo retrieve Operations Resource Enclaves existing within the system
58ingest_commandspartTo retrieve Operations Resource Enclaves existing within the system

Outside of the standard configurations, program behavior, and scripting locations, new ‘pools’ of information can be localized or extended through the use of meta-specific ‘ResourcePool’ modules. These modules can occur in any meta-structure and are used to localize general program specific information into a meta-related local context.

Additionally, if you choose to provide top-level node support you can customize the initial initializers. You're able to set or extend default variables, or install root level customizations.

These files all can all be modified, extended, or for the most part - eliminated entirely at startup if you choose to replace them with other functions. Use EntityScript™ in different ways according to your needs. To see more about the startup process and interacting with these parts click HERE