historic_bruno

The path shouldn't cause a problem, since the logs and everything else are working. What error do you see when you try to open public.zip? Maybe you can try reinstalling the game? I don't think the installer is corrupt, or it would have given an error when you installed.

That would be helpful, yes

It seems like the game didn't install correctly, when I rename public.zip in the A15 install directory, I get the same error. Can you check if public.zip exists in: C:\Documents and Settings\[YOUR NAME]\Local Settings\Application Data\0 A.D. alpha\binaries\data\mods\public\ ? Also check that it's about 1.22 GB in size, and you can try opening it up in any program that supports zips to test that it's not corrupt.

Fixed in r14731.

An error like this has been reported a few times, I don't know why yet, can you click "Continue" and play? It might fail in fullscreen mode but work in windowed mode. If that's the case, you can change the setting in your local config file: http://trac.wildfiregames.com/wiki/Manual_Settings

Hmm, what I'm looking for should be logged in the main log as well, mainlog.html. If there's any line in there about OpenAL init failing, that would be relevant.

Glad it worked for you. It's kind of a workaround for now, I will go back to the old build process for A16, that didn't have so many problems.

There's no reason to run the game in compatibility mode, it should work on every version of Windows from XP on. If you're having a problem running it normally, please let us know the error messages and provide the crashlogs if applicable (see Reporting Errors).

r14725 should fix the crash. I don't know why OpenAL is failing to init, but I don't think it's our issue, more likely a driver or OS problem we're encountering. I seem to recall the old sound manager implementation would repeat the init process over and over until it worked, so maybe we lost that in the transition...

Hi, please attach the crashlog files as it says, you can find them in the game's log folder. By "log in", do you mean starting the game?

DebugView must be running already in the background, it will capture the normally hidden debug output from the game.

I've seen a similar report before and IIRC, it was fixed by downloading the 64-bit bundle rather than the 32-bit bundle. You only need the 32-bit bundle for old 32-bit Macs or if they run Leopard. Of course the 32-bit bundle should still work, even on Mavericks, but there is obviously a problem.

Thanks! It looks identical to #2387. I don't know if it's really sound related, do you have other programs playing sound in the background, like music? I would like to see the debug output when the game starts up and crashes, please download and run Microsoft's free DebugView, then run the game. When it crashes, the DebugView log may contain some useful info, please copy/paste the contents in your reply

I wouldn't try to target 10.6 from Mavericks, there are a lot of problems, even if you fix the build, it may not run stably. You should either leave MIN_OSX_VERSION unset or make it 10.8+. It doesn't matter unless you're trying to run the same executable on an older version of OS X.

Thanks for the info. The Mac's graphics card (Radeon X1600) is fairly low end by today's standards, so maybe we just pushed it beyond its limits, or as wraitii said, it could be a lingering driver bug. I would simply leave that option disabled in your config, and if everything else works, be happy Or if possible, consider upgrading the graphics card, but on very old systems, that may not be worth it.

Thanks, should be fixed in r14709.

Let's tackle one problem at a time. Every time you run the game you get this error first and it's reproducible? Or did it only happen once? If it's reproducible, please run the game to get the error, then choose "Exit" in the error window. Which OS are you using? If it's Windows, please upload the resulting crashlog files in the game's log folder. They will help us analyze what caused the crash. See How to Report Errors.

Hi, can you post the system_info.txt for that Mac? It's in the game's log folder. I don't know why that option is enabled by default anyway

In the past when there was a single skeletons.xml file, changes to any of the model skeletons could break the others. The SVN logs for the skeleton directory show 3 commits have touched those files since A15, so I would revert each one and any other animation changes until we find a revision that works. Maybe leper should know about this too. Trac ticket for this bug: #2332

Seems reasonable, but will LAN games be a separate mode? Or will any non-lobby mulitplayer games also send these messages? And I wonder how the UI might look, perhaps when hosting (Multiplayer > Host Game) there could be an option to enable LAN advertising, and when joining (Multiplayer > Join Game) there could be an option to display the list of LAN games. It's a convenient feature to have

Apart from what's already said, you could begin here if you've not visited that page. Other pages of interest might be Coding Conventions, EngineProfiling. Just a tip - we don't commit every little change that analyzers or profilers might suggest, it really boils down to how readable the code would be, whether it makes any difference in performance, how well it matches the style of existing code, etc. So it takes some understanding of the code and judgement It's probably not the best or easiest place to begin for those reasons, but everyone has their own preferences.

The jsapi IRC log? It's pretty interesting. I think one of the stronger points in favor of the Maps is ordered iteration, then again that's something we could get with our own implementation, even if it was more work. It would certainly be interesting to profile the entity collections more closely and compare their performance with objects vs. Maps. To me it feels like one of those things that should be part of the C++ API for AIs, that brings up JS<->C++ overhead as the ticket points out, it would be good to know exactly what we're dealing with there too.

Please pull the latest changes from leper's i18n branch. These changes fixed the build for me on OS X Lion. Note: you will need to run build-osx-libs.sh again to build ICU and tinygettext, and update-workspaces.sh as usual when things change I haven't tested on Mavericks and it could have its own problems, so let's see how it goes for you. The game won't run yet, it segfaults, we think it's the tinygettext API using STL types and probably some compiler flags are different. Anyway it looks a lot like the same problem which can be encountered on Windows, until we fix tinygettext.

It's one of the relatively few remaining planned gameplay features we don't have yet. So indeed, our attention should be turning to it soon Another thing that will change, or should IMO, is the interaction of territories and diplomacy. That is, what happens when your ally expands and takes over some of your buildings. Well currently the territory manager doesn't know anything about diplomacy, so your buildings will start to decay as if they were in enemy territory, but I would argue that shouldn't happen. There is also the possibility of building some things in ally territory. Really, there's a lot that can change once we have the code in place. It won't be 100% realistic because that's not our goal, rather a balance between historical accuracy and what is most fun and challenging.

Is there any data that suggests this is a bottleneck in our scripts? I think a strong case needs to be made before we use more experimental non-standard JS features. I would much rather use C++ data structures where we can change the implementation and have finer control over e.g. serialization and memory usage, as well as being able to implement good algorithms natively, rather than using these maps. And there should really only be a limited number of cases where that is necessary, I can't see us needing to go through every script and change every "associative array" object to a map.