It's currently not showing Ulduar lockouts. Any chance of updating for that? Thank you!

Confirmed this issue has been solved with v1.3.2. Closing issue thread.

There seems two other issues have arisen from this v1.3.2. I've opened up two other issue threads instead for dealing with them specifically; #35 and #36.

Thanks for reporting this @JacobMa778290 🙏🏻

I'm not sure why it wouldn't show, since other Wotlk raids are working. But if you are not seeing it, then clearly something is weird with Ulduar.

A likely culprit could be the InstanceID of "603" being used for Ulduar either not being the correct one or not working as other Raids in the expansion does.

I'm unfortunately very limited with how much I can test this and find the cause since I don't have access to the game. If someone else is willing to work on the fix, or just do some testing in-game and report back I would very much appreciate it.

To find a solution let's see if we can get some thing tested and verified in-game first.

Things to verify:

• Is Ulduar not showing up as being locked in the addon for anyone else using the addon? In other words; is everyone having this issue?
• Is Ulduar showing up as locked in the games default Raid lockout window? What is the raid called there? (name or screenshot would be very helpful).
• Is the addon throwing any Lua errors? You can enable seeing this with /console scriptErrors 1 (and disable again with /console scriptErrors 0)
• What is the InstanceID reported as in-game while inside the raid? Is it 603 or something else? You should be able to see this by pasting this into chat: /script print(GetInstanceInfo())

Well, I had no idea how lua behave if number of arguments differ, I'm just a humble Java dev 😄

I'll test it out later on today and let you know if it works.

No, the problem isn't in the points you mention. The id is still 603. I have a feeling that it has something to do with GetSavedInstanceInfo

According to documentation, it should return a set of 13 fields, but currently, it returns 14, example bellow:

Very nicely spotted @sbombic! Thanks for assisting with this 🙌🏻

It looks like Blizz have added the InstanceID as a 14th field to the return values of GetSavedInstanceInfo, but the first 13 fields still seem to match the documented API. This is actually a very good addition to the API that I wished was there when I first wrote this addon. If this is true for all instances, then some improvements to this addon could be made based on this.

Anyhow- I could be wrong, but I don't think this change to GetSavedInstanceInfo would cause issues. In the addon code we are only ever accessing name, reset, difficulty, numEncounters and encounterProgress (1st, 3rd, 4th, 11th, 12th fields). So unless Blizz have changed the numeric order of the now 14 fields, which as far as I can tell from your image does not seem like they have, I don't think the addition of the 14th field would cause any issues since we are not trying to access it.

I think I have spotted the issue based on your screenshot @sbombic .

The difficulty (field 4) is reported as "175". This is the "difficulty ID" which can be used together with GetDifficultyInfo to get more information about the difficulty.

However right now in the code we are asserting that the "difficulty ID" value should be either 3 or 4 for 10-man or 25-man difficulty, which is not correct in this case.

local name, _, reset, difficulty, _, _, _, _, _, _, numEncounters, encounterProgress, _ = GetSavedInstanceInfo(savedIndex)

if difficulty == 3 then
    name = name .. " 10"
end
if difficulty == 4 then
    name = name .. " 25"
end

Since it does not match either of these cases for Ulduar it does not get added to text for the Titan Panel bar. But it might for other raids and heroics.

A better solution for this would probably be to simply use maxPlayers value instead for WotLK raids, since it will always be either 10 or 25.

I can probably look at making a hotfix and publish a beta for testing later today to see if this fixes the issue.

I've uploaded a new version 1.3.2 Beta to CurseForge, can also be downloaded here on Github.

Hopefully this should fix this issue. Thankful if someone can test and give feedback on this.

Thanks @sbombic, great to know that this was indeed the issue and it seems to be working 👍🏻

Yeah I noticed that @margathon did a fix as well with PR #34. I have merged this into master and created a new release version here on Github. However I'm not able to log into CurseForge right now (issues with their website?). So I'll check on doing a proper release of this on CurseForge tomorrow evening instead.

I'll keep this thread open for a bit until after release.

Seems to be working, 10 men lockout shows correctly

Oh, you have pulled PR by @margathon , I was about to ask since his approach seemed to be cleaner.