historic_bruno

The crash occurred in your graphics driver, make sure you have the latest driver installed on your system.

Is the problem only with sound files? Maybe it's an issue with the sound card or drivers. Can you describe what modifications or changes to the game you had most recently? When did it work last?

If you installed to C:\Program Files (which you should never do), it's possible that Windows used the VirtualStore in C:\Users\<Username>\AppData\Local\VirtualStore (for compatibility with old apps that try to write in Program Files on Vista+), which will override whatever is in C:\Program Files and doesn't get uninstalled automatically either.

My thinking was the router could be dying or otherwise broken. You could check if it has firmware updates available, or replace it if necessary (lots of people have routers now, even spares, so it's not hard to test a replacement). We still can't rule out your ISP as the problem, though, they may be filtering traffic or doing something else to interfere with the game.

Something like that is planned, there's a ticket for it: http://trac.wildfiregames.com/ticket/131

In-game terrain modification is all but ruled out for Part 1, due to design choices in pathfinding and complications in other things, e.g. terrain-based features like territories and water rendering. A lot of optimizations and caching can be used if the terrain doesn't change. Personally, I wouldn't mind having it with limited applications, but 0 A.D. isn't really about civil engineering/city building/etc. So part of me would like building roads, digging canals, building bridges, but it's not a focus Instead, RTSes tend to abstract such processes with technologies and stat changes.

Multiplayer restart would be far more complex, but I think it's something we can do for single player. It would be nice for development/testing too.

Specifically, it's VMware Workstation 8 with a Windows 7 64-bit host. I configure most hosts with 4GB RAM and 4 CPU cores, and install the guest tools.

That sounds like the issue with water rendering on Intel GPUs? Please attach your system_info.txt from the game's log directory (http://trac.wildfiregames.com/wiki/GameDataPaths)

Hello and welcome!

On my system the game is playable in a Linux VM, in fact the framerate is higher than on Windows but it doesn't look as good. It all comes down to what drivers the VM provides (I have VMWare Workstation, VirtualBox is sadly far behind in most aspects that I've seen), what level of virtualization it has and the underlying host's hardware. I would check what graphics drivers it's using in the Linux guest, if it's software GL rendering, then it will be very slow indeed. Input lag is potentially going to be annoying too, as it's having to go through an extra layer.

As a workaround, try setting the "SDL_HINT_MAC_CTRL_CLICK_EMULATE_RIGHT_CLICK" environment variable from the terminal, like this: export SDL_HINT_MAC_CTRL_CLICK_EMULATE_RIGHT_CLICK=1open path/to/0ad.appchanging the path to wherever 0ad.app is. Kind of yucky for OS X, I know, but it's only a workaround after all My thinking is to add an "emulatemacrightclick" option to the game's config, defaulting to true, Mac users can disable it if they have a two button mouse.

No one else disconnects when building walls? That sounds like a network problem on your end. Is there any way you can alter your network setup for testing? Maybe try a different router, network card, and/or internet connection?

That would only work for a touchpad, with a mouse it would surely be interpreted as a standard double click? That said, SDL2 does add touch/gesture support, I've been looking into for my iOS branch. Honestly though, if you're playing desktop games, you need a mouse with real buttons.

Out of sync errors on rejoin are a known problem in A17. You may still be able to finish the game, but it's not reliable. When that happens, the best way to help us debug is to provide the oos_dump.txt files from each player (from the game's log directory) and a commands.txt from that game as well. By comparing the oos_dump.txt files, we can see what might have gone wrong. The OOS on rejoin has proven difficult to troubleshoot, however.

Well that's the tricky part... I think a 0 A.D. app would never be approved by Apple for relying on GPL code and plus it's a development version and violates all sorts of Apple's app design sensibilities even if they changed the GPL policy. So it can't be distributed through the app store or TestFlight (requires a review for beta apps). Then there are what Apple calls "ad hoc" and "enterprise developer" distribution, they don't require an app review, but only people registered as members of a dev team (for a yearly fee) can install the app and of course there are limits on that. As far as I know, all the official Apple channels require signing the app as a paid developer before it can be installed on a device, even for personal testing. That basically leaves jailbreaking the device and using a third-party distribution as the only way 0 A.D. could be distributed to non-developers. Cydia is one such service, I don't know anything more about it.

Indeed, it seems to be a slightly changed behavior in SDL2. We are not using that hint currently, but it will slightly change hotkey behavior. Ctrl+Click is a hotkey used for unit group selections, we would need to reassign it, possibly to Command+Click?

I've only tested in the simulator, which isn't useful for performance measurements. I don't own a real iOS device either, so someone else would have to test that

Fixed the orientation problem, it was a bug in our code (incidentally it also affects desktop versions of the game, when the fullscreen resolution changes), and the model_common shader had failed to compile due to a type issue, that is now fixed. The next step will be building for real Apple hardware and ARM, not the i386 simulator. A slightly more realistic test on a simulated iPad 2, rotated to landscape view:

Decided to experiment with the iPhone simulator in Xcode, after a bit of work I was able to build an iOS app that runs in the simulator: This is Xcode 6 on updated OS X 10.9.5, and the simulator is showing iPhone 4s / iOS 8.0. I tried other devices and they mostly work as well, except the Retina-based iPads have incorrect resolution and orientation changes (rotation) corrupt the screen. The Retina issue might be fixed by enabling HiDPI mode in SDL2. When touching a text input box, the onscreen keyboard pops up as shown below, which is nice. Most hotkeys don't work of course. There are some issues with touch input specific to iOS. But I'm quite happy that it works as well as it does In the coming days, I'll make an ios-support branch on Github, once I have a reasonably stable and cleaned up changeset.

The mainlog.html is from a different instance of the game, but here's the call stack from the crashlog: > pyrogenesis.exe!CShaderTechnique::BeginPass(int pass=0) Line 134 + 0x9 bytes C++ pyrogenesis.exe!CLogger::Render() Line 290 C++ pyrogenesis.exe!Render() Line 258 C++ pyrogenesis.exe!Frame() Line 369 C++ pyrogenesis.exe!RunGameOrAtlas(int argc=1, const char * * argv=0x00f27a30) Line 511 + 0x5 bytes C++ pyrogenesis.exe!SDL_main(int argc=1, char * * argv=0x00f27a30) Line 555 + 0xd bytes C++ pyrogenesis.exe!main(int argc=1, char * * argv=0x00f27a30) Line 140 + 0xd bytes C pyrogenesis.exe!wmain(int argc=1, wchar_t * * argv=0x01091d80) Line 380 + 0xa bytes C++ pyrogenesis.exe!__tmainCRTStartup() Line 583 + 0x17 bytes C pyrogenesis.exe!CallStartupWithinTryBlock() Line 397 C++ kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes The only time I see that error is when there's a problem with the game data, for whatever reason, maybe the game crashed and continued running in the background, or there were multiple instances of the game running, or something else was interfering with it. Please ensure that is not the case, and sometimes a reinstall helps.

This can be caused by one of two things: either you really have an old graphics card and the message is correct, or you have a decent graphics card but incorrect drivers installed. Can you attach the system_info.txt from the game's log folder (see GameDataPaths?

A new OS X bundle has been uploaded, as it had some missing translations and potentially crashed when sharing between user accounts (#2689). Most users won't be affected by this, if you are, please update

It looks like there's a problem opening the game's public.zip data archive. It's possible you have multiple instances of the game running (check task manager for pyrogenesis.exe), either that or the game's public.zip is missing, corrupted or being accessed by another application (antivirus scanner, etc?) I had that exact error when forcing the game to crash, but continue debugging in the background, while opening a new instance of the game.

Is there no crashlog.dmp? Please attach that file, too.