historic_bruno

Nice. This could be very handy for visualizing the AI's performance during a game and fine-tuning it

There used to be an "advanced search" link for the forums, but now once you enter some text in the search box it seems you can't do an advanced search (only if the text box is empty - which is not all that clear IMO).

Whatever you did, seems to work really well qBot is definitely better organized now. I notice there were some "No stone found" warnings early in the game which was clearly wrong, qBot clearly had access to stone mines in its base. Also the siege is much more effective now due to preferred attack classes.

Both bugs should be fixed in r11809, thanks for reporting them (Probably best to use Trac in the future though.)

Looking into it, not quite sure what's going on with the default civ in Atlas, it should be using the values in player_defaults.json.

In the screenshots it appears there are units trapped in the foundation, and the building can't begin until they have cleared off. Can you confirm that?

Good question. It might be possible to include both binaries, but I think it would be breaking the app bundle concept to use a script for that (there's supposed to be only one binary per bundle). Probably we would want the main bundle to have a new binary that detects OS and architecture, then loads the appropriate secondary bundle aka plugin. Of course that complicates the build and release process, in particular, building a 10.5-compatible binary would be a pain on 10.7+ which is what people are most likely to be using in the near future. For now I think we should just offer a separate, semi-official 10.5 package when possible and quietly stop supporting that when it becomes too much hassle.

About the crash when toggling fullscreen, I've just disabled the toggle shortcut on OS X and prevented the window from being resizable - as a workaround until the bug can be fixed. Now it should behave much more sanely. You can still use the setting in default.cfg if you want.

Not from me, I'm a bit busy doing other things We're only like a week or two from the release hopefully.

Yeah, for now you'll want to change the window size/fullscreen mode in the config file as described here. Maybe we should disable the hotkey on OS X until the underlying problem is fixed (if it's possible to disable dynamic resizing/windowing in SDL). It would actually be *much* easier to build on a real 10.5 system, as the cross-compiling is a headache, though it did help me work out some problems with build scripts I'm working on. But I figure more developers are likely to have access to a 10.6+ system than 10.5 (it may also be possible to cross-compile from 10.7, but since Xcode 4 doesn't support the 10.5 SDK, you need a workaround). You could probably build it now using the existing instructions with Mac Ports, but I'm planning an overhaul of the build system.

0ad-r11724-osx-i386.dmg (360MB) Should work on Intel Macs running OS X Leopard or Snow Leopard, but not Lion. Please report here how it works. Note: this is a development version so it has whichever bugs/features/fixes are current in SVN, as of r11724

Uploading a 32-bit 10.5 test bundle now.

For Windows, I've used CamStudio.

That's certainly something to take into account, either by having your own ranged units to respond or just turning the melee units loose, or have them retreat further. The exact tactic will always be up to the player, stances don't change that, they only enhance it (with a good implementation) I was mostly responding to your claim that stances aren't necessary, which is just wrong IMO. What we have is broken, that's why I bumped this thread and I'm working on a patch to fix it Being an alpha means lots of stuff is broken or incomplete but we don't just abandon it. I stated my own feeling above: "I personally would rather aim for consistency, all player orders are forced and can't be interrupted by attacks, unless the stance allows it (violent)." It seems rather that the response will depend on the type of order: attack and move will never be interrupted, but more passive orders like gathering and repair can be interrupted (but only after the unit reaches the build/gather target).

Sure there is. Stances, if they work correctly, let you set up groups of units with specific behaviors and then leave them alone for a while. It eliminates micromanaging hundreds of units on multiple fronts which would get annoying very quickly. It's not always attack or idle. Sometimes units are intended for patrol/watch and you don't want them going all over the map on a wild chase. You might say we should have a patrol command then, but sometimes it's even more nuanced, there may be a dangerous area of the map, and you want units to defend themselves in a restricted space but not chase enemies into the dangerous area (e.g. not fall into a trap). Sometimes you don't want units to move at all, but still defend themselves as much as possible, which is what the stand ground stance is for. Another thing I use stand ground for is defending narrow passages, when there's no walls or gates - it prevents enemy units from coming through. It's also good for allowing a retreat of weaker units in a rout. Good management of stances is essential in my experience, but it may just be my style of play. Stances are more useful than formations IMO, and we need them, but we need their behavior to be consistent and sensible too.

It does, thanks There was also an error with the cpuid asm function in x86_x64.cpp: ../../../source/lib/sysdep/arch/x86_x64/x86_x64.cpp: In function ‘bool x86_x64::cpuid(x86_x64::CpuidRegs*)’: ../../../source/lib/sysdep/arch/x86_x64/x86_x64.cpp:81: error: can't find a register in class ‘BREG’ while reloading ‘asm’ ../../../source/lib/sysdep/arch/x86_x64/x86_x64.cpp:81: error: ‘asm’ operand has impossible constraints Which according to Philip's recollection is an issue with PIC, old GCC, and 32-bit builds - all of which affect my test I've used his fix from r9023 as a work around (I was responsible for adding the asm back in r9891, but didn't realize it had existed previously - luckily no one has complained about it recently) Now it's a matter of fixing the 10.6+ only functions (like CGDisplayCopyDisplayMode).

Ok, I found the magic flags to make Spidermonkey build in this configuration, based on a comment from a Bugzilla report Now my configure commands looks like this: CC="gcc -arch i386" CXX="g++ -arch i386" AR=ar CROSS_COMPILE=1 ../configure --prefix=${INSTALL_DIR} --disable-tests --disable-shared-js --enable-macos-target=10.5 --with-macosx-sdk=/Developer/SDKs/MacOSX10.5.sdk --target=i386-apple-darwin9.0.0 --enable-debug --disable-optimize So then I was able to attempt building the game and other than the known OpenAL-GCC bug, the most serious errors are these: I don't know whether this is an STL bug affecting the 10.5 SDK or something we can fix (it certainly doesn't fail on any other combination of OS + GCC that I've tried). The same compiler works fine against the 10.6 SDK. I also tested GCC 4.0 with even worse results In case it helps, the compiler version is "i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)"

So I have a patch to fix units ignoring player orders when attacked, which is directly related to stances. It may not be clear what the desired behavior is in all possible cases or even what cases exist, so I've made a table to clarify. I think it's important to make sure every case is correct (if there's any consensus on what "correct" is), otherwise units do things players don't expect, which is annoying. Unit will respond to attacks when... Stance is: violent other Order is: ------------------------------ walk to point Y N walk to target Y N in response to a player order leave foundation Y? N attack (player ordered) Y N attack (gathering animal) Y Y* because this is part of a "gathering" order? attack (auto / LOS) Y Y garrison Y N ungarrison* - - garrisoned units can't be attacked (in theory) gather Y Y gather near position* Y Y used for rally points heal (player ordered) ? ? heal (auto / LOS) ? ? healers can really only respond by fleeing; "violent" stance makes no sense return resource (player order) Y N return resource (auto)* Y Y shuttling trade Y Y repair/build* Y Y repair and build are the same order flee* Y Y used by healers when attacked cheer (promotion)* - - unit is temporarily invincible during promotion I personally would rather aim for consistency, all player orders are forced and can't be interrupted by attacks, unless the stance allows it (violent). But the above list comes from some IRC discussion with Mythos_Ruler and my own guesses.

So I tried a 32-bit 10.5 build on Snow Leopard. I discovered and fixed some cross-compiling bugs in the library build script, so that's good. But Spidermonkey failed, so that's bad Here's how I invoked its configure: ../configure --prefix=${INSTALL_DIR} --disable-tests --disable-shared-js --enable-macos-target=10.5 --with-macosx-sdk=/Developer/SDKs/MacOSX10.5.sdk --target=i386-apple-darwin9.0.0 --enable-debug --disable-optimize producing a bunch of errors in the JIT build. It works fine without the --target flag, though obviously that would produce a 64-bit lib on Snow Leopard. Then I tried with the necessary compiler flags in place of e.g. --with-macosx-sdk: CFLAGS="-isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -arch i386" CPPFLAGS=$CFLAGS LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk -arch i386" ../configure --prefix=${INSTALL_DIR} --disable-tests --disable-shared-js --enable-debug --disable-optimize and that caused some different, obviously related build errors. I don't have them in front of me but can post later if anyone's interested. It seems Spidermonkey doesn't like me using all these advanced cross-compiling options

It would have to be before r10897 at least. I can try compiling on Snow Leopard against the 10.5 SDK, and see what happens

Agreed.

VMWare is really easy to setup (or you can use VirtualBox as a free alternative, but VMWare is slightly more polished), you just create a new virtual machine, insert the CD or ISO of the install disc, it will normally detect the OS automatically, then you create a virtual hard drive of whatever size you want, then it will boot the installer disc and away you go Afterwards you'll want to install the guest support tools if available, that gives you copy/paste between guest and host, 3D acceleration, etc.

I suspect we'd need a separate build of the game and its dependencies for Leopard, it complicates the build environment, the code would need special handling for the API that changes between Leopard and newer versions -- all of which would increase maintenance going forward, and we'd need someone with a Leopard system to test. It seems much better for now to give priority to whichever version(s) Apple still supports.

I find it strange that you would have serious lag on the main menu. Maybe it's a driver problem, which drivers do you have (the contents of system_info.txt can also be helpful)? What's your framerate (Alt-F) on the main menu? Which version of the game are you using?

That's not in SVN yet, it's still a work in progress