IdleLight - A Lightweight Web Managed Idling System
17 replies, posted
This is a project I started some time ago to make it easy to remotely manage idling across my cluster of servers and I decided to see if anyone was interested in me polishing up the project for other people to use. This allows me to manage idling remotely, so that I don't have to be at the machine as well as multiple machines at once. I regularly used this to idle about 20 - 25 accounts at a time on one of my servers and it worked flawlessly.
[B]Showcase from Beta(best viewed in 720p):[/B]
[video=youtube;PUVQ4FAtzJ8]http://www.youtube.com/watch?v=PUVQ4FAtzJ8&hd=1[/video]
[B]Features (As of now):[/B]
• It allows idling to be managed remotely, such as by a phone or laptop, away from the machine doing the idling.
• Can manage an infinite number of Steam Accounts, Groups and even [B]Separate Idling Machines.[/B]
• Manages groups of Steam ID's in Groups for easy launching.
• [B]Automated creation of Sandboxes in Sandboxie and all Client files.[/B]
• One time Setup of each Steam account.
• Starts and Stops Clients and Groups of Clients on command.
• Automated deletion of Clients, Groups of Clients and Sandboxes on command.
• Automatically cleans up memory between Client launches and passively during the Idle process.
• Automatically beats clients 'hearts' so that items are deposited in the backpack as they are received.
[B]And the part that holds it all together, Error Recovery:[/B]
• If a client will not start, Error Recovery will kick in and FORCE it to start through several means, have yet to have a client completely fail to start.
[B]Features (In Progress):[/B]
• ( 75% ) Automated updating of Steam and TF2 for all Clients.
• ( 50% ) Tracking and display of item drops.
• Schedule Starting and Stopping of Groups so that the entire process can be Automated on a weekly basis.
[B]Features (Planned):[/B]
• Moving Clients from one group to another.
I'm interested in seeing what people think of the idea and if I should pursue to finish it so that others can use it.
I think you may have missed this thread.
[url]http://facepunch.com/showthread.php?t=1161862[/url]
[QUOTE=Ax3l;39288734]I think you may have missed this thread.
[url]http://facepunch.com/showthread.php?t=1161862[/url][/QUOTE]
I have seen it, but it never fit the bill because it didn't allow remote management or management of multiple systems at once so I had to come up with my own solution. Being that the server that this ran on wasn't at home, I had to be able to do it remotely and thought I'd make an easy way to just manage it from my smartphone.
This is really good, keep it alive!
WOW!!! Keep it up!
[QUOTE=Belarr;39289040]I have seen it, but it never fit the bill because it didn't allow remote management or management of multiple systems at once so I had to come up with my own solution. Being that the server that this ran on wasn't at home, I had to be able to do it remotely and thought I'd make an easy way to just manage it from my smartphone.[/QUOTE]
This actually seems like a good alternative for anyone who can't use or manage multiple sandboxxie accounts, well done!
This sounds fantastic, particularly the error reporting and scheduled starting of idles. Assuming you make it open source so myself and others can verify it's trustworthy, I would absolutely make use of the program.
[QUOTE=Omniusaspirer;39310840]This sounds fantastic, particularly the error reporting and scheduled starting of idles. Assuming you make it open source so myself and others can verify it's trustworthy, I would absolutely make use of the program.[/QUOTE]
I have no problem releasing the source of the software for people to check it, assuming that anyone knows the abstract language it's written in. I'm currently trying to write the update handler and it's a pain because I can only test it when a game needs updated, so I have to flip flop a different game between beta and release which wastes a ton of bandwidth for no reason.
[QUOTE=Belarr;39314298]I have no problem releasing the source of the software for people to check it, assuming that anyone knows the abstract language it's written in. I'm currently trying to write the update handler and it's a pain because I can only test it when a game needs updated, so I have to flip flop a different game between beta and release which wastes a ton of bandwidth for no reason.[/QUOTE]
Hell, I'd be thrilled to even see what you have currently. I've been thinking of making something similar for a while now, but had been slacking on actually starting it. I'm very curious how you set up error handling and the "heartbeat" as well.
So the only practical application of this that I can see is that it'd be a good thing if you had a server box full of idles. It wouldn't make much sense to turn on your phone and start an idle on your home computer unless you're that addicted.
[QUOTE=residntevl;39317056]So the only practical application of this that I can see is that it'd be a good thing if you had a server box full of idles. It wouldn't make much sense to turn on your phone and start an idle on your home computer unless you're that addicted.[/QUOTE]
but what if you are away from your home for some days/weeks for some reason and you want to idle but you are not home at your computer but you can start/stop the idles if you are not home and that is a good thing
[QUOTE=Omniusaspirer;39316663]Hell, I'd be thrilled to even see what you have currently. I've been thinking of making something similar for a while now, but had been slacking on actually starting it. I'm very curious how you set up error handling and the "heartbeat" as well.[/QUOTE]
Aha, well the code is so dirty and peppered with commented out blocks and unused snippets that I'd be ashamed to post the source right now. But anyone is more than welcome to ask how specific stuff works and I'll post the snippets with an explanation. I'll write something up later today for those two for you.
[QUOTE=residntevl;39317056]So the only practical application of this that I can see is that it'd be a good thing if you had a server box full of idles. It wouldn't make much sense to turn on your phone and start an idle on your home computer unless you're that addicted.[/QUOTE]
As minecraft.exe said, it's mostly a convenience thing *cough* I'm lazy *cough*, it's just nice to have the option of using the mobile as well as anything with a web browser.
[QUOTE=Belarr;39317939]Aha, well the code is so dirty and peppered with commented out blocks and unused snippets that I'd be ashamed to post the source right now. But you're more than welcome to ask how specific stuff works and I'll post the snippets with an explanation. I'll write something up later today for those two for you.
[/QUOTE]
Awesome, very much looking forward to seeing how you approached those. :smile:
[QUOTE=Omniusaspirer;39318006]Awesome, very much looking forward to seeing how you approached those. :smile:[/QUOTE]
Here's the bulk of the error handling script, it's fairly simple. That's changing slowly because the function has to integrate update handling into it, but this is it in its current incarnation.
The comments explain most of it, but basically what it does is attempt to start TF2 and adds one to the check counter, waits to see if it has started, if it hasn't started it adds one to the check counter again. If it hasn't started the first time around, it attempts to issue the command to Steam to start it again. If it still isn't started after the second time it adds one to the check counter again. When the check counter equals 3 (2 failed starting attempts) it uses the Sandboxie API to kill the entire sandbox, resets the check counter and starts the process all over again.
[CODE]
$tempcheck = 0 ;Sets temp check flag
While Not WinExists($folder & "\" & $array1[$i] & "\") ;Checks for existence of TF2 window
$tempcheck += 1 ;If not exist, then add one to check flag
if $tempcheck > 2 Then ;If two attempts to start failed, restart process
ConsoleWrite(@LF & "Attempting to restart uncooperative sandbox.")
Run(@ComSpec & ' /c ""' & $sb_install & '" /box:' & $array1[$i] & ' /terminate"') ;Terminate sandbox
$tempcheck = 0 ;Set flag back to zero so starting process starts over again
sleep(10000) ;Wait 10 seconds for processes to terminate
EndIf
Run(@ComSpec & ' /c ""' & $sb_install & '" /box:' & $array1[$i] & ' "' & $folder & '\' & $array1[$i] & '\Programs\Steam\Steam.exe" ' & $params & '"') ;Attempt to start Steam and TF2 within Sandboxie
sleep($scheck)
WEnd
[/CODE]
The essence of the heartbeat system is this line here, the rest of the script is just looping for all the clients. All it does is bring the window into focus (or select it) for a period of time so that TF2 doesn't go into 'sleep idle' mode and stop recognizing item drops until it's brought into focus again.
[CODE]WinActivate ($folder & "\" & $array1[$i] & "\" ) ;Brings client into focus[/CODE]
I got around to writing the installation routine tonight, fairly simple, but it takes care of setting up the initial master files that each idling account will clone.
[B]Best viewed in 1080p.[/B]
[video=youtube;4L_gOIGOxqQ]http://www.youtube.com/watch?v=4L_gOIGOxqQ&hd=1[/video]
The TF2 update yesterday allowed me to write the TF2 update handler today.
[B]Best viewed in 720p.[/B]
[video=youtube;ubjr3Sj1yK0]http://www.youtube.com/watch?v=ubjr3Sj1yK0[/video]
Code auto item trade to main account and you are the king.
Except that,nothing in it for me really
Also,do you mind sharing system specs of your cluster servers and how many accounts you can run at once (20~25 ?)
I take it this is just a showcase of what your doing and nothing is actually publicly available right now?
Sorry, you need to Log In to post a reply to this thread.