This worked great.. but I had to run the updater and then lost the option. Could the turn target casting bar box be put back into the control window. I have the marcro set up lol.. but was so used to using the control center.

r u going to be putting the casting bar option back into the ui by a check box or we still gooing to have to use the macro.. loved when it was a check box option :) thanks in advance.

Is anyone else seeing what the target and implied target are both casting?

Same thing, If I hard target anyone I see what they and the implied are casting.

A new issue that's a big problem for the healers... apparently the monster's castbar is now being shared with the player castbar. Healers in general target their tank, and need to see the implied target's casting. Right now, the monster's castbar goes away when the tank casts an ability.

In raids especially, healers DEPEND on seeing the mob's cast bar. Some detriments are so awful that they have to be cured before they tick even once, and that means you have to click your cure button JUST BEFORE it hits. There are usually NOT good visual cues saying that the monster is casting the Curse O'Doom in 5, and even if there were, if you have your graphics turned way down for raiding, you probably can't see it anyway.

Please, fix that cast bar ASAP! I don't care what my tank is casting, I need to see the casting activity of whatever the tank has targeted!


Forum threads on this topic:

• http://forums.station.sony.com/eq2/p...opic_id=520564
• http://forums.station.sony.com/eq2/p...opic_id=520528
• http://forums.station.sony.com/eq2/p...opic_id=520571

.

It's in the default UI and not something we can really change. If the target window itself has a cast bar, you may have to depend on that for now. Any UI that uses a separate larger cast bar, has both bars overlayed on top of one another. There's no way to decipher NPC from PC casts in the UI.

This just needs to be reverted by SOE for PVE.

I don't think I've seen any problem with the target and implied-target windows themselves. They seemed to both be working OK on raid last night. The independent casting bars (the ones you can show in the middle of the screen) were doing that, but I think that's because there's only 1 casting-bar window and it's trying to do double-duty and failing half the time (which half depending on your role).

Most healers rely on the large stand-alone cast bar. It is suddenly showing both target and implied target casting on the same cast bar and the mob cast is being overwritten by the tank cast. It's just horrible to deal with. I don't know if it needs to be separated on sony's end or the UI end. It needs fixing asap.

Thanks. I'll take a look at it and see about shifting the second one down.

Terrorgaunt wrote:

I'm not sure how long it will take for them to fix this, but at least a fix is in the works.

Gremlin in the mix
 

I don't about anyone else, but I've noticed since I have been tweaking my "Target" window that the "cast" bar on the target window & the "Target Casting" window both have a glitch where the bar almost never makes it completely across before disappearing... I target my self and hit my GH call a 5sec cast with 92% ability cast speed (on a 80 inquisitor), and one moment while trying to cast it, it shows i'm casting it for 1-2 seconds then disappears, i hit esc or jump and then cast it again and the next time it gets 2-4 seconds through the cast and vanishes... very random as to how long the window or bar will show... I am guessing by my fiddling and lack of real knowledge when it comes to building ui's its not a UI issue its a SOE end issue i'm having with it... its like the dynamicdata is lost or dropped before the cast completes... kinda wish SOE would loosen up some of the hard codes and let us have more control over things... in my tweaking of the target window I've been trying to move the spell icons above the hp/mp bars but am finding its either not possible or i'm just doing it wrong

I'm seeing similar things, the casting bars in the target and implied target window work perfectly but the target casting window bars are erratic. Sometimes they fail to show entirely, other times the bar runs way too fast and isn't in sync with the target/implied-target window bars. I'm getting the impression that, because it's a custom window, the dynamic data isn't being fed to it the same way it's being fed to the standard windows.

That and some other issues actually getting the bars to show long enough to see where they are is making it a pain getting the size and position decent. I'm trying to see if using some other dynamic data will make the bars show all the time so I can position them right.

I think I've got the size and position right. The target casting bar appears on top, the implied target casting bar below it. I notice some changes on Live to the casting bars, I'll have to look those over to see what's in them. I'm attaching the updated XML file for anyone who wants to try it before it's on the updater.

This is being patched to Live tomorrow: 7/31

GENERAL

Options for who to display a casting bar for, as well as special coloration for allied casting bars, have been added. These options can be found under User Interface (Advanced) - Targeting Windows.

I don't know if Profit will be updated for this but Drums had a fix in for this all weekend.

I'm still unsure of the development schedule for ProfitUi as Silat no longer works on it. Changes do occur but its my understanding its not in active development.

Always liked Profit but may switch to Drums as I am picky about not waiting more than a day for 3rd party UI fixes.

Looks like your post came even after tknarr posted a fix to the casting bar. Profit is still maintained he did explain that he has a large work schedual right now and would be delayed. As I believe dolby has pointed out these authors work free of charge and I have even seen silat chime in and make some fixes when needed. Also note the fix wasn't from a 3rd party ui author for the issue that the casting bar was having it was on SoEs side with a work around provided by SoE on their official forums which drums happen to take advantage of while waiting for the SoE fix.

I'm not sure this is the same issue. I haven't seen the UI code on Test, so until it goes live I've no idea what they're changing. My fixes were strictly to the positioning of the progress bars in a ProfitUI-specific custom window (the bars were overlaid on each other so you couldn't see both at once). Once I see the UI XML changes I'll know what needs done in Profit to accommodate it.

If you want same-day support for changes in the UI, generally the only way to get that's with the default UI. For any third-party UI, it depends on how much free time the authors/maintainers have and how big the changes are. I tend to prioritize things, changes that'll break Profit and make it unusable get my attention ASAP while purely cosmetic things or things with easy workarounds take a bit longer.

I'm headed into the game now and will take a particular look at the new settings for the casting bars. I'll post if anything breaks.

I patched in and ran a diff, and the only changes to the UI XML are on the welcome screen. Whatever they did, it doesn't affect the UI code so I'm guessing no changes needed to custom UIs.

The casting bar changes were all internal to the Options window. For authors wanting to duplicate the new options elsewhere in the UI (or for creating macros), commands for the new settings are:

show_target_effects 1 or 0
show_implied_target_effects 1 or 0

show_casting_bars_type 0 through 3, for each of the four types in the dropdown

ally_casting_bar_rgb_red (0 through 255)
ally_casting_bar_rgb_green (0 through 255)
ally_casting_bar_rgb_blue (0 through 255)


PS: Custom castbars are not completely back to normal yet since the spell progressbars are still failing to show up for the duration of some casts, which is a new problem introduced with the last game update. This thread has the details.


.

I couldn't see any change in the bars themselves. Advanced Options gave me a four-stage popdown to select whose bars would appear when.

Hey guys. I have a couple of requests for the target casting bar to make it more manageable.

One. Is it possible to make it really click through enabled? The problem I'm having, is I kinda have the bar in center screen, and when I'm trying to click a rez box, or a loot accept window, or the guild hall portal selection, the target casting window, even though I cant see it, gets in the way and I cant click OK and such.

Two, seeing how the bar seems to still be there and just not visible. Is there to make it show up all black from hitting F10, so I can position it whenever, and not just when someone is casting something?

Don't know if either of these are possible, or if its just a game issue. Or even an operator issue. But would be great if ya guys can do it. Thanks a lot and keep up the good work.

For the first, I can look over the XML and see. It may be a flag I can control with appropriate settings.

For the second, that's under the control of the client itself. It's pretty much the same problem as with the Heroic Opportunity window, and there's not much that can be done about it in the UI XML.

For the target casting window click-through, I can't find anything in the UI XML to control it. If you can't get it to work by changing the window options, then I don't think I can do anything in the code. If someone can point me to an attribute setting that affects it, I can experiment.

Eh, thats too bad. Was hoping a fix would be available. :(

I am curious if the original question was ever resolved. It would be nice to have the npc casting bar be persistent over game plays. I will often be mid raid and missing interrupts, then have to open macro window and look for the macro. I would use this window all the time on every toon no matter what level so having it be always "on" would be nice if possible.

I tried setting the value to true in the casting bar settings file and including it however I still seem to have to use the macro before it finally shows up.

Unfortunately it's a limitation in the game UI: windows that aren't part of the game's default set won't be automatically displayed. It's probably a consequence of them not being saved in the UI settings file, so the game wouldn't know where to display them. Or more likely that the game reads the UI settings file and displays what it finds there based on the settings, and since custom windows aren't there they aren't automatically displayed. Either way the end result's the same.

Just wondering what window does the bottom bar duplicate? because I don't think that is part of the game UI and its automatically displayed isn't it?

Actually it isn't automatically displayed. Things start out in eq2ui_mainhud_experience.xml which is automatically shown on startup, it has code in OnShow to show and unshow the control center window, which has OnShow code that opens the bottom bar window. It's possible to modify the macros to show any custom window, but making it conditional so it's shown or not depending on user preference takes a bit more coding than just showing it all the time. It'd also want adding a button somewhere in the control center to toggle the bar off and on, rather than having to type out commands to do it.

Yeah there is a control panel mod Silat had here that has that in it at least a checkbox. Seems he couldn't get it to work properly without some side effect or something. Since it isn't persistant through sessions and the settings file doesn't seem to do the trick I simply hit the macro on my hotbar when I log a character in. I'm gonna dabble in the modified center and see what I can do :)

To make showing it conditional, you'll need to look at eg. the code that reads _ProfitUI_Settings_GroupWindow.txt. It'd be something similar: have a _ProfitUI_Settings_TargetCastingBar.txt with a setting in it to control whether the bar's shown at startup or not, code to read that file to get the setting, and code to make showing the window conditional on that setting being true. Then a button or checkbox in the control center that'd just show or unshow the window, possibly with the added code to check whether the window was currently shown or not and Do The Right Thing automatically.

Good enough for me thank you. I was just curious.

If I remember correctly it kept causing the subclass detector to bug out for some reason. It wasn't a high priority for me and I never got back to it.

Silat