SyncPlay - Customizable modular source engine log event handler.

[Funky]

SyncPlay
Customizable modular source engine log event handler.

By listening to a tf2 servers real time log via "logaddress" SyncPlay can communicate with the server itself and trigger actions. An action can be anything from a database query to sending information back to the originating server or any other server configured in the configuration file.

SyncPlay is an engine that can trigger actions based on events sent from a source server. By using ActionPacks you can extend SyncPlay to do anything you like with the data sent by the server. By using ActionPacks (for lack of a better term) you can expand the abilities of SyncPlay.

For more information visit the project website.


Project Website

http://code.google.com/p/syncplay/


Release Information
08-24-2008-r93

• Game servers can now point there log_addresses to a SINGLE port!
  

08-24-2008

• Server events should now be parsed. Valve changed the date format on me.
  

08/23/2008

• Added the Jetty web server. (Can be enabled or disabled)
• Completely new configuration code.
• Separated configuration code.
• Added the Wicket web development framework.
• Added ActionPack developer API.
• Created new XPlay ActionPack. (Replaces "SyncPlay")
• Removed all game specific code.
• Removed announcements.
• Updated documentation.
  

I haven't tested this release much so I would be happy if someone could let me know how their experience goes if they use it. Thanks!

[trewq]

i don't like the idea of freezing and stuff but that could have grate potential because it can trigger stuff. Good Work

[Mooga]

I've forwarded a link off to LART

[Funky]

I'm hoping interest in this will increase. I know it's not the most fascinating thing to create but anyone who's tried to get HLstatsX working knows what a pain it is. When I saw that it was PHP4, mysql4 and perl... I thought a nice java solution would be welcome.

As for the whole multi server communication the example were just examples of things that could be done. Also, this project is at an early stage so it can really be turned into anything. I am very open to suggestions.

[lart]

I have to say the source for hlstatsx really sticks. it's be hacked soo much and is not well documented. however I don't know that java is the best route to take. I think a better route would be a sourcemod plugin as you could talk directly to the database and srds that way.

[Funky]

lart Wrote:I have to say the source for hlstatsx really sticks. it's be hacked soo much and is not well documented. however I don't know that java is the best route to take. I think a better route would be a sourcemod plugin as you could talk directly to the database and srds that way.

Here are some thoughts on that idea:

• One instance of the plugin per server might be overkill for this sort of application.
• Database querys might slow things down and all that added extra logic to a server is not right.
• A separate server can be run on another machine to save server resources.
• A game/server update might break the plugin.
• If the plugin gets updated, now you have to update it across all servers.
• If the plugin needs to be updated the server needs to be restarted.
• If sourcemod is updated it might break the plugin.
• The configuration is much simpler as well. Instead of having to configure database settings for each one of your game servers it could be kept in one place.
• The less the server has to deal with the less problems it will encounter.
• Keeping it it generic could allow it to function on more games that support logaddress and rcon.
• (Maybe not on this forum but...) More people know java than sourcemod plugin development. Which would allow more people to contribute to the project.
• It would be a lot easy to add multiple database support to a java app rather than a sourcemod plugin (Oracle, MsSql, etc). Due to OOP and a database abstraction layer.
• A java application can be expanded to do more than just stats.
  

I understand that having a plugin to all the work seems like a good idea. It's a centralized thing that is directly related to the server it is on but I think that if it doesn't need be part of a server then it shouldn't. Yes it would allow direct communication to the server but is that really needed for a stats collecting software? A plugin can be written to allow rcon commands to do anything anyway and rcon commands can come from remote machines.

Java is a great language to use for this. If this project grows enough the jetty webserver can be included in the package and it can have a built in webserver for stats display and configuration with a very simple setup. It could be made into a very simple deployment. Also, my implementation is heavily based on threading so that all events are handled in a different thread making the main program always available to receive new information. This is something hlstatsx failed at and I don't think a plugin can handle this as well.

BTW lart, I appreciate your work on the hlstatsx plugin getting it to work with tf2! I use it myself.

[Funky]

Release Information

07/17/2008

* The syncplay feature is now active and stable.
* Health boost and freeze are the only available actions.
* Preliminary database support has been added but not currently available.
* Added syncplay advertisement letting players in game know how many servers are participating in the network.
* Updated documentation on project website.
* Many bug fixes.

[Funky]

Just want to say that am a still working on this project. Current changes so far (but not released) are:

• In-active servers no longer receive SyncPlay events from active servers.
• Added the Jetty web server to allow public viewing of statistics without the need to install an external web server like Apache. (Can be enabled or disabled)
• Refactored the locations of the config classes.
• Added a Web config section to the config xml.
• Added the Wicket web development framework.
• Externalized regular expressions and action mappings. (Allows much easier adding and changing of actions based on regex triggers.)
  

Basically the major improvement is that programmers can now create a class that inherits from Action and develop any triggers they like by adding their class to the new mapping file which maps server events to java actions.

[Funky]

Release Information

08/23/2008

• Added the Jetty web server. (Can be enabled or disabled)
• Completely new configuration code.
• Separated configuration code.
• Added the Wicket web development framework.
• Added ActionPack developer API.
• Created new XPlay ActionPack. (Replaces "SyncPlay")
• Removed all game specific code.
• Removed announcements.
• Updated documentation.
  

I haven't tested this release much so I would be happy if someone could let me know how their experience goes if they use it. Thanks!

[moniquem]

This plugin is a modular source engine log event handler. It is tasked with logging all the significant events in source engine's various modules, libraries, and tools. The most notable of these are: Its check https://masterbundles.com/events-and-conferences-you-cant-miss/ for latest events. The Masterbundle for photoshop is the agreat package of all resource for Photoshop right now. Compile process, link process, build processes, resource loading processes, and general module/library events. A handy tool for logging events in Source engine based games where easy access to the logs is required.