Ykkrosh

Is it unreasonable to expect that Adobe ought to do this work to make their product usable on Win7?

It's still a customised version, and a standard Premake won't work correctly. It'd be nice if the relevant fixes/features (minus nasm support which we don't rely on any more) could get added to the Premake upstream source, so that we could eventually converge on an official version, but only if someone cares enough to bother doing that work

The source in tools/atlas/GameInterface shouldn't get compiled into the AtlasUI library. (That code is part of the engine; AtlasUI only uses some headers from that location, since it's the other side of the interface.)

Yeah, the stuff that premake4.lua wraps in 'if _OPTIONS["aoe3ed"]' shouldn't be compiled and isn't expected to be portable.

The .exe comes from the SVN checkout, not from the compilation . (It's in SVN since that seemed the least problematic way to ensure artists on Windows could run an up-to-date version of the game without having to compile anything themselves.)

Probably should be tied in with whatever we add to make infantry not automatically target buildings, and any other kind of target prioritisation we need. (Incidentally, I think AoM+ used the concept of a "tactics" file which the entity definitions pointed at, to specify this kind of stuff and to share it between multiple entities; don't know if that'd be a useful thing in our system (since we already have sharing via inheritance).)

I think Alpha 7 has some renderer optimisations, but no gameplay optimisations, so it shouldn't be any better. There's various performance problems in code I wrote that I'm interesting in fixing and have various ideas for (particularly redesigning the pathfinder to work much better in the worst case), but I've not had any time recently to work on them, but it's a high priority and should be much improved for the next alpha release

That also seems to make the terrain very dark, which helps distinguish it clearly from the units or other objects on it. Maybe we should view colours as HSL, and use separate bands of S+L to distinguish terrain from territory borders and from units (and from resources?), and have just the H determined by the player colour.

Uploaded again (650f5ea5f0d80b27c43547cecc10b8e7). (Well, downloaded rather than uploaded, but whatever )

Uploaded the new .dmg here again (md5 f708e3a565137402aaf843c360e474c0).

I'd hope it would mostly just involve running configure/make/make install (probably with some prefix) to make the libraries available, which doesn't sound like it should be quite that much work (though I'm unfamiliar with the quirks of building on OS X). It's okay if we state it has to be a clean installation of some specific version of OS X to avoid it getting confused by MacPorts etc (like how the Windows executables are built on a dedicated VM to avoid unexpected environment changes that might break things). I think my general concern is that we ought to have a build process, not just a build. (Having any OS X build is definitely better than having none, though - I don't mean to be just complaining, more looking for further improvements ) When we want to do a new release (which may have changes to game code and libraries and build system etc), it ought to be available on all platforms simultaneously, and if part of the process requires manual work then it's more likely to introduce a delay and more likely to introduce bugs due to human error and more likely to stop working in the future when people disappear. The Windows and Linux builds are largely automated to avoid those problems and to make everything more predictable. It takes more effort to set up at first but I think it's a good thing to strive for. I suppose I be the power in this case, so I copied your version (from earlier today) here which ought to provide enough bandwidth for now

Some old stats indicate very few OS X users at all, so detailed breakdowns would probably be meaningless. Something like a shell script that downloads and builds and installs the libraries might be sufficient. I think the important thing is that we can easily update and rebuild everything consistently and reliably, when there's important updates to those libraries (security fixes etc), rather than it requiring manual effort (since then we probably would be too lazy to update libraries).

Dragging sounds a bit fiddly; probably would be easier to do something like shift-right-click to set multiple rally waypoints (same as setting waypoints for units), if we want that basic functionality.

It's the latest standalone release (1.8.5), which is equivalent to Firefox 4. No - the game forces ES5 strict mode and SpiderMonkey's strict warnings on all scripts it runs, to help find bugs and improve code quality.

The PPA only supports 10.04/10.10/11.04/11.10 currently. 9.10 isn't supported by Ubuntu any more, so it won't get important security updates, and you really ought to upgrade to a newer version if possible

I assume that's the glxinfo from the older machine, not the "newer" one? The "i810E" is from about 1999 so I'd hate to imagine what could be older and still in use . The game will never work on that machine - it needs something more powerful to handle the 3D graphics.

Cleaned up again

Laptop keyboards (which I imagine are fairly common) usually don't have a separate numpad, so that probably wouldn't be a good default . We really need an options screen that lets you rebind the keys, and I suppose it would be nice if it had selectable presets for various keyboard layouts (QWERTY (default), AZERTY, Dvorak, etc) - would that solve the problem adequately? (You can always use arrow keys to move instead, and ctrl+arrows to rotate, which may be easier )

Probably we should do <Attack replace="">...</Attack> in the ranged champions, so that they replace the melee attack parameters instead of merging both sets of elements together. (Then the Python script would have to be fixed handle replace="", I guess . I have a Perl script that does the XML inheritance properly (in the script's apply_layer function) - replace="" and disable="" and datatype="tokens" trigger the special behaviour. Maybe it'd be nice to have a Python equivalent of that, returning the entire resulting template after applying the generic inheritance stuff, then the stats script can pick out the desired fields from that.) If it's too inconvenient in the wiki then we easily have a standalone HTML page with the script's output.

Thanks, should be deleted now.

I don't agree that that's agreeing . "My Documents is where users store their files" is not saying it's where applications store files that users want to see. I think My Documents is appropriate when the user has taken an explicit action to create a file (and so they won't be surprised when a file appears in My Documents), and that doesn't include log files since the user has never chosen to save a log file. When the problem is that we want users to find some files (and in this case only a tiny proportion of users, since most should never get crashes and most of the rest won't bother reporting them anyway), simply telling them "open %appdata%\0ad\logs\ in Explorer" is no more complex than telling them "open My Documents (or Documents if on Vista/Win7, or the equivalent in your language) then My Games then 0 A.D. then logs". (Users will never want to look for these files on their own initiative, it'll only be in response to us telling them to look for them, so there's no value in the location being intuitive.) I'm assuming a hypothetical future in which we have a working config system and users will never edit them by hand. Don't have much of an opinion on what we should do before then, since that's only temporary It only looks like about 20 lines of code per path, so I think it's more important to choose whatever's the optimal file layout from a user/platform-convention/etc perspective without caring about whether it saves a trivial amount of implementation complexity. If we stored cache data in (roaming) appdata then Windows would take even longer to start, so isn't that a good reason to keep the distinction? People might want to share them with other people online, or back them up, I guess. Probably not very often, but they seem to match the desired semantics of being files that the user actively chose to store. (I forgot about recorded games; those should go in My Documents too.) Ought to be written "0 A.D.", as long as the trailing "." doesn't cause problems. (It caused problems with NSIS at least, hence the use of "0 A.D. alpha" for the installation directory and start menu folder.)

Requirements for the Windows Vista Logo Program for Software says Windows 7 Client Software Logo Technical Requirements & Program Eligibility says Some guy says I think: * cache should go in LOCALAPPDATA * config should go in APPDATA (users shouldn't need to edit it manually) * logs should probably go in LOCALAPPDATA since it doesn't need to support roaming * screenshots should go somewhere under MYDOCUMENTS (don't know exactly where) * If we used "MYDOCUMENTS\My Games", does "My Games" need to be localised into other languages to be consistent with what other games do? * Saved games should go somewhere under MYDOCUMENTS * A user's local mod (with their saved maps etc) should go somewhere under MYDOCUMENTS * Mods installed from remote sources should go in APPDATA * I don't like the installer asking for admin privileges simply to install in Program Files (and if we have an auto-updater that'd need to ask for admin privileges too), so still install the game into APPDATA or something like that. If we make any changes to paths, remember to update source/tools/dist/0ad.nsi appropriately.

Also the output of running the command "glxinfo" from a terminal might be helpful.

#859 - not fixed yet (needs a better patch).

Flicker on resize is probably inevitable, since we can't redraw synchronously - the current Canvas::OnResize often makes that happen on Linux (I don't remember about Windows). Changing position probably shouldn't be problematic though - I guess we should avoid calling the ResizeScreen handler if the OnResize wasn't triggered by a change in the width/height.