historic_bruno

If a model is already cached, it won't be converted from DAE again.

Correct.

Can we also update or remove the contributors.txt? Also vts and Yves definitely need to be mentioned.

Hello, try running Microsoft's DebugView utility, then running the game. This will allow us to see the debug output from the game when it tries to start. Please paste the results in your reply. Perhaps we will see the cause of your problem or the point at which loading stops.

That's a runtime error, which is telling you that Collada.dll wasn't found (and so the game's DAE models and animations can't be loaded). Did you follow our Build Instructions and were there any errors in the build?

Fixed in r10904.

Nice job Do you think it would work on other Solaris/OpenSolaris variants?

You don't have std::wstring, quick research led to conflicting suggestions as to whether it's possible to use wstring with NDK.

That's because libraries/sdl/include gets added to the include search path, I guess so we have consistency on all platforms. One solution is to copy the SDL 1.3 includes to a new directory that has the expected SDL/SDL*.h structure, and make sure you add it to the search path.

http://trac.wildfiregames.com/wiki/Manual_Settings

As a reference, see the build process for Blender and their SVN structure, especially the lib/ directory. I've compiled Blender on Windows and it was a very smooth process, their Mac instructions look good, too

I don't think this makes sense on OS X. Technically we should use the Preferences API instead of our own config management, but that sounds like a pain to special case for OS X, so I would prefer a standard visible directory. Part of the problem with ~/.foo is no one can find them, which mostly defeats the purpose I think cache should go in "~/Library/Application Support/0ad/cache" because that sounds nice and obscure, perhaps all other data could go in "~/Documents/0ad" - roughly equivalent to My Documents on Windows? The mods path is a tricky question and not fully resolved even on Windows or Linux. Clearly it doesn't make sense for the user to have to copy new files into the app bundle, just as it hardly makes sense for people to copy mod files into "%localappdata%\0 A.D. alpha\binaries\data\mods\" on Windows. We should address this when we generally improve mod support.

I've noticed something like that after the game slowed down considerably, as if the simulation goes faster for a few seconds to "catch up". I don't know if this is intentional or a bug. Was the game particularly slow before you noticed the speed increase?

Nice, so destroying an enemy trade unit gives some fraction of their carried goods as loot? What if a player destroys their own trader? I think they should get nothing but maybe that's how your patch works Why not have the tooltip a bit to the right of the mouse cursor (and transparent)? In other words move it dynamically instead of being in a fixed position. I'm thinking we will do that for failed building placement as well, it won't seem so strange. You can make it multiple lines if it looks too long.

What about cache, logs, screenshots, and saved games? I almost feel like those too should go in the user's home directory, but then it depends on how we think of an app bundle, is it a.) 100% self-contained, writable and valid for one user only, or b.) more like our Linux packages that are essentially read-only and files created by the game end up in the user's home directory? This question may be best answered by observing how other OS X games work.

I believe that's Philip who does the Windows release packaging, uploads the source and data archives for Linux, and probably does some other behind the scenes stuff I'm sure there are a number of maintainers for the various Linux packages. It works well enough, the biggest issue is having so many Xcode projects and the pyrogenesis/Collada/AtlasUI/ActorViewer projects are not linked together. It would be nice if there was only one project that linked the parts together - as on Linux and Windows. Also it's common to pack the app bundle into a dmg (disk image) for distribution. It's not necessarily either/or, take Xcode as an example, you download it from the App Store, getting an "Install Xcode" app bundle which is run and installs Xcode permanently on the system. I don't believe all the files installed by Xcode are in a single bundle Most of the dependencies in our build instructions, or use the list of suggested ports. I'd like to drop Mac Ports as a requirement for building the game on OS X, because it would be nice to not be dependent on their maintaining port files or having to worry about what versions they provide or being limited by the build configurations they use. 10.5 is the cutoff I've had in my head for a while, most people here on the forums who are following Mac development seem to have either 10.6 or 10.7. I'd be fine with just distributing a 64-bit build of the game and all libraries, at least for a start. PPC support is not even on the table, unless a community enthusiast wants to develop and test that When we say "universal" we are only meaning 32/64-bit Intel.

I don't know that we'll ever have that, much less for Alpha 9.

Like this?

Check out HandleEvent in source\gui\CGUI.cpp. See also EGUIMessageType in GUIbase.h. In fact you should be familiar with most of source\gui. For the XML parsing you'd want the CGUI::Xeromyces_* methods at the bottom of CGUI.cpp. For camera movement, see the CGameView class in source\graphics\GameView.cpp.

This has been discussed at various times in the past, personally I think it would make nice screenshots and videos but would generally interfere with gameplay, or at least not add very useful aspects to gameplay compared with other things we're missing. I kinda feel the same way about seasons and weather.

That's partly my fault for not defining sensible defaults for cases like this (which I did not consider). I see Philip fixed it though

The game's input events originate from SDL, so the real question is does SDL support these Android-specific events? At least in the development branch there is an SDL_TouchFingerEvent that should work for this. You only need to add new events to the GUI XML schema if you're going to add new GUI object types, which might be reasonable on an Android port. I'm thinking it would be easiest to avoid that until absolutely necessary. Either way the GUI manager will need to be extended to capture these events and pass them onto scripts like the session input.js, which is where the most interesting event handling occurs (unit selection, building placement, etc.) Unfortunately the GUI engine code is a mess.

At a guess, CC=gcc46 CXX=g++46? I've never done this to know the proper variables. Is there a reason you need to compile with GCC 4.6? Maybe it's a line ending problem introduced by the patch. Try reverting that file and applying the changes by hand in a text editor. Hopefully all the files don't have similar problems.

5101.../../../source/scriptinterface/ScriptTypes.h:92:2: error: #error Your compiler is trying to use an incorrect version of the SpiderMonkey library. 5102.../../../source/scriptinterface/ScriptTypes.h:93:2: error: #error The only version that works is the one in the libraries/spidermonkey-tip/ directory, 5103.../../../source/scriptinterface/ScriptTypes.h:94:2: error: #error and it will not work with a typical system-installed version. 5104.../../../source/scriptinterface/ScriptTypes.h:95:2: error: #error Make sure you have got all the right files and include paths. Is there some other conflicting version of Spidermonkey that you've built or installed?

That's a strange error, maybe something to do with file permissions. Does it happen often, and have you tried make clean to force a full rebuild? Those are warnings from SDL and unrelated to the other problems.