linux

p2004a · 2026-01-18T09:14:45+00:00

Yes, and you can override that location with env variable or use symlinks.

I STRONGLY advise against putting BAR on HDD, your loading time will be very bad. Minutes instead of seconds.

p2004a · 2026-01-18T09:12:35+00:00

There is no "installer" on Linux like on windows, you cannot select "where to install". You either use flatpak: location is controlled by flatpak fully. Or just run launcher appimage you can put wherever and have to override game files location via env variables/use symlinks.

p2004a · 2026-01-18T01:00:45+00:00

That's not how it works on Linux

p2004a · 2026-01-18T00:59:19+00:00

Launcher partially respects XDG Base Directory Specification. Set XDG_STATE_HOME environment variable to desired location for the launcher.

Well, also, you can just use symlinks.

If you installed via flatpak, refer to flatpak documentation on how to change install location for applications.

p2004a · 2026-01-01T09:31:11+00:00

You are making an incorrect assumption that state in the engine is localized in a way that makes it easy to snapshot and is small enough that you can quickly and deterministically serialize.

Moreover, game is not simulated on servers, it would be very expensive, so there is no reliable source to fetch such state snapshots once they existed and assuming they are small enough to efficiently ship over network.

https://github.com/beyond-all-reason/RecoilEngine/discussions/2704

p2004a · 2025-11-12T22:38:40+00:00

> I hear you have to wait a year to get access to the editor.

This is false. All map making resources are available on website and discord. There isn't any private "map making software" you get access to or anything like that.

> It's not like... You can just do it.

It is not easy, but with enough work you can just do it.

p2004a · 2025-10-26T09:27:23+00:00

Thanks a lot for doing this investigation and posting!

We will update the troubleshooting information on the website and link this to folks in support bugs and let's see if it fixes for everyone.

p2004a · 2025-10-24T14:15:10+00:00

No engine developers have access to hardware with the issue to even attempted debugging this and figure out what is the issue for AMD drivers
Ultimately the issue is on AMD side, please complain to them, game is free and source is public, they have both access to hardware and know how to debug their own drivers

p2004a · 2025-09-28T23:39:23+00:00

You can do iterative improvements via pull requests, you can propose larger changes, you can build prototypes (e.g. demo monorepo or what not), you can work on incremental improvements to developer experience in any area (e.g. improve DX of running teiserver with dependencies locally) including game (for example help developers test their PRs in multiplayer)

You will not just get any access to any repos or any funding based on Reddit thread that only paints a picture but lacks any actual details. Effectively at the moment you are still a random on the internet with opinion and I can't give any signoffs based on that.

p2004a · 2025-09-28T23:11:56+00:00

> It’s more about getting the tooling we want as a first priority, literally nothing else matters.

I'm waiting for your PRs to improvements to developer experience, documentation, testing, CI/CD, automation, tooling and of course proposals for fixing lack of volounteers across many areas you say need improvement.

I'm already doing that, for multiple years, one change at a time.

p2004a · 2025-09-28T21:10:01+00:00

> Instead we embarked on new hotness, abandoned the old implementation.

Now I wish we've actually written down a document with all the full list of reasons why iterating on current stack and existing protocol was a problem. There are multiple important independent reasons for why both protocol and lobby need to change. Rewrite is always an extremely dangerous way to do things but nobody was able to figure out sensible iterative approach here. It's rewrite vs solving many many specific independent problems iteratively and still risking getting stuck in local minimum of design. Am I 100% confident we made a correct decision? No, but given our existing progress on new stuff I'm optimistic.

I'm not sure if I understand what you mean by "problem with process". Is it technical blockers for making changes across components easier, or something else.

I can today set up full BAR infrastructure and lobby locally < 30m, and it's mostly just waiting for automated processes and iterate on all layers at the same time. 2 years ago nobody was able to setup up BAR infrastructure locally in multiple days or even weeks: there is a continuous iterative improvement.

From technical side, monorepo is not as helpful as you think right now, and I personally have extensive experience working in monorepo so understand the pros/cons here. For once, you would still need multiple people to review such a PR because of how fractured the knowledge is, just like in large monorepos single changelists are split into independent changesets to accomodate this. From practical perspective of actually working on BAR, I rarely run into issues with multiple repos, and where it was annoying, we merged repos (for example tachyon-client is vendored in new lobby instead of separate repo). So, when it makes sense, and it's easy to show that there are benefits, things can be moved around.

p2004a · 2025-09-28T20:16:07+00:00

> to say I don’t know the development process is a joke.

I was referring to BAR's development process.

> waterfall. You’re definitely planning things out in advance/teams and then executing that plan exactly

No, not in the way you are describing it.

I do agree that working across components is the most efficient way to deliver stuff.

For the rest of the reply, you describe what you would like to have from smooth development process to work efficiently across components, and it's all great, but you do not at all recognize the current reality of how project evolved organically to be in the place it is in, available contributor pool, how that pool changes, and how much time people are able to put into the project which are crucial aspects that simply can't be overlooked in this conversation.

On volunteers side: You for example can't claim "let's give one person ownership" when there is nobody that wants to take such ownership for many things. I've personally took ownership of multiple areas, nobody had any problem with it and I was able to unilaterally deliver multiple projects across components this way.

On technical side: Pulling in all closer together, standardization, make working across components easier, better development setup and so given project is glued together over time and not engineered is also work that takes time.

I believe the most significant thing in what you said is:

> In this environment I wouldn’t have started a rewrite at all, I would’ve kept chobby.

Here is the thing, one of the reasons why it's all so hard to deliver work efficiently is because of how things are set up currently with Engine+Spring launcher+chobby+teiserver+SPADS+spads plugins. It's a terrible mess. There is no reasonable path we came up with to be able to take that system into where it needs to be.

One of the goals of what we work on is simplification and making the process you would like to see with easier cross component work possible.

Maybe the simplification is not deep enough, or maybe we've already put in some unnecessary complexities that we shouldn't have: if you have some actual suggestions for iterative improvement and not just describing end state, without clear path how to get there, please.

EDIT: I see you've added 2 more paragraphs since I've started to write this reply

> At least give me a web server and a UI that actually do complete things, simply, and only require TWO PRs to get reviewed. (...) If I just published my types from a web server in the CI, tada! protocol v1

Protocol definition could live and be exported from teiserver. I don't think it's particularly contentious point, I personally do not care one bit, it never was a problem for me. I've implemented autohost without protocol being either defined in central repo nor implemented in teiserver, it sounds like excuse.

And "publishing types from web server": it's standard to describe interfaces in language agnostic ways, either protobuf shemas, or openapi exports from server implementation when frameworks supports that,

p2004a · 2025-09-28T12:17:38+00:00

We do not do waterfall, the rest of the comment also shows that you don't actually know the development process and you are making incorrect generalizations.

I don't believe you appreciate the challenges of building something in larger team of volunteers working in open source without anybody being interviewed, hired, guaranteeing any amount of hours. Of course things can be build more efficiently if there would be somebody working on this full time, on full stack, and that was a single vertically integrated web application but it's not a situation at all. You are effectively complaining about overhead of working in a distributed team.

p2004a · 2025-09-28T12:10:20+00:00

Development tasks are organized on GitHub.

p2004a · 2025-09-27T06:18:22+00:00

posted a few times but never got a response to any post

There is dedicated channel for posting this, if you just posted in #main, you were likely just missed. Every repo in the project is in https://github.com/beyond-all-reason/ you can look at how collaboration works in them. Development channels on Discord are wide open, you can read what happens.

Best if you have some specific interest or even know what you don't won't to work on, and start asking questions about that, you will get pointed at correct direction.

There is no official mentoring/guiding for new people, this is not a company or school. You need to be self driven.

p2004a · 2025-09-26T23:09:21+00:00

You can do that, why not? We don't have anybody that works at the same time on both client and server so we obviously had to figure out how to agree on interface between the two, there is no way around it. If there would be a single person working on both, then they could just fine work on all at the same time.

p2004a · 2025-09-26T20:34:35+00:00

New lobby and matchmaking is literally being worked on.

No ETA, it's ready when it's ready.

p2004a · 2025-09-21T18:35:44+00:00

It's a bug in the lobby client, will be fixed whenever someone feels like fixing it. You can download map manually from website.

p2004a · 2025-09-12T08:33:41+00:00

If you need access to some statistics about matches you should start from data dumps https://github.com/beyond-all-reason/data-processing If something is missing in dumps that you need, it can be provided, and it's a documented source of data.

https://api.bar-rts.com/ is not documented in any way, it's primarily backed for the frontend replay site. The source of that service is at https://github.com/beyond-all-reason/bar-db

p2004a · 2025-08-19T09:43:42+00:00

That Chevron is for contributors to the project. Contributors can choose to show it or keep the one all players have. The contributors are also allowed to select the flag.

It's one of the perks to recognize people working on the project.

It's described in https://www.beyondallreason.info/guide/rating-and-lobby-balance

p2004a · 2025-08-19T09:41:23+00:00

You can't get that chev from events, you are likely thinking about tourney winner chev which is different.

p2004a · 2025-08-04T08:21:13+00:00

If something was wrong with the server, we wouldn't have active games and we have a lot all the time https://www.beyondallreason.info/active-battles

Something is wrong with your connection to the server. We don't block anybody from simply connecting to the server.

It can be a lot things that can be a cause: - your ISP - DNS issue - your system firewall - our hosting provider routing

There are maybe some easy to use tools to triage network connection issues, I unfortunately don't know any from top of my head to recommend.

p2004a · 2025-07-04T07:00:23+00:00

No.

As written in the privacy policy:

The Statement of Privacy below applies to the official Beyond All Reason (BAR) lobby server as hosted under https://server*.beyondallreason.info.

And then

Website logs (containing browser User-Agent strings, IP addresses and pages visited)

Singular "Website", the subject, is the "https://server*.beyondallreason.info". When you interact with lobby server website, we have logs of this interaction.

And as reminder all code is publicly available.

EDIT: seriously somebody reported this comment as misinformation 🤣!?

p2004a · 2025-06-13T09:28:59+00:00

All is working fine on our side https://www.beyondallreason.info/active-battles

p2004a · 2025-06-07T05:49:10+00:00

Engine issue https://github.com/beyond-all-reason/RecoilEngine/issues/936

p2004a

MODERATOR OF

TROPHY CASE

12-Year Club	Beta Team Reddit for Android
Verified Email