vladislavbelov

Hi! Could you post your mainlog.html and system_info.txt from the log folder?

The JS error doesn't seem to be matched. UPD. A similar error was fixed here: https://trac.wildfiregames.com/ticket/6433

It was a great time to work with you! You've done uncountable amount of things to improve 0 A.D. in many areas. It was taking a lot of time and energy, it wasn't simple for you but you've made much further than many others in that situation. Thank you for all you've done! I wish you a nice journey and to only do things you really enjoy 0 A.D. development is keep going and I'll be always glad to hear your feedback if you came to say hello

It doesn't seem to work. For example if a person plays on a computer without an internet connection and uses a phone to download files and visit websites. If they can pass registration captcha why they wouldn't for login? Also we don't have a reliable way to distinguish a real person from a prepaid person to spam until they post.

Highly likely it means outdated drivers. Do you have any other game with Vulkan to test?

We use captcha for the registration on the forum. I'll check what we can do.

Currently we build with an older macOS & SDK because of compatibility (also https://trac.wildfiregames.com/ticket/6193). Ideally it should be compiled on modern macOS, but I'm not sure it works for newest updates. I'll be able to test it on M1 or M2 in a few weeks.

Yeah, we include those shaders in release and release candidate builds. Thank you for the feedback!

Hi! What were the issues? We don't plan to have the main repo on github, so adding its actions isn't in our priority (especially its support). Currently our goal is to decide and perform (if finally decided) the transition from svn to git (on our server). After that we might want to setup similar actions on our server. Currently we have autobuild for Windows, and for Linux/macOS we automatically build releases and RC. We have thoughts about nightly/weekly builds for all platforms. But we're really limited in free hands (for creating and reviewing), so it's not going to happen soon. Also you might take a look at @andy5995 appimage work: https://github.com/0ad-matters/0ad-appimage

You might take a look at old docs: https://trac.wildfiregames.com/wiki/AndroidPort and related files in the repo: https://trac.wildfiregames.com/browser/ps/trunk/build/android We should have no problem with the arch itself since we build the game for macOS ARM64. I think it might be possible (especially if it can be done in a fork to avoid support cost for us, at least for now).

Hi! It might mean outdated video drivers, could you update them? Also could you attach your logs (mainlog.html, you might find path to them here: https://trac.wildfiregames.com/wiki/GameDataPaths)?

Eh. We had experimental support of Android builds long time ago. In theory it should be possible to make it working again, but we have no people for that.

In the game or in the emulator?

Can you try Vulkan (it needs to use RC builds or SVN, SVN also requires 0ad-spirv mod to be installed)?

I'll remove such users.

That's strange, because the error literally says it can't find vulkan-1.dll. Make sure that you're running the game (pyrogenesis.exe) from the same directory with vulkan-1.dll.

Thank you! I'll try to reproduce.

Then it seems Vulkan RT wasn't installed properly.

Maybe do you have minimal amount of steps to reproduce the crash?

%LocalAppData%\0ad\logs (for example, C:\Users\JohnDoe\Documents\My Games\0ad\logs, https://trac.wildfiregames.com/wiki/GameDataPaths#WindowsVista1011)

Could you attach the crashlog.dmp file?

Usually it shouldn't affect Vulkan. That's interesting, as workaround you might check that file C:\Windows\System32\vulkan-1.dll exists. And if it does you could copy that file to the 0 A.D. binaries folder (near to pyrogenesis.exe): path/to/0ad/binaries/system/.

Unfortunately that option doesn't affect CPU cost of a pipeline state switches.

Yes, it's not a fast process. We're pretty limited in available developers but we're still moving forward. It looks similar to #6658, so it might be a template problem rather an out of memory. GDB is a debugger, it also allows to retrieve a stack information.

It's not entirely correct. OOM crashes highly depend on a map. I don't remember any local crash because of OOM during first few minutes on a random map. It's a complicated process and we're working on that: #2611 I successfully generated that map in a "Giant" size and it consumes 1.6 GB (there is a room before 3GB/4GB depending on a Windows version) on Windows when revealed and the whole map is visible. So a reason of your crash doesn't seem in a regular out of memory. Could you share you system info, crash files and run the game with GDB to retrieve a stack?