historic_bruno

Persians are a new civ for the next release (Alpha 8), while Romans will take a bit longer

If so, can you try starting a game and opening the profiler (F11)? See if you get a crash and/or error message like "ERROR: CRenderer::EndFrame: GL errors occurred". The message will be annoyingly hidden under the profiler overlay, so you might need to press the ~ key to view it (or you can check the game's interestinglog.html).

Some special units will be able to siege buildings IIRC, that includes fiery arrows?

Only revert if you want to play the autobuild version rather than your custom build (may be relevant for multiplayer games if it's been a while since the last autobuild). Normally, I just select the conflicting files in the update window and choose "resolve conflicts using mine", which makes the message go away. As Erik said, it's really nothing to worry about

I don't see any problem when replaying a multiplayer or single player match (turn length shouldn't matter because that's just how fast the simulation ran). Maybe your visual replay is affecting the simulation. Can you provide the commands.txt file?

Check out the changes and commit message from r10339

I believe I found the problem with selections. It was an intermediate calculation when converting screen coordinates to world coordinates (in order to do ray tracing from the cursor to find a point on the terrain). This error has always existed, but it was not noticeable with narrower FOV (about 1.7% error at 20 degrees FOV, compared with 10% error at 45 degrees, it gets worse the wider you go). Only the horizontal (x) coordinate was affected and you would notice it especially in the far corners of the game view. This particular calculation only depends on the game view's aspect ratio, far plane distance, and FOV, which are all fixed so moving the camera would make no difference. The good news is we found the bug and selections will be more accurate because of it (would have only made a few pixels difference before). I'll commit a fix shortly

Not sure, 16 is the previous hard-coded value. You can change them if you find defaults that look better

Trying to place an object in Atlas shows it much more clearly, in the corners there is a significant difference between cursor position and object position (problem with translation from screen to game coordinates?). Set the FOV back to 20 degrees in default.cfg and the problem is not really noticeable.

Hmm, this might be lingering issues with our current bounding box selection code. Are you not able to select anything, or maybe you're accidentally selecting something whose bounding box is in front of the desired object (trees seem especially bad because they are often curved but their bounding box is a large cube)? Hopefully vts' patch in #914 will fix this, I will try it tonight.

That's what I was thinking and it would be a good start. Then we'd need to add some nice effects like a "tree falling" sound, maybe some leaf/dust particles, and adjust the worker's position and animations so they chop down into the fallen tree instead of attacking the air. I don't know whether it should work like AOK, where you have to chop down the tree before gathering, probably by reducing HP to 0 (that sounds like a pain to allow trees to be attacked), or whether the falling should take place when a fixed percentage of the resources have been gathered. Even though we have different shapes and types of trees, it might be good enough to just use the same behavior for each, not worrying about slight visual differences (cypress vs. baobab) since it's just an approximation.

I haven't tested the behavior nor looked at qBot's code, but does it check the BuildRestrictions minDistance between CCs before building? (Currently I think the minDistance is within the territory "range" of a single CC, so in theory only building outside territory would be OK, but we might change that distance and maybe certain maps allow building too close to an existing CC but outside territory.)

Works great on Ubuntu w/ Code::Blocks 10.05. I tried building both release and debug config, and tested the debugger feature, with no problems. I went ahead and tested on OS X Lion too, as a possible Xcode alternative. It gives the following error when building the engine project: /Users/Ben/0ad/source/ps/XML/RelaxNG.cpp|26|error: libxml/relaxng.h: No such file or directory Which is strange, somehow it's not finding libxml2 includes? "locate relaxng.h" shows: /Developer/SDKs/MacOSX10.6.sdk/usr/include/libxml2/libxml/relaxng.h /Developer/SDKs/MacOSX10.7.sdk/usr/include/libxml2/libxml/relaxng.h /Users/Ben/0ad/libraries/libxml2/include/libxml/relaxng.h /usr/include/libxml2/libxml/relaxng.h /usr/share/doc/libxml2-2.7.3/html/html/libxml-relaxng.html This is probably a separate issue, I think you could commit your patch

Looks like it, I just upgraded a public checkout on OS X from SVN 1.6 to 1.7.1 with no errors

Just want to point out that those hotkeys are available in the config file, so users can always change attack-move to A and garrison to G if they want, our decision isn't the final word

Remember that not all units will be able to attack buildings anyway, once we implement capturing So in that sense it would be logical to ignore buildings. We could make it more complicated by checking if any units in the group are capable of attacking buildings (siege or other specified units) and if so let them attack the buildings, otherwise ignore them. That sounds more like an issue with formations than desired attack-move behavior, IMO formations are almost totally broken and useless. A formation should not "break up" unless the player orders it, so current formation attack behavior is clearly not correct (there's a ticket describing part of the problem). I don't see why attack-move should be any different. Can we come up with a decent solution to attack-move without a decent solution to formations?

I'll add a ticket for this

Hey, great ideas I can see people not liking the "fee", and we haven't discussed a fee with other proposed features like trading (though I think we should). Hmm I was thinking we'd allow certain buildings to be constructed in allied territory by default, such as defensive structures, but we haven't made that change yet. Building too much in the ally's territory could be perceived as a threat, but they could always retaliate by dissolving the alliance, causing their former ally's buildings to experience health/loyalty drain. However, I don't believe we've fully defined the behavior of buildings in ally territory (some questions left unresolved in that topic). How about revealing allied explorations and possibly their LOS? AOK had a "cartography" tech and it was quite useful.

That was if you had "One-Click Garrisoning" enabled, otherwise it was Alt-Right-Click. Either way it would automatically deposit resources when the villager was garrisoned.

Playing a few multiplayer games (against experienced players) has really taught me the value of territories. If you only play against AIs, you won't see this at all, because they hardly support territories. You need to expand if you want to gather resources safely after your base runs out, which places you that much closer to your enemies. The risk is having more land to defend, the benefit is more resources and additional/larger bases with defensive structures. Diplomacy and possibly technologies will add another dimension to territories. Don't be surprised if they continue to be tweaked and possibly end up as a game setup option

Is the "Super" key the same as the Windows key? If so, please don't use it as a hotkey On the one hand, it won't matter too much what we choose, as people can change the hotkey at will. We just need a sensible default, and we might as well follow AOM on this. Let's make sure we have a unique cursor for attack-move, so people can also see the difference. As far as the attack behavior, shouldn't it depend on unit stances? IMO this is better than guessing what the user intends. Let's say you have some archers and you give them "Stand Ground" stance, and some infantry you give "Defensive" stance, then you group them together and attack-move to some point. When an enemy comes in sight of one of them, the formation stops, then we use stances to determine behavior. The archers remain in place, while the infantry are free to move about somewhat. On the other hand, if you gave them all an "Aggressive" stance, they would continue attacking any enemies they found until there were none left in LOS, then they'd return to formation and move again. Edit: In other words I don't think we need an explicit attack command, just stop the formation, and let existing UnitAI do it's work, then re-form and start moving again.

Yeah I wouldn't worry about it, the odds are that even if someone wants to use Code::Blocks as their IDE in Windows, they'd still need MSVC installed to compile, and getting all the options correct looks like a pain (I do think it's possible).

Excellent I assume you mean Linux/GCC?

Looks like Blender animations export mostly correctly with 2.60a?

Your hard drive's not running low on free space is it? Can you check if this file exists: (%appdata%\0ad\cache\mods\public\art\meshes\structural\hele_civic_struct.pmd) ?