historic_bruno

There may be a patch for SDL 1.2 that fixes the Lion fullscreen issue, which would be worth testing. Otherwise if we use a 1.3 development version on OS X, we have a whole different set of possible bugs to work around and it diverges from the Linux and Windows paths. Of course there are other problems with SDL 1.2, namely the GL context gets lost when switching between windowed and fullscreen in Windows and OS X, which requires some changes on our end.

I believe when you run an app bundle, the working directory is set to the directory where the bundle is located, not where the binary itself is located, it's a special OS X thing, so that's why it will search and find libraries there. At least that's what it does by default, I don't know if the behavior can be changed.

Just curious, are you having problems either finding a Linux package of 0 A.D. or compiling it yourself, or are you just testing Wine compatibility? What problems are you having, specifically (error messages help)?

How are you using the placer though? That code by itself won't do anything. Sometimes the placers fail if the constraints fail too often, they're fidgety like that. There's some documentation about rmgen, if you haven't seen it.

OS X support is iffy on almost all games I've seen and indeed almost all software that claims to be multiplatform. From my perspective, this is because: a.) they are a small market, much smaller than Windows, this means many less developers have OS X experience and it's less of a priority, b.) you can really only use OS X on Mac hardware which requires going out and buying the latest Mac, unlike Windows and Linux that work on systems from a variety of different manufacturers, they mount significant resistance to using OS X in test environments like VMs or non-Mac branded hardware (though it's still possible), c.) Apple doesn't care about making widespread changes to their APIs and potentially breaking many apps - such as the debacle with Lion, which blindsided and broke even well-known commerical apps, d.) Apple wants to force all developers and users to do things Apple's way, using their compilers and toolchain, basically disregarding the likes of the mature and well-established GCC, e.) Apple doesn't care about making massive changes to the way their development tools look, feel, and work internally, just compare Xcode 3 and 4 for example, they totally changed their paradigm, f.) the above problems don't just affect 0 A.D., but every library the game depends on, they struggle with these same problems which means bugs creep in and features remain unimplemented. Basically, Apple is not interesting in encouraging a healthy atmosphere for development, especially not multiplatform development, but rather channeling as much money as possible into their App Store and iStuff. That's not to say we shouldn't have better OS X support, but it is just some of the issues that are faced when developing a multiplatform app that also targets OS X.

Hi, it's a known problem and will be fixed at some point

Unfortunately there's no up-to-date list of features, it may be quicker to just test and see what isn't implemented yet A good starting point for developers is here. You could try Eclipse.

That would checkout the entire SVN again, nested inside of .../build/workspaces, which doesn't seem like what you intended to do. You should only use "svn co" once. If you've already checked out SVN, then just go to the root of your working copy (christophe/0ad) and run "svn up" to update to the latest revision. But you'll probably want to delete the extra copy first to avoid confusion.

That's the plan, but the serializer needs to support more Javascript features like #406 and #407, which means fiddling around with Spidermonkey's internals.

qBot's trying to gather from enemy farms (as in sending dozens of females into enemy territory, where they just stand around a farm). I guess it needs to distinguish between player owned, gaia, and enemy resources when building its resource map? Edit: I can't always reproduce this, I guess it depends on the map and game state, but still I think it would be a good fix, there's really no cause for qBot to ever send so many females to an enemy farm, and least of all when it's well defended

Oh, sorry to hear that, dependencies can be a pain indeed, hope you have better luck this time

I'll test as much as possible tonight, but not noticed any bad behavior yet Well done.

Wow I've never had someone make a musical instrument to wish me Merry Christmas, that's awesome Hope yours is a good one!

I've had something similar happen to me during a game, so it's not only AIs. The siege units in formation cause pathfinding nightmares, for one thing, and formations generally are garbage when there's only a narrow path (as over a cliff). The best thing would be to have no maps with narrow passes for now, including cliffs.

I'm not aware of any feature in Visual Studio for debugging JavaScript, I don't think it even syntax highlights the code when you open it. You'd be much better using *any* other editor I just use Notepad++ and debug by hand. There is some planned work on a script debugger but I don't know the current status, except that it's not finished. Not sure what you mean, we use a fairly standard JavaScript, the version provided by SpiderMonkey. Though we don't use it the way most developers do, and a generic JavaScript debugger wouldn't really have much value because the game has significant interaction between the C++ engine and the scripts, not to mention we use JIT optimizations.

That's Spidermonkey, and you don't need that package because we bundle the source with the game. It gets compiled when you run ./update-workspaces.sh, unless you use the --with-system-mozjs185 option. The only reason you would use libmozjs185-dev is to avoid the delay of having to rebuild it each time the game is compiled (after ./clean-workspaces.ch), which in your case does not seem to be the biggest concern. I don't know how fast your computer is, but it takes only a short time to build for me.

This tells you the problem: ERROR: DllLoader: dlopen(libCollada.dylib) failed: dlopen(libCollada.dylib, 6): image not found; Can you check and see if binaries/system/libCollada.dylib exists? If not, we need to discover why building it failed. How are you building the game, Xcode or GCC? Probably if you're using Xcode, the Collada project is not properly linked as a dependency of the pyrogenesis project (I believe this is a known problem). In that case you'd need to open both projects and build separately. Whereas if you're using GCC, it will automatically build all projects.

Also, can some mod move this topic to the technical forum?

This is true, they don't have LOS restrictions yet, so they can attack buildings and units not yet explored, which I think is mostly a technical issue rather than a deliberate cheat. My hope is that our AIs get good enough so as to be competitive with our best players, without cheating, and then we can let them cheat if needed for an extra challenge (and dumb them down for easier levels).

I don't think AIs can cheat yet, they have the same abilities as a human, although they can be faster and multitask better

Should be fixed in r10775, thanks

When you follow the steps here, first you'll want to make sure ./update-workspaces.sh finishes with no errors (it's finished when premake generates the gcc and codeblocks workspaces). Then after you run the make command, it should finish with no errors (it will say "linking pyrogenesis ... linking test". If it doesn't finish, then run make again and you should see errors (using the "-j" option means it will build several things at once, not in order, and you may not see it finish with an error, but the build process stops early). You can usually select the error text in the terminal window, right-click and choose copy, then paste it here in your reply. Je parle un peu du francais, mais je ne sais pas que je vous aide avec ces questions techniques

Interesting, I notice they're not using batch training, hopefully the new tooltips will make this more obvious and provide more useful info Also I had to laugh at the camel getting stuck in player 1's base right in the middle of battle.

Can you try one of the fixes suggested in the above link? Try replacing the pthread_np.h include in jsnativestack.cpp:54 with this: #pragma GCC visibility push(default) #include <pthread_np.h> #pragma GCC visibility pop

That means the build failed, check the output for error messages and post them here.