More obvious queue lock visual effect

[blwbrk]

I think the most important thing for gcd tracker is the queue lock: when you can press the next gcd action. You can not always stare at the circle or bar

[CaiClone]

Hello! thanks for the feedback. Are other things in the bar/wheel distracting? Or is it just too much of a hassle to look at if the bar has passed the queue lock point?

In the Bar we could maybe make the queue lock change color once it has been reached. That way you could tell at a glance if you can or cannot queue your next skill. Another alternative is just coloring the whole bar/wheel but that might be a little too much color with clip/abc/queuelock.

Would this solve your problem?

[aspiringnobody]

Could do something like:

            // draw cast/gcd progress (main) bar  
            if(bar.CurrentPos > 0.001f){  
                var bgColor = conf.frontCol;  
                if (bar.CurrentPos > 0.8f && bar.CurrentPos < 0.85f)  
                    bgColor = new Vector4(1f, 1f, 1f, 1f);  
                ui.DrawRectFilledNoAA(bar.StartVertex, bar.ProgressVertex, bgColor, conf.BarGradMode, conf.BarGradientMul);  
            }  

and flash the bar a different color when we pass the queuelock. I tested this and I was able to see it pretty clearly out of my peripheral vision reasonably well enough. Probably best to do some math to come up with the more contrasting color and pick black or white based on their current bar color. We could reuse the code for the text outline. Optionally fade into and out of the color if we really want to be extra.

My other idea was to enlarge the bar/wheel when we pass the mark:

            CurrentPos = castBarCurrentPos;            
            Width = CurrentPos > 0.8f && CurrentPos < 0.9f ? (int)(sizeX * widthRatio * 1.25f) : (int)(sizeX * widthRatio);  
            Height = CurrentPos > 0.8f && CurrentPos < 0.9f ? (int)(sizeY * heightRatio * 1.25) : (int)(sizeY * heightRatio);  

That one would really need the easing into/out of to make sense.

Edit:

We could also make a new window that the player could place at the center of the screen (or anywhere else they wanted) and show them the up and down triangles for slidecast and queue lock since we already have that convention established and they have pretty clear meanings.

Edit Edit:

~I like the floating triangles for my own use I’m going to implement it for myself I think. I think I’ll do it so that the triangle is green if you can move or queue an ability, and turns red when you can’t move or queue an ability.~

I've got the window setup and drawing the triangles. I'll get the logic added to change the colors tomorrow and I should have something ready to test.

[aspiringnobody]

https://github.com/aspiringnobody/GCDTracker/tree/floating_triangles

[CaiClone]

Thank you! Adding here a video of how these triangles would look ingame. In case @blwbrk has some comments. From my understanding first triangle is the slidecast trigger (Can you move and not cancel the skill) and the second one is the queue lock (Will pressing a new ability queue it)

https://github.com/user-attachments/assets/f3ebddc6-4c5f-4128-9986-e0e8e7d5d3b3

[blwbrk]

for the second solution，maybe no need to draw the queue lock effect in the bar, for exam, border flash. i am not sure the final effect, just an idea.

CaiClone @.***>于2024年8月25日 周日23:20写道：

Hello! thanks for the feedback. Are other things in the bar/wheel distracting? Or is it just too much of a hassle to look at if the bar has passed the queue lock point.

In the Bar we could maybe make the queue lock change color once it has been reached. That way you could tell at a glance if you can or cannot queue your next skill. Another alternative is just coloring the whole bar/wheel but that might be a little too much color with clip/abc/queuelock.

Would this solve your problem?

— Reply to this email directly, view it on GitHub https://github.com/CaiClone/GCDTracker/issues/18#issuecomment-2308893595, or unsubscribe https://github.com/notifications/unsubscribe-auth/BFIJGHIUUCXHZBJHGX4HPOLZTHY5XAVCNFSM6AAAAABNCOIEC6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYHA4TGNJZGU . You are receiving this because you authored the thread.Message ID: @.***>

[blwbrk]

Could do something like:

            // draw cast/gcd progress (main) bar  
            if(bar.CurrentPos > 0.001f){  
                var bgColor = conf.frontCol;  
                if (bar.CurrentPos > 0.8f && bar.CurrentPos < 0.85f)  
                    bgColor = new Vector4(1f, 1f, 1f, 1f);  
                ui.DrawRectFilledNoAA(bar.StartVertex, bar.ProgressVertex, bgColor, conf.BarGradMode, conf.BarGradientMul);  
            }  

and flash the bar a different color when we pass the queuelock. I tested this and I was able to see it pretty clearly out of my peripheral vision reasonably well enough. Probably best to do some math to come up with the more contrasting color and pick black or white based on their current bar color. We could reuse the code for the text outline. Optionally fade into and out of the color if we really want to be extra.

My other idea was to enlarge the bar/wheel when we pass the mark:

            CurrentPos = castBarCurrentPos;            
            Width = CurrentPos > 0.8f && CurrentPos < 0.9f ? (int)(sizeX * widthRatio * 1.25f) : (int)(sizeX * widthRatio);  
            Height = CurrentPos > 0.8f && CurrentPos < 0.9f ? (int)(sizeY * heightRatio * 1.25) : (int)(sizeY * heightRatio);  

That one would really need the easing into/out of to make sense.

Edit:

We could also make a new window that the player could place at the center of the screen (or anywhere else they wanted) and show them the up and down triangles for slidecast and queue lock since we already have that convention established and they have pretty clear meanings.

Edit Edit:

~I like the floating triangles for my own use I’m going to implement it for myself I think. I think I’ll do it so that the triangle is green if you can move or queue an ability, and turns red when you can’t move or queue an ability.~

I've got the window setup and drawing the triangles. I'll get the logic added to change the colors tomorrow and I should have something ready to test.

I like the idea of “new window”

[blwbrk]

and, a sound effect maybe a good addition for slidecast and queue lock event, i’m not sure if Dalamud has this ability.

[aspiringnobody]

If @blwbrk likes the triangles in the video above I will add some configuration options (turning off one or the other triangle, etc.) and some polish (rounding the corners, etc.).

I'll probably implement the bar flash as well, but that idea doesn't translate very well to the wheel. Any ideas what we could do there? Maybe increase the size of the wheel so that it "pulses" when we pass the queuelock?

I think for ease of use for the average user it's best to hide these options in the advanced tab since they're likely very niche.

[aspiringnobody]

and, a sound effect maybe a good addition for slidecast and queue lock event, i’m not sure if Dalamud has this ability.

sound effects are possible, but I'll leave that to @CaiClone to decide. That's a significant investment in code.

[blwbrk]

If @blwbrk likes the triangles in the video above I will add some configuration options (turning off one or the other triangle, etc.) and some polish (rounding the corners, etc.).

I'll probably implement the bar flash as well, but that idea doesn't translate very well to the wheel. Any ideas what we could do there? Maybe increase the size of the wheel so that it "pulses" when we pass the queuelock?

I think for ease of use for the average user it's best to hide these options in the advanced tab since they're likely very niche.

sorry，I can’t open the video.

[blwbrk]

Thank you! Adding here a video of how these triangles would look ingame. In case @blwbrk has some comments. From my understanding first triangle is the slidecast trigger (Can you move and not cancel the skill) and the second one is the queue lock (Will pressing a new ability queue it)

Triangles.mp4

I just saw the video, If the new triangles can be moved, it's ok for me.

[aspiringnobody]

I just saw the video, If the new triangles can be moved, it's ok for me.

They can be moved (and resized) just like the bar and the wheel.

[CaiClone]

Triangles seems like a nice solution then!

• Bar flash, we could maybe do it by changing color on the outline as that could maybe translate to both wheel and bar, otherwise I think it's okay to just implement it into bar for now, as there are many things that are hard to translate to wheel anyways, so it just ends up being the "light" version.
• Sounds, I'm heavily against, as I feel it affects the game, especially when it is repetitive. It might just be trauma from other games with plugins that end up with an airhorn every 2 seconds, but that's a route I would prefer to avoid.

[aspiringnobody]

Triangles seems like a nice solution then!

* Bar flash, we could maybe do it by changing color on the outline as that could maybe translate to both wheel and bar, otherwise I think it's okay to just implement it into bar for now, as there are many things that are hard to translate to wheel anyways, so it just ends up being the "light" version.

* Sounds, I'm heavily against, as I feel it affects the game, especially when it is repetitive. It might just be trauma from other games with plugins that end up with an airhorn every 2 seconds, but that's a route I would prefer to avoid.

Prelim support for the bar and wheel flashes in my branch now. The bar will need quite a bit more work. I put it into the barinfo class reflexively but that was a bad choice. It needs to go into BarDecisionHelper instead, because we need to turn it off for mounts and the like. I'll clean it up later but I wanted to get it out there so you can see how it feels and we can decide if we want to keep it in.

Wheel wasn't a problem, just growing the scale of it looks surprisingly good. Almost like we planned it that way.

[aspiringnobody]

Triangles seems like a nice solution then!

* Bar flash, we could maybe do it by changing color on the outline as that could maybe translate to both wheel and bar, otherwise I think it's okay to just implement it into bar for now, as there are many things that are hard to translate to wheel anyways, so it just ends up being the "light" version.

* Sounds, I'm heavily against, as I feel it affects the game, especially when it is repetitive. It might just be trauma from other games with plugins that end up with an airhorn every 2 seconds, but that's a route I would prefer to avoid.

Prelim support for the bar and wheel flashes in my branch now. The bar will need quite a bit more work. I put it into the barinfo class reflexively but that was a bad choice. It needs to go into BarDecisionHelper instead, because we need to turn it off for mounts and the like. I'll clean it up later but I wanted to get it out there so you can see how it feels and we can decide if we want to keep it in.

Wheel wasn't a problem, just growing the scale of it looks surprisingly good. Almost like we planned it that way.

Edit: I definitely think we should leave the wheel change in, it really works I think. The bar maybe isn't worth the trouble, but I don't mind hiding the option away behind the advanced settings and letting it exist out there. It's just complicated more than the wheel because the runtime of the bar isn't constant. We need information from the BarDecisionHelper to decide how the pulsing should behave, but we also need to update the dimensions in BarInfo since that's where everything else flows from.

I'm sure it is possible to work though but I thought I'd pause with "mostly working" and see what you thought. It's a cool effect for sure but perhaps a bit of a gimmick. I like it but don't love it. For me, I think I'd only want to use the color -- the size changes overlap with other UI elements I have placed right next to the castbar.

[aspiringnobody]

Edit: I reworked the bar so that it's less janky now, and cleaned up the options somewhat. I also added in the options for the slidecast, since, why not. If you have the slidecast color flash enabled the bar will change to the slidecast color. If everyone is good with where this is I'll open a pull request and we can start reviewing the changes.

I stacked the triangles, seemed to make more sense in a world where we are going to allow turning them on and off independently.

@CaiClone could you update the video to see if that still works for @blwbrk ? And I suppose maybe include the changes to the bar and/or wheel as well. If everything is good with the stacked triangles I'll finish up making the bar not do stupid things on non-ability casts.

[CaiClone]

Sure! Attaching here how it looks with everything turned on as in these settings:

https://github.com/user-attachments/assets/3d5baf4b-f1c6-4e61-9eef-91a5ac109e55

Code wise, we can discuss it further in the PR, but I think we should start moving towards creating a generic "Alert" type that can be triggered by any event SlideCastReached/QueueLockReached/Clipped/abc and can be represented by a Pulse/Window/Alert.

I think the long term goal would be something like these options (maybe finding a cleaner way to handle Wheel/Bar split)

[aspiringnobody]

Code wise, we can discuss it further in the PR, but I think we should start moving towards creating a generic "Alert" type that can be triggered by any event SlideCastReached/QueueLockReached/Clipped/abc and can be represented by a Pulse/Window/Alert.

I think the long term goal would be something like these options (maybe finding a cleaner way to handle Wheel/Bar split)

Yeah, that's a good idea. We will have to sort out some kind of migration strategy. I think that really fleshes out the customization options. I had a thought today but I haven't tested it, which was to make the bar/wheel shake if an alert was triggered. I'm not sure if it would be too distracting or not. I didn't want to add any (additional) config options though so I didn't bother.

Anyway, if we all like the three options we've got now I'll open a PR and we can work out any bugs.

[blwbrk]

Sure! Attaching here how it looks with everything turned on as in these settings:

all_on.mp4

Code wise, we can discuss it further in the PR, but I think we should start moving towards creating a generic "Alert" type that can be triggered by any event SlideCastReached/QueueLockReached/Clipped/abc and can be represented by a Pulse/Window/Alert.

I think the long term goal would be something like these options (maybe finding a cleaner way to handle Wheel/Bar split)

Good job! Thank you both!

[CaiClone]

@blwbrk With the merge of #23 (Thanks @aspiringnobody!) and the release v1.0.4.2 which has just released these options have been implemented as a preview feature, and you can see them on the settings under advanced -> Preview Features. Feel free to try them out and report any issues/feedback here! I'll keep this open for a couple of days.

[blwbrk]

@CaiClone @aspiringnobody Thanks to both of you. much of the function works for me, except for some little issues:

First, for the floating triangles, could it hide when the gcd bar disappeared? and there is no need for the red color stage if they are treated as a notification.

Second, Could there be an option for the pulse color?

[aspiringnobody]

@blwbrk @CaiClone

I'm on Vacation so I only had like 20 minutes to work on this. I tested that it works, in that I logged in and fought a single mob to test. Should be scrutinized. I was playing on NA servers from the UK so the latency was terrible.

https://github.com/CaiClone/GCDTracker/pull/24

[CaiClone]

@aspiringnobody Thanks! PR was good, I changed a couple of things directly because I didn't want to bother your vacatiion but everything was working well.

@blwbrk Updated with the new options, an update should appear shortly that adds them. Thanks for the feedback will keep it in mind and consolidate it into a better option menu, probably with a selector of I only want to see triangles when (green, red, always), allowing you to chose slideLock color and I was also thinking about just showing the triangles when in combat.

[aspiringnobody]

For now, the triangles use the bar settings for show in combat and the like. So it will appear whenever the bar appears. We will need to break this out to have its own settings for people who only use the wheel eventually.

I figured we would do that when we integrate it into the alert system.

I wasn’t sure if I should add the slidecast color or not; it seemed the most natural to use the same color as the slidecast itself. I didn’t want to have like a checkbox to “use slidecast bar color” and a color chooser pop up when you don’t have the checkbox ticked. It just seemed like a bunch of extra complexity when 90% of people will leave it at the same color as the slide lock.

Maybe a checkbox to optionally use whatever color is selected for the queue lock instead of the slidecast color is enough?

P.S. I agree with the Vector3. I meant to do that anyway but forgot to go back and change it. Since the Alpha comes from the bar color it would be confusing to have the alpha not do anything for the pulse setting. Good catch.