wraitii

A very good release indeed.

Iirc the plan is to have only Aegis if possible for Alpha 12, with the new shared API. However with school restarting for me, and other issues I've had progress is mostly stalled for two weeks, and after that it'll still be fairly slow.

qBot? Might be an attack that couldn't "reach" its target. If I recall correctly, it checks for distance to the middle of the formation, and here it may not trigger. If it's not attacked it keeps walking forever in that case.

Slightly related: I've updated the wiki page with a warning for Mountain Lion users about GateKeeper (can be changed if needed, obviously).

So it doesn't load the scripts from a random other map, it just creates a completely random stuff?

I assume only infantry can be garrisoned. 3 heroes, 3 champions, 3 base type + female = 10 different kinds of infantry. Basically this can never happen.

Never mind my previous comment, it was caused by changes I did (tried to blindly copy some of the old ARB shader ports, but I must have gotten something wrong).

The day when formation is fully implemented, we might want to consider a "RTW" mode. You start with armies, you battle it out thanks to the game's strategical capabilities, perhaps with a few other stuffs thrown in.

See the earlier topic about this subject here. Mythos discussed introducing "loyalty" for buildings, but since the topic was mainly centered around that, I think a clean start would be better. So, capturing buildings is as far as I know the last big gameplay stuff to introduce (edit: I'm forgetting formation revamp), and I don't believe the mechanic is completely agreed upon. I think the main settled point is that infantry and infantry only would be able to capture. Cavalry would defend those units, and siege are for destroying. Now, some points are still up to discuss from a gameplay point of view: -Should walls/gates be capturable? I don't think they should, given units cannot go on top of them. I think the idea is that infantry/cav can't usually attack walls, but can attack gates, while siege units could destroy those, obviously. This would make walls a very convenient stuff to protect your buildings from capture and invasion, and would make walls an important gameplay aspect. Balance must be considered: they should be breach-able "fairly" easily by siege units. -Should buildings completely switch allegiance? Ie could you train enemy units from captured buildings? In the current template implementation, this would be the easiest thing to do, along with not allowing captured building to recruit anything. The other system would have captured buildings train your units, but there are only few cases of building type overlapping. I think this could be allowed between similar civs (when capturing an Athenian gymnasion as Sparta, you could recruit stuffs from the Spartan gymnasion), but not otherwise. This might seem like an unfair advantage however, though it would certainly be interesting from a gameplay point of view. -How should the capture mechanism be handled? Basically, there are three methods: units could have a "capture Range", and buildings in range would slowly be captured if no enemy unit is also in range. Or they could have a "capture" action, à la empire Earth (or healing), where they would stand next to the building and capture it. Third way (which I favor) would be to "garrison" your units in enemy buildings, where they would fight enemy garrisoned units and slowly capture the building (with attrition). First way is probably sub-optimal. Second way is efficient, and allows the enemy to easily attack the capturing units, but has the problem of feeling a little hacky/easy. Third way would allow fighting by garrisoning more units, and is probably more realistic/interesting, but has the obvious drawback of showing nothing: you'd see a progress bar, perhaps another indicator of an ongoing capture, but not much beyond that (unless the system was drastically changed, with "interiors" for buildings and units would capture stuffs room by room, but that's waaaaaay beyond the scope of the game). -Should all buildings be capturable? Should there be a HP threshold for capture (to simulate having torn the doors down, or something like that) -How fast should it be compared to destroying? Remember that a captured building could then be disbanded immediately. Territory attrition also means captured buildings would very likely be destroyed in the 2/3 minute range, but if the building is a fortress/CC.

I'm too having buggy GUI when using the developper interface. Didn't happen before, so a recent change must have broken something.

I'm thinking sheep will be used as scouts anyway on maps where there is no easier choice. It was a pretty common AOE2 strategy (and pretty sneaky because you didn't always notice the new sheep, so didn't always notice you were scouted). Changing it to territory won't really change that.

Has anybody noticed the occasional unit going way out of territory before heading back? qBot's units and qBot-xp's units have shown such behaviour sometimes.

Borders are messy in RMs. The placer won't really let you place things out of the boundaries, but the check is a bit restricite, and probably should be abanonned for terrain placement (since all maps are squares displayed as circles).

It's not too bad if you don't really look for it. The problem on RM is that either the terrains looks like it's random (and it is), or it's a bit too flatly textured. We should use more clever system for that, which we probably have but never really bothered to implement.

That's why I'd like two sliders. A difficulty level, that would make the AI gradually harder, and some sort of "unpredictability/entertainment" slider that would have a few levels, like: "efficient at all costs"/"normal"/"fun"/"extreme". On the extreme level, the AI would react to your cheats by using cheats itself, or things like that. Of course it's pretty low priority.

Cheater AI is absolutely possible now. The AI can send cheat commands very easily. It may be necessary for some "god-mode" for the AI, but I don't think we ought to need that for the "hard" mode. (If I get my way with the "unpredictability" slider, you may have a level that would be "extreme", where the AI would use cheats a little irresponsibly, calling e=mc2troopers and things like that).

I'm with you here. I think battle detection should not only be implemented for battle music, but for battle ambient sounds. geek: have you installed the dependencies with macports? It looks like the "libjpeg" library has not been installed on your computer.

And I have it.

I just had a sigfault with the error: ERROR: error loading sound: pathname=audio/resource/farming/hoe_16.ogg, error=No error reported here

It's not necessarily a problem to have a different AI for the easy mode even in the final game, but it will be more of a burden to support if problems arise. I agree though that'll be both easier and better to have a single configurable AI (perhaps allowing to choose between different AIs still though) with difficulty levels and perhaps other settings (I had an unpredictability setting in mind).

Actually, just extend the rock below the ground (in a rock-like manner). "Foundations" merely means "part of the model that can be revealed when on a hill", not actual blocky squares.

Okay, I was wondering because it appeared you changed every xml file (didn't check the material properties though). Cliffs are one who will benefit from that the most, I think.

Aaaand it's redownloading every texture. Oh well. Worth it. Did you change every texture xml to adopt trilinear mapping?

Hm. You shouldn't see .h and .cpp files... At what part were you referring to?

For macusers who can't compile, you may try this (it probably won't work unless you followed the first few steps of this(install the dependencies), though. Download the SVN repository, and replace the "binaries/system" folder by this. Then, download stwf's patch above, put it in the main 0 A.D. folder (where the binaries, build, source folders are). Open it, go to line 177 ( should be "Index: build/premake/premake4/build/gmake.unix/Premake4.make"), and erase the rest of the file, including this line (so you have a 176 line long diff). Then, launch the terminal, type "cd " (without the quotation marks) and drag your main 0 A.D. folder to the terminal window (the one in which you find the Binaries, build, source and libraries folder). The terminal should now read something like "cd somPath/yourTrunkFolder/". Press enter. Now run "patch -p0 -i RealPatch2.diff". It should show a bunch of lines, and then try running the pyrogenesis executable in binaries/system.