Realtime log monitor?

[arantius]

I want to design a two-part key sniffer. Part one: realtime log monitor. This watches your log file for a pre-defined key string. When found it fires off part 2: single time attach to EQ process and snatch key and UDP it to SEQ.

I'm confident I can get this done myself, but I'm not too sure what the best way to monitor the log in realtime is. I know it's doable w/out serious performance issues. See Xylobot, EQ Companion. What I'd like to know is the right way. Basically, how do I "tail -f" under winblows? Thanks in advance.

P.S. Key phrase would be user configurable of course. Be it "You need to equip a fishing pole..." or "You think you are facing.." or whatever, of course!

[zarzax]

Basically, how do I "tail -f" under winblows?
Take a look at FindFirstChangeNotification. It sets up a handle to an event that can be watched with any of the wait functions (i.e. WaitForSingleObject). It monitors changes in a directory, including file writes and file size changes, but not on specific files. It is easy enough for you to check if the log file is the one who changed. You can then restart the notification with FindNextChangeNotification.

[Poser]

It would actually be possible to use EQWatcher Advanced to do this. It supports a spawn command that fires off another executable.

[baelang]

Originally posted by arantius
Basically, how do I "tail -f" under winblows? Thanks in advance.


well, with cygwin and it's bash shell, you can actually do a "tail -f" under windows.

[Catt]

Originally posted by Poser
It would actually be possible to use EQWatcher Advanced to do this. It supports a spawn command that fires off another executable.

I've worked with this idea a little, and run into 1 fatal snag.

When the called program launches, it takes focus, i.e. crashes EQ.

Otherwise, this would be a neat solution to getting a key when you need it.

Perhaps there is something I'm missing, anyone got any ideas?

I do not wish to use EQW.

[arantius]

A properly coded program will have no window. I am pretty sure we can spawn the process without having it steal focus, as long as we are careful to make it totally non-interactive (not a big challenge).

[Catt]

OK, that was easier than I thought it would be.

Just changed project to a Windows app, never define a window, and killed all printfs.

Works sweetly.

[Poser]

Catt,

Would you mind posting your modified sniffer code for this here. I can't seem to make it work.

Thanks

[Catt]

I don't have the source here to be able to post it, not sure I'd want to have 100's of copies of it running out there.

But, here is what I did, and you can do too:

Started with the basic ideas from this forum, combining the key seeking from one source, the config file reading from another, added some custom stuff, deleted things I don't need (I don't play on test often, and doubt that the offset would match anyway).

This was all done as a console app (i.e. DOS box app).

Originally I had it written to run continuosly looking for the key every 30 seconds and writting to a file if it was newer than already in the file.

The idea of triggering it from the log was presented (thanks Poser), which I liked, so I rewrote it to run once and end, however, it was still a console app. so when triggered it took focus and dumped EQ. This was not desired, hense my post about it, and the reply from arantius (thanks) which got me thinking a bit differently (no, not Mac differently, that's crazy and another topic all together, but they are getting closer with the *nix base.). What I did was change the project definition to a windows app (vs. console) and comment out ALL output to screen (printf. . .), being that it was a console app it did not have a window defined, and therfore does not open one, staying completely in the background, and leaving EQ running (FAT, DUMB & happy (maybe with 4Gigs of RAM?) ) in the foreground, and executes in well under 1 second, they better watch close to catch it. (OK, a couple .'s . . so you can catch your breath after that sentence.)

Just as a point of interest I use a share so I don't have to move the file, it's written where it needs to be.

Also to pull things together a little, if you write the key to a share all that needs be done is to have SEQ load it when it changes. I prefer to do this manually, so I added a "Hotkey" in SEQ as follows (also posted in Dev. forum):



m_decoderMenu->insertItem("Load Session Key", this, SLOT(load_decoder_key()), Key_F12);

You only need to insert the ", Key_F12" in the above code, it's in interface.cpp about line 732.

Just incase it's not perfectly clear this makes F12 load the key file.

[arantius]

I have actually not yet written my log-watcher program to trigger it from in game, yet I have other methods at my disposal to execute the proggy on demand. I've done basically the same thing as Catt. Unfortunately my Win32 programming is um...not robust :) so I had to just use MS Visual Studio to create a "blank" win32 app and paste in the code appropriately. Then had to change a bunch of silly syntax things to get MS to compile it. If I compile the same code with MinGW it still opens a console box, so I deal with it I guess.
Also, I've got the key getting pushed through UDP, so SEQ grabs it automatically, don't have to push a key on that box.
Not hard to do, code is available here :)

[Poser]

Finally after much trial and error I have gotten what I wanted.

1. My sniffer app opens up, sniffs the key, sends it the SEQ box via UDP, and then shuts down. The app is a background windows app, so it doesn't steal focus.
2. Wrote a script for EQ Watcher Advanced that spawns my sniffer.
3. Set up a hotkey in EQ that triggers the EQ Watcher Advanced script.

So now, I can send a decode when I choose to. If I am just running through some zones, I can still have my map. But, when I settle down to hunt I can hit my EQ hotkey and, viola, SEQ decodes.

BTW, I would just like to say thanks!!!! I am a programmer by trade, but not a C++ programmer. By reading the forums I figured out everything I needed to know to pull this off. It was a couple of hours work, but not hard. Reading the forum is the main thing. Thanks to everyone who posted!!!