I’ve been trying to find the code that sets the komi to 5.5 for 9x9 boards but can’t find it. Closest I can find is fillDefaults() in GoEngine.ts, but that seems to be for 19x19. Anyone able to point me to the appropriate source file? Thanks!
If your reason for looking for this specific line of code is so that you can submit a request to change it to “the value that is obviously better (according to you)” then this will 100% require substantial community discussion and agreement (good luck with that) before any change to the default komi would be accepted.
Yes. New Zealand and Ing rules allow for ties on 19x19 with whole number komies. Therefore, for 9x9 it seems reasonable for it to be 5 instead of 5.5 when using those two rulesets. I hoped to make and test the code change, then submit it for discussion and review.
3 Likes
I agree with you that those rulesets should permit draws on 9x9 as in 19x19. On the other hand, I disagree that komi should be 5. There is broad agreement that komi for a 9x9 board scored by area should be 7, which is also the standard on GoQuest and CGOS.
1 Like
^ thus the substantial need for discussion and the high unlikelihood that the community will agree on anything 
2 Likes
I generally favour integer komi (with the possibility of draws) but anyone looking to implement it needs to consider how it would apply to elimination tournaments.
1 Like
I can make that code change, too. Once someone shows me the code file I’ll be happy to tinker with it and submit for review and discussion.
1 Like
Rules business logic is server-side code, which is not open source (AFAIK).
When I got the source code it created a server for me on port 8080. Seems like an open source server. But if there’s another layer behind that (presumably APIs) that’s closed then that makes me sad. There are also a couple bugs in the tournaments I hoped to look at: double-elimination doesn’t work in the last round and players can get several byes in a row. But that’s probably also server side. OGS should make it all open source so people can contribute fixes.
2 Likes
anoek isn’t explicitly against opening up the back-end code to be open source one day, but as it currently stands, the code is a complete shambles haha and so he doesn’t want anyone other than matt and himself digging through it, as explaining the code to others would be more work than fixing whatever issue has come up himself.
Tidying it up to the point where it could be publicly released is one of the items on his rather long list of “todo’s” 
1 Like
The client is open source.
The server is not. Whether the advantages of open sourcing this outweigh the disadvantages for either the owner or the community is another non-obvious discussion. IMO the last thing we need is a fork of OGS server.
The “server” that you see created on 8080 is a react development server that serves to you your client code that you are working on to your browser - that’s a development tool only.
2 Likes
I don’t think someone forking the server (should the entire code be released) would be a major concern. Ultimately, the server is not defined by its code, but rather its community. The staying power of OGS is as much about the playerbase as the code.
I think there might be some unwarranted fears about making the full code open source. However, consider Lichess for example. A full open-source model seems to have worked very well for them.
5 Likes
Yeah - I didn’t mean to say (though it reads as if I said) “We should not do this due to the risk of a fork”.
I meant “a fork would be bad, and that is one consideration, just as an example of why this isn’t an easy thing to decide”.
Bhydden’s point is more immediate and concrete: anoek has said that he can’t support other developers in the server codebase at the moment - not even “special access”, let alone fully open source, due to the complexity and legacy nature of it.
This is something the community would surely want to see on the roadmap to be rectified, since right now our precious server and community is in the fate of one person’s hands… but would we like features or futureproofing? 
2 Likes
well… two… matburt might be busy, but he’s still an OGS partner with backend server access 
I vote for futureproofing. Making it possible for other people to add features is worth it. A short-term delay in new features is a good investment for more features and quicker deployment in the long-term (plus more resiliency in the project from having more people on board).
Such a choice also seems to be a false dilemma. One can modulate efforts between working on new features now and working toward readying the code for release.
Can I just say “God bless” for trying to fix automatic komi for 9 x 9 and 13 x 13 NZ games? Not being able to play ranked small board games with integer komi is by far my biggest issue with OGS. <3
And yeah, from my online research, it seems reasonable to set integer komi for all three ranked board sizes to 7.
3 Likes
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.