Elijahlorden

17 minutes ago, BrisingrAerowing said:

This is actually really cool. I may mess with creating some additional drivers for this later (e.g. for Power Management [Extreme Reactors / Draconic Evolution / RFTools / etc], Fluid / Inventory management [Refined Storage / Pressure Pipes / Inventory Controller / Tank Controller / etc], and automated farming [Robots?]).

If you do end up creating additional drivers, let me know.  I would love to include them!

I designed the tablet driver with the intention of using linked cards.  I find wireless networks in OC to be unreliable, especially where the tablet is concerned.  I can add an option to toggle the use of wireless cards in responding to a ping and accessing the gateRegistry, though.

Initial post updated

Wow.  Ok then.  The OS is heavily network-oriented.  It's written so any device can run a command on any other device in the network.  The reason for having to press a key to bring up the prompt is because running one of these commands from the network will mess up the prompt if it is open.  listComponentMethods takes an address, if you look at the arguments listed in 'help listComponentMethods' (I can allow it to look for components by primary if it does not find one by address).  The shutdown/reboot command errors are legit, it's happening because the command does not for the case where a device-specific module (I call these 'Drivers') is not actually loaded (this happens by default since the device is set to 'Default', which does not load a file from /Drivers/.  I forgot to remove some testcode which compiled the installer/InstallData files on boot, which is why it says it's removing them every time it starts (it's also why you see the OS packaging itself every time it starts).

https://github.com/elijahlorden/StattenOS-Installer

You can get the installer files from here for now.  use wget to close the Installer and InstallData files to files of the same names in the root directory of an existing OpenOS install (not the OpenOS floppy).  Next, run the installer and power cycle the computer once it has completed.  I will add instructions to the initial post (including the wget commands for copy/paste).

The first OS install will have to be done on top of an existing OpenOS install, which will be erased and replaced with StattenOS.  The OS has a command you can use to install copies of itself to another drive.  Additionally, if you update the OS on the central server, you can use the sendUpdate command to compile and send a copy of the new OS files to every device on the network, which means you don't need to go to every device and update it individually.

Currently I manually add the files via windows explorer, but I'm working on an installer that can be downloaded and run from an OpenOS install.  

This is not dead.  Recent updates:

- Finished basic Stargate control implementation

- Added Mekanism fusion reactor control program

I will eventually get around to updating the initial post with more information.

The simplicity is intentional, I prefer to be rather utilitarian with my code.  The system IS very network-oriented.  The goal is to be able to access any device on the network from any other device on the network.  The eventual point of this project is a system which will allow me to control various aspects of my base from anywhere (this is accomplished by using linked cards in the control tablets).  Currently I am going to be focusing mostly on utility.  The first useful function the system will perform is SGCraft related.  I know there are already plenty of gate control systems out there, but mine will have a few additional functions.  All saved addresses are stored on the server, the tablets only keep a cache of this kind of information.  Any change to the registered gates will automatically be replicated to other tablets.  This means large groups of players won't have to manually share any newly created gates.  The gates directly connected to the network will of course have Iris automation.  Long story short, this project aims to centralize things that you would normally create isolated systems for.

https://github.com/elijahlorden/StattenOS

This is a very early implementation of StattenOS, a networked base control system I am developing.

Installation instructions:

You will need a hard drive with an existing OpenOS install, and an internet card to access Pastebin. You will also need one tier 3.5 memory (at least) in order to run the installer.

Navigate to the root directory (which is just up one from the default OpenOS directory) and run the following commands:

pastebin get fNQ4EUTg InstallData

pastebin get uZhxkJLt Installer

The first file may take a moment to download, as it is rather large.

After both of them have downloaded, type 'Installer' into the prompt and wait.  (If you get a 'too long without yielding' error, please report it in this thread)

Once the installation has finished, power the computer off and on again, and it should now boot into StattenOS.  (Currently, if no network card is installed, it will crash)

Purpose:

The purpose of StattenOS is to allow a player to automate parts of their base, and then access those parts from anywhere, at any time.  Any device on the network can run a command on any other device, and receive feedback.  Devices can also broadcast notifications across the network to alert the player if something happens while they are out around.  If the OS is updated and you install the update on the central server, you can send the update to all networked devices, you can also create a new StattenOS install from any existing StattenOS install.

Devices currently supported:

SGCraft Stargates - Allow Tablets to wirelessly dial Stargates, and save addresses to the server which are then replicated to other tablets on the network.

Mekanism Fusion Reactors - Allow automated charging and firing of the ignition laser, as well as checking status and a notification if, for whatever reason, the reactor deactivates.

StattenOS will load device-specific settings and commands based on what 'Device Driver' it has been set to.  You can use the command 'listDeviceDrivers' to print out a list of these.  In order for the network to function correctly, at least one device must use the 'Server' driver.

StattenOS can also compile task-specific lightweight versions of itself called 'miniApps'.  Currenttly there are two of these:

GCont - Simple gate control program which works with the dialGate and closeGate commands in the Tablet driver.

LRelay - A relay for sending/receiving packets via linked cards.  The primary purpose of this is to allow Tablets a network connection no matter where they are.  (I couldn't get Linked Cards to function properly when placed in Relays)

In order to install one of these apps, insert a floppy disk (I generally use a Floppy disk for these, but you can use a hard drive aswell) into a computer with a StattenOS install, and note the assigned drive letter (Drive A will always be the drive where the StattenOS install is located) and use the command 'installMiniApp driveLetter appName' to install the application on the disk.  The disk can then be removed and placed in another computer.  If a StattenOS update also updates one of the miniApps, you can simply insert the disk and it will automatically be wiped and updated with the new version of the app. (as long as you do not change the label)

More information will come later.

I see that linked cards can be put in relays, but I'm not sure what port messages relayed by linked cards are sent on.

Is this still being worked on?  This is a fantastic concept, and I would love to see it in-game!

Nevermind!  It appears that other Lua variants handle concurrent tasks differently than OC Lua.  For anybody who is interested, you can use the following to run a function repeatedly even while event.pull() is holding up the thread:

event.timer(0.05, function() print("stuff") , math.huge)
  --interval between runs, callback function, number of times to be run

I am attempting to write my own operating system.  So far everything is going perfectly fine, except for this extremely annoying issue I am having.  (I am not writing my own core libraries, I copied those from the OpenOS files on GitHub)  For my Shell, I would like tasks running in the background to be able to print to the screen without messing up the user input prompt.  My attempt at doing this:

local Shell = {}

Shell.ShellBacklog = {{Type = "print", Text = "- Init Shell -"}} -- {Type = "print", Text = " "}

Shell.promptOpen = false

Shell.prompt = ">>> "
Shell.history = {}

Shell.step = function()
	if (#Shell.ShellBacklog > 0) and (not Shell.promptOpen) then
		repeat
			local p = Shell.ShellBacklog[1]
			if (p.Type == "print") then
				print(p.Text)
			end
			table.remove(Shell.ShellBacklog, 1)
		until (#Shell.ShellBacklog == 0) or (Shell.promptOpen)
	end
end

Shell.keyDownEventListener = function(event, address, key, code, plr)
	if (Shell.promptOpen) then return end
	Shell.promptOpen = true
	term.write(Shell.prompt)
	local strIn = term.read(Shell.history):gsub("\n", "")
	table.insert(Shell.ShellBacklog, {Type = "print", Text = strIn})
	Shell.promptOpen = false
end

Shell.start = function()
	event.listen("key_down", Shell.keyDownEventListener)
end

Shell.print = function(...)
	table.insert(Shell.ShellBacklog, {Type = "print", Text = ...})
end

The step function is called in the main loop.  My issue is that term.read() pauses everything, including the main loop.  Is there any way around this?  I attempted to use coroutines, but could not get them to function correctly.