Omnisharp Update - Unable to find Mono. Ensure that Mono's '/bin' folder is added to your environment's PATH variable. #4489

mdmoura · 2021-04-09T18:26:39Z

Issue Description

Visual Studio Code just automatically updated Omnisharp and now I get the error:
Unable to find Mono. Ensure that Mono's '/bin' folder is added to your environment's PATH variable.

A few hours ago it was working without any problem ...

Logs

OmniSharp log

[ERROR] Error: Unable to find Mono. Ensure that Mono's '/bin' folder is added to your environment's PATH variable.

Environment information

VSCode version: 1.55.1
C# Extension: 1.23.10

Mono Information

There is a problem with running OmniSharp on mono: Error: Unable to find Mono. Ensure that Mono's '/bin' folder is added to your environment's PATH variable.

Dotnet Information

.NET SDK (reflecting any global.json): Version: 5.0.102 Commit: 71365b4d42

Runtime Environment:
OS Name: Mac OS X
OS Version: 11.0
OS Platform: Darwin
RID: osx.11.0-x64
Base Path: /usr/local/share/dotnet/sdk/5.0.102/

Host (useful for support):
Version: 5.0.2
Commit: cb5f173b96

.NET SDKs installed:
3.1.405 [/usr/local/share/dotnet/sdk]
5.0.102 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 3.1.11 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.11 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download

Visual Studio Code Extensions

Extension	Author	Version
Angular2	johnpapa	11.0.0
azure-account	ms-vscode	0.9.8
azure-pipelines	ms-azure-devops	1.183.0
csharp	ms-dotnettools	1.23.10
docker-explorer	formulahendry	0.1.7
jupyter	ms-toolsai	2021.5.702919634
markdown-all-in-one	yzhang	3.4.0
python	ms-python	2021.3.680753044
remote-containers	ms-vscode-remote	0.166.1
rest-client	humao	0.24.5
typescript-hero	rbbit	3.0.0
vscode-docker	ms-azuretools	1.11.0
vscode-mjml	mjmlio	1.0.4
vscode-todo-highlight	jgclark	2.0.1
vscode-yaml	redhat	0.17.0

krrg · 2021-04-09T18:42:19Z

Same thing here; it was working fine with 1.23.9, but the 1.23.10 update is completely broken for me.

I've tried setting "omnisharp.useGlobalMono": "never", but Omnisharp is still throwing the same error, refusing to format files or offer any Intellisense.

Current workaround is to force downgrade to 1.23.9.

filipw · 2021-04-09T18:55:14Z

very sorry to hear you ran into these issues. there is an unfortunate bug introduced in the last release, where the extension fails to start when global Mono is not installed on the machine (also present if you configured it to not use global Mono).

there should be a hotfix as soon as possible, for now a workaround is to install a global Mono https://www.mono-project.com/download/preview/ then it will work fine (also with the setting "omnisharp.useGlobalMono": "never")

edit: the PR with the fix is here #4492

devantler · 2021-04-09T19:08:24Z

@filipw
There also seems to be problems with the new Microsoft.AspNetCore.Razor.VSCode.BlazorWasmDebuggingExtension. I have dotnet on the path, but it throws this error when trying to attach to a hosted Blazor Webassembly app.

Launching debugging proxy from /Users/nikolaiemildamm/.vscode/extensions/ms-dotnettools.blazorwasm-companion-1.0.0/BlazorDebugProxy/BrowserDebugHost.dll
ERROR: It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '5.0.0' was not found.
  - No frameworks were found.

You can resolve the problem by installing the specified framework and/or SDK.

Here is proof dotnet is on the path with the required framework:

This is my launch configuration:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch and Debug Hosted Blazor WebAssembly App",
            "type": "blazorwasm",
            "request": "launch",
            "hosted": true,
            "preLaunchTask": "npm run build:debug",
            "program": "${workspaceFolder}/src/Presentation/WebApp/Server/bin/Debug/net5.0/EcosystemMapGenerator.Presentation.WebApp.Server.dll",
            "cwd": "${workspaceFolder}/src/Presentation/WebApp/Server"
        }
    ]
}

JoeRobich · 2021-04-09T20:25:22Z

@mdmoura @krrg @niem94 We have a prerelease build with Filip's fix - https://github.com/OmniSharp/omnisharp-vscode/releases/tag/v1.23.11. Will be validating and releasing this afternoon. Here are instructions for installing our prerelease builds if you would like to upgrade now - https://github.com/OmniSharp/omnisharp-vscode/wiki/Installing-Beta-Releases

JoeRobich · 2021-04-09T20:40:47Z

There also seems to be problems with the new Microsoft.AspNetCore.Razor.VSCode.BlazorWasmDebuggingExtension. I have dotnet on the path, but it throws this error when trying to attach to a hosted Blazor Webassembly app.

@captainsafia which repo should we move this issue to?

captainsafia · 2021-04-09T20:51:48Z

You can move it to the aspnetcore repo.

krrg · 2021-04-09T21:30:05Z

Confirmed, 1.23.11 fixes the issue. 🎉
Thanks for the fast turnaround on this!

ericdrobinson · 2021-05-06T21:50:32Z

I'm still seeing this with a Unity project. My environment details:

macOS 10.14.6
Unity 2019.4.23
VSCode 1.56.0
OmniSharp 1.23.11
Mono 6.12.0.122

The error I see when attempting to start OmniSharp is:

[ERROR] Error: Unable to find Mono. Ensure that Mono's '/bin' folder is added to your environment's PATH variable.

I have attempted to regenerate the solution files from within Unity. I have restarted VSCode. I confirmed that my "omnisharp.useGlobalMono" is indeed set to "always". I still have this issue.

Any ideas? Is this still a bug for certain configurations?

For the record, typing which mono in the VSCode terminal shows Mono installed here:

/Library/Frameworks/Mono.framework/Versions/Current/Commands/mono

The project where I'm seeing this occur is new. Older projects do not appear to suffer from this issue.

JoeRobich · 2021-05-07T01:38:01Z

@ericdrobinson Sorry you are runnign into issues. Not sure why mono wouldn't be on your path. I know that on Mac, the environment variables that an application can see are based on how the application was launched (from the dock, from the commandline, etc). You can set the omnisharp.monoPath settings to /Library/Frameworks/Mono.framework/Versions/Current so that the path is always searched.

ericdrobinson · 2021-05-07T15:30:43Z

@JoeRobich Thanks for the response. Some responses in-kind:

I know that on Mac, the environment variables that an application can see are based on how the application was launched (from the dock, from the commandline, etc)

Launched from the dock. OmniSharp works fine in some pre-existing projects from that launch. The project I'm experiencing this issue with was created in the same VS Code process as the working projects. VS Code's terminal (which starts with the same environment as VS Code itself, as I understand things) is able to locate mono using which mono and identifies the aforementioned path.

You can set the omnisharp.monoPath settings to /Library/Frameworks/Mono.framework/Versions/Current so that the path is always searched.

Why is this global-only (User setting versus Workspace setting)? I expect that someone may want to override the specific mono-path on a workspace-based setting if for no other reason than to test different versions or ensure that some environments are locked to a known-working version. Is there a specific reason for such a decision?

In other news, using the setting suggested above does enable the problematic project to use OmniSharp. That said, I've started seeing stuff like this in the OmniSharp Log:

[info]: OmniSharp.MSBuild.ProjectManager
        Update project: Assembly-CSharp-Editor
[fail]: OmniSharp.MSBuild.ProjectLoadListener
        Unexpected exception got thrown from project load listener: System.NullReferenceException: Object reference not set to an instance of an object
  at OmniSharp.MSBuild.ProjectLoadListener.GetSdkVersion (OmniSharp.MSBuild.Notification.ProjectLoadedEventArgs args) [0x0000b] in <9ecc61c9716b45d19f58afb1114317db>:0 
  at OmniSharp.MSBuild.ProjectLoadListener.ProjectLoaded (OmniSharp.MSBuild.Notification.ProjectLoadedEventArgs args) [0x0001a] in <9ecc61c9716b45d19f58afb1114317db>:0

This now happens in both previously working and previously not working projects. Error/warning reporting looks to be unaffected, however, and features like IntelliSense do work. I include it here for completion's sake. I should also point out that this output was, to my recollection, not present in the OmniSharp log for previously working projects before changing the global mono path. No idea what's going on or if this actually even matters.

JoeRobich · 2021-05-07T19:55:24Z

@ericdrobinson Glad things are working a little better.

VS Code's terminal (which starts with the same environment as VS Code itself, as I understand things) is able to locate mono using which mono and identifies the aforementioned path.

I believe the terminal simply hosts a shell which would construct its environment with additions from its config files.

Why is this global-only (User setting versus Workspace setting)?

Many users and projects commit workspace settings to their repo. This setting, if committed, could cause issue for other team members who use Mono and might be different platforms. That being said. We have certainly recieved feedback that our users would like more flexibility with these settings.

Unexpected exception got thrown from project load listener: System.NullReferenceException: Object reference not set to an instance of an object
at OmniSharp.MSBuild.ProjectLoadListener.GetSdkVersion

This seems to indicate that the PATH didn't include the dotnet installation folder either.

ericdrobinson · 2021-05-07T23:15:53Z

@JoeRobich Thanks again for the responses:

I believe the terminal simply hosts a shell which would construct its environment with additions from its config files.

So why, then, would previous versions of OmniSharp work without issue but suddenly break for one new project?

Many users and projects commit workspace settings to their repo. This setting, if committed, could cause issue for other team members who use Mono and might be different platforms. That being said. We have certainly recieved feedback that our users would like more flexibility with these settings.

I guess I don't understand why these settings can't simply be available in both User and Workspace contexts? Presumably a User setting would be "global" and a "Workspace" would be local to the specific workspace (and override any global setting). This is how VSCode's own settings tend to be, right? Is there a specific reason to not provide this flexibility?

This seems to indicate that the PATH didn't include the dotnet installation folder either.

Interesting. Any advice on how to address this?

JoeRobich · 2021-05-08T00:03:08Z

OmniSharp works fine in some pre-existing projects from that launch. The project I'm experiencing this issue with was created in the same VS Code process as the working projects.

How was the project that display's the issue opened in VS Code? VS Code's File > New Window? code . from the VS Code Terminal?

Is there a specific reason to not provide this flexibility?

Nothing other than the intial reasoning that made it a user setting.

Interesting. Any advice on how to address this?

It likely has the same root problem that is causing Mono not to be avilable from the PATH.

soloschenko-grigoriy · 2021-05-08T00:44:09Z

Just in case anyone else gets here looking for a solution

Got the same issue right now, perhaps occurred after recent MacOS update. Killed vscode, killed Unity. Restarted Unity, regenerated project files (Unity -> Preferences -> External Tools) then opened vscode from within Unity (dbclick on any script). Took about a minute for intellisense to kick off but it did eventually. Hope it helps

ericdrobinson · 2021-05-08T10:53:10Z

@JoeRobich Some responses:

How was the project that display's the issue opened in VS Code? VS Code's File > New Window? code . from the VS Code Terminal?

Select "Open C# Project" from the "Assets" menu in Unity. To be fair, I did not actually try opening the project by creating a New Window and then use "Open Recent" to see if that changed anything. My assumption going into this was that the PATH was configured at application launch and all windows would share that setup, regardless of how new projects were opened. Is that not the case?

It likely has the same root problem that is causing Mono not to be avilable from the PATH.

Sure. Is that something that can be configured in settings somewhere? Also, what exactly is not working when that failure occurs?

qcha0s · 2021-05-17T16:11:03Z

1.56.x is just broken for Unity. multiple things don't load, git not seeing the repo and telling me there is no repo and to initialize one, OmniSharp can't find mono - Nothing above was helpful, Reverted to 1.55.2 (https://code.visualstudio.com/updates/v1_55) - No issues, everything works as expected.

ericdrobinson · 2021-05-17T18:21:03Z

@qcha0s Is this something that should be reported to the VSCode issues, then? Or did you attempt to do anything about getting a specific earlier version of OmniSharp before changing your VSCode version?

I imagine that the git issues you described had very little if anything to do with the OmniSharp extension...

j1mmie · 2021-06-02T23:44:13Z

Just in case anyone else gets here looking for a solution

Got the same issue right now, perhaps occurred after recent MacOS update. Killed vscode, killed Unity. Restarted Unity, regenerated project files (Unity -> Preferences -> External Tools) then opened vscode from within Unity (dbclick on any script). Took about a minute for intellisense to kick off but it did eventually. Hope it helps

Worked for me 🙌

ghostlhq · 2021-06-08T07:21:26Z

Just in case anyone else gets here looking for a solution
Got the same issue right now, perhaps occurred after recent MacOS update. Killed vscode, killed Unity. Restarted Unity, regenerated project files (Unity -> Preferences -> External Tools) then opened vscode from within Unity (dbclick on any script). Took about a minute for intellisense to kick off but it did eventually. Hope it helps

Worked for me 🙌

Me either, thx~ Totally save my day : )

jonmumm · 2021-06-10T12:26:28Z

+1 worked for me

yrcloud · 2021-07-04T21:13:21Z

Just in case anyone else gets here looking for a solution

Got the same issue right now, perhaps occurred after recent MacOS update. Killed vscode, killed Unity. Restarted Unity, regenerated project files (Unity -> Preferences -> External Tools) then opened vscode from within Unity (dbclick on any script). Took about a minute for intellisense to kick off but it did eventually. Hope it helps

+1 worked for me too

chestermjr · 2021-07-05T04:51:27Z

+1, thank you!

ardunster · 2021-07-26T00:19:06Z

Regenerating my project files did nothing. Terminal can find mono:

% which mono
/Library/Frameworks/Mono.framework/Versions/Current/Commands/mono

I tried setting "omnisharp.monoPath" to "/Library/Frameworks/Mono.framework/Versions/Current", "/Library/Frameworks/Mono.framework/Versions/Current/", "/Library/Frameworks/Mono.framework/Versions/Current/Commands/", none of which make any difference, every time I open the project (via clicking a script inside Unity, or via simply reloading the program with the last workspace) I get [ERROR] Error: Unable to find Mono. Update the "omnisharp.monoPath" setting to point to the folder containing Mono's '/bin' folder.

I do also have "omnisharp.useGlobalMono": "always" set.

This is with version 1.23.13 of the C# extension.

I have no intellisense or anything useful from the C# extension except maybe a few snippets (and some really annoying behavior on spacebar that I had to disable using autosuggest on commit character over).

Edit: following directions from the vscode unity doc I downloaded and installed the latest version of mono and then restarted my laptop. It seems to be working now.

I did not install the Visual Studio Code editor package for Unity. it hasn't been updated in about 2 years and the features the page says are missing (generating csproj and sln files, and opening scripts from unity) are present and working in the 2020 lts version of Unity that I have this project in.

MahdiFarzami · 2021-09-06T05:20:15Z

Just in case anyone else gets here looking for a solution

Got the same issue right now, perhaps occurred after recent MacOS update. Killed vscode, killed Unity. Restarted Unity, regenerated project files (Unity -> Preferences -> External Tools) then opened vscode from within Unity (dbclick on any script). Took about a minute for intellisense to kick off but it did eventually. Hope it helps

this solution worked for me

ghost · 2021-10-04T22:42:47Z

Just in case anyone else gets here looking for a solution

Got the same issue right now, perhaps occurred after recent MacOS update. Killed vscode, killed Unity. Restarted Unity, regenerated project files (Unity -> Preferences -> External Tools) then opened vscode from within Unity (dbclick on any script). Took about a minute for intellisense to kick off but it did eventually. Hope it helps

After Adding "omnisharp.useGlobalMono" to "Always" and then following the steps above got it working in no time. It was hitting regenerate project files for me. Using VS code and unity on Mac! Thanks for this thread everyone!

sawirricardo · 2021-10-09T08:48:26Z

Mine's not working. What did you guys do other than:

setting omnisharp.useGlobalMono to "Always"
Regenerate project
Restart, Kill Unity

I've done these, yet bear no result.

VSCode 1.60.2
Unity 2020.3.20f1
Mono 6.12.0.122
.NET SDK (5.0.401)

anchpop · 2021-10-13T03:52:35Z

@sawirricardo I had the same issue on my macbook, but rebooting made it work for me. Did you get it working?

sawirricardo · 2021-10-13T11:01:40Z

@sawirricardo I had the same issue on my macbook, but rebooting made it work for me. Did you get it working?

Rebooting works. Until I have to shut down my vscode. And secondtime I open again, the problem reappears again. I made it work again by restarting Unity, though.

carmenmckie · 2021-10-15T14:33:02Z

Just in case anyone else gets here looking for a solution

Got the same issue right now, perhaps occurred after recent MacOS update. Killed vscode, killed Unity. Restarted Unity, regenerated project files (Unity -> Preferences -> External Tools) then opened vscode from within Unity (dbclick on any script). Took about a minute for intellisense to kick off but it did eventually. Hope it helps

thank you!

anchpop · 2021-11-11T16:15:02Z

@JoeRobich Just so you know this fix is incomplete. It works after a reboot or after force quitting vscode, but doesn't work after closing and reopening vscode normally (on my mac)

$ dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.402
 Commit:    e9d3381880

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  11.0
 OS Platform: Darwin
 RID:         osx.11.0-x64
 Base Path:   /usr/local/share/dotnet/sdk/5.0.402/

Host (useful for support):
  Version: 5.0.11
  Commit:  f431858f8b

.NET SDKs installed:
  2.1.818 [/usr/local/share/dotnet/sdk]
  5.0.402 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.30 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.30 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.11 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.30 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.11 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

ther0ok1eboy · 2022-01-12T02:52:53Z

I have resolved this problem due to installing Mono and mono-msbuild and my computer is Arch.

gregharding · 2022-02-28T06:50:49Z

The original issue might have been fixed but I am seeing the same error while trying to open both C# projects from two different Unity instances. One project will open fine but Intellisense will not start in the second project and the OmniSharp log shows the same 'Unable to find Mono' error.

I am currently running macOS 11.6, VSCode 1.64.2, OmniSharp 1.24.0, Mono 6.12.0.162 (but it's been happening for a looong time).

Using @JoeRobich's suggestion above, I edited the settings.json to include a manual path "omnisharp.monoPath": "/Library/Frameworks/Mono.framework/Versions/Current". Now two different Unity instances can open their C# projects at the same time and both projects' Intellisense works fine.

Astrofol · 2022-03-10T12:21:46Z

Just in case anyone else gets here looking for a solution

Got the same issue right now, perhaps occurred after recent MacOS update. Killed vscode, killed Unity. Restarted Unity, regenerated project files (Unity -> Preferences -> External Tools) then opened vscode from within Unity (dbclick on any script). Took about a minute for intellisense to kick off but it did eventually. Hope it helps

It worked the first time then the problem returned!!

antobom · 2022-04-25T20:08:24Z

Regenerating my project files did nothing. Terminal can find mono:
% which mono
/Library/Frameworks/Mono.framework/Versions/Current/Commands/mono
I tried setting "omnisharp.monoPath" to "/Library/Frameworks/Mono.framework/Versions/Current", "/Library/Frameworks/Mono.framework/Versions/Current/", "/Library/Frameworks/Mono.framework/Versions/Current/Commands/", none of which make any difference, every time I open the project (via clicking a script inside Unity, or via simply reloading the program with the last workspace) I get [ERROR] Error: Unable to find Mono. Update the "omnisharp.monoPath" setting to point to the folder containing Mono's '/bin' folder.

I do also have "omnisharp.useGlobalMono": "always" set.

This is with version 1.23.13 of the C# extension.

I have no intellisense or anything useful from the C# extension except maybe a few snippets (and some really annoying behavior on spacebar that I had to disable using autosuggest on commit character over).

Edit: following directions from the vscode unity doc I downloaded and installed the latest version of mono and then restarted my laptop. It seems to be working now.

I did not install the Visual Studio Code editor package for Unity. it hasn't been updated in about 2 years and the features the page says are missing (generating csproj and sln files, and opening scripts from unity) are present and working in the 2020 lts version of Unity that I have this project in.

edit worked for me !

chengengliu · 2022-10-29T18:38:52Z

The original issue might have been fixed but I am seeing the same error while trying to open both C# projects from two different Unity instances. One project will open fine but Intellisense will not start in the second project and the OmniSharp log shows the same 'Unable to find Mono' error.

I am currently running macOS 11.6, VSCode 1.64.2, OmniSharp 1.24.0, Mono 6.12.0.162 (but it's been happening for a looong time).

Using @JoeRobich's suggestion above, I edited the settings.json to include a manual path "omnisharp.monoPath": "/Library/Frameworks/Mono.framework/Versions/Current". Now two different Unity instances can open their C# projects at the same time and both projects' Intellisense works fine.

Hi @gregharding I'm having exactly the same issue as you did. It works perfectly when only one project is opend but not for two projects opend together. Did you simply add the one line to the setting.json file? I have tried but still got [ERROR] Error: Unable to find Mono. Ensure that Mono's '/bin' folder is added to your environment's PATH variable.
Fixed it. I think I am updating the wrong setting.json file. I am modifying the workspace/setting.json file. It turns out I should modify the user settings.json file.

LightGameStudio42 · 2022-11-15T12:05:15Z

[ERROR] Error: spawn mono ENOENT

edited the settings.json to include a manual path "omnisharp.monoPath": "/Library/Frameworks/Mono.framework/Versions/Current". Now two different Unity instances can open their C# projects at the same time and both projects' Intellisense works fine.

Drops an error for me
[ERROR] Error: spawn mono ENOENT

filipw mentioned this issue Apr 9, 2021

move the global Mono check to the correct place #4492

Merged

JoeRobich closed this as completed in #4492 Apr 9, 2021

JoeRobich mentioned this issue Apr 9, 2021

BlazorWasmDebuggingExtension cannot find 'Microsoft.AspNetCore.App' version '5.0.0' dotnet/aspnetcore#31653

Closed

Omnisharp Update - Unable to find Mono. Ensure that Mono's '/bin' folder is added to your environment's PATH variable. #4489

Omnisharp Update - Unable to find Mono. Ensure that Mono's '/bin' folder is added to your environment's PATH variable. #4489

Comments

mdmoura commented Apr 9, 2021

Issue Description

Logs

OmniSharp log

Environment information

krrg commented Apr 9, 2021 • edited Loading

filipw commented Apr 9, 2021 • edited Loading

devantler commented Apr 9, 2021 • edited Loading

JoeRobich commented Apr 9, 2021

JoeRobich commented Apr 9, 2021

captainsafia commented Apr 9, 2021

krrg commented Apr 9, 2021

ericdrobinson commented May 6, 2021 • edited Loading

JoeRobich commented May 7, 2021

ericdrobinson commented May 7, 2021

JoeRobich commented May 7, 2021

ericdrobinson commented May 7, 2021

JoeRobich commented May 8, 2021

soloschenko-grigoriy commented May 8, 2021 • edited Loading

ericdrobinson commented May 8, 2021

qcha0s commented May 17, 2021

ericdrobinson commented May 17, 2021

j1mmie commented Jun 2, 2021

ghostlhq commented Jun 8, 2021

jonmumm commented Jun 10, 2021

yrcloud commented Jul 4, 2021 • edited Loading

chestermjr commented Jul 5, 2021

ardunster commented Jul 26, 2021 • edited Loading

MahdiFarzami commented Sep 6, 2021

ghost commented Oct 4, 2021

sawirricardo commented Oct 9, 2021

anchpop commented Oct 13, 2021

sawirricardo commented Oct 13, 2021

carmenmckie commented Oct 15, 2021

anchpop commented Nov 11, 2021

ther0ok1eboy commented Jan 12, 2022

gregharding commented Feb 28, 2022

Astrofol commented Mar 10, 2022

antobom commented Apr 25, 2022

chengengliu commented Oct 29, 2022 • edited Loading

LightGameStudio42 commented Nov 15, 2022

krrg commented Apr 9, 2021 •

edited

Loading

filipw commented Apr 9, 2021 •

edited

Loading

devantler commented Apr 9, 2021 •

edited

Loading

ericdrobinson commented May 6, 2021 •

edited

Loading

soloschenko-grigoriy commented May 8, 2021 •

edited

Loading

yrcloud commented Jul 4, 2021 •

edited

Loading

ardunster commented Jul 26, 2021 •

edited

Loading

chengengliu commented Oct 29, 2022 •

edited

Loading