Revan's OS: Revision 23
NEWS HEADER/RECENT CHANGES LOG:
Changes to Revision 23:
1. By Syranide's suggestion, I fixed the issue where duplicated computers have the same computer names because the CPU doesn't reset. The CPU will now recognise when it is duplicated.
Changes to Revision 22:
1. Network groups are now using gShare(N) thanks to ZeikJT for adding that by request!
2. Modules that utilize InputType '2' will no longer add the key that switches the type back to normal to the string
Changes to Revision 21:
1. Paint module added
Changes to Revision 20:
1. R-Chat is now implemented - Please note the error that can occur and how to avoid it by reading the download section at the end.
2. New display modes
3. Function calls/stack has been tested and repaired
4. -cprint altered to support -cls as a subcommand using function calls
Official Developers
Revan - Working on web pages
n00berific
d3cr1pt0r
|GWCD| Jonny
Introduction
After seeing this post:
http://www.wiremod.com/forum/contrap...-v-2-97-a.html
I decided that I too would give making a wire OS a shot. Now, understand, I have only worked on this for 2 days thus far, and so I don't have as many functions/commands as the OS listed above, however, I do believe that the groundwork of the OS to be more expandable. As this OS becomes more advanced, I expect it to evolve into a community project for all experienced users, anyone can add to it.
For those who like to jump the gun, the downloads are at the bottom.
DEFINITIONS: PLEASE READ
1. Computer - This term is to refer to the entire setup of this OS. This means the various modules which are described below as well as the appropriate screens and the wire keyboard.
2. E2 - Like anywhere else on this forum it means Expression Gate 2
3. The entire OS is written using the E2. While I use the term 'CPU' on occasion, it is to refer to the name of the E2 that centralizes processing on the computer, not the CPU chip of wiremod. The CPU for this is explained below
4. The key word to my OS is modular. Every separate E2 for it is a module. Modules are more clearly defined as a distinct body of the OS which adds relevant data to the computer and interacts with at minimum, one other module of the computer.
3. Library - A library in this OS is to refer any E2 that contains commands which the CPU can run. A library can contain one function or many or none. Libraries take input from the user and act upon it. They are the force of the computer which stores and uses it's memory and decides when to and what to write to the output screen. Two sample libraries are included with this revision, read about them below.
4. The Stack - In this case, the stack is a set of memory which can only have data added to and read from the last element in it. The CPU gate in this OS uses the stack to handle functions, but allows modules to set items onto the stack also. More on this later (mostly for developers anyway)
Key Concepts
1. All commands are registered in the system as lowercase. That means -PRINT is the same as -print, however, what comes after the command remains the same, thus if I said "-print HI", it still reads as "HI", not "hi".
2. At the moment (this will definitely be fixed), all output is displayed where the return character (next line character) is shown as a space (or null) character. This means if it tried to print "hi" on one line and "yo" on the next, it looks like "hi yo". The string still wraps to the next line if the max characters is reached for the line it was last on, you just can't use the return character. (for users, this doesn't matter, only confused developers [to become a developer read much farther below])
3. This computer is 'lag' resistant. That means that it can be calibrated to deal with different lag situations. You can do this in two ways.
First, input can and in many cases will mess up for those of you who download this. Messing up can mean making two of a character when it shouldn't, or not typing a character when it should. The reason for this is the timing it takes to register. This is likely to vary based on your ping as well as how fast you type (for slow typers, this shouldn't be an issue). To change this so that it works best for you, open the input module and change the line that says "interval(120)" so that the number is higher or lower (based on which issue you get).
Second, you may change the interval values of any other module to increase performance. In most instances it does little than lag the server, but as modules become more and more complex, it may be necessary to have them register faster. I only recomend changing the clock of anything *but* input to developers who are designing modules that call for faster updates.
Modules
1. Input - Gets information from the user, is responsible for managing entry data and sending it to the memory and the associated entry output module.
2. Entry Output Module - This module is responsible for taking data the input module gives it and writing it out to a console screen so that the user may see what they're typing. The focus of it is to use the most efficient updating methods possible for the screen. It will only change cells that need to be changed, with the exception of screen clears. If modules enable certain functions, this screen may not display what the user is typing in order for that module to take direct control over input.
3. The CPU - Again, this is *NOT* a CPU chip, it is the *NAME* of the expression 2. This chip has a few main functions. 1. This module will identify the computer by assigning it a group name for it's global storage. 2. This module will redirect input to the libraries and only allow new commands to be run when libraries are not actively working. 3. This module handles 'dumb commands', or commands that don't exist, by way of a timeout feature. 4. This module handles the stack and internal function calls - this is mostly for developers, so if you're interested, read in the developers section
4. Main Library - As described above, this is a library. It contains functions which will affect the computer. This is *NOT* the final version of the function list, more are being added as you read this
Current function list:
Code:
-print - This function will take whatever appears after a space that follows and show it on the screen. IE: User enters "-print hi", the screen shows "hi".
-cprint - This function works similarly to -print, it was created to demonstrate the concept of having multiple lines of input. It allows you to enter a message and then continue entering a message until the closing keyword "-quit" is entered, which returns the user to normal data entry. IE: User enters "-cprint hi", the screen shows "hi", the user then enters "how's it going", the screen then shows "hi how's it going", the user then enters "-quit", and the screen doesn't change. All future input is read as a normal command. This function now also will accept -cls as input after -cprint before a -quit is read. That means that you can -cls at any time while using -cprint. (see -cls next)
-cls - This function will clear the output screen of all data.
-endproc - Every library must now implement this function. It is there to ensure that the CPU can *always* return to a default state if instructed by the user.
5. The Lib Library - This library does nothing, it is an example library meant to be built on as a template for additional libraries. It also allowed me to prove the concept of modular libraries.
6. Reactionary Output - This library is responsible for displaying information passed from a library. The Main library for instance, takes the -print function and sends the appropriate text to the screen.
Specialty Modules - Modules that arn't considered basic/necessary, but were also created by developers
1. Pong - This library will allow users to play pong against an AI opponent, now fully working.
Code:
-pong - This command will start the game. To exit, press 'q' until the game quits. Controls are managed with the up/down arrow keys. Have fun!
2. Singlesend Router - This module allows other modules to utilize what are essentially functions (called with global variables), to send data across a network. When used with a network adapter, you can send data between computers. The pro's of this internet protocol is that you may easily send data, the con being that you can only send one piece of data per execution. For most modules that won't be an issue, especially when you can use the "NetSpeed" global variable to modify it's update rate to match that of the module that is sending it the data. I designed this to be fast and efficient and to get data from group A to group B (not really called that), and that's all. This has no commands that the user will be able to interface. All managing of this module is done by other modules.
3. Network Adapter - This module works with the Singlesend Router to send data across the network. It has two commands, and a built in feature for the first virus, there is a way to clear the virus, but I'll let you find that out for yourself 
.
Code:
-connect <network name here> - thus I could type "-connect moo", and it would connect to the network "moo" and give me a confirmation message to that effect.
-ping - This command is used to find out if there are any other computers connected to your network. It will send data to the network, which any other computer with a network adapter (doesn't even need a singlesend router) that is on your network will reply to. Your computer then will tell you if it gets a reply or time out after 2 seconds and tell you that it didn't.
-evil - This command will make it so that any computer that pings yours will be infected with a virus. The command toggles the value. There is a message telling you the value after it's executed. Be warned: Once a single computer on a network is infected, any computer that pings will also become infected. The virus isn't *that* annoying, hardly noticeable when doing anything *but* pong (but adding community modules would change that), all it does is clear your screen every 30 seconds after the first minute of being infected. As I said before, you can figure out how to remove the virus on your own.
4. R-Chat - This module allows any number of computers to chat in real time. It supports an effective method of data loss prevention that ensures that everyone receives all data. Commands are as follows:
Code:
-rchat - This command initiates the chat program. It will ask you for your screen name, or handle, followed by what chat room you want to join. Anyone who you want to speak with will need to join the same chat room. It works with gSetGroup(S), so the same rules of casing apply (and I don't know what they are). Once you're in the room, your screen will be blank until someone (either you or anyone else on the same room) types something; it will then list the speaker's name and their message. There are two built in subcommands, -cls, which will clear the screen (if you type it as a message) and also -quit, which will end the chat and send you back to normal input. -endproc will also do the same thing.
I'm going to add another internal command to -rchat called -screw, which will be the means by which to perform the next virus/hack. It's not implemented yet, but it's on the way.
5. Paint - This module implements one program, paint, which allows you to draw images with complete control over pixel location and RGB values. While it may take forever to make anything half decent, you can do it.
Code:
-paint - This will activate paint mode
When in paint mode:
1. Pressing 'q' will end the command
2. C is your cursor, you can move it with the arrow keys
3. RGB values are listed in order at the lower left of the screen. They're limited to 0-9 because of the limitations of wire, to find out the corresponding actual RGB code (0-255) add one to it and then multiply that number by 25.5
4. R value - when 'r' is pressed it increments, when 'e' is pressed it decrements
5. G value - when 'g' is pressed it increments, when 'f' is pressed it decrements
6. B value - when 'b' is pressed it increments, when 'v' is pressed it decrements
7. Pressing enter will redraw the pixel under the cursor with the RBG values you have selected.
Future Plans
1. Add more commands to Main
2. Networking - Work in progressa. DONE - There will be 2 new components, the network adapter and the router.
b. The network adapter - DONE (maybe needs a few more commands - This will be a cluster of initial commands that can be executed on your computer through the internet. Some will be voluntary, some may not be. This cluster of commands is what is going to make it realistic, there will be pros and cons alike to the internet, and the basics of them will be stored and run out of here. This is where viruses will be added. Yes, I said it, viruses. You're computers will be able to be infected with a few varieties of virus. The good news, as with every virus there will be anti-spyware modules/commands/w/e to combat these foes (also read about the router)
c. RChat - DONE - As a separate module from the network adapter - This will allow users to create chat rooms, passworded or not, allowing as many clients as desired. It will work like MSN in that everyone has a screen name, and everyone can send messages. In later iterations of this module I may also allow you to directly send pieces of data, of course with a little confirmation message box for the virus weary
d. NEXT - Web pages - I will support the easy creation of web pages and create a browser for them.
e. I will be adding different internet protocols (only matters for developers) which means that data can be sent in several formats. While you can always override the formatting and skip direct into the network, I advise not to unless you have to run a background process (see the bottom of the network adapter [ping])
3. New Design - I'm going to make it look more like a computer... less ugly, one screen, etc.
4. Threading - To make it a real OS, I will allow multiple processes to run at the same time, but doing so may require libraries to have flags saying if they are background processes....etc.
5. Depending on community support for this project, I may add an SVN download from one of my computers.
6. Passworded computers
7. More as it comes + community modules
So why should I care that it's modular?
It being modular means that *any* wiremod user who is experienced with the E2 can add and alter the computer with ease. You can add your own commands, functions, libraries, and programs to the computer. The Lib module is an example module which contains the basic structures of a module, you can use this as a template on which to build your own modules. Many E2 contraptions that have already been made using a console screen can be easily adapted to work with this computer, just apply the template. More support for this type of adding is coming soon (see the future plans section).
Developer Info
How to become a developer
There are two types of developers, one requires my approval, the other does not:
1. Community Developer - These developers can be anybody, they do not require my approval, but their content will not be added to the official release either (but depending on how good it is, with their permission I will add this to a special section of this post). These developers will most likely release libraries only, but are free to alter the other modules to their liking as they please.
2. Official Developer - If you are skilled with wiremod, particularly the E2, and you would like to help develop the OS, you may contact me on steam to apply to join the team. Applying is simple, show me what you can do, if you're good, you're on. Users that I know to be experienced are welcome without trial. Official Developers will help me change the modules outside of the libraries to be more efficient, more universal, and otherwise greater so they are as fast and useful as possible. They may also release official libraries from time to time.
Creating a New Module
Before you start making a module, it's imperative that you know exactly how the default modules work. You absolutely must understand the Input, CPU, and Output modules to create a successful module. I highly advise that you look over how Main works aswell, as it contains working commands that utilize the other modules, and quite frankly, it's good code that you can steal for your own modules. Looking over the other modules can only help you! Especially if you're doing any networking, I advise you look at the modules that utilize and make up the networking systems.
Please note: If you're altering one of the existing modules that I have created, 90% of the time you will be doing something wrong. Avoid the practice if you can, use what's already in place. If you really think that one of them needs to be changed, tell me about it in a post at the end of this thread with an explanation of why (with your current code attached) and I will evaluate the usefulness of the change. If it's any good, I'll commit it to the OS.
For anyone who is interested in adding their own modules, I suggest that you start by copying the 'lib' library file and altering it. Start by removing the useless function that does nothing. You can then add your own function calls by getting data from global variables, see the Main library about this, it's got good in-code documentation now.
How to Make Functions
Your job is to recognise a function and act on it. To recognise a function, compare the string against the name of it (see Main). Acting on it will vary largely based on what you intend the function to do, so I won't explain it a whole lot, instead, I'll tell you how to change the rest of the computer.
1. If you need to store data, there are two ways to do it, and it's important to recognise which to use:
a. Do you need to store data for your module *only*? If the answer is yes, then store your data in persistent variables. They will save for each iteration of the E2 and keep the data you desire, but be mindful about clearing it when you're done with it!
b. If you need to send data *between* modules, then I suggest using global variables. Now, that means that you *could* potentially alter other data by accident, and that's no fun, so that means you need to be specific in how you name it. If it's in the "Moo" module, then you should call the data "MooVariable". If you need to make large amounts of data, you can treat the global spectrum as a table, just be mindful again, have a table that works with the following indexes: "MooRAM1", "MooRAM2", "MooRAM3". This shows where it's from, what it's storing, and which index it's at.
2. If you need to write to the screen, you must do the following:
a. Determine what DisplayType you're using. See them listed below
WARNING - BE VERY VERY VERY VERY VERY CAREFUL NOT TO SPAM TO THE CONSOLE DISPLAY! THIS WILL CREATE MASSIVE LAG
b. To use any DisplayType you must first set it through the global variable - Note: Switching between display types will *not* erase previous data inherantly, but DisplayType 1 *will* after an update.
c. All DisplayTypes will only show data when you set the global number "DisplayUpdate" to 1. Please note that you should set all parameters for the display, IE, "WX", "WY", "ToWrite", and "Args" as they apply *before* you run "DisplayUpdate" or they may not be read.
c. DisplayType 1 - To use this DisplayType you only need to set the text to display and the update variables. Be sure to update *after* you set the text.New There now is another variable that interacts with this DisplayType. The variable is "DisplayBuildDir". When it's value is 0, new text is added to the top of the screen as old text is pushed down. When the value is 1, new text is added to the bottom, old text is pushed up when there is no more room. Any other value will default it to 0.
d. DisplayType 2 - To use this DisplayType you must set the text, the WX, and the WY positions through global variables before use. WX and WY are the positions to start drawing at.
e. DisplayType 3 - This DisplayType works exactly like DisplayType 2 with one difference; you can now specify arguments (like color) in the "DisplayArgs" global number. These arguments will be displayed with writeString(S,N,N,N)
f. DisplayType 4 - To use this DisplayType you must set the WX, WY, Args, and Text values. WX and WY automatically find the X and Y positions to write to (keep that in mind when trying to scroll), and args behaves normally.
g. DisplayType 5 - To use this DisplayType you must set "WX" and "Args". "WX" becomes the X and Y position, like it normally is, and "Args" behaves normally as well. Note: To use this mode in revision 20 (I'll fix this later) you will need to replace the output module, I didn't put it in the adv duplicator file, only in the E2 code.
h. For more detail on the precise names to set globally and how this works, please view the actual file, it is commented well enough that as long as you have worked with console display before, you should understand it.
3. If you run a command through your expression, you must determine one of two things will happen:a. It runs once, changes some values, and ends. If this is the case, you must set the global variable of Mode to 0 and the global string of Cmd to "" to reset the CPU.
b. If you're running multiple times, on the first iteration set Mode to either 2 or 3. 2 means that you don't need additonal input, but you are going to be running for more than 100 miliseconds. 3 means that you require additional input from the Input module, if you use this mode you may also want to consider changing the InputType variable. Running multiple times will usually involve the setting of the 'Running' variable so that your library knows that it is active. You absolutely *MUST* have a way of terminating your command. There must be some set of conditions that always lead to setting Cmd to "" and Mode to 0 when you're done executing your command. If you fail to do this, the CPU will *not* reset. While -endproc can get you out of many hairy situations, if the library changes the InputType, you could be stuck until you replace the CPU.
4. Somewhere in your module you *MUST* have an -endproc command listed. I included one with lib, so if you copy that library as a base, you should be fine, just ensure that any variables that you add that would otherwise make your module not act as if it had just been created fresh are reset when this function is called. This is a safety command to ensure that bad modules don't bottleneck the system.
NEW - The Stack
Alright, for those of you who read earlier in the post about the stack, here it is. First, an explanation of what a stack is... (gonna steal a little from the real CPU chip tutorials)
Picture the stack as a stack of plates. You can't take one from the bottom (well you could, but it'd be difficult, so lets just say you can't), only from the top. You cant really add to the bottom either, you'd need to lift the whole thing and shove one underneath, much easier to... stack one on top.
The stack is used to store information for later.
In this particular instance, the stack allows you to do one of two things:
1. Use it to call functions - This is done automatically, all you need to do is run the proper commands (listed a bit lower)
2. Use it manually to add data - This means you want to take direct control of the stack to push (add) and pop (remove) data. In this case, you're free to add all you please, just be mindful, it's better to empty the stack of all data you added when you're done with it (but just don't remove too much!)
When to and when not to use the stack:
It's important to understand that the stack is just an array that allows itself to be modified via global variables. If you need a stack, in most instances, you can make one within the module that needs it, without bothering with sending data to the CPU and all that; and I *do* advise that you use a separate stack unless you need to use the one on the CPU. The only time one would manually change the stack (IE: Not using the "Call" or "Return" commands [shown below]) is to save data that you're sending *between* modules. If the stack you want only needs to store data within the module you have open, don't bother putting it on the CPU.
So you may be wondering what happens if I leave too much data on the stack or remove too much from it....
1. If you add too much to it, it will attempt to run the extra values as functions one at a time, most likely timing out for each of them. While this won't cripple your CPU, it will take a bit for it to return to normal
2. If you take too much from it, one of two things will happen.
a. Nothing - If there was nothing on the stack when you added to it, then nothing will happen because the stack won't allow you to remove more places then it has; that means that you will have just emptied the stack... a lot.
b. Bad - If any data was on the stack before you started to work with it, it will now be gone, that means that if your function was called via a call command, you will no longer revert to that function; likewise, if that function stored data on the stack and you removed that data, it's no longer accessible. I'm not saying that you can't do this, I'm not saying that you shouldn't either, I can think of valid instances in which to remove data from the stack that you didn't add, I'm just suggesting for the inexperienced that you avoid the practice.
So how do you work with the magical stack you may ask... here's a list of global variables that work similarly to internal commands that let you work with the stack:A. "StackPush" - This is a string global - whatever you set to it will be added to the top of the stack
B. "StackPop" - This is a global *number* (see the next one) - Whenever this is set to a value of one, value C (see next) will contain the last value on the stack and the stack will decrease in size by one element (eliminating the value you just read)
C. "StackPop" - This is a global *string* - This is used to return data called from B - When "StackPop" the number is set to one, this string is used to return data to the caller; more specifically, the last value on the stack.
D. "Call" - This is a string global - This will set the current function to the top of the stack and then set Cmd to "Call"'s value, effectively running Call's value as a command. Be mindful that any function you call *from* will need to set "Mode" again after it is executed after the call; I suggest you store a local variable to manage this.
E. "Return" - This is a string global - This value will be set by a module which has been activated by "Call" - When this value is set, the current function will end, the stack will pop out a value and set the Cmd value to it, running the function that called the one that just ended. Finally, it will set the value of "Return" to the "Cmd2" global, to be used similarly to additional input on your module.
F. "StackSize" - This is a global number - This value will be set by the CPU as you alter the stack. Every time you run "StackPush", "StackPop" (the number), "Call", "Return", or if the CPU clears the stack attempting to run it's values as functions, this value will change accordingly to reflect the amount of values in the stack.
There is one more pertinent global that doesn't reflect the stack's values as much as it does function calls:
"CalledFunc" - This is a global number - This value increments by 1 every time a function is called via another module as opposed to by the user. This value also decrements as "Return" is called. This value will reset to '0' every time that the input module registers the enter key when the module is in input mode '1' (normal entry). I included this value so that functions that only need to run when called, not when the user attempts to run them (when they won't see anything) the function can decide not to do anything (or do something different).
IE: I could essentially 'overload' a function that lets say for our purposes just adds two numbers passed as parameters. When a user runs it directly, it may decide to print the value to the screen. When a function runs it however, it may decide to print nothing and just return the value.
Special Thanks
d3cr1pt0r - Always looking for inspiration, and you certainly gave me some
Chinoto - Thanks for helping me out with the input and output, while I no longer use the method of output you showed me, you did get me started 
Thgin^ - Thanks for helping me with the edits I made on the output
The wire team (especially Syranide) - Need I say more?
Pics/Vids (eventually)
Nothing fancy shown, just a command and it's effect as well as the general display of the computer. (PREVIOUS VERSION - In fact, so far back that it now has 2x the number of modules)
Download Info
The download is now listed as a .rar file. Extract it to your steam account folder and it will automatically add the expression and adv dup files to your data.
Be warned, the wirelinks between the output E2s and the consoles may need to be rewired.
LinkBack URL
About LinkBacks
Reply With Quote
Revan's OS 
Originally Posted by Eirath245
Nice work
Posting Permissions 
Bookmarks