• Wow Version: Retail
• Prat Version: Prat-3.0-3.9.3-26-gae689cd.zip

"Frames" settings page is back with recent version however 2 options inside does not work as intended:
"Set Chatframe Alpha" seem to be stuck on value 1 in the code, value 0 should "stop" frame from reacting to mouse by being completely invisible.
"Zero Clamp Size" does not work on a reload for the General/default chat frame. My 2nd chat window i myself created remembers to stay flush with edge of screen while default chat frame gets knocked up away from the edge of screen.

Image shows "Set Chatframe Alpha" set to 0 but behaves like value 1:

Thank you all for keeping Prat alive and well!

The clamping issue should have been fixed in the newest alpha (which you have installed). Can you screenshot your chat before and after the glitch?

So the way chat alpha works is, when you interact with it, it'll make it "less alpha" and slowly fade towards the alpha you have set. I can look further into why it's doing that :)

-version: Prat-3.0-3.9.4.zip
No changes to my issues.
@QartemisT Yeh i figured if you had it at 0 it wouldn't switch the alpha at all. I'll hold on for a few days and see what you guys come up with before i try a variable reset. After all with system changes a complete settings wipe has worked out a few times.

Chatframe alpha issue should be fixed as of e8562af

-version: Prat-3.0-3.9.3-28-gde0e740.zip
This is after a relog/reload. Chatframe alpha still not working or is it intended to react a little bit? Left chat moused over, right one not.
I currently "fix" the clamp issue by using Leatrix Plus option "Unclamp chat frame" so i believe the Clamp setting in Prat bugs out but super weird it only happen to General/default chat frame after relog/reload.
In 2nd picture i temporarily for that session fix it this way not using LTP unclamp feature: Edit mode -> select the problem chat frame -> Reset to default position -> revert position, magically puts the frame flush where it is supposed to be. Im back to square one after a reload unless i use LTP though.

Version 3.9.4 - setting the chat frame alpha to 0% works, but gets reset after a reloadui/relog.
Note I only use 0% background for chat frames 2 and 3, while main chat frame is at 25%, if this has any value.

I am also having the frame clamp issue. Whenever I enter edit mode and try to move the frame I get this blizzard error

I'm also experiencing most of these bugs. While the 'Zero Clamp Size' feature seems to be working, the 'Remember Position' is not, Position from the very left bottom resets on every reload / relog to the Blizzard's original position (without the zero clamp).
Actually I spent great amount of times to find these settings in Prat, and I really don't understand why did you separate Zero Clamp and Remember positioning -- and on top of this why is remembering position is OFF by default. - Only people who want to use editbox on top will interested in this feature and we want chat window to reach the bottom permanently anyway. I think you could merge these 2 options without any complaints.

I tried it in Edit Mode with Snap on and Snap off. It resets either way.

Another strange thing is when I set the chatframe Alpha through General tab's right click menu -> Background -> Color Picker it resets on reload too but if I set in Prat/Frames option panel to say 0.8 it's ok and it keeps it throughout reloads/relogs as intended.

I use the version Prat-3.0-3.9.4 btw.

@Voxxel thanks for mentioning that background alpha can be set from the Prat options, I forgot. So this seems to be the issue! Whatever you set in Prat settings is remembered after reload, ignoring whatever the user set from chat's tab > background > color picker. Sadly, the Prat settings only allows for one alpha setting for all frames, while Blizz way allows for setting different alpha values for each chat frame. In my case I only want 25% alpha on chat frame 1 (main) while on the loot and trade windows I want no background at all (background set at 0% alpha).

Yea, I think the main issue here is the clamping. I just found out if I move my chat in Edit Mode to the bottom, using Prat's Clamp option the game often saves the chat position but only if I switch to another character. However, if I just reload the game or relog into the same character it resets back. Very strange.

Adding a

ShowUIPanel(EditModeManagerFrame)
HideUIPanel(EditModeManagerFrame)

to the loading process gets the frame put in the right place, but can cause an extra 0.3s loading time

but can cause an extra 0.3s loading time

Well, the Intel 486 times are over.

Pushed a new solution to Curseforge though that doesn't have that issue 😄

Prat-3.0-3.9.4-3-g1c4b940.zip

Prat-3.0-3.9.4-3-g1c4b940.zip

"This version is archived by the author." - the CF app says this. is this normal?

You can just install the latest alpha from CF to get rid of the message.

-version: Prat-3.0-3.9.4-4-g7ae8931.zip
Can confirm "Zero Clamp Size" is fixed.
"Set Chatframe Alpha" no changes. (chat frame still reacts to mouse over. Chat tab set to 0 alpha, prat set to 0 alpha.

The new alpha fix doesn't maintain the old behaviour on either classic or retail - the chat will get darker on hover.

Adding

DEFAULT_CHATFRAME_ALPHA = prof.framealpha

Will fix the issue, but will also cause this taint error when opening edit mode (because the Blizzard functions use the DEFAULT_CHATFRAME_ALPHA value when doing their stuff):

or this

Unfortunately even the fix recently done causes a taint error.

I suspect we'll need to rewrite the frames code to set the alpha directly and avoid passing values through Blizzard functions that interact somewhat with edit mode.

Programmers doing Slalom around literal mines in the code, i like! :D

Prat-3.0-3.9.4-5-gf061889
Can confirm that the background alpha for individual chat frames (set through the Blizz UI) is now persisting through reload/relog.

So just to confirm @Daeveren @Crusherix, the latest build both "background alpha" and "zero clamp size" is fixed?

So just to confirm @Daeveren @Crusherix, the latest build both "background alpha" and "zero clamp size" is fixed?

I can confirm that the background alpha set via right click on the chat header > background > color picker no longer resets at reload/login, it correctly persists through sessions now.

So just to confirm @Daeveren @Crusherix, the latest build both "background alpha" and "zero clamp size" is fixed?

-version: Prat-3.0-3.9.4-5-gf061889.zip
My issue isn't the same as Daeverens although for testing purpose i tried setting a value of 1(max) which should make the chat total black when mousing over but after a reload it does not do that.
My issue is that the chat reacts at all when alpha is set to 0 as in it still gets a little vague tint letting you know you moused it over which i do not want and am pretty sure wasnt there before pre-patch. Looking into it further i came across a post about "remove chat hover delay" that was a blizzard interface setting a few years back, not sure that is the same thing as the Prat setting.

Spent some time on the problem, remaking the textures and changing their opacity works, but is messy. Its sufficiently awkward it would likely be a time sink in the future too, so not sure as to whether its worthwhile to try to get a fully working version.

diff --git a/modules/ChatFrames.lua b/modules/ChatFrames.lua
index 2a4af0b..9f4255e 100644
--- a/modules/ChatFrames.lua
+++ b/modules/ChatFrames.lua
@@ -284,6 +284,36 @@ end
     end
   end

+  local FramesReplaced = {}
+  function mod:RecreateBackgroundTextures(frame)
+    if FramesReplaced[frame] then
+      return
+    end
+    local _, _, r, g, b, a = FCF_GetChatWindowInfo(frame:GetID())
+    FramesReplaced[frame] = true
+    for _, name in ipairs(CHAT_FRAME_TEXTURES) do
+      local texture = _G[frame:GetName() .. name]
+      local layer, sublevel = texture:GetDrawLayer()
+      local newTexture = frame:CreateTexture("CF" .. frame:GetName() .. " " .. name, layer, nil, sublevel)
+      for i = 1, texture:GetNumPoints() do
+        newTexture:SetPoint(texture:GetPoint(i))
+      end
+      newTexture:SetTexture(texture:GetTexture())
+      newTexture:SetTexCoord(texture:GetTexCoord())
+      newTexture:SetSize(texture:GetSize())
+      local texture = texture:GetObjectType();
+      if ( texture == "Button" ) then
+        texture:GetNormalTexture():SetVertexColor(r, g, b);
+        texture:GetHighlightTexture():SetVertexColor(r, g, b);
+        texture:GetPushedTexture():SetVertexColor(r, g, b);
+      else
+        newTexture:SetVertexColor(r, g, b)
+      end
+      newTexture:SetAlpha(self.db.profile.framealpha)
+      texture:Hide()
+    end
+  end
+
   -- get the defaults for chat frame1 max/min width/height for use when disabling the module
   function mod:GetDefaults()
     local cf = _G["ChatFrame1"]
@@ -308,11 +338,11 @@ end
   -- set the max/min width/height for a chatframe
   function mod:SetParameters(cf, enabled)
     local prof = self.db.profile
-    if prof.framealpha ~= DEFAULT_CHATFRAME_ALPHA then
-       FCF_SetWindowAlpha(cf, prof.framealpha)
-    end
+
     local minWidth, minHeight, maxWidth, maxHeight
     if enabled then
+      self:RecreateBackgroundTextures(cf)
+
       minWidth, minHeight = prof.minchatwidth, prof.minchatheight
       maxWidth, maxHeight = prof.maxchatwidth, prof.maxchatheight

The chat will now have a constant alpha value when the frames module is enabled, no fading away or fading in.

Mouse over:

Mouse out:

What is the expected behaviour, as it can't both have a fixed alpha value, and a value changeable via the default UI?

Well you do need to have both because either the changes in Prat settings affect only 'chat frame 1' (and then the user controls the other chat frames via Blizz chat tab menu), either Prat settings controls all the chat frames with just 1 value for all the frames (and then the user can't have different background transparencies for different chat frames) - if you ask me, I think neither of these is ok. Alternatively, Prat Frames setting would let the user select different values for each Chat Frame (ideally they'd be also linked to the background alpha value that is changeable from the Blizz chat background setting).

Latest change you did fixed (again) the ability to have individual background values per chat frame (which is fine for me, no need to open a new issue - it's just unfortunate that this feature stopped working with various alpha versions). Except that the thing I notice now is that the alpha values now from Prat and from chat tab UI work additive so to say - as in, after last alpha version, setting chat UI to "100% alpha" + Prat to 50% makes the chat background actually reach 50% background; setting both of them to 50% results in actual 25% background; setting Blizz alpha to 0% and Prat to 50% result in actual full transparency (0% alpha); in order to have a black background now the user has to set both of them at 100% (setting Prat to 100% does not make background black unless the chat background setting is also at 100%). These things feel pretty wrong and confusing to the user so at minimum I believe you should add a disclaimer in the Prat > Frames page, informing the user to make sure they check the Blizz alpha value too. This also has the potential to disrupt everyone's UI once they update to the next stable Prat build, because their background transparency value has just changed (ie: mine was 50% for chat frame 1, after updating to latest alpha it was too transparent and it required playing with both alpha values and comparing to my past screenshots in order to set to a similar background value).

I'm fine with any approaches, as long as individual chat frames can have separate background transparency (which worked before and works now too after the fix).

About the post earlier "The chat will now have a constant alpha value when the frames module is enabled, no fading away or fading in." really for the sake of clarity of the users that do not read this github page - I think that the option should be under a "enable/disable darken on mouseover" (or whatever the choosed name) or atleast inform them in some way that Prat has lost the ability to darken the chat frames on mouseover. Having it always 'disabled' might be confusing for some or could also be frustrating to others - think of the ones that have the chat window at full transparency (0% alpha) and that were using the "darken on mouseover" to find their actual chat frame size or to read text that would otherwise be hard to read with fully transparent background.

Whether you think it's best to open a new issue on github or keep this thread, well, it's up to you.

Awesome work, thank you.

The chat will now have a constant alpha value when the frames module is enabled, no fading away or fading in.

This broke being able to set up the background via right click on chat tab > background > color picker and also broke the ability to set a different background alpha version for different chat frames (because this can only be done from the default UI).

Maybe move the changes to a separate module that can be enabled/disabled by the user

What is the expected behaviour, as it can't both have a fixed alpha value, and a value changeable via the default UI?

Would having the combination of the alpha and the default UI set colour/transparency work?

(@Daeveren I've pushed that change to the latest alpha, if it still isn't right open a new issue)