Skip to content

Prevent addon from displacing base channel set#92

Open
tekHudson wants to merge 1 commit intoiraizo:masterfrom
tekHudson:add-reserved-channels-count
Open

Prevent addon from displacing base channel set#92
tekHudson wants to merge 1 commit intoiraizo:masterfrom
tekHudson:add-reserved-channels-count

Conversation

@tekHudson
Copy link

@tekHudson tekHudson commented Feb 2, 2026

I have the addon continually displacing the base channels (1-General, 2-trade, etc) this ensure it it starts at 8 so the base channels are never displaced

@tekHudson
Copy link
Author

Fixes #94

@Jungleonly1740
Copy link
Contributor

Hey, thanks for working on this, too! The idea of reserving channel slots to avoid conflicts with other addons/channels makes sense.

However, I think there's an issue with your current implementation that would prevent the addon from working for most players:

The Problem

In JoinLayerChannel(), if the first open channel slot is <= 7 (as you are setting local RESERVED_CHANNEL_SLOTS = 7), the function returns early:

local firstOpenSlot = GetFirstOpenChannelSlot()
if firstOpenSlot <= RESERVED_CHANNEL_SLOTS then
    AutoLayer:DebugPrint(
        "Open chat slot " .. firstOpenSlot .. " is reserved (1-4). Delaying layer channel join."
    )
    return
end

The debug message says "Delaying", but there's no actual delay mechanism - it just aborts(returns).
For players who have fewer than 7 channels joined on their clients (which is probably the majority), this condition will always be true, and the layer channels will never be created. This would do more harm than good for most players.

Even if we added a retry mechanism, there's a deeper issue, WoW assigns channels to slots sequentially.

If slot 4 is the first free slot, JoinChannelByName("layer") will put it in slot 4 - which is in the "reserved" range. Then the code leaves the channel again because its in the "reserved" range, and the next attempt does the same thing. This would create an endless loop and never create our channels - so the addon would fail to function for those players unless they joined additional channels as "dummy" channels.

There also seem to be some syntax errors - missing end statements in the JoinLayerChannel() function around lines 641-656. At least my lua debugger is throwing lots of errors in that range. The nested if statements don't have matching closing end keywords.

While thinking about this problem and iterating ideas, I figured there might be a much easier approach that would work for all players without messing with their channel setup whatsoever - simply by adding real delay logic before the addon tries to join its channels simply because the game will have time to join the default channels like general, trade etc and our channels will naturally just add behind them. This will not prevent it from taking channels that other addons usually populate in your interface that might do the same and simply add a delay but i dont think this is of great importance?

I made PR #95 to reflect that, it's just a tiny bit of code that might just do the trick.

it will wait until there are at least 2 chat channels joined, if there are 2 joined channels it will join the addon channels, if thats not the case it will retry that 2 times and then fallback to just joining the channels anyway (which makes it a delay of 6 seconds in total if the condition is not satisified)

Opinions?

@iraizo iraizo added the triage This issue needs to be verified label Feb 8, 2026
@jdorsman
Copy link
Collaborator

Similar to my comment in #95, this is making the assumption that people always want the layer channels to be the last ones in the channel list. But what if someone deliberately re-ordered it? Say 1 = General, 2 = layer, 3 = Trade?

We can't really know for sure what the player's preference is. I think whatever approach we take, automatic re-ordering should be a toggle-able configuration that is disabled by default as to not mess up people's custom ordering.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

triage This issue needs to be verified

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants