Auto-hiding bugs.

[wizen]

Two small, minor things.

First, the EQBuddy app does not remember window hiding preferences between installs. I have to re-check the box every update.

Second, the quest tracker does not hide when the main window does.

Thank you for your ongoing work!

---

EQBuddy 1.88.3 · Windows 19045

[DranakCorps-bot]

Two separate things, and they have quite different answers.

The quest tracker not hiding with the main window — that's a straightforward bug and you're right to expect it to. Auto-hide takes the widget and its chip windows; the Quest Tracker was never wired into that set. It should be. Noted as a defect, not a request.

The settings not surviving an update is the more interesting one, and I don't think the installer is the culprit. I checked: it never touches settings.json. What I believe is happening instead:

EQBuddy saves settings by writing the whole file from the snapshot it loaded at startup. That's fine with one copy running. With two copies running it isn't — the second one to save reverts the first one's changes wholesale, silently, with nothing on screen to say so. And during an update you can very easily end up with two briefly: the old copy still running while the new one starts.

That would present exactly as you describe — you tick the box, it's ticked, and after the next update it isn't.

What would confirm it: after your next update, open %APPDATA%\EQBuddy\error.log and look for a line about overwriting settings that changed underneath. 1.88.4 logs that case specifically, precisely because it used to be invisible. If it's there, we know.

Meanwhile, a workaround that costs nothing: fully exit EQBuddy (tray icon → Exit, not just closing the window) before running an installer. If the setting sticks when you do that and doesn't when you don't, that's the same confirmation.

Thanks for reporting both — the second one has been suspected for a while and never had a reproducer attached to it.

[wizen]

No mention of the setting, oddly.

[2026-08-10 20:59:28] Watch breakout hidden via its ✕ (re-enable: Options → Breakout windows)

[2026-08-10 21:06:26] Damage breakout hidden via its ✕ (re-enable: Options → Breakout windows)

[2026-08-12 09:24:43] Damage breakout hidden via its ✕ (re-enable: Options → Breakout windows)

[2026-08-12 17:27:13] Watch breakout hidden via its ✕ (re-enable: Options → Breakout windows)

[2026-08-15 11:08:15] Log archived → C:\EQLegends\Logs\archive\eqlog_NAME_SERVER_20260815100528.txt

[2026-08-15 20:45:18] Log archived → C:\EQLegends\Logs\archive\eqlog_NAME_SERVER_20260815204518.txt

[2026-08-16 09:54:48] Log archived → C:\EQLegends\Logs\archive\eqlog_NAME_SERVER_20260816084459.txt

[2026-08-16 20:25:53] Log archived → C:\EQLegends\Logs\archive\eqlog_NAME_SERVER_20260816202553.txt

[2026-08-17 01:35:28] Log archived → C:\EQLegends\Logs\archive\eqlog_NAME_SERVER_20260817002736.txt

[2026-08-17 10:28:28] Log archived → C:\EQLegends\Logs\archive\eqlog_NAME_SERVER_20260817092135.txt

[2026-08-17 12:10:03] Log archived → C:\EQLegends\Logs\archive\eqlog_NAME_SERVER_20260817121003.txt

[2026-08-17 18:18:48] Log archived → C:\EQLegends\Logs\archive\eqlog_NAME_SERVER_20260817171116.txt

[2026-08-17 20:38:52] Log archived → C:\EQLegends\Logs\archive\eqlog_NAME_SERVER_20260817193257.txt

[DranakCorps-bot]

The quest tracker one is fixed in v1.91.0. The settings one is still open, and your error.log is why.

Auto-hide. You were right that it should follow, and the reason it didn't is worse than a missed window: the hide took the widget and the surfaces that redraw on the widget's own tick — the chips, the breakouts — and nothing had ever considered a window you open from a menu. The Quest Tracker wasn't forgotten so much as never in scope.

So the fix is deliberately not a list of windows that follow. It is a list of the few that don't — the chip stacks and the breakouts, which are already driven by that same flag and would fight a second hand on the switch. Everything else follows by default: the map, the spawn tracker, drops, gear, history, item info, and the quest tracker you reported. A window added in a future version follows without anyone having to remember, which is the actual defect here — an allow-list would have stranded the next one exactly the same way.

They come back together too, and only the ones the hide took: a window you closed while alt-tabbed stays closed.

The settings across updates — your error.log rules out my theory, and that is useful.

I said to look for a line about overwriting settings that changed underneath. You checked and there is no mention of it, only breakout dismissals and log archiving. That is a real answer, not a null result: the two-copies-racing explanation is now unlikely, because 1.88.4 logs that case specifically and it never fired.

Which leaves something else, and I would rather find it than guess again. When it next happens — you tick the box, and after an update it's unticked — the useful thing is the timing:

• Does the setting survive a normal exit and restart of EQBuddy, without any update involved? That separates "saving is broken" from "updating loses it".
• Is it only that one tick-box, or do other Options changes go too?

If it survives a plain restart and only dies across an update, that narrows it to something the installer or the first run of the new build does, and I'll go looking there instead.

Thanks for checking the log — a clean log is evidence, and it moved this on.

[wizen]

I'll check it out next update. Last update I got prior to 1.92.0 removed all tabs from the setting screen. 1.92.0 has it back, I'll check the boxes and begin the arduous task of waiting for an update.