External Event Sounds Script

[jamincollins]

Entropy has asked that I bring the discussion for this to the programming forum.

 

As many of you probably know, several people have various scripts that monitor the chat_log.txt for changes and play different audible alerts based on the different text entries.

 

Not all events are written to the chat_log.txt, and most really shouldn't. I'm looking to go beyond what is possible with simply following the chat_log.txt by passively monitoring and parsing the network traffic between the client and server.

 

The external script would sniff the packets between the client and server, parse the data structure, and be able to trigger audible alerts based on any event sent by the client or server. This script wouldn't have any information/knowledge that the client doesn't already have.

 

What do you think?

[trollson]

Will this detect whether sounds have been switched off on the client?

 

What if you are running two clients on the same host?

[Florian]

What if you are running two clients on the same host?

Two different dest ports, no problem.

[trollson]

What if you are running two clients on the same host?

Two different dest ports, no problem.

How do you know which one to issue sounds for?

For example: There are two (or more) clients running, using different 'elc.ini' files. Primary client is doing the fun stuff, and has sound enabled. Secondary client is doing the drudgery, minimal sfx and no sound.

 

I'll answer myself then -- the snoop listens to messages from the client to the server, and is controlled by text commands. These should be ignored by the server, and should not appear in chat (#...).

 

Edited June 17, 2007 by trollson

[jamincollins]

Will this detect whether sounds have been switched off on the client?

It could check the el.ini files, but I had planned on having this operate independently of the client settings. That is, the application will have its own configuration file and option to enable/disable its sounds events.

 

What if you are running two clients on the same host?

 

As Florian has already indicated the different ports used by each client can be used to differentiate which client the sounds are for. However, for the initial version I haven't planned to differentiate multiple clients, but rather get the event detection and sound structure working. Once the initial rough spots have been ironed out, it probably wouldn't be that hard to create a list box in the application's GUI with the different EL clients detected and allow the user to turn sounds on and off for each of the clients.

[bkc56]

As many of you probably know, several people have various scripts that monitor the chat_log.txt for changes and play different audible alerts based on the different text entries.

As one of these types, I would like a more general solution. I don't like filling my log-file/disk with extra server messages but that's the only way to see "You stopped harvesting" messages. Being able to "see" the messages without writing them to a log would be nice.

 

BTW, I only watch two types of messages, the above harvesting ones, and anytime someone PMs me. A tool should probably be configurable such that you can at least define the text/event to watch for and the sound to play when it's seen.

[trollson]

What if you are running two clients on the same host?

As Florian has already indicated the different ports used by each client client...

Not actually the point of the question (see above). We've already used snoops to decode the EL protocol for a running session (using pcap libraries).

[bluap]

Is there a reason we don't just add support to the client directly. It could easily be configurable. On/off options for a bunch of events. We could even have options to change the default sounds.

[jamincollins]

Not actually the point of the question (see above). We've already used snoops to decode the EL protocol for a running session (using pcap libraries).

I read your response above. I don't much care for sending erroneous extraneous text messages to the server to control the event sounds application.

 

Preferably, the extra application will be transparent to the official client and server no additional load of any kind for either of them. The application I propose would have its own configuration window(s) and configuration file independent of the official client.

 

Is there a reason we don't just add support to the client directly. It could easily be configurable. On/off options for a bunch of events. We could even have options to change the default sounds.

C isn't a strong language for me. The client is written in C. The lack of configurable sounds is an itch for me, and I'm attempting to scratch it.

 

Additionally, with the sounds external to the client they can be updated separately from the client.

[ttlanhil]

As I see it, there's probably 2 reasons for something like this to be used.

 

1) Ping (as in a sound effect) on PMs or when your name is mentioned.

If someone wants to provide a high-quality sound file that meets Roja's approval, and Ent approves of the idea, I'll add the code for playing a sound file myself. I don't expect it would take long.

 

2) Notification when you break something or stop harvesting.

I really don't like this, since I see no reason you should be playing if you're not playing.

Reading the forums? Fine. Alt-tab back every few minutes, it's not hard to do (I often do this, even when programming for EL. Maybe I miss out on some harvesting time, but hey, I expect that when I'm semi-afk-harvesting).

I know people do this by watching the tail of chat_log.txt already. But it seems to me like passive-macro-ing... The player still clicks, but they aren't actually playing most of the time.

[bkc56]

I know people do this by watching the tail of chat_log.txt already. But it seems to me like passive-macro-ing... The player still clicks, but they aren't actually playing most of the time.

I don't want to get side-tracked with a "how do you define play" discussion, but I'd like to point out that when you're just setting there harvesting you aren't really "playing" either. Watching the screen while you wait for something to happen, or watching the TV while you wait for something to happen - it's about the same thing. This of course excludes when your chatting, or modding, or mixing, or etc, etc, etc.

[jamincollins]

As I see it, there's probably 2 reasons for something like this to be used.

 

1) Ping (as in a sound effect) on PMs or when your name is mentioned.

If someone wants to provide a high-quality sound file that meets Roja's approval, and Ent approves of the idea, I'll add the code for playing a sound file myself. I don't expect it would take long.

 

2) Notification when you break something or stop harvesting.

I really don't like this, since I see no reason you should be playing if you're not playing.

Reading the forums? Fine. Alt-tab back every few minutes, it's not hard to do (I often do this, even when programming for EL. Maybe I miss out on some harvesting time, but hey, I expect that when I'm semi-afk-harvesting).

I know people do this by watching the tail of chat_log.txt already. But it seems to me like passive-macro-ing... The player still clicks, but they aren't actually playing most of the time.

Those are only two items that can be, and are being, with the existing chat_log tails.

 

With the network stream the possibilities open to include any notice from server or client. For example some possibilities off the top of my head:

• each spell can have unique audio.
  
• notification when poisoned
  
• Gauntlet-esque low health notifications
  
• background noise/music while walking
  
• notifications when buddies come online/go offline
  

And I'm sure that there are countless others that simply aren't jumping out right now.

 

Edit:

The short of it is that I'm willing and planning to do the work. The real question here is whether anyone believes this breaks any rules, if so, which and why?

Edited June 18, 2007 by jamincollins

[ttlanhil]

Some of this is already half-developed with NEW_SOUND in the client, which torg was going to try to finish off. We'll need the sound files as well, of course, but a lot of this is already being worked on/will be worked on.

 

ed: as far as illegal... I don't think you can get an answer on if it counts as automation/macro-ing/illegal client from anyone except mods. No other rules seem to apply

Edited June 18, 2007 by ttlanhil

[jamincollins]

ed: as far as illegal... I don't think you can get an answer on if it counts as automation/macro-ing/illegal client from anyone except mods. No other rules seem to apply

 

Well, the mods sent me to Radu. Radu sent me here. Now, you're suggesting I talk to the mods. I see a loop in my future.

[ttlanhil]

Well, the mods sent me to Radu. Radu sent me here. Now, you're suggesting I talk to the mods. I see a loop in my future.

Hmm. Me too. Personally I don't like it, and think it may fall under automation, but I'd think only mods can really say if something is against the rules.

[Torg]

I think that as Ent is allowing you to do it, it isn't against the rules.

 

That only aspect I consider being possibly against the automation rule is the make semi-AFK harving easier, and that is currently possible by tailing the log anyway, so this util isn't going to affect that.

 

I think the discussion Ent wants to bring to this forum is whether some of that functionality should be included in the client, or the util.

 

My opinion on that is things like sounds for walking etc should be part of the client (and are under NEW_SOUND).

 

Given you are keen to do the work, and aren't comfortable with C, then things like notifications should be in this extra util.

[majestyk]

That just seems wrong to me. Sound effects belong into the client - they are a part of the game after all (and one that has been neglected too long, while we're at it).

It would still be possible to make things extendable and configurable, but at least there would be something in the client, for all users, without the need for external utilities.

[Grum]

I tend to agree with majestyk, if we could directly handle this in the client without giving up configurability, that would be much better.

[Aislinn]

Speaking as a mod, I am uneasy at things that affect game play, including but not limited to:

 

1. Low health notification

2. Poison notification

3. Harvest event stops notification

4. etc...

 

Things like pm notifications or buddies online don't affect much one way or another and shouldn't be an issue. I personally would not include anything such as what I mentioned above without precise and specific disclosure to entropy and his specific approval on each item.

[bkc56]

I personally would not include anything such as what I mentioned above without precise and specific disclosure to entropy and his specific approval on each item.

Entropy has asked that I bring the discussion for this to the programming forum.

It would seem to be at least partially covered already as I'm sure Entropy is smart enough to figure out the types of notifications people would be already using even if jamincollins didn't give specific examples when discussing it.

[Aislinn]

A mod's opinion was asked for, and I have learned to never assume.