historic_bruno

Really? I would think the most useful time to save a game would be during multiplayer games. Maybe the devs are just too lazy to account for all the special cases...

Hmm I could see people getting very upset about children being killed if they are regular units Maybe if we have "animated" buildings, with people walking in and out, doing chores etc., then children could be included like props.

Saved games is generally needed, I would consider it a high priority feature

Herd animals should behave more acceptably now

I think the point of this thread was that even people who aren't developers (and don't want to mess with SVN or wait for an extra multi-GB download), should be able to use a simple installer and have a portable install. They wouldn't have to extract the files to Program Files, it could be the Desktop or a thumb drive or whatever But at least the paths issue needs to be fixed, it's a higher priority IMO.

Currently it's the AI's responsibility to determine where it can build based on the obstructions map. In Alpha 6, the simulation would also do its own checks for all players, to prevent them building where they shouldn't. This will be reinstated once problems like http://trac.wildfiregames.com/ticket/969 are fixed, it shouldn't be long, but until then the AI can do almost anything (but note that your AI should still do its own checks correctly). It may be the simulation check was simply masking problems in the AI build logic.

About this ticket, which has been an annoyance for some time but easy to fix if we come to an agreement. First, what are the exact differences between herd passive and hunt passive animals (besides coralling, which we don't have yet)? If one of my units attacks a goat, should it run away or stay in place? I think for wild, huntable animals (like deer) it is clear they should run away, but not for herd animals regardless of who owns them. Also, I think goats/sheep have a max HP that is way too high. They should not be as hard to kill as human units

Some questions/comments about the patches (haven't tested the build yet, and won't be able to for a week or so): Why do you include ps/Pyrogenesis.h in several source files? Why the #undef _T in UniDoubler.h? (_T is a macro for wxStrings and shouldn't be mixed with engine definitions in any case, Atlas doesn't know about CStr, which I believe is intentional. Any strings shared between Atlas and the engine use std::string or std::wstring instead). As a general question, does your build support precompiled headers? In Memory.h, it's conventional to name the macro guard after the file, so MEMORY_H. In AtlasUI, I notice several files have changed <> includes to "", any particular reason for that? Why is RGBColor renamed to RGBColorVector? (The engine seems to build fine in my tests and Atlas shouldn't conflict with engine code).

There won't be another release until Alpha 8, so if you want to test the fix sooner that would be great You'd need to check out the latest SVN: either compiling it yourself or waiting for the next autobuild (should be soon).

I don't think any of our developers are familiar enough with Xcode and OS X development to do that. I personally only have a virtual Mac and have only spent a small amount of time on build issues. Then there are questions of which versions of OS X and architectures do we want to support. I don't see any reason why it can't work, the Xcode projects are just text files and we need to make sure the right bits get thrown in. Thinking more about the dependencies, I believe we can bundle pre-built libraries for OS X, like we do already for Windows.

Oh, I think some things like cache should be in AppData and maps/logs/etc. in My Documents (like this discussion)

Confirmed on Ubuntu 11.04. I notice there are GL Errors when starting Atlas from the command line but not from the main menu. Sounds like a good starting point

Doesn't sound minor to me and I have no idea why that would cause water rendering to fail I'll boot into Ubuntu and see if it's reproducible there.

Interesting, can you make a Trac ticket for this? (updates can be sent to you via email, in case we need more info) I'd say attach your debugger output and also %appdata%\0ad\logs\system_info.txt if you have that.

How long have you noticed that, and which version of the game are you using?

Hello and welcome steggy There's some ongoing, relevant discussion on AI taking place in this forum, if you want to get a feel for the current state of things

I believe Atlas in particular requires source\tools\atlas\AtlasUI built as a shared library (libAtlasUI) that ends up in binaries\system and which is dependent on source\tools\atlas\AtlasObject and source\tools\atlas\AtlasScript and of course source\tools\atlas\GameInterface (gets built in any case). All the rest is optional as far as I know, but if you want you can include the ActorEditor project which should create a separate binary. Hope this sheds some light on the situation

The Atlas code is shared among several utilities (such as AoE3Ed) which aren't built by default. I would guess all the above are optional. Looks like the problem where we want to initialize a std::wstring with a wxString and use c_str() instead of wc_str(). Possibly worth fixing, but see the above

Could make auras only show on selection or alternatively, toggle them with a hotkey.

The releases include debug symbols for just this situation

Hmm that sounds a bit like another problem with DELAYLOAD, but more information is needed. Are you comfortable trying to debug the game, to find out what it's doing?

What's the dark purple area?

I was looking at how to properly implement the AI's Entity.isEnemy() and Entity.isFriendly(), but I couldn't figure out how to hook up the arrays you mention. Maybe instead of being part of the the Entity class they should be somewhere else that has access to the game state. It would be nice to have that, so the AI could attack real enemies instead of massing at allies' civ centres

I seem to have encountered this as well, on OS X. Which OS are you using? Edit: the scrolling code is in CGameView::Update (source\graphics\GameView.cpp).

Why not make a Trac ticket and add your patch? Looks good at a glance, I didn't test it yet. One suggestion, instead of copying the territory Grid<u8> to Grid<u16> we could just add the necessary JS conversions (source\simulation2\scripting\EngineScriptConversions.cpp) - the most flexible solution would be to use templates, as we do for arrays. No idea what's going wrong with the dirtyID. The missing bits are (as you said) to expose the territory map to AI scripts and also to add BuildRestrictions data to the simulation state (GuiInterface.js), that way the AI can determine if a building is allowed in own, neutral, or enemy territory (for that matter diplomacy is not implemented either for the AIs, but this is a lesser point).