Original Post
[WIP] Desktop Broadcaster
Hey everyone.
Just posting some early stuff about a new thing I'm starting on.

Super basic so far. All it does is check the broadcasts made and pops up a message from the tray. That way you can see if a new tourney is going down if you're neither ingame or on the forum.

Made in python and I'm sort of learning the libraries required as I'm doing it so that's been fun. No source yet but image of functionality. Lots of you guys could probably whip up something better faster but idgaf.

I'm also starting work on a market bot since they are allowed now. If anyone wants to get in on that send me a Pm.
How are you checking the broadcasts? via polling the api on the market, or sitting ingame?

Also I want to see your market bot thing.

ps: if you want to talk about coding stuff check out #foobar in irc. We bite, but not much.
<~suomynona> TITS OR ELEELETH
It uses the broadcast page api.
Checks it every so often and if the newest broadcast is the same as the last one displayed it does nothing and checks again soon.
If it's different it displays the new broadcast and saves what was just displayed so that it can be used in the previous display check above.

Market bot will be a bit more difficult, at least to give good functionality to which will also hopefully make profit. It would be easy enough to get working but I'd have to sit down and really think hard about how it would decide on what to buy and sell and what price.
Indeed, coming up with a successful algorithm for a market bot would be difficult, especially since the market is so volatile.

e: A similar idea I've had is to apply the same line of thinking to ingame betting. It'd be easy to set parameters for when to bet, and how much. Then you just seed the bot account with a certain amount of TC and watch it go.
<~suomynona> TITS OR ELEELETH
I told you to stop inviting people back to our place, Anthony. Not even to watch.

Edit: Fuck it, I'll add some real content.

So I don't get why all of you feel the need to recreate the wheel with these notification systems. Why not hook into an existing system like Snarl or Growl. Most of the systems out there share a network protocol, so it would be pretty simple to push notifications using a set protocol, and guarantee that it works on all platforms.
Last edited by Juntalis; May 20, 2014 at 01:18 AM.
I'm looking into Snarl using PySNP. It's going well but there's not great documentation on PySNP and I can't figure out how to make it work like the default included Snarl apps like the clip Daemon for eg. Only way I can make it work at the moment is by running a loop in my python code to check for new broadcasts and then show a notification.

Thanks for the point in the direction, I'll keep working on it and if I ever figure it out it should be easy to expand to add notifications for Pms and all sorts of stuff (if a vBulletin thing doesn't exist for it already).

Only thing is that users need to have Snarl as far as I understand and I can't make this into a standalone program.
Yeah, using Snarl is a bit of a trade-off. It eliminates the burden of writing code that gives the end user the ability to customize the look and behavior of the notifications, but it also adds that additional dependency. To be fair, though, unless you intend on packaging this application with py2exe or cxFreeze, you're already assuming that the user has a valid Python interpreter installed. (And I'm guessing that your code doesn't account for compatibility with Python 3, so you're also assuming that the installed version is the same version as your own)

Anyways, if you're looking to maintain compatibility across platforms, (for instance, having it work with Growl on Mac OSX) you'll probably want to use the GNTP protocol instead of SNP. (There's a python module for it here) GNTP is the protocol used by Growl and Growl for Windows, but SnagIt also accepts it. (Growl, meanwhile, does not accept SNP)

Anyways, if it was me writing this, I'd try to keep the logic that handles parsing server output and pushing notifications separate from rest of the code. I'd then write two classes, one that takes the notifications and pushes them out to Snarl/Growl/Whatever (Let's call it GNTPCaster), and another that takes the notifications, and displays them with the GUI you were originally writing into this. (We'll call this one GUICaster)

By doing all that, I could then do the following in the startup code:

from broadcasters import GNTPCaster, GUICaster
from gntp.notifier import GrowlNotifier

def main():
	broadcaster = None
		# Attempt to connect to the user's notification software. (Snarl/Growl/etc)
		client = GrowlNotifier(
			applicationName = 'Desktop Broadcaster',
			notifications = ['Some notification','Some other notification'],
			defaultNotifications = ['Some notification'],
		broadcaster = GNTPCaster(client)
		# If no notification software is currently running, an exception will be
		# thrown. At this point, we'll fall back to using the application's own
		# GUI system to display notifications.
		broadcaster = GUICaster()

	# Blah blah. Fast forward to when you've finished parsing the server output/whatever
	# and you're ready to show a notification, message, whatever_else)
In the end, it'd allow you to support both options, but you'd end up writing even more code, which sort of defeats the purpose of my original suggestion. Anyways, all that's your call, and since you're doing this to have fun and learn, I wouldn't worry about it too much.

Personally, I'm probably never going to use this, (don't really care what's going on in the servers and even if I did, notification programs start annoying the fuck out of me after the 5th popup) so my advice is strictly from a programming standpoint. Nonetheless, if have any questions or want to bounce ideas, I'm usually in the IRC channel Leel mentioned.