I certainly hope that C is the obvious answer for ease of use.

If you don't want to dip into using background threads, you can simply subscribe to the OnLogLineRead event and start your hooking as soon as an event is raised without the isImport flag. That should be a fairly safe indication that EQ2 is writing to the log file(or something is). You can even unsubscribe to the event at that point.

Thanks Aditu,

i just fire a background thread now which notifies the main thread when hooking is finished. Was easier to implement then i thought and works like a charm,-)

Still on schedule for a first release this weekend . Did my first raid yesterday using the plugin.
It will just be an early release to get some feedback regarding:
- does it run on other platforms (only using Vista64 for testing here)
- performance/stability (after some nice memory leaks both should be fine now )
- look/feel (open for any suggestion how to pimp up the look,)
- feature requests (attach a reasonable amount of platin and i will see what i can do Basically, now that the hooking works, i can display any information on screen[from ACT or from outside ACT])

These function will probably not make it into the first release:
- drawing a timer bar (code is in but i face some directx problems i have to look into)
- text flashing (easily done, just short on time)


Frank

P.S.: I have one enhancement request for ACT. I miss a field for storing some information about Timers (like "damage type","mana-drain" ...). I like to have this information available because i can't remember every timer. What i currently do (and which is also available in the overlay ) is to misuse the "timer start sound" field for that info (cause it basically stores any string). That's not a clean solution, so i would prefer having an additional "info field" for a timer.

Frank_Harmann wrote:

P.S.: I have one enhancement request for ACT. I miss a field for storing some information about Timers (like "damage type","mana-drain" ...). I like to have this information available because i can't remember every timer. What i currently do (and which is also available in the overlay ) is to misuse the "timer start sound" field for that info (cause it basically stores any string). That's not a clean solution, so i would prefer having an additional "info field" for a timer.

I suppose a few people have requested something like that... but there isn't a lot of UI space to put a full text box into. Then fitting that optionally into the timer display itself. That's the worst part of GUI programming... making room for everything. It's certainly not the data management that's a problem.

Using the timer start sound like that sounds sort of like a bad idea though. Every time a timer starts, ACT will read it and attempt to play a WAV file of that path. If you're not raising an exception every time like that, you're at least filling ACT's error log with file not found errors.

Sounds like your solution is everything I had hoped for in mine, so Im going to bow out at this point=). I simply show the parse in the corner of the screen, and I havent had luck converting my project to use late injection. Essentially what I had done was hijack the Direct3DCreate9 function to return a pointer to my version of the dreict3Ddevice9, which had my implementation in it. I know im close to getting the late injection working, but you have all the features anyone will need. Best of luck, I look forward to using your plugin.

Quote:

Using the timer start sound like that sounds sort of like a bad idea though.

Well, i know it's very dirty and i will replace that as soon as you have a new field for it. It's just that i can't miss that data because i'm getting too old to remember every spell effect,-)

@zero: Well, let's hope my version will work on other configurations then mine. Otherwise we will have to use your hooking method. In order to use late injection for d3d-hooking you need to get a device pointer on your own (because the application might already have passed the Direct3DCreate9 function). After getting a device pointer you can continue as usual with pointer rewriting.

I think i just found the timerbar rendering problem. Doing vertex draws inside the present-Hook seems to be no good idea because thats not really supported outside a beginScene/endScene block. So i will try to switch to endScene-Hooking (well, should be just one line of code change) and see what happens. So maybe the bar will make it into the beta,-)

Just thinking of the best way get attention to a timer warning. Currently the text just changes from color1 (customizable) to color2(customizable).
Flashing the text between color2/color3 is on the todo list. I'm currenlty thinking of an option to zoom a timer into view when the warning time is reached (to a customizable location and with a customizable zoom-scale). Any better visualization ideas to get attention to the timer are welcome (well, playing a sound is still the best method when there is much action going on,-))


Frank

I did just send the first beta to Aditu (mail).
Let's hope it passes his scrutiny

Hi,

thinking of adding some of the mini-window funtionality now (personally i am interested in extDPS encounter and zone, but i will try to just use whatever is configured for the mini-window in ACT. So if anyone wants hps instead, he is free to do so *shrug).
Can you provide me some code how to pick up that data (that means the data after it has been processed by the text formatting, but before rendering. Basically a per player string i then can display).
I will try to make it as customizable as the spell timer window, so you(well i do this for myself to be honest) can configure it in a way it will overlay(or prefix) the names in the raid window to show the players dps/zoneDps.

Thanks,

Frank

Well, if you want the data that might go to the mini-window that isn't rendered... you could just request the data the same way the Mini-Window gets it except at your own pace. The mini-window, clipboard and macro exports all use FormActMain.GetTextExport(). There are a bunch of different overloads depending on what exactly you want to do... but essentially you pass it an EncounterData object and a TextExportFormatOptions object and it gives you back the text. If you don't wish to generate your own formatting options, you can find stored presets in the ClipFormats and MiniFormats properties.

Thanks, i will look into it.
Just finished testing on XP32 and after some minor adjustments(just a link depency i overlooked) it's now also running there,-)

Hmm, GetTextExport seems fine regarding the formatting stuff, but the problem i have with it is, that i would prefer to get a string per player instead of one string which includes all players (otherwise i can't configure line distances etc. for the overlay on my own). Is there an easy way to get it without rebuilding what GetTextExport internally does (i always dislike rebuilding things).

Btw, do you know if it is possible to get the order of the allies like they are listed in the raidwindow? My original idea was to prefix(or so) each member in the raid window with his mini-window data (dps f.e.), but that of course would require that order.

Frank

I don't see what's so hard about getting a string per player...

Code:

string export = GetTextExport(encounter, formatting, arial, 25); string[] exportLines = export.Split(new char[] { '\n' }, StringSplitOptions.RemoveEmptyEntries);

The above code will give you the export for encounter, according to formatting, tabulate the columns according to the character widths of arial and give you a maximum of 25 returned lines. Then split the export per new line into a string array.

Quote:

Btw, do you know if it is possible to get the order of the allies like they are listed in the raidwindow? My original idea was to prefix(or so) each member in the raid window with his mini-window data (dps f.e.), but that of course would require that order.

You may need to explain this one a bit better. You can specify the sorting order in formatting, but I have a feeling that's not quite what you mean.

Oh, thanks Aditu. I didn't recognize that splitting up the resulting string per player is easy as that (though to relate each resulting string to a player requires that his name is in the generated string itself [that depends on the formatting options i think)

Regarding the second question, i just search for an idea do get the order of the raid like it is shown in eq2's raid window (that has nothing to do with ACT itself). If i could get that order i could prefix each name in the raid window with f.e. it's dps. Unfortunately i don't see any way to get that order

Type /whoraid into EQ2 and you'll get the order. Of course it won't tell you about empty group spaces... so if there are two people missing in the raid, there's no indication as to where the blanks are.

Ah, thanks, didn't know that command . I will have to think how far this info will get me (too bad i can't get infos about the free places. Or is there by chance something like /whoraid 1 to get only the names of group 1).

If i can't get infos about the free places, i still have one very ugly method in mind how to get the positions of the player names in the raid window, but therefor i would have to intercept each font->Draw call and check it against the names in the list i got from /whoraid. The correct position could then be computed by using only that matches that have the same x position (if using a vertical aligned raid wiindow), because the names will probably be drawn to the screen more then once (chat windows etc.).
This sounds a bit like an overkill, so i will think a bit longer and probably start with just copying your mini-window to the d3d screen.
My old code for that was a framerate killer but doing the copies and texture generations outside the EndScene hook should eliminate that problem (still looking for a better method then Hbitmap of your window->bmp structure in shared memory->createTextureFromFileInMemoryEx).
I am also thinking about installing a keyboard/mouse hook to allow dragging the window around or to implement an overlay menu, but currently that's all just plans for some time in the future as my time is rather limited in the moment.)

Did you already found time to have a look at the current version (1.0.0.0)? If it's ok, i would like to release this version as it is (spell timer overlay only), because i don't know when i will find time to add new features and feedback would probably show me what is needed most(if anybody will use it at all ).

Frank