Settings are browser-specific. I can use OGS with some settings on Firefox, and other settings on Edge, etc.
OGS allows analysis in live games too (if you tick âEnable Analysisâ), though I and much of the Go world outside OGS thinks analysis in live games should never happen and is cheating, whereas in correspondence it is part of the standard culture. So I strongly think OGS should be analysis off in live always, no option to enable it. I definitely think analysis should be on by default in correspondence, and think it would be fine to ditch the option to disable analysis in correspondence so itâs always on (thus ditch the checkbox and simplify OGS) which is your preference.
I suspect a lot of people answering here were thinking of live games, which coupled with your argumentative and entitled tone led to a less positive reception.
Nah. If you agree to certain settings, play according to those settings. Itâs a simple contract of mutual honesty over a (digital) board and a few dozen stones.
If you donât, youâre either outright cheating or at the very least your honesty and manners are lacking.
You donât need to take the challenge of the player who has analysis off; you can take any other. If you want to take that specifically and bend it to your preference, thereâs a character flaw that should be worked on.
Anyone can coat it how they want, but it is what it is.
No, I think it purely depends on the game settings. Regardless of time settings, the players should adhere to those settings, and not circumvent disabled analysis by using an external SGF editor.
A few players turn analysis off in correspondence games because they prefer to practice reading in their head.
Sure, if thereâs enough demand for that then I think analysis off in live, choosable in settings for correspondence (default on, so on for title tournaments / ladders) is also fine. But even if thereâs demand for analysis on in live, I think it shouldnât be possible.
Iâm sorry, I wonder if weâre having a language problem here? I have no idea what that paragraph says.
OGS definitely does save your theme settings. It saves them in local browser storage on your device, so that you can have different settings on different devices. It reloads them each time you log in.
For example, when I log out and log in again, I still see the âaccessibleâ theme (blue and orange on profile page) and I still have my choice of stone images.
If your browser is losing your settings and you have to set them manually each time you log in, we can maybe help you solve this problem, if you can describe your situation in more detail - itâs a problem on your side.
This works for everyone else, as far as I know.
We need to know what device, what browser, can we have a screenshot of the browser console⌠etc.
This time, itâs not an avique issue:
Unlike a text file, local browser storage is not something that can be easily
copied between devices. â (One could brute-force this with a system image,
and there almost-certainly is some easier way, but I at least have no clue
what file I would go to to try copying from my browserâs local storage.)
Where did âcopy between devicesâ come into it though?
I thought we were talking about âis my theme savedâ?
Actually, it does. Simple as that.
unless I could have this as a file (possibly as simple as a text file like /etc/xpdf/xpdfrc,
which can be edited with a simple text editor, if one wants, and copied as wished too)
Oh right, so after wrongly asserting that they are not saved, we went on to demanding that they be exported in a text editor friendly format I think I was hearing âblah blah blahâ at that point
Perhaps you can play with this?
I donât see file-exported settings being something that OGS should prioritizeâŚ
prioritize, probably fair. But have somewhere on the ânice to have, if someone gets around to itâ list? yeah, I think it would warrant a place there. Not necessary, I donât mind going through settings and getting everything as I like it on a new device (I appreciate the flexibility per-device preferences offer), but could be a nice QoL feature to be able to import/export them to/from json (or whatever text format, Iâm just assuming json would make the most sense here, I could be wrong)
You donât even need any OGS code changes to export localStorage to a string and save it in a file, and then import it somewhere else. Anyone with the necessary js skills can do this in the developer console of their browser right now.
That makes sense; I got the impression from this thread that it wasnât accessible from the browser, but I guess I misunderstood. Obviously once you have the json, it would be trivial for one to hack together some Python to strip out everything except the OGS stuff
⌠you wouldnât even have to strip: the browser knows which local storage is for what application.
However, unless youâre doing this purely âto see if it can be doneâ, dumping local storage is just the wrong way.
Itâs a useful observation to note that it can be done, to establish that OGS does save the settings, but if users really need save-edit-restore or transfer-to-another-device, then that should be a feature not a hack.
You might get lucky editting a local storage value outside the application, but you might not as well. And heaven help us with the bugs this would introduce. âHey, what is that value doing there??â
⌠hours later âWhy, you SOB ⌠you edited itâ⌠no wonder it doesnât work.
localStorage.setItem('ogs.my-stones-have-5-liberties', true)
Itâs this part that I find really questionable. Most users have some persistent browser that theyâre accessing.
Mmmm ⌠now let me see, how can I sign these settings?
Thatâs why this whole discussion started with âthe problem is in your environment, not OGSâ.
We never really learned what the actual problem was anyhow, it all became a hypothetical âwhat if I want to do xxxxâŚâ