historic_bruno

Open a Terminal window and use the open command. So for instance: open ~/Library/Application\ Support/0ad/logs/sim_log

In your local.cfg file, are those options inside a [hotkey.camera] section? Alternatively you can name them e.g. hotkey.camera.rotate.ccw. I'm not clear on what you're reporting. These options worked before but don't work in A19?

Hi, the screenshot doesn't contain much useful information. Can you post the crash logs from the game's log folder? Both the .txt and .dmp file are preferable.

That sounds like the wrong log folder, which instructions on that page did you follow? The game must create some log files or it wouldn't even run. The game doesn't output anything to the Windows command line, it is only debug output that requires a tool like DebugView or a debugger to view.

It's not trivial because of broken drivers, even when a certain feature is technically supported, it may have terrible performance or glitches that we must account for. Anyway it's planned to improve that at some point.

Please attach the logs here DebugView didn't capture anything from the game, either the game fails very early or there was a problem capturing the output. Maybe you need to run DebugView as administrator? I never have problems with that but I recall some people do. ProcessExplorer might also need to run as administrator to generate a minidump. Both of these work on my system, so I'm not sure why they don't work for others. One question, do you have 32-bit or 64-bit Windows 7, and which edition is it (Pro, Home, etc.)? Really knowing your full system info would help.

It would be good to run the game in a debugger, but that's a somewhat advanced topic One relatively easy thing is to run DebugView before launching the game, that will show any "hidden" debug output and may tell us what is going wrong. Another thing is to run Process Explorer, find pyrogenesis.exe in the list kinda like task manager, right-click on it and choose Create Dump > Create Minidump... to save the dmp file somewhere. That will provide us with a call stack of what the game is doing. You can zip it and attach it here for analysis. I don't know how well it works, but we can find out The standard procedure for reporting these issues is to provide the game logs, see Reporting Errors.

Note that option is in the [view] section of default.cfg, so you either need to use view.fov or put it into a [view] section. It won't set the fullsreen resolution due to some problems in SDL2 (so the comment is temporarily wrong), see #2845, but it will set the size in windowed mode.

Just FYI, I wouldn't make a full copy of default.cfg, because sometimes the options change from one release to another. It is better to copy only the lines you want to change

I just did a clean build in 10.11 w/ Xcode 7.0.1 and there were no such errors. Which versions are you using? Do you have any local modifications to SVN? It would be good if SM could build with the existing ICU, to save time and space, as long as it doesn't need a separate debug version (we only make a release build of ICU).

Unfortunately the UI (taking after the game itself) is quite ugly. A web version should be more dynamic and legible, but I agree it would be nice to have a generated manual/enyclopedia for some game content. See also #1840 for an attempt at generating a PDF manual.

We need some more information, please see http://trac.wildfiregames.com/wiki/ReportingErrors Are you on OS X 10.7 by chance? If so, unfortunately A18 will crash in multiplayer, that bug is fixed for the next release (A19): http://trac.wildfiregames.com/ticket/3109

Philip (Ykkrosh) is the one in charge of the Trac server, so you might be able to discuss it with him.

That's odd, there should be output about running as root, but I'm glad you were able to fix it

The ticket description was errant, but the end result was 100% intentional. Indeed in a previous ticket, I was going to make all the buttons follow Windows order (the choice is ultimately arbitrary, consistency is all that matters), but when I looked into it, fewer in-game UIs by far were using Windows order. The order was inconsistent for quite some time and people get used to it. So the least disruptive change was to swap the few, and that's what we've been doing. The Esc hotkey functionality is a secondary issue defined by button order, not vice-versa.

Just an update: wraitii and others have been doing some great work on the pathfinder, and many issues have been solved. Now we need as much testing as possible before A19 And a note on formations specifically: the team discussed this during today's meeting; it seems they have many problems compared to A18, so we may have no formation set by default in A19 (units will move all individually unless a formation is chosen), until they can be properly fixed. Again, some testing is needed to decide this.

Hi gameboy, please try again with the latest SVN version. There were many changes today.

Fixed in r17116 (requires new build). Thanks to all who reported and investigated it

One of the issues I'm seeing with the pathfinder and formations is that it prevents formation movement through gaps. A good example is on Acropolis Bay (2), take 3-4 of your initial military units and try to send them down the hill toward the middle of the map. They will walk the long way around the back even though they have no problem going down the hill individually. I don't know if this is an intentional behavior to try to improve formation pathfinding, but the result is quite awful in this case. It's not clear what is happening based on the pathfinder overlay.

Would be useful to have the mainlog and system_info.txt from that session, but the log may have been overwritten since then.

Can you be more specific about what happened? Did the sound stop during a game? Or was it after you reloaded the game? Is it still broken (esp. after reboot) or did it only happen that one time?

That's funny, I seem to recall the AoE series having the same "bug" Should be fixed in r16919

Can you confirm this? Also, try some older revisions until you find one without the performance issue, so we can narrow it down a bit?

This is useful to work on. In the past I've noticed many small allocations and a rather fragmented heap, when troubleshooting memory leaks on Windows. It may not be the complete solution, but it's probably a step in the right direction. As you say, figuring out how to use it will be the hardest part.

In fact, that is exactly what should happen with the latest version of the game, when built with SDL 2 instead of SDL 1.2. The old SDL 1.2 had a number of issues with multimonitor support. Which version of the game are you playing, and is it a package or did you build it yourself? If you care to download and build the latest version from SVN and using SDL 2, I think you'll find it improved, but we need people to test: http://trac.wildfiregames.com/wiki/BuildInstructions I only have one monitor, but reports I've seen are that most if not all such issues are fixed.