showeq.xml Question

[fransick]

Seeing inconsistent behavior with the terminal MessageTypeFilter defaults and am wondering if my 20 year old showeq.xml preferences are out of whack. Each time I start ShowEQ the terminal MessageTypeFilters have different channels turned on and off and saving prefs doesn't change anything. Relevant xml:

<section name="Terminal">
<property name="EnabledTypes">
<uint64 value="7fe8f09dfd68"/>
</property>
</section>
Not sure what to make of that value or how to interpret it. Anyone have thoughts on what may be happening here?

[cn187]

I want to say that value is a bitmask of the message types. 0th bit is on/off for message type 0, 1st bit is on/off for message type 1, etc. The message types are in message.h, I think.

I've seen some random issues with preferences not saving correctly. I haven't been able to track it down yet, though.

[xerxes]

I've been having this same issue, with them flapping between all off and random ones turned on. Been driving me nuts. Saving changes doesn't appear to work.

[fransick]

Finally got around to investigating this issue. As best I can tell, changing Interface|Terminal|MessageTypeFilter settings and then Saving Preferences does not change the uint64 value in showeq.xml. I tried all unclicked, all clicked, only guild clicked, and then random channels clicked while Saving Preferences each time and checking the showeq.xml file and the uint64 value never changed. Also, if a channel doesn't have a numeric value in message.h will that create a problem when setting the bitmask value in .xml? Sorry more questions than answers at this point.

[cn187]

Thanks for doing further testing. I had kind of forgotten about this, so thanks for bringing it back up. I'll dig into it as soon as I'm done with the thing I'm currently working on.

The type not having a numeric value is fine. The way enums work in C and C++ is that if they have a number assigned, that's their number, but if they don't then it increments by 1 for each item.

There are holes in the sequence (no 1, 6, 9, 10, 12, 13) so the early items have to have the numbers specified in order to skip the holes, but after that, they increment normally without specifying anything. So MT_Debug is 16, MT_Info is 17, etc.



enum MessageType
{
MT_Guild = 0,
MT_Group = 2,
MT_Shout = 3,
MT_Auction = 4,
MT_OOC = 5,
MT_Tell = 7,
MT_Say = 8,
MT_GMSay = 11,
MT_GMTell = 14,
MT_Raid = 15,
MT_Debug,
MT_Info,
MT_Warning,
MT_General,
MT_Motd,
MT_System,
...

[cn187]

OK, so this looks like collateral damage from the Qt3 -> Qt4 update.

There was a bunch of complicated stuff to ensure Qt2 and Qt3 compatibility, which I've now ripped out and replaced with simpler stuff that works in Qt4, Qt5, and likely Qt6.

I've done several rounds of testing and it seems fine, but if you want to apply it and test it, that would be swell. You'll want to use "-p1" instead of "-p0" when you apply the patch.

I've applied this patch to the cn187_devel branch, but will wait to apply it to trunk until it's been tested some more. (Side note: cn187_devel has all the 6.3 stuff too, so if you'd rather just pull from there instead of applying the patch, that will work as well)

[fransick]

Patch looks pretty good so far. It saves terminal MessageFilterType much better than before. If I enable all it will mostly save that but for some reason drops the last 4 channels as being selected when I restart. Danger, Caution, Hunt & Locate will not keep their checkmarks.

[cn187]

OK, I think I know what's happening with that, I just have to track down where/why and what to do about it. It's progress, at least...

[cn187]

OK, I guess I'll blame inadequate coffee intake today ;-)

Anyway, apply this patch on top of the previous one, and you should be good-to-go.