Things I am working on:

• Automatic updates
  
• Improving guest account
  
• Addition of app store
  
• General performance improvement and better code readability (Should help me troubleshoot and expand code more easily)
  
• Improving UI usability and flow while improving multi-thread support (Switching between programs and never leaving the UI)

Hopefully this will be out within the week!

I may modify the program to add in an exit button, but general functionality is preserved.

Also here is my forum thread which will include the credit and links once I have implemented the store. Thanks for letting me spread your program around haha

Can I have permission to implement this into my OS?

coolmark1995, on 14 June 2015 - 02:05 AM, said:

This is actually designed for the advanced pocket computer. Haven't tested on a normal pocket computer, but it should work mostly. (Will need to remove color before it is supported by basic computers)

Actually, thank you Coolmark! I enjoy feature suggestions as I was unsure where to take the OS. The guest account does work, you have to simply make a new account and set the permission level to 0. This will mark the account as guest.

Be warned, however, as the guest account is still undergoing work to make it truly secure.

Minor update to improve local and global tag usage, and prevented users crashing the logout timer program.

OHH TABLES! I forgot about arrays! (Tables whatever...) Good suggestion! And yes Dragon! I totally realized after I released the update but was way too lazy to fix it haha.

Thanks for the suggestions fellas! I love this community.

Alright gentlemen and gentleladies, I have slaved hard for over 15 minutes and compiled all the suggestions into something beautiful.

Let me know what you all think!

--Default Variable Settings--
local alrm=true
local lck=false
local light=true
local function cleanup()
term.clear()
term.setCursorPos(1,1)
end
--Object Manipulation Functions--
local function toggleAlrm() --Alarm
alrm = not alrm
end
local function toggleLck() --Locks
lck = not lck
end
local function toggleLight() --Lights
light = not light
end
--Setup--
cleanup()
--MainProgram--
while true do
--Present Choices--
print'Welcome to Base Control'
print'Please make a selection:'
  print('1: '.. (alrm and "Disable" or "Enable" ) ..' Night Alarm')
  print('2: '.. (lck and "Disable" or "Enable" ) ..' Base Lockdown')
  print('3: '.. (light and "Disable" or "Enable" ) ..' Base Lighting')
  print'4: Exit'

print''
--Pull Input--
write'Selection:'
local rInput=read()
rInput=tonumber(rInput)

--Get States--
if alrm then
  alrmState="Disable"
elseif not alrm then
  alrmState="Enable"
end

if lck then
  lckState="Disable"
elseif not lck then
  lckState="Enable"
end

if light then
  lightState="Disable"
elseif not light then
  lightState="Enable"
end

--Menu Value Masks--
local chAlrm=1
local chLck=2
local chLight=3
local chQuit=4

--Process Choice-- 
if rInput==chAlrm then
print(''..alrmState..'ing alarm!')
toggleAlrm()
elseif rInput==chLck then
print(''..lckState..'ing lockdown!')
toggleLck()
elseif rInput==chLight then
print(''..lightState..'ing lights!')
toggleLight()
elseif rInput==chQuit then
print'Closing!'
return
else
print'Invalid choice'
end

--Cleanup--
sleep(1)
cleanup()
end

Pastebin: http://pastebin.com/JH6K4GkE

Thanks! As well, I have known and dealt with the local vs global issue before. Very often with my networking and communication programs. (As well in my KOS)

I have a terrible habit of forgetting to use local or just adding it in much later than I should. I had no idea that forcing local would improve performance, but it makes total sense!

Again, thanks for the tips. I look forward to releasing more programs with these tips in mind.

Thanks guys! After posting this I did consider booleans but wanted to wait for suggestions. Never seen the ability to classify based on a boolean in one string. Pretty neat!

And yea, I often am too lazy to use elseif and the lot. Bad habit!

Thanks for the suggestions!

Greetings Fellas!

I am once again bored at work, doing a bit of programming. I am making a little program to allow me to switch the states of a few objects from on to off and back on. As I have almost always programmed the same way for the last few years, I would like a few suggestions on improving my code.

The functional part of this code hasn't been created. I have no issues doing that. What I would like to know is: Is there a better, more compact or more correct way to build the menu I have created. Is what I have solid, or am I missing a very obvious alternative that could improve my code?

Here is my code:

--defaults
alrm=1
lck=0
light=1
function getAlrm()
if alrm==1 then
  alrm=0
  return
end
if alrm==0 then
   alrm=1
   return
end
end
function getLck()
if lck==1 then
  lck=0
  return
end
if lck==0 then
  lck=1
  return
end
end
function getLight()
if light==1 then
  light=0
  return
end
  if light==0 then
  light=1
  return
end
end
while true do
--::home::
if alrm==1 then
alrmState="Disable"
end
if alrm==0 then
alrmState="Enable"
end
if lck==1 then
lckState="Disable"
end
if lck==0 then
lckState="Enable"
end
if light==1 then
lightState="Disable"
end
if light==0 then
lightState="Enable"
end
print'Welcome to Base Control'
print'Please make a selection:'
  print('1: '..alrmState..' Night Alarm')
  print('2: '..lckState..' Base Lockdown')
  print('3: '..lightState..' Base Lighting')
  print'4: Exit'

print''
write'Selection:'
rInput=read()
rInput=tonumber(rInput)

if rInput==1 then
print(''..alrmState..'ing alarm!')
getAlrm()
end
if rInput==2 then
print(''..lckState..'ing lockdown!')
getLck()
end
if rInput==3 then
print(''..lightState..'ing lights!')
getLight()
end
if rInput==4 then
print'Closing!'
return
end
if rInput~=1 and rInput~=2 and rInput~=3 and rInput~=4 then
print'Invalid choice'
end
sleep(1)
term.clear()
term.setCursorPos(1,1)
end

Alternatively, here is the pastebin: http://pastebin.com/b8HPJCKE

Again, there is nothing functionally wrong with the menu. It works as intended.

Yea, sorry guys. Work has kept me too busy to update. Eventually I will get in and add some more security features. Again, as stated, I wanted to focus on features for a bit and get a basic GUI laid out.

At the moment, if you throw your tablet at a friend on your server, chances are, they won't be able to hack into it without being given the password. (Granted, the guest account still needs work.) My main goal was to have a secure login system, and I was never really interested in having file restrictions or the lot. It just fell into place due to the guest account.

Also Atenefyr, I took no offense to your criticism. I appreciate any suggestions as long as you don't simply insult me for not being an ace programmer.

Anavrins, on 26 April 2015 - 07:47 PM, said:

Incompetent? Don't be an ass. If you re-read the main post, this is still in development. I'm no professional so stop expecting perfect. If you want perfect, go make it yourself.

Atenefyr, on 24 April 2015 - 09:09 PM, said:

Yea, I will fix this. Fixed

Yea, probably a better method, but pulling the loop out has allowed me a little more comfort in how I am used to it. Plus I can easily add more to the button loop if needed, rather than passing variables about.

Update 1.6!

• Added a new GUI API (touchpoint)
  
• Improved GUI
  
• Added guest GUI support
  
• Fixed several security bugs, improved gui support for programs

Love the API. I do have an issue where I can't break the loop in the run function. I removed the while true do from there and placed it around my t:run() in my gui program. Then I was able to easily use a button function to kill my GUI loop at the end.

I'm sure there is a way to break the loop in touchpoint from my GUI program, but I could not figure it out.

This api is extremely unstable . I had to make major changes just to be able to add multiple buttons. Even still, the toggle and remove functions do not work at all. I had to rebuild the detect API to pull an event so that you can click a button. The button table almost always crashed on a nil value for some reason.

It looked promising but is clearly unfinished and no longer active.

Yea, I run the user creator if no users file exists. It's the first-use event. I should probably hide that for that instance ;D

My bad... your name is creator... you bolded creator... my brain... is slow!

;D Thanks Creator! It's got a long way to go, but it's making progress!

Updated to 1.5! Added a basic GUI and framework. More to come, enjoy!

Edit: I used this (broken) API to help forge my GUI. I would like to credit account.username for the API. I did have to change it a lot though.

I think you guys are missing that I am simply defining my own edit and delete programs. Not in ROM, but in my own OS's filesystem. This custom edit and delete prevents users editing important OS files or viewing the users files.

The solution I have chosen works perfectly because you now cannot run, edit or use the old methods of editing/deleting.

Since the user has to use my edit and delete, I can rebuild edit and delete to not allow editing or deletion of my own OS files.

As of this moment, I have found my solution.

Update: Fixed extend crashing on non numeric entry.

Anavrins, on 22 April 2015 - 01:18 AM, said:

Yea, I had thought of using a salt as well, but with a sha256 hash on a computercraft OS with no currently seen methods to access the hash without logging in, I am not too concerned. If you really need that much security, then don't allow guests.

My major concern is making sure there are no up front vulnerabilities and fixing any bugs that crash the OS or have unwanted results. I will come back and make it more secure but I would really like to move on to working on a GUI.

All that bit of code does is say if you try to run delete or edit remotely by typing /rom/programs/edit or //////////////rom/programs/edit, that it will not allow you.

Just a way to stop people editing OS files.

Nice find! Thanks! I'll fix that tomorrow.