historic_bruno

My preference would be two install options on Windows, "Typical" which goes to Program Files and has an uninstaller (you might need admin permissions), and "Portable" which extracts the files wherever you choose and is self-contained as described in this thread. I still don't believe that we need to use AppData

That would be a feat!

Just committed the Atlas fix. I believe Kenny was going to look into the OS X audio problems.

Probably, I suspect drivers will have the most impact, but it's a crapshoot regardless of OS

We could have a <RestrictedAttackClasses> element in the Attack component, and for some animals we would add "Structure". I think it would also be nice to prevent females from attacking soldiers and buildings.

As of r10300, this is possible Note: you'll need the wxWidgets-devel (2.9.x) library also known as wxOSX/Cocoa, because a 64-bit build is only possible with Cocoa (the stable 2.8 version of wxMac used Carbon instead). cc_julian will need to create the Xcode projects for Atlas, if not already, and bundle that dependency Otherwise just use the usual build instructions for OS X (update-workspaces, etc).

Any more progress on this? Now that we also have territory borders on the minimap, I wonder if there's any way to make them more visible, on some maps they are very hard to see.

Maybe MacPorts didn't install properly?

Interesting, thanks for all the info and files, it's a very welcome contribution to the community (people have been begging recently for an Alpha 7 binary for OS X) I'll see if we can get some stats on how many OS X 10.5 or previous users we have and also how many 32-bit Macs (there are these semi-unrelated stats, which show 10.5 is at least as popular as 10.7 among browsers of that website, but I don't think we can assume 0A.D. players break down the same way). My feeling is that it's not a big deal, 0A.D. requires fairly good hardware to be enjoyed and Mac users seem to not mind spending out on new stuff, on an annual basis With Alpha 7 we include a new build system (not default yet) that generates an Xcode project on OS X (you'll see it using the normal build instructions but substitute update-workspaces-new.sh). Some effort has been spent getting this far, but it's not perfect. What we would prefer is to get that working correctly as it does on other platforms, instead of having to construct the Xcode project by hand (since we might refactor/restructure the code, add new files and folders, and we want that handled automatically to make the process as painless as possible, which it's not currently). Probably that involves fixing small bugs and deficiencies in Premake. I think it's close but I'm not that knowledgeable about app bundles and the OS X build process. It would benefit from an expert opinion MacPorts is annoying and I wouldn't mind finding an alternative, but it doesn't really fit in with our build process to require manually downloading and compiling a bunch of libraries from source. I seem to recall reading somewhere that Xcode can manage these dependencies, I may be mistaken. The paths patch will definitely need to be more specific, we want the standard Unix path scheme for SVN builds. That code is due for changes anyway, even Windows builds need more reasonable data paths.

Aha, thanks for the link Looks like they are working on fixing it in SDL. We'll have similar issues with OS X since we also need to use the display API (for detecting resolution), so their solution could be helpful for us in multiple ways. Edit: Another forum member has contributed an Alpha 7 binary for OS X

Interesting. I don't think the current AIs use that array which may explain why we haven't noticed this. It's a short-term hack to make AI usable until they and the interface can be rewritten The alternative was no AI or let the game be extremely slow when they repeatedly fail to build without knowing it (as I understand, they would send a "construct" message and hope that it works).

The territory calculation doesn't know anything about diplomacy. So if the building influences territory, it would carve out your own territory (each tile can only be associated with one player). I guess the bigger concern is the health decay when disconnected from a CC, there's no way to know if you originally placed the building in an ally's territory, it only matters who owns the territory at present We can get around that if the building doesn't influence territories because it will be on your ally's territory - the health decay can take diplomacy into account. Seems reasonable to me, but they do have an affect on territory weighting, so it would be like a mini-territory. Which raises the question of whether scout towers ought to be territory "neutral".

We kinda forgot to about this for Alpha 7. Maybe that's OK since we'll get lots of feedback on territories. Do we still agree on the above suggestions (the ally ones)?

I don't understand, are you saying the CC doesn't train your unit? The obstruction map shouldn't be any different, but building restrictions are too advanced now for the AIs to understand given the information they have, especially since we added territories. So yes the build restrictions are disabled for AI players, but they wouldn't have any way to know even if they weren't. This is one of the reasons why I hope we completely overhaul the AI system.

Is that specific to Lion? I thought the game always has to be windowed on OS X (since it doesn't get the resolution in full screen).

Probably, I mostly copied the text verbatim from the design document.

Well if you're interested in compiling yourself, there has been a discussion here - several people have succeeded in building and running the latest revisions on OS X. We'll be updating the build instructions in the future. But OS X support is still very experimental and will need some fiddling to make it work.

For one thing, there's no point having code after a return statement (haXe seems to be including $s.pop(); at the end of every function). I think that's what the warning is about: a code path that doesn't return a value (even though it's not reachable in the first place, it could indicate a logic bug).

That's interesting. Are you using the default theme for Ubuntu (assuming there are others)? For some reason your buttons are ignoring the background colour setting. I've found this problem on OS X, but I didn't know it affected wxGTK too. Maybe we do need to use a standard control for this.

The problem was that there were two "pyrogenesis" entries listed in Xcode under Executables (in the Groups & Files pane). After doing a clean-workspaces, there is only one and it seems to switch the build configuration properly again. I have no idea what went wrong but I'll keep an eye out for that problem in the future

This ticket is relevant. There's no mechanism for saving the variations in the map file, so even if the control was added back to Atlas it wouldn't have much meaning (when we do implement this, the referenced ticket has some advice )

Hmm, do you see the colors on the environment panel buttons (lighting, etc)?

Hmm, I tested just now and it seems to work for me (also using 2.8.11.0). Maybe check the basics first, like are you running the same binary that you built (debug vs. release) and check the date to make sure the build time is as expected. If that checks out, are there any specific steps to reproduce this?

Interesting, I can boot into Ubuntu 11.04 x64, I thought that button worked a few days ago. What's the result of running "wx-config --version-full" from the terminal?

I think the advantage of My Documents is that it's a.) accessible for Windows users who are used to thinking in these terms (many don't so much know or care what a folder even is), and b.) it's portable, so it should be possible to copy it all over to a USB flash drive and onto another computer or back again, and not be broken, even if 0 A.D. needs (re-)installing. App data by comparison is very obscure, even if we could spoon-feed instructions on how to access it, why should we have to? To use the example of another free open source multiplatform game, OpenTTD, they install the game in Program Files (minding whether it's the 32- or 64-bit build), and then My Documents\OpenTTD is used for all content downloaded in the game, crash dumps, logs, saved games, scenarios/maps, and config files - anything created while the user plays the game. Not that we have to copy what others do, but it's a least some precedent. This is a very good point, and I back up My Documents every week So shouldn't we make it easy to back up config too? Nothing worse than having to change all your settings after losing everything...