angelic-kernel 0.1__tar.gz

angelic_kernel-0.1/PKG-INFO

@@ -0,0 +1,296 @@
+Metadata-Version: 2.4
+Name: angelic-kernel
+Version: 0.1
+Summary: A fake OS kernel framework for Python
+Home-page: 
+Author: ERROR-Xmakernotfound
+Requires-Python: >=3.8
+Description-Content-Type: text/markdown
+Requires-Dist: pygame
+Dynamic: author
+Dynamic: description
+Dynamic: description-content-type
+Dynamic: requires-dist
+Dynamic: requires-python
+Dynamic: summary
+
+# Angelic-Kernel
+![Logo](https://image2url.com/r2/default/images/1772877162462-6192faf8-1121-44a3-8524-622a8ba885c7.blob)\
+![Python](https://img.shields.io/badge/python-3.8+-blue)
+![Version](https://img.shields.io/badge/version-0.1-green)
+![License](https://img.shields.io/badge/license-MIT-orange)
+Have you ever, and I mean EVER wanted to create an OS but then tried to and then thought, "nah, I'll stick to python" but still want to create an OS?
+
+Well, you can now, okay, not a **real OS,** however, with Angelic-Kernel you can make a python program that **feels** like one, now lets get right into it!
+
+Sections:
+1. [Installation](#installation)
+2. [Documentation](#documentation)
+3. [Versions](#versions)
+
+# Installation
+for installing angelic-kernel, use this command.
+```bash
+pip install angelic-kernel
+```
+# Documentation
+Okay, I *really* don't want to write a full documentation, but at the same time I don't want **anyone** to be in the dark and so it makes sense. So this is the entire documentation for all versions, to see specific data about specific versions go to the version section and find the version that you have and click the link. It will take you to the full documentation with everything about that version. Writing these documentations take 3-5 hours depending on how much is in the version, I write them anyway just so people actually understand what's in the version. And inside the documentation you can find; the change log, the tutorial on how to use angelic-kernel, code examples that work for the version and notes. Now, enough talking about what's **in** the documentations lets get right to them!
+## Documentation for 0.1
+Sections:\
+[Change log](#change-log)\
+[Documentation](#documentation-1)\
+[Examples](#examples)\
+[Notes](#notes)
+### Change log
+Created `Kernel` class\
+Created `SD` subclass for the `Kernel` class\
+Created `screen` subclass for the `Kernel` class\
+Created `sound` subclass for the `Kernel` class\
+Created `file_system` subclass for the `Kernel` class
+### Documentation
+Alright, even though this is literally the **first version** of angelic-kernel, it's feature-rich, made with 500+ lines and five main classes, if you took a peek at the change log you should be able to identify which ones; the `Kernel`, `SD`, `screen`, `sound`,  and `file_system` classes that each play important roles for our code, lets first start with the `Kernel` class:
+
+First lets setup
+```python
+from angelic_kernel import *
+k=Kernel()
+```
+Now hopefully you know what's going on here, but if you don't I'll explain, `from angelic_kernel import *` imports all the classes that I stuffed into this thing, and `k=Kernel()` sets the `k` variable to a `Kernel()` instance, now let's expand it.
+```python
+from angelic_kernel import *
+k=Kernel()
+sd=k.SD()
+sc=k.screen(640,600,sd)
+sound=k.sound(sd)
+fs=k.file_system(sd)
+```
+Now, let's explain each line of new code; `sd=k.SD()` sets the sd variable to a `Kernel.SD` instance, `sc=k.screen(640,600,sd)` sets the sc variable to a `Kernel.screen` instance, the first and second input is the width and height of the screen, the last input is the sd instance we defined earlier, `sound=k.sound(sd)` sets the sound variable to a `Kernel.sound` instance with the only input being the sd instance we defined earlier *see a pattern yet?* `fs=k.file_system(sd)` sets the fs variable to a `Kernel.file_system` instance with the only input being the sd instance we defined earlier
+
+Okay, now lets actually get into the classes, we'll skip SD because there's not much in it, and it doesn't really do anything useful other than provide basic SD saving for the other classes *that's why they need it*
+
+**sections**:\
+[screen](#screen-class)\
+[sound](#sound-class)\
+[file_system](#file_system-class)
+
+### Screen class
+#### Basic info
+The screen class manages a window with APIs for Graphics and GUI, the GUI engine used is pygame, so if you have even basic knowledge of pygame then this should be easy to use. If not, don't worry, I've spent several days making the screen class *WAY* easier than raw pygame so this shouldn't be too bad.
+#### Core commands:
+Core commands are commands that most likely will be used a **LOT** when using the screen class so, lets list them before we go over what they actually do.\
+`clear()`\
+`clear_logs()`\
+`frame()`\
+`events()`\
+`shift()`\
+Alright, now that we got them down, lets go through them one by one and explain what they do.\
+`clear()`: clears the screen; `clear()` has no inputs however originally `clear()` was going to have an input for clearing the text logs, but that idea was scrapped for `clear_logs()`, on that note, `clear()` does **not** clear the text logs *we'll get into more detail about the text logs soon when we talk about `print()`,`input()`, and `set_font()`.*
+
+`clear_logs()`: clears the text logs; `clear_logs()` clears the text logs, preventing text from showing up when input is called.
+
+`frame()`: displays the next frame; `frame()` does **one** job, display the next frame, when `clear()` is called the current frame says "Nah, I'm out" and disappears, however in order to see the changes you have to call `frame()`, the only input is the tick input which pauses for a bit to keep the frame rate under control and defaults to 60 so the GUI doesn't run at CPU clock speeds *which is around 2.5 GHz and 4.0 GHz by the time I wrote this*
+
+`events()`: returns the current event; `events()` does a lot of jobs at once, but all you need to know is what events it returns; when a key is pressed it returns `("keydown",key_name)` with the second output being the key's name, the opposite of this is `("keyup",key_name)` this is returned when a key is released, with the second output being the name of the key, `("mousedown",(mouse_pos_x,mouse_pos_y))` is returned when the mouse clicks inside the window, the second output is a tuple of two values, value 1 being the x position of the mouse and value 2 being the y position of the mouse, `(None,None)` this is returned when None of the events that I listed here happened.
+
+`shift()`: returns the shifted equivalent of the inputted key; `shift()` literally just presses shift for you, when you input a shiftable letter, say, "a" for example, it returns "A", which if you've ever typed in all caps when sending a **totally** formal letter to someone you where mad at, you know that the shifted letter of "a" is "A", and if you're a coder, *like me*, your example is if you input "[" it will output "{", just like pressing shift on a keyboard.
+#### Text commands:
+text commands are stuff like `print()` and `input()` but also `set_font()`? yeah, to explain what's going on here, we're going to have to dive in so lets list then explain\
+`set_font()`\
+`print()`\
+`input()`\
+Now time to explain
+
+`set_font()`:sets the font; this one surprisingly is simple even though it's one of the commands that I spent over an hour working on, the first input is the mode, it accepts 1 or 2 as an input, if the mode is 1 it sets the font to an external font file *like a .ttf file* if it is set to 2 then it uses a system font *like Arial*. The second input is the font name or the font file name. if you set the mode to 1 previously then set the font input to the name of the font file, note that the font file has to be inside the same folder as your script. if you set the mode to 2 then set the input to the name of the font, note that the name of the font has to be installed on your computer. the last input is the size input, and luckily this one doesn't change depending on the mode, just enter the size that you want the text to be. 
+
+`print()`: prints onto the screen window; this one literally is pythons `print()` function for the window, the first input is the text, simple, the next two is the x and y position of the text, the next? the color, it's a tuple of three values up to 255, the last two actually are kinda important, the second-to-last one is `add_to_text_log`, which is a bool `True` or `False`. If it's true then it adds the text to the text logs, and it will appear when `input()` is called. if it's false then it won't touch the text logs, the last is really important and **extremely** useful, `blit_surface` sets the blit surface, that's it, *we'll talk about surfaces later...*
+
+`input()`: creates a text prompt on the screen window; this one took me five hours to make, and I'm not joking this time, with how much I crammed into this thing it takes up 100+ lines of the file, just to create a basic input function. Anyway enough with the lore of this **extremely** overweight function, lets get into the inputs. The first input is the prompt input, it's just the prompt text, the next is the base_prompt input which sets the base text that appears when you call it. The third and fourth input is the x and y pos of the prompt the fifth input is the color, and the last is the blit surface
+#### Sprite commands:
+This was simple enough to create, and since there's like ten commands here I'm going to try and keep it short, but there's just a lot of important stuff here so... yeah...\
+`add_sprite()`\
+`render_sprites()`\
+`move_sprite()`\
+`set_sprite_pos()`\
+`set_sprite_image()`\
+`kill_sprite()`\
+`sprite_touching_sprite()`\
+`sprite_touching_mouse()`\
+`sprite_click()`\
+`scale_sprite()`\
+Alright time to explain what each of these do *there's so many :(*
+`add_sprite()`: Adds a sprite; the only input is the name of the sprite, remember the name it's important for most of the next commands
+
+`render_sprites()`: renders **ALL** sprites; that's it.
+
+`move_sprite()`: moves the inputted sprite; this is simple the first input is *of course* the name of the sprite with the second and third input being the x and y *had to rewrite this, fell asleep halfway through writing this hah...*
+
+`set_sprite_pos()`: sets the inputted sprite's position; that's literally all this does, the first input is the name of the sprite and the second and third is the x and y of the sprite
+
+`set_sprite_image()`: sets the inputted sprite's image; the first input is the name of the sprite and the second is the name of the image file, note that the image must be in the same folder as the script.
+
+`kill_sprite()`: "kills" the inputted sprite; don't worry it only deletes the inputted sprite the only input is the name of the sprite
+
+`sprite_touching_sprite()`: returns True if the first sprite inputted is touching the second input; in less confusing terms, if the sprite with the name of the first input is touching the sprite with the name of the second input it returns true, else, it returns false
+
+`sprite_touching_mouse()`:returns True if the inputted sprite is touching the mouse; that's it the first input is the name of the sprite
+
+`sprite_click()`: returns True if the inputted sprite was clicked; that's it, the first input is the name of the sprite the second should be the output of `events()`
+
+`scale_sprite()`: scales the inputted sprite; that's it, the first input is the name of the sprite and the second and third is the width and height
+#### Surface commands:
+Okay this one is much shorter than the sprite second, but uh... yeah, it's in the screen class, we have to go over them... *GOD-*\
+`surface()`\
+`render_surfaces()`\
+`surface_click()`\
+`surface_touching_mouse()`\
+`kill_surface()`\
+Alright now the explanation.../
+`surface()`: creates a surface; this one is one of the functions that have too many inputs, so uh, prepare for me to talk for an hour. The first input is the name and the second and third is the x and y position, forth and fifth is width and height and the last is the color, Huh... that actually wasn't so bad...
+
+`render_surfaces()`: renders **ALL** surfaces; that's it, no inputs
+
+`surface_click()`: returns true if the inputted surface was clicked; the first input is the name of the surface while the second is the event, the event must be the output of the `events()` command
+
+`surface_touching_mouse()`: returns true if the inputted surface was touching the mouse; that's it the only input is the name of the surface
+
+`kill_surface()`: don't worry it only deletes the surface; the only input is the name of the surface
+#### misc commands:
+these are just some helper commands that don't really belong to a group of commands so they are just misc
+`quit()`\
+`wait()`\
+`set_window_name()`\
+`set_window_icon()`\
+`mouse_down()`\
+`is_held()`\
+`mouse_pos()`\
+now for the explanation
+
+`quit()`: exits the program; that's literally it no inputs
+
+`wait()`: waits the inputted time; that's it, the only input is the time
+
+`set_window_name()`: sets the screen window's name with the input; that's it the only input is the name
+
+`set_window_icon()`: sets the window icon to the inputted file; the file must be in the same folder as the script
+
+`mouse_down()`: returns true if the mouse is held down; that's it no inputs
+
+`is_held()`: returns true if the inputted key is held down; the only input is the name of the key
+
+`mouse_pos()`: returns the mouse position; no inputs, but just as a warning, it returns the mouse's position as a tuple
+
+wow... that was a lot... and we're not even done, we still have two classes to go...
+
+### Sound class
+#### Basic info:
+the sound class is *overly* simple, and currently only has three commands, so lets get into them
+#### All commands:
+Alright lets list the three commands and then explain what they do
+`add_sound()`\
+`play_sound()`\
+`stop()`\
+Alright now for the explanation
+
+`add_sound()`: adds a sound to the sound cache; on its own it doesn't play anything, you need to call `play_sound()` for them to play, the only input is the sound input and the sound file has to be in the same folder as the script
+
+`play_sound()`: plays the inputted sound; it only plays the sound if it was in the sound cache, if it's not then nothing will happen.
+
+`stop()`: stops the inputted sound; the sound must be in the sound cache, if not then it won't do anything
+
+Alright that's all for the Sound class. Now it's time for the last one, the file_system class, which with how *BIG* it is it's probably competing with the screen class in terms of how much does it take up the file!
+
+### File_system class
+#### Basic info:
+There's a lot in this one. And even though most of the commands are **microscopic** and easy to explain, there's a **LOT** of them and I mean **25+** commands and even though the screen class has more commands *30 commands by the way* there's just a **LOT** but uh... yeah... I have to go through them...
+#### Useful Tools:
+These are some Useful tools and yeah, they help a **LOT**. Anyway, lets get into them\
+`set_root()`\
+`goto()`\
+`back()`\
+`list_dir()`\
+`current_path()`\
+Alright lets explain what these do
+
+`set_root()`: sets the root for the file system; the input is a list, for example if the root is C/Users/User1/Home, then the input would be `["C","Users","User1","Home"]`, and here's a few notes about this though, the paths have to exist, or it will raise a `PathError`, when you set the root you **Cannot go back farther than the root** that's the entire reason the root exists!
+
+`goto()`: goes to the inputted path; if the path doesn't exist, is protected, hidden, a file, or the TypeID identifier it will raise Errors, the only input is the path
+
+`back()`: goes back to the last path; if the path is at the root then it says "Nah, can't go back farther", and raises a PathError
+
+`list_dir()`: lists the current directory; it skips over Type Identifiers, protected dirs, and hidden dirs
+
+`current_path()`: returns the current path; that's literally it.
+#### "Make" Tools:
+these basically are just functions that make paths, that's basically all they do, now lets list them and then explain them:\
+`make_dir()`\
+`make_file()`\
+`make_protected()`\
+`make_hidden()`\
+now let's explain them, *this is taking WAY to long, it's been 4+ hours :(*
+`make_dir()`:makes a dir; the only input is the name, just as a disclaimer, the name shouldn't already exist, or it will throw Errors
+`make_file()`: makes a file; the three inputs are the name, the file_type, and the data, the path shouldn't already exist, or it will throw Errors
+`make_protected()`: make a protected path; the only input is the name, and the name shouldn't already exist
+`make_hidden()`: makes a hidden path; the only input is the name, and the name shouldn't already exist
+#### "delete" Tools:
+These tools delete stuff, couldn't be simpler *well, maybe it could if there weren't so many of them AGH*\
+`delete_dir()`\
+`delete_file()`\
+`delete_protected()`\
+`delete_hidden()`\
+Alright now time to explain them...
+`delete_dir()`: deletes the inputted dir; that's it the only input is the name and the dir has to already exist
+
+`delete_file()`: deletes the inputted file; the only input is the file name and the file has to already exist
+
+`delete_protected()`: deletes the inputted protected path; this one is different from the others, yes, it still has the name input as the first input, but there's also the force input and if you don't set it to True then it's going to raise a PermissionError
+
+`delete_hidden()`: deletes the inputted hidden path, that's it the path has to exist and has to be hidden
+#### "Check" Tools:
+these functions check for stuff, good if you don't want your code to be littered with `try` and `except` functions
+`path_exists()`\
+`path_is_dir()`\
+`path_is_file()`\
+`path_is_protected()`\
+`path_is_hidden()`\
+`file_is_type()`\
+`is_root()`\
+Wow.... There's a lot here...
+`path_exists()`: returns true if the inputted path exists; that's it
+
+`path_is_dir()`: returns true if the inputted path is a dir; that's it
+
+`path_is_file()`: returns true if the inputted path is a file; that's it
+
+`path_is_protected()`: returns true if the inputted path is protected; that's it
+
+`file_is_type()`: returns true if the inputted file is the second input which is the file type; that's it
+
+`is_root()`: returns true if the path is at the set root; that's it
+#### "Open" Tools:
+These tools open files, however I'm going to tell you here *so I can save you time* **the files must exist or all of the functions will raise errors**\
+`open_file()`\
+`open_protected()`\
+`open_hidden()`\
+Alright now to explain\
+`open_file()`: returns the data of the inputted file; the only input is the file name,
+
+`open_protected()`: returns the data of the protected path; the only input is the path name
+
+`open_hidden()`: returns the data of a hidden path, the only name is the name of the path
+#### "modify" Tools:
+Alright, I'm on the brink of falling asleep, but luckily for me, we only have two commands here
+`modify_hidden()`\
+`modify_file()`\
+Alright now to explain\
+`modify_hidden()`: modifies a hidden path, the first input is the name and the second is the key you want to modify, and the last is just the value, the hidden path must exist for it will raise an Error
+
+`modify_file()`: modifies a file, the first input is the name the second is the key you want to modify and the last is the value you want to set it to, the file must exist, or it raises an Error
+### Examples
+*Experimenting, come back in a later update...*
+### Notes
+*none lol*
+
+# Versions
+*disclaimer; these dates are in the MM/DD/YYYY format*
+
+0.1: \[3/7/2026\] Release date. [Version Documentation](#documentation-for-01)

angelic_kernel-0.1/README.md

@@ -0,0 +1,280 @@
+# Angelic-Kernel
+![Logo](https://image2url.com/r2/default/images/1772877162462-6192faf8-1121-44a3-8524-622a8ba885c7.blob)\
+![Python](https://img.shields.io/badge/python-3.8+-blue)
+![Version](https://img.shields.io/badge/version-0.1-green)
+![License](https://img.shields.io/badge/license-MIT-orange)
+Have you ever, and I mean EVER wanted to create an OS but then tried to and then thought, "nah, I'll stick to python" but still want to create an OS?
+
+Well, you can now, okay, not a **real OS,** however, with Angelic-Kernel you can make a python program that **feels** like one, now lets get right into it!
+
+Sections:
+1. [Installation](#installation)
+2. [Documentation](#documentation)
+3. [Versions](#versions)
+
+# Installation
+for installing angelic-kernel, use this command.
+```bash
+pip install angelic-kernel
+```
+# Documentation
+Okay, I *really* don't want to write a full documentation, but at the same time I don't want **anyone** to be in the dark and so it makes sense. So this is the entire documentation for all versions, to see specific data about specific versions go to the version section and find the version that you have and click the link. It will take you to the full documentation with everything about that version. Writing these documentations take 3-5 hours depending on how much is in the version, I write them anyway just so people actually understand what's in the version. And inside the documentation you can find; the change log, the tutorial on how to use angelic-kernel, code examples that work for the version and notes. Now, enough talking about what's **in** the documentations lets get right to them!
+## Documentation for 0.1
+Sections:\
+[Change log](#change-log)\
+[Documentation](#documentation-1)\
+[Examples](#examples)\
+[Notes](#notes)
+### Change log
+Created `Kernel` class\
+Created `SD` subclass for the `Kernel` class\
+Created `screen` subclass for the `Kernel` class\
+Created `sound` subclass for the `Kernel` class\
+Created `file_system` subclass for the `Kernel` class
+### Documentation
+Alright, even though this is literally the **first version** of angelic-kernel, it's feature-rich, made with 500+ lines and five main classes, if you took a peek at the change log you should be able to identify which ones; the `Kernel`, `SD`, `screen`, `sound`,  and `file_system` classes that each play important roles for our code, lets first start with the `Kernel` class:
+
+First lets setup
+```python
+from angelic_kernel import *
+k=Kernel()
+```
+Now hopefully you know what's going on here, but if you don't I'll explain, `from angelic_kernel import *` imports all the classes that I stuffed into this thing, and `k=Kernel()` sets the `k` variable to a `Kernel()` instance, now let's expand it.
+```python
+from angelic_kernel import *
+k=Kernel()
+sd=k.SD()
+sc=k.screen(640,600,sd)
+sound=k.sound(sd)
+fs=k.file_system(sd)
+```
+Now, let's explain each line of new code; `sd=k.SD()` sets the sd variable to a `Kernel.SD` instance, `sc=k.screen(640,600,sd)` sets the sc variable to a `Kernel.screen` instance, the first and second input is the width and height of the screen, the last input is the sd instance we defined earlier, `sound=k.sound(sd)` sets the sound variable to a `Kernel.sound` instance with the only input being the sd instance we defined earlier *see a pattern yet?* `fs=k.file_system(sd)` sets the fs variable to a `Kernel.file_system` instance with the only input being the sd instance we defined earlier
+
+Okay, now lets actually get into the classes, we'll skip SD because there's not much in it, and it doesn't really do anything useful other than provide basic SD saving for the other classes *that's why they need it*
+
+**sections**:\
+[screen](#screen-class)\
+[sound](#sound-class)\
+[file_system](#file_system-class)
+
+### Screen class
+#### Basic info
+The screen class manages a window with APIs for Graphics and GUI, the GUI engine used is pygame, so if you have even basic knowledge of pygame then this should be easy to use. If not, don't worry, I've spent several days making the screen class *WAY* easier than raw pygame so this shouldn't be too bad.
+#### Core commands:
+Core commands are commands that most likely will be used a **LOT** when using the screen class so, lets list them before we go over what they actually do.\
+`clear()`\
+`clear_logs()`\
+`frame()`\
+`events()`\
+`shift()`\
+Alright, now that we got them down, lets go through them one by one and explain what they do.\
+`clear()`: clears the screen; `clear()` has no inputs however originally `clear()` was going to have an input for clearing the text logs, but that idea was scrapped for `clear_logs()`, on that note, `clear()` does **not** clear the text logs *we'll get into more detail about the text logs soon when we talk about `print()`,`input()`, and `set_font()`.*
+
+`clear_logs()`: clears the text logs; `clear_logs()` clears the text logs, preventing text from showing up when input is called.
+
+`frame()`: displays the next frame; `frame()` does **one** job, display the next frame, when `clear()` is called the current frame says "Nah, I'm out" and disappears, however in order to see the changes you have to call `frame()`, the only input is the tick input which pauses for a bit to keep the frame rate under control and defaults to 60 so the GUI doesn't run at CPU clock speeds *which is around 2.5 GHz and 4.0 GHz by the time I wrote this*
+
+`events()`: returns the current event; `events()` does a lot of jobs at once, but all you need to know is what events it returns; when a key is pressed it returns `("keydown",key_name)` with the second output being the key's name, the opposite of this is `("keyup",key_name)` this is returned when a key is released, with the second output being the name of the key, `("mousedown",(mouse_pos_x,mouse_pos_y))` is returned when the mouse clicks inside the window, the second output is a tuple of two values, value 1 being the x position of the mouse and value 2 being the y position of the mouse, `(None,None)` this is returned when None of the events that I listed here happened.
+
+`shift()`: returns the shifted equivalent of the inputted key; `shift()` literally just presses shift for you, when you input a shiftable letter, say, "a" for example, it returns "A", which if you've ever typed in all caps when sending a **totally** formal letter to someone you where mad at, you know that the shifted letter of "a" is "A", and if you're a coder, *like me*, your example is if you input "[" it will output "{", just like pressing shift on a keyboard.
+#### Text commands:
+text commands are stuff like `print()` and `input()` but also `set_font()`? yeah, to explain what's going on here, we're going to have to dive in so lets list then explain\
+`set_font()`\
+`print()`\
+`input()`\
+Now time to explain
+
+`set_font()`:sets the font; this one surprisingly is simple even though it's one of the commands that I spent over an hour working on, the first input is the mode, it accepts 1 or 2 as an input, if the mode is 1 it sets the font to an external font file *like a .ttf file* if it is set to 2 then it uses a system font *like Arial*. The second input is the font name or the font file name. if you set the mode to 1 previously then set the font input to the name of the font file, note that the font file has to be inside the same folder as your script. if you set the mode to 2 then set the input to the name of the font, note that the name of the font has to be installed on your computer. the last input is the size input, and luckily this one doesn't change depending on the mode, just enter the size that you want the text to be. 
+
+`print()`: prints onto the screen window; this one literally is pythons `print()` function for the window, the first input is the text, simple, the next two is the x and y position of the text, the next? the color, it's a tuple of three values up to 255, the last two actually are kinda important, the second-to-last one is `add_to_text_log`, which is a bool `True` or `False`. If it's true then it adds the text to the text logs, and it will appear when `input()` is called. if it's false then it won't touch the text logs, the last is really important and **extremely** useful, `blit_surface` sets the blit surface, that's it, *we'll talk about surfaces later...*
+
+`input()`: creates a text prompt on the screen window; this one took me five hours to make, and I'm not joking this time, with how much I crammed into this thing it takes up 100+ lines of the file, just to create a basic input function. Anyway enough with the lore of this **extremely** overweight function, lets get into the inputs. The first input is the prompt input, it's just the prompt text, the next is the base_prompt input which sets the base text that appears when you call it. The third and fourth input is the x and y pos of the prompt the fifth input is the color, and the last is the blit surface
+#### Sprite commands:
+This was simple enough to create, and since there's like ten commands here I'm going to try and keep it short, but there's just a lot of important stuff here so... yeah...\
+`add_sprite()`\
+`render_sprites()`\
+`move_sprite()`\
+`set_sprite_pos()`\
+`set_sprite_image()`\
+`kill_sprite()`\
+`sprite_touching_sprite()`\
+`sprite_touching_mouse()`\
+`sprite_click()`\
+`scale_sprite()`\
+Alright time to explain what each of these do *there's so many :(*
+`add_sprite()`: Adds a sprite; the only input is the name of the sprite, remember the name it's important for most of the next commands
+
+`render_sprites()`: renders **ALL** sprites; that's it.
+
+`move_sprite()`: moves the inputted sprite; this is simple the first input is *of course* the name of the sprite with the second and third input being the x and y *had to rewrite this, fell asleep halfway through writing this hah...*
+
+`set_sprite_pos()`: sets the inputted sprite's position; that's literally all this does, the first input is the name of the sprite and the second and third is the x and y of the sprite
+
+`set_sprite_image()`: sets the inputted sprite's image; the first input is the name of the sprite and the second is the name of the image file, note that the image must be in the same folder as the script.
+
+`kill_sprite()`: "kills" the inputted sprite; don't worry it only deletes the inputted sprite the only input is the name of the sprite
+
+`sprite_touching_sprite()`: returns True if the first sprite inputted is touching the second input; in less confusing terms, if the sprite with the name of the first input is touching the sprite with the name of the second input it returns true, else, it returns false
+
+`sprite_touching_mouse()`:returns True if the inputted sprite is touching the mouse; that's it the first input is the name of the sprite
+
+`sprite_click()`: returns True if the inputted sprite was clicked; that's it, the first input is the name of the sprite the second should be the output of `events()`
+
+`scale_sprite()`: scales the inputted sprite; that's it, the first input is the name of the sprite and the second and third is the width and height
+#### Surface commands:
+Okay this one is much shorter than the sprite second, but uh... yeah, it's in the screen class, we have to go over them... *GOD-*\
+`surface()`\
+`render_surfaces()`\
+`surface_click()`\
+`surface_touching_mouse()`\
+`kill_surface()`\
+Alright now the explanation.../
+`surface()`: creates a surface; this one is one of the functions that have too many inputs, so uh, prepare for me to talk for an hour. The first input is the name and the second and third is the x and y position, forth and fifth is width and height and the last is the color, Huh... that actually wasn't so bad...
+
+`render_surfaces()`: renders **ALL** surfaces; that's it, no inputs
+
+`surface_click()`: returns true if the inputted surface was clicked; the first input is the name of the surface while the second is the event, the event must be the output of the `events()` command
+
+`surface_touching_mouse()`: returns true if the inputted surface was touching the mouse; that's it the only input is the name of the surface
+
+`kill_surface()`: don't worry it only deletes the surface; the only input is the name of the surface
+#### misc commands:
+these are just some helper commands that don't really belong to a group of commands so they are just misc
+`quit()`\
+`wait()`\
+`set_window_name()`\
+`set_window_icon()`\
+`mouse_down()`\
+`is_held()`\
+`mouse_pos()`\
+now for the explanation
+
+`quit()`: exits the program; that's literally it no inputs
+
+`wait()`: waits the inputted time; that's it, the only input is the time
+
+`set_window_name()`: sets the screen window's name with the input; that's it the only input is the name
+
+`set_window_icon()`: sets the window icon to the inputted file; the file must be in the same folder as the script
+
+`mouse_down()`: returns true if the mouse is held down; that's it no inputs
+
+`is_held()`: returns true if the inputted key is held down; the only input is the name of the key
+
+`mouse_pos()`: returns the mouse position; no inputs, but just as a warning, it returns the mouse's position as a tuple
+
+wow... that was a lot... and we're not even done, we still have two classes to go...
+
+### Sound class
+#### Basic info:
+the sound class is *overly* simple, and currently only has three commands, so lets get into them
+#### All commands:
+Alright lets list the three commands and then explain what they do
+`add_sound()`\
+`play_sound()`\
+`stop()`\
+Alright now for the explanation
+
+`add_sound()`: adds a sound to the sound cache; on its own it doesn't play anything, you need to call `play_sound()` for them to play, the only input is the sound input and the sound file has to be in the same folder as the script
+
+`play_sound()`: plays the inputted sound; it only plays the sound if it was in the sound cache, if it's not then nothing will happen.
+
+`stop()`: stops the inputted sound; the sound must be in the sound cache, if not then it won't do anything
+
+Alright that's all for the Sound class. Now it's time for the last one, the file_system class, which with how *BIG* it is it's probably competing with the screen class in terms of how much does it take up the file!
+
+### File_system class
+#### Basic info:
+There's a lot in this one. And even though most of the commands are **microscopic** and easy to explain, there's a **LOT** of them and I mean **25+** commands and even though the screen class has more commands *30 commands by the way* there's just a **LOT** but uh... yeah... I have to go through them...
+#### Useful Tools:
+These are some Useful tools and yeah, they help a **LOT**. Anyway, lets get into them\
+`set_root()`\
+`goto()`\
+`back()`\
+`list_dir()`\
+`current_path()`\
+Alright lets explain what these do
+
+`set_root()`: sets the root for the file system; the input is a list, for example if the root is C/Users/User1/Home, then the input would be `["C","Users","User1","Home"]`, and here's a few notes about this though, the paths have to exist, or it will raise a `PathError`, when you set the root you **Cannot go back farther than the root** that's the entire reason the root exists!
+
+`goto()`: goes to the inputted path; if the path doesn't exist, is protected, hidden, a file, or the TypeID identifier it will raise Errors, the only input is the path
+
+`back()`: goes back to the last path; if the path is at the root then it says "Nah, can't go back farther", and raises a PathError
+
+`list_dir()`: lists the current directory; it skips over Type Identifiers, protected dirs, and hidden dirs
+
+`current_path()`: returns the current path; that's literally it.
+#### "Make" Tools:
+these basically are just functions that make paths, that's basically all they do, now lets list them and then explain them:\
+`make_dir()`\
+`make_file()`\
+`make_protected()`\
+`make_hidden()`\
+now let's explain them, *this is taking WAY to long, it's been 4+ hours :(*
+`make_dir()`:makes a dir; the only input is the name, just as a disclaimer, the name shouldn't already exist, or it will throw Errors
+`make_file()`: makes a file; the three inputs are the name, the file_type, and the data, the path shouldn't already exist, or it will throw Errors
+`make_protected()`: make a protected path; the only input is the name, and the name shouldn't already exist
+`make_hidden()`: makes a hidden path; the only input is the name, and the name shouldn't already exist
+#### "delete" Tools:
+These tools delete stuff, couldn't be simpler *well, maybe it could if there weren't so many of them AGH*\
+`delete_dir()`\
+`delete_file()`\
+`delete_protected()`\
+`delete_hidden()`\
+Alright now time to explain them...
+`delete_dir()`: deletes the inputted dir; that's it the only input is the name and the dir has to already exist
+
+`delete_file()`: deletes the inputted file; the only input is the file name and the file has to already exist
+
+`delete_protected()`: deletes the inputted protected path; this one is different from the others, yes, it still has the name input as the first input, but there's also the force input and if you don't set it to True then it's going to raise a PermissionError
+
+`delete_hidden()`: deletes the inputted hidden path, that's it the path has to exist and has to be hidden
+#### "Check" Tools:
+these functions check for stuff, good if you don't want your code to be littered with `try` and `except` functions
+`path_exists()`\
+`path_is_dir()`\
+`path_is_file()`\
+`path_is_protected()`\
+`path_is_hidden()`\
+`file_is_type()`\
+`is_root()`\
+Wow.... There's a lot here...
+`path_exists()`: returns true if the inputted path exists; that's it
+
+`path_is_dir()`: returns true if the inputted path is a dir; that's it
+
+`path_is_file()`: returns true if the inputted path is a file; that's it
+
+`path_is_protected()`: returns true if the inputted path is protected; that's it
+
+`file_is_type()`: returns true if the inputted file is the second input which is the file type; that's it
+
+`is_root()`: returns true if the path is at the set root; that's it
+#### "Open" Tools:
+These tools open files, however I'm going to tell you here *so I can save you time* **the files must exist or all of the functions will raise errors**\
+`open_file()`\
+`open_protected()`\
+`open_hidden()`\
+Alright now to explain\
+`open_file()`: returns the data of the inputted file; the only input is the file name,
+
+`open_protected()`: returns the data of the protected path; the only input is the path name
+
+`open_hidden()`: returns the data of a hidden path, the only name is the name of the path
+#### "modify" Tools:
+Alright, I'm on the brink of falling asleep, but luckily for me, we only have two commands here
+`modify_hidden()`\
+`modify_file()`\
+Alright now to explain\
+`modify_hidden()`: modifies a hidden path, the first input is the name and the second is the key you want to modify, and the last is just the value, the hidden path must exist for it will raise an Error
+
+`modify_file()`: modifies a file, the first input is the name the second is the key you want to modify and the last is the value you want to set it to, the file must exist, or it raises an Error
+### Examples
+*Experimenting, come back in a later update...*
+### Notes
+*none lol*
+
+# Versions
+*disclaimer; these dates are in the MM/DD/YYYY format*
+
+0.1: \[3/7/2026\] Release date. [Version Documentation](#documentation-for-01)

angelic_kernel-0.1/angelic-kernel/__init__.py

@@ -0,0 +1,2 @@
+from angelic_kernel import Kernel
+__all__ = ["Kernel"]