historic_bruno

We had recently discovered and fixed a similar problem on Deep Forest: http://trac.wildfire...com/ticket/1513 Does this occur on any Alpine Lakes settings, or is it worse with a certain number of players, map size, etc.? Also if you want to register on Trac and create a ticket for this, that would be great

I don't think anyone's working on improved formations in particular. Ship and siege formations could be worked on independently of the new pathfinder work (not sure what progress has been made on that...)

Using flags like that is not a good idea, they would only be confused with garrisoning. I wouldn't mind something subtle like using banner or statue props: more or fancier banners could indicate a later phase. I'm not sure it would look good with every civ's style though.

This is already done and will be part of Alpha 11

I don't know how the this setup compares with rigify / autorigging, but in that case you have to "bake" the animation before exporting.

I don't think you have to add those libs manually, they are already part of our project. The errors are simply indicating that GL support is not enabled (yet) in your wxWidgets libraries. Did you build wxWidgets yourself or acquire the prebuilt win32 libs? There may be some problems if you tried building wxWidgets on VS 2010 since it's not supported. Otherwise, be sure to set wxUSE_GLCANVAS to 1 as the comment explains, we do need the GL canvas enabled for Atlas.

I was going to say that's how it is, but when I tested, I noticed the order of icons changes when selecting a female citizen or a citizen soldier - even though they can construct most of the same buildings. That doesn't seem right, we should at least have a consistent order (preferably civilian/economic buildings on top, followed by military, then special buildings).

I think a different pathfinding mode could help there, but it has to be considered that there are a number of different formations and the desired motion is formation specific (down to the individual unit and type of unit). I'm not sure how well that generalizes. Can it be accomplished with the existing pathfinder, with the unit motion planned by the formation logic? Maybe the formation can generate a series of points for each unit to follow independent of obstacles and which handles changes of direction more nicely, then pass them to the pathfinder for obstacle avoidance. Here's another problematic case I've noticed. When one unit is in pursuit of another, it has to stop constantly when it reaches its destination, which means fast units pursuing slow units look silly and are mostly ineffective. Instead the pursuit should be continuous, especially in combat, a cavalry unit should pursue and then pass "through" its enemy, without stopping and possibly with a speed burst. Not only in combat but with escort or guard behaviors. So a "follow" or "pursue" pathfinding mode would also be helpful IMO.

The minimum requirement is purely from a technical point of view, as in there is a minimal set of hardware/software on which the game will run without serious errors. "Recommended" is more subjective, we should base it on the ability to run with decent frame rate, with all graphics settings enabled (no AIs since they can cause problems even on high end systems). We should break them both down by OS, since OS X users seem to think in terms of Mac version; whereas Windows and Linux users think more in terms of processor speed, RAM, video card, etc. Just to start things off, minimum requirements: Windows Version: 2000 Processor: 1 GHz Intel or x86 compatible (I think 1 GHz is a decent cutoff without getting into specific processor types) Memory: 512 MB Graphics: card supporting OpenGL 1.3 w/ 3D hardware accelerated drivers and at least 128 MB memory; Radeon 9000, GeForce 3, or similar* Screen resolution: 1024x768 OS X Version: 10.5 2006 or later Intel-based Mac (http://en.wikipedia...._by_CPU_type#P6) Screen resolution: 1024x768 Linux Processor: 1 GHz Intel or x86 compatible Memory: 512 MB Graphics: card supporting OpenGL 1.3 w/ 3D hardware accelerated drivers and at least 128 MB memory; Radeon 9000, GeForce 3, or similar* Screen resolution: 1024x768 * We can probably make a list of known graphics cards that don't work. Intel is not recommended, at least pre-Intel HD 3000, due to buggy drivers and terrible performance. Certain other brands are problematic.

Well I think this is pretty easy: https://github.com/h.../tree/osx-build No MacPorts/Homebrew/etc required, just run the libraries/osx/build-osx-libs.sh script. You do need cmake to build NVTT - that's the only dependency not handled by the script. Testing welcome, if you want to try Git. But I won't be able to update that branch until I'm back on my main computer.

The saved game might help, which revision? Were you playing with AIs? Tell us some more of your system info, which OS and 32- or 64-bit?

I wonder if that could be the Mauryan support elephant, I changed it to be able to repair but not place new foundations, so likely the AI must be updated to handle this case (I didn't know the AI even supported that unit!)

Player 8 is just a dark grey. When I say pure black, I mean "0 0 0". I remembered slightly incorrectly though, it's pure white that is a special case, it gets removed from territory border rendering (since gaia is white - it uglified the borders when rendering both). So then, pure white "255 255 255" is a no-no I agree with the pre-defined palette, that's what I was alluding to in my last post. Doesn't the host have to choose all game settings currently?

Just to clarify, Alt+Enter was intentionally disabled on our end because changing resolution or toggling fullscreen on OS X destroys the GL context and we have no way to reload it yet (similar problem on Windows if we used the real libSDL instead of our own emulation). SDL 2 might work around that, but as long as we have to use SDL 1.2 in the foreseeable future, if we want window resizing on OS X, we'll have to figure out reloading the GL context http://trac.wildfiregames.com/ticket/741

Thanks! Your steps more or less agreed with svenstaro's patch here, but that would break pre-1.44 Boost, so I made a new patch for compatibility with v2 and v3 depending on the Boost version available. Tested on OS X Lion w/ Boost 1.49 and 1.50. Hopefully it works for you too If I get time, I'll try compiling Boost 1.43 and confirming that works, then commit the patch for A11.

It's been suggested before and some thought it was a good idea, but we didn't make a ticket about it. One thing to keep in mind is how player colors might interact with the minimap, some colors can be very difficult to view on certain terrains (e.g. blue that's similar to water). There are also some colors that are unavailable for various reasons, I think pure black is a no-no. So while I agree we shouldn't hardcode which player is which color, I think we should provide valid nice-looking color choices and defaults.

Make sure you install the latest command line tools for Xcode (it's probably best if you uninstall any previous tools, including those packaged with old Xcode), then you'll have a GCC front end for LLVM which is the compiler Apple prefers now. To get SpiderMonkey to compile, you'll likely want to define environment variables CC=gcc and CXX=g++, as the config script expects gcc-4.2 by default.

Found the culprit, there is a potentially useless linking of X11 for Atlas and it even tries on Windows builds! http://trac.wildfiregames.com/browser/ps/trunk/build/premake/premake4.lua?rev=12198#L939 I'll fix that in SVN. Also welcome to the team wraitii

Hmm, that's not ideal and unintended. There shouldn't be any X11 dependencies But now that I do an "otool -L libAtlasUI.dylib" I notice: /usr/X11/lib/libX11.6.dylib is listed, it slipped under my radar somehow. Will need to look and see if the offending lib can be configured without X11 (everything should use native APIs instead). Requiring XQuartz would be a last resort. Thanks for testing! This is why MacPorts is evil and must be replaced I'm working on that. Meanwhile, maybe it was a broken port or some optional wxWidgets features weren't enabled (GLCanvas comes to mind). This is a known problem: Boost 1.50 breaks the game. But if you've gotten it to build, please attach a patch with your changes. I haven't gotten around to messing with 1.50 yet. Actor Editor is broken on OS X anyway And on *nix it doesn't save all its changes... Agreed, but the exact process isn't clear to me and I really haven't had any time to look into it. Probably the required certificate(s) are something to be managed by Wildfire Games and need coordination to set up. So users will have to manually enable the 0 A.D. bundle for now, if they use Gatekeeper in its default state. Short term I'll be happy to get the bundle working on a clean Mountain Lion system (no XQuartz, etc.). There's a lot of useful info on code signing, starting here: https://developer.apple.com/library/mac/documentation/security/Conceptual/CodeSigningGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40005929-CH1-SW1

All the behavior is modifiable, most of the interesting parts are in XML, JS, and JSON See http://trac.wildfiregames.com/wiki/Modding_Guide for an overview of modding, it's not complete but there are links in there to more specific topics.

There are still errors on some systems with the current preview textures: http://www.wildfiregames.com/forum/index.php?showtopic=16309 Edit: confirmed I get debug warnings too, with a debug build:

Hi, did you see this topic about rocks? http://www.wildfiregames.com/forum/index.php?showtopic=16192 It should be possible to have one shaped like your reference image, if someone is willing to model and texture it Maybe Gen.Kenobi has some tips on the process.

What are you using for the dependencies: MacPorts, Homebrew or other? Maybe there are some updates available, or we may have to wait as we did for SDL supporting Lion. Can you verify if the Alpha 10 bundle works? Preferably fullscreen and also Atlas. Then we'll know what if any changes need to be made for ML support.

If you do, one thing we definitely want is a "snaking" behavior for the column / long distance formation. I guess other formations should have some kind of smooth "wheeling" behavior around a given point (obstacles will still cause issues, but in the open it should be smooth). Also it's worth considering the difference between how infantry can move vs. cavalry and siege units.

I believe it's the Formation component adjusting all units simultaneously to stay oriented with the (invisible) formation entity. The reason is there's no better logic implemented yet