People suggested I post here, original thread here,
Hello friends from afar this project is a console parser for all Source Engine based games it uses the inbuilt log commands and reads that information to execute commands in-game and out without hooking into the game at all, so no chance of VAC. I'm not sure about ESEA Client but I assume it should be fine since it only reads the log file the game outputs. (Please confirm)
Taken from the project's git wiki
Overview
This repository provides an easily extensible Source Engine console parser capable of reading all output from the in-game console and sending commands to the game. At the time of writing there are four example extensions:
1. An example extension to show the basic usage to create your own (Extensions\ParserExtended.cs)
2. An auto-spectate extension (Extensions\AutoSpec.cs) that will automatically send you spectate when the console outputs spec; useful for pugs where spec is called and you don't want to play medic
3. A silly extension that smiley binds every time you get a frag (Extensions\SmileyBinder.cs)
4. A dynamic hud switcher (Extensions\HudSwitcher.cs) which can be used for various uses such as using a different hud per class (including a different hud crosshair), changing between a spectator hud and a normal hud and whatever else.
These extensions are aimed towards Team Fortress 2, but any Source Engine game will work such as Counter-Strike Global Offensive, Left 4 Dead etc and just scrape the surface of what is possible. I'll let you figure out some interesting uses for this, I've gotta keep some secrets :+1:
Usage
Basic usage is as follows, the arguments sent to the exe tell the program which cs files to compile (don't include the extension on the end it assumes .cs for all files). Please note, extensions should be placed in the running directory of the application. Eg. "SourceEngineConsoleParser.exe SmileyBinder AutoSpec" Would compile both the SmileyBinder and AutoSpec extensions and use both of them. If arguments aren't provided it writes the engine output to its own console.
How to use AutoSpec
Start the exe with AutoSpec as a command line argument, and ingame type _parser_autospec_enabled_. You should get a message saying Parser > Auto-spectate enabled in the in-game console. From there on it will auto-spectate you whenever it detects 'spec' in the console. Quite a basic way to do autospec but can be extended easily if needed.
How to use SmileyBinder
Same as above but replace with SmileyBinder in the arguments and ingame type, _parser_shittalk_enabled_. You will get a confirmation message in the in-game console. It will then smiley bind every kill you get. Enjoy..
How to use HudSwitcher
This one requires more user actions than the others so make sure you follow the instructions completely or it will delete your hud. To change hud you can type _echo parser_hudswitcher_changehud \path relative to running directory\_. Please note a hud_default should always be placed in the running directory containing a backup of your resource/scripts folder. Upon game close the program will attempt to restore this hud back into your custom folder.
For example if you wish to have a separate hud for scout, you would put in your scout.cfg _echo parser_hudswitcher_changehud \hud_scout\_. Upon going scout it will replace the hud and reload the hud for you. It is then recommended you place _echo parser_hudswitcher_changehud \hud_default\_ into the other class configs to swap back when you change class.
One more thing to note is that ClientScheme.res and SourceScheme.res in \resource\ cannot be changed without restarting your game. Therefore if you wish to use completely different huds, you will need to merge these files together for every hud you wish to use, or they will not work correctly.
Notes
The base program does automatically update your autoexec (it only appends never overwrites) with the required commands to make itself work. It should never corrupt your autoexec, but just in-case make a backup of it. You have been warned.
Go here for more information.
Not sure if I'm allowed to post download links but it's here
People suggested I post here, original thread [url=http://ozfortress.com/showthread.php?p=982724#post982724]here[/url],
Hello friends from afar this project is a console parser for all Source Engine based games it uses the inbuilt log commands and reads that information to execute commands in-game and out without hooking into the game at all, so no chance of VAC. I'm not sure about ESEA Client but I assume it should be fine since it only reads the log file the game outputs. (Please confirm)
Taken from the project's git wiki
[code]
Overview
This repository provides an easily extensible Source Engine console parser capable of reading all output from the in-game console and sending commands to the game. At the time of writing there are four example extensions:
1. An example extension to show the basic usage to create your own (Extensions\ParserExtended.cs)
2. An auto-spectate extension (Extensions\AutoSpec.cs) that will automatically send you spectate when the console outputs spec; useful for pugs where spec is called and you don't want to play medic
3. A silly extension that smiley binds every time you get a frag (Extensions\SmileyBinder.cs)
4. A dynamic hud switcher (Extensions\HudSwitcher.cs) which can be used for various uses such as using a different hud per class (including a different hud crosshair), changing between a spectator hud and a normal hud and whatever else.
These extensions are aimed towards Team Fortress 2, but any Source Engine game will work such as Counter-Strike Global Offensive, Left 4 Dead etc and just scrape the surface of what is possible. I'll let you figure out some interesting uses for this, I've gotta keep some secrets :+1:
Usage
Basic usage is as follows, the arguments sent to the exe tell the program which cs files to compile (don't include the extension on the end it assumes .cs for all files). Please note, extensions should be placed in the running directory of the application. Eg. "SourceEngineConsoleParser.exe SmileyBinder AutoSpec" Would compile both the SmileyBinder and AutoSpec extensions and use both of them. If arguments aren't provided it writes the engine output to its own console.
How to use AutoSpec
Start the exe with AutoSpec as a command line argument, and ingame type _parser_autospec_enabled_. You should get a message saying Parser > Auto-spectate enabled in the in-game console. From there on it will auto-spectate you whenever it detects 'spec' in the console. Quite a basic way to do autospec but can be extended easily if needed.
How to use SmileyBinder
Same as above but replace with SmileyBinder in the arguments and ingame type, _parser_shittalk_enabled_. You will get a confirmation message in the in-game console. It will then smiley bind every kill you get. Enjoy..
How to use HudSwitcher
This one requires more user actions than the others so make sure you follow the instructions completely or it will delete your hud. To change hud you can type _echo parser_hudswitcher_changehud \path relative to running directory\_. Please note a hud_default should always be placed in the running directory containing a backup of your resource/scripts folder. Upon game close the program will attempt to restore this hud back into your custom folder.
For example if you wish to have a separate hud for scout, you would put in your scout.cfg _echo parser_hudswitcher_changehud \hud_scout\_. Upon going scout it will replace the hud and reload the hud for you. It is then recommended you place _echo parser_hudswitcher_changehud \hud_default\_ into the other class configs to swap back when you change class.
One more thing to note is that ClientScheme.res and SourceScheme.res in \resource\ cannot be changed without restarting your game. Therefore if you wish to use completely different huds, you will need to merge these files together for every hud you wish to use, or they will not work correctly.
Notes
The base program does automatically update your autoexec (it only appends never overwrites) with the required commands to make itself work. It should never corrupt your autoexec, but just in-case make a backup of it. You have been warned.
[/code]
Go [url=https://github.com/Paymh/SourceEngineConsoleParser]here [/url]for more information.
Not sure if I'm allowed to post download links but it's [url=https://www.dropbox.com/s/h82d1fj8p6q4wc2/SourceEngineConsoleParser.rar?dl=0] here [/url]
3. A silly extension that smiley binds every time you get a frag (Extensions\SmileyBinder.cs)
just bind mouse1 'say 8)'
And then play scout and only get meatshots
[quote]3. A silly extension that smiley binds every time you get a frag (Extensions\SmileyBinder.cs)[/quote]
just bind mouse1 'say 8)'
And then play scout and only get meatshots
This looks really really cool.
This looks really really cool.
Posting so I remember to try this out when I get home, looks awesome!
Posting so I remember to try this out when I get home, looks awesome!
Thinking of some possible uses, this could be used to play a sound for whenever you get a kill.
Could it potentially be used to track which players are alive? I know people have wanted to be able to play with the scoreboard enabled during normal gameplay to see who is up and who is dead. Could this enable/disable hud elements when players die or are spawned?
Could this potentially be a way around using the wait command in certain scripts?
Thinking of some possible uses, this could be used to play a sound for whenever you get a kill.
Could it potentially be used to track which players are alive? I know people have wanted to be able to play with the scoreboard enabled during normal gameplay to see who is up and who is dead. Could this enable/disable hud elements when players die or are spawned?
Could this potentially be a way around using the wait command in certain scripts?
Not_MatlockThinking of some possible uses, this could be used to play a sound for whenever you get a kill.
Could it potentially be used to track which players are alive? I know people have wanted to be able to play with the scoreboard enabled during normal gameplay to see who is up and who is dead. Could this enable/disable hud elements when players die or are spawned?
Could this potentially be a way around using the wait command in certain scripts?
You can use the mp_showrespawntimes command to show a rough idea when players spawn. I have tried to implement that + tracking when players die a long time ago, to no success. I might try again though. It is possible using this command in conjunction with this program, just I'm not sure to the accuracy of it.
As for playing a sound when you kill someone, you can modify one line of the SmileyBinder.cs. To do that change the Program.ExecuteIngame("say =)"); to Program.ExecuteIngame("playsound <whatever>");
As for bypassing wait commands, you are better off using AutoHotkey or similar but you could do it with this program; but it's much less work to use AHK.
[quote=Not_Matlock]Thinking of some possible uses, this could be used to play a sound for whenever you get a kill.
Could it potentially be used to track which players are alive? I know people have wanted to be able to play with the scoreboard enabled during normal gameplay to see who is up and who is dead. Could this enable/disable hud elements when players die or are spawned?
Could this potentially be a way around using the wait command in certain scripts?[/quote]
You can use the mp_showrespawntimes command to show a rough idea when players spawn. I have tried to implement that + tracking when players die a long time ago, to no success. I might try again though. It is possible using this command in conjunction with this program, just I'm not sure to the accuracy of it.
As for playing a sound when you kill someone, you can modify one line of the SmileyBinder.cs. To do that change the Program.ExecuteIngame("say =)"); to Program.ExecuteIngame("playsound <whatever>");
As for bypassing wait commands, you are better off using AutoHotkey or similar but you could do it with this program; but it's much less work to use AHK.
Hud Switcher? Holy shit, that's a perfect idea
Hud Switcher? Holy shit, that's a perfect idea
Could it also be used like a crosshair switcher but for HUD crosshairs as opposed to the custom crosshairs?
Could this also mean that crosshairs could actually be triggered by what weapon is equipped rather than by the frequently inaccurate butt on press method used by the other crosshair switchers currently available?
Could it also be used like a crosshair switcher but for HUD crosshairs as opposed to the custom crosshairs?
Could this also mean that crosshairs could actually be triggered by what weapon is equipped rather than by the frequently inaccurate butt on press method used by the other crosshair switchers currently available?
This is amazing, can't wait to get to writing plugins for it
This is amazing, can't wait to get to writing plugins for it
PankeymanI like the smiley binder idea. Is there one I can get that makes it so an automated message appears for other situations like popping an uber or deploying certain buildings?
Furthermore, is there a way to announce in teamchat if you kill a specific class? This could be very useful for Spies if it was able to determine whether DR was triggered or not.
You can trigger anything that appears in the console. This means that when you ask "is there any way to do x", you are really asking "how can I get x to appear in my console".
For the uber and building things, you could have captions enabled but no caption for those events. Then you could read the error message that comes from not having a caption (this was discussed in the ozfortress thread).
If you want to know if you killed a specific class, you would need to know the names of every player on the other team and what class they are playing. Totally plausible, and probably worth the 2 mins of entering the names at the start of the game for matches. It would also theoretically be possible to keep track of people who change their names in the middle of the game, as you can call a "status" command in console at the beginning of the game, and then any time you die to a name that isn't recognized, status could be called again and the SteamIDs could be cross referenced and names updated. You could also write a Chrome extension that grabs names and corresponding classes from pugme and tf2center and tries to load them into the plugin (it would probably be better to grab their Steam IDs from the website and call status on the match starting to make sure that you don't run into trouble of pugme/tf2center being out of sync with their actual Steam name).
Also you could essentially duplicate the scoreboard and have what classes are alive and when they spawn on a second monitor. You would basically call mp_showrespawntimes when the first player in the game dies. Then you would have a timer that lasts as long as the respawn time for both teams, and calls mp_showrespawntimes again when that timer is up. You would also need to update the timer whenever a point is capped. You could then just cross reference when players died with when the next wave is periodically.
Edit: Added idea I had about having scoreboard always open and being able to still play the game properly
Edit 2: Accidentally a word
[quote=Pankeyman]I like the smiley binder idea. Is there one I can get that makes it so an automated message appears for other situations like popping an uber or deploying certain buildings?
Furthermore, is there a way to announce in teamchat if you kill a specific class? This could be very useful for Spies if it was able to determine whether DR was triggered or not.[/quote]
You can trigger anything that appears in the console. This means that when you ask "is there any way to do x", you are really asking "how can I get x to appear in my console".
For the uber and building things, you could have captions enabled but no caption for those events. Then you could read the error message that comes from not having a caption (this was discussed in the ozfortress thread).
If you want to know if you killed a specific class, you would need to know the names of every player on the other team and what class they are playing. Totally plausible, and probably worth the 2 mins of entering the names at the start of the game for matches. It would also theoretically be possible to keep track of people who change their names in the middle of the game, as you can call a "status" command in console at the beginning of the game, and then any time you die to a name that isn't recognized, status could be called again and the SteamIDs could be cross referenced and names updated. You could also write a Chrome extension that grabs names and corresponding classes from pugme and tf2center and tries to load them into the plugin (it would probably be better to grab their Steam IDs from the website and call status on the match starting to make sure that you don't run into trouble of pugme/tf2center being out of sync with their actual Steam name).
Also you could essentially duplicate the scoreboard and have what classes are alive and when they spawn on a second monitor. You would basically call mp_showrespawntimes when the first player in the game dies. Then you would have a timer that lasts as long as the respawn time for both teams, and calls mp_showrespawntimes again when that timer is up. You would also need to update the timer whenever a point is capped. You could then just cross reference when players died with when the next wave is periodically.
Edit: Added idea I had about having scoreboard always open and being able to still play the game properly
Edit 2: Accidentally a word
Not_MatlockCould it also be used like a crosshair switcher but for HUD crosshairs as opposed to the custom crosshairs?
Could this also mean that crosshairs could actually be triggered by what weapon is equipped rather than by the frequently inaccurate butt on press method used by the other crosshair switchers currently available?
I'll try to answer the rest later but I've got to go to work right now, deetr is doing a good job anyway, thanks!
Yeah it can be used to change HUD crosshairs, just create a backup of your hud's resources/scripts and edit the hudlayout.res or wherever your xHairs are then run the parser command. As for changing crosshair per weapon, I don't recommend it due to the slight freezing that occurs when you reload hud.
deetr-snip-
Look forward to seeing what you do with this
Also forgot to change reference on KeyPressLibrary from my private version of this. For now you will need to copy KeyPressLibrary.dll to C:\ Oops...I'll fix it later
[quote=Not_Matlock]Could it also be used like a crosshair switcher but for HUD crosshairs as opposed to the custom crosshairs?
Could this also mean that crosshairs could actually be triggered by what weapon is equipped rather than by the frequently inaccurate butt on press method used by the other crosshair switchers currently available?[/quote]
I'll try to answer the rest later but I've got to go to work right now, deetr is doing a good job anyway, thanks!
Yeah it can be used to change HUD crosshairs, just create a backup of your hud's resources/scripts and edit the hudlayout.res or wherever your xHairs are then run the parser command. As for changing crosshair per weapon, I don't recommend it due to the slight freezing that occurs when you reload hud.
[quote=deetr]-snip-[/quote]
Look forward to seeing what you do with this
Also forgot to change reference on KeyPressLibrary from my private version of this. For now you will need to copy KeyPressLibrary.dll to C:\ Oops...I'll fix it later
Does the game log events before they in game happen or at the same time? For example, could I read messages in chat and filter them by changing hud_saytext_time? I only ask because I know a lot of Unity games log events as soon as they are called instead of when the code actually executes.
Does the game log events before they in game happen or at the same time? For example, could I read messages in chat and filter them by changing hud_saytext_time? I only ask because I know a lot of Unity games log events as soon as they are called instead of when the code actually executes.
Is there any console output when you take damage? If so you could potentially have a hud element that pops up when you have crit heals and disappears when you lose them.
Is there any console output when you take damage? If so you could potentially have a hud element that pops up when you have crit heals and disappears when you lose them.
As far as I can tell this would be against the ESEA rules.
The way that it runs commands in game is by binding a key to exec a config file and then pressing that key automatically.
Any script that may be determined as providing an advantage would also fall under this category, that would include anti-recoil scripts.
http://play.esea.net/index.php?s=content&d=hnban
komorebiIs there any console output when you take damage? If so you could potentially have a hud element that pops up when you have crit heals and disappears when you lose them.
There is a caption for a class taking damage, but I can't seem to find a way for knowing if you personally took damage
As far as I can tell this would be against the ESEA rules.
The way that it runs commands in game is by binding a key to exec a config file and then pressing that key automatically.
[quote]Any script that may be determined as providing an advantage would also fall under this category, that would include anti-recoil scripts. [/quote]
http://play.esea.net/index.php?s=content&d=hnban
[quote=komorebi]Is there any console output when you take damage? If so you could potentially have a hud element that pops up when you have crit heals and disappears when you lose them.[/quote]
There is a caption for a class taking damage, but I can't seem to find a way for knowing if you personally took damage
deetrDoes the game log events before they in game happen or at the same time? For example, could I read messages in chat and filter them by changing hud_saytext_time? I only ask because I know a lot of Unity games log events as soon as they are called instead of when the code actually executes.
Outputs at same time to console.
Updated git and download link with proper references for KeyPressLibrary.dll, just place in running directory now, sorry!
komorebiIs there any console output when you take damage? If so you could potentially have a hud element that pops up when you have crit heals and disappears when you lose them.
I'm currently looking into a way to see which elements can have the "command" "xyz" attached to it, regarding hud elements. If I figure out a way to do that then it would be possible. Otherwise no.
[quote=deetr]Does the game log events before they in game happen or at the same time? For example, could I read messages in chat and filter them by changing hud_saytext_time? I only ask because I know a lot of Unity games log events as soon as they are called instead of when the code actually executes.[/quote]
Outputs at same time to console.
Updated git and download link with proper references for KeyPressLibrary.dll, just place in running directory now, sorry!
[quote=komorebi]Is there any console output when you take damage? If so you could potentially have a hud element that pops up when you have crit heals and disappears when you lose them.[/quote]
I'm currently looking into a way to see which elements can have the "command" "xyz" attached to it, regarding hud elements. If I figure out a way to do that then it would be possible. Otherwise no.