historic_bruno

Hmm maybe it compiled the library for the wrong architecture? Can you paste the result of running: uname -v

Well we need something to make territories worth having

Discussion Philip and I were having in IRC: what happens if I build e.g. a fortress in my ally's territory? There's two cases: 1. ally's territory is connected to a civ centre: disable the health drain so ally's can't harm each other? 2. ally's territory is not connected to a civ centre: all buildings in the territory suffer the health drain? The border calculation doesn't know anything about diplomacy and I agree with Philip that we should keep it that way, if possible. So what if building in ally territory had this caveat: it's like setting up a base which you own along with the surrounded land, it falls under your protection. But your ally can no longer build civ centres and houses in that enclave. That's not a new feature, but I'm trying to determine if our current behavior has a logical explanation

Yeah, that's annoyed me for a while. I'm always left clicking when I should be right clicking

Anyone tried ship garrisoning since r10020? Also what are people's opinions on one-click ship garrisoning? Personally I think it makes sense because what better action would a unit have for their own ships? The only weirdness is the bounding-box-as-selection issue, but that affects other parts of the game too. It's a simple change btw.

Thanks for digging that up, Jeru, I was always curious about this

You can try using our new build system (update-workspaces-new.sh instead of update-workspaces.sh), which creates an Xcode project - I've been able to successfully build in Xcode 3 on Snow Leopard. Hopefully it will be the only build system for Alpha 7, if we can squash the remaining bugs. Then I agree, it can only help OS X development

Not sure which part of V8 you need, but if you've got scripts that depend on V8 features, would it be possible to just make wrappers for them? Then you wouldn't even have to touch the engine.

I tried it, looks nice But still with 8 players on a large map, there are waaaaay too many shipwrecks. It would be a very dangerous group of islands to have so many

Not sure how you mean. When you generate a random map in Atlas, it should be the same as loading a new map, so environment settings and everything should be updated in Atlas. If not, it's a bug

Well I don't mind the way it is now, because it's not very hard to click the players tab to change number of players

I'd like to see order priorities and user orders ought to have close to the highest priority, with the possible exception of promotions.

I'm thinking they should be totally separate, because for one thing it simplifies the design and also like you said, there may be cases where random maps might generate X number of players but you really want Y.

Kinda random question, but could we have a special cursor for ship garrisoning? (I'm working on the logic for this atm)

Fixed (there was a typo). Maybe the number of players control can be copied to the map panel and stuck in the random map section, then it would be more clear.

We already do this for buildings

Yeah I fixed it. If I'm not mistaken the point was that the starting camera angle hides the building and possibly units, if they're rotated the wrong way. It's not as realistic as all the buildings facing different directions but it's a nice way to start the game

Cool! It's about time we had an islands random map, will definitely check it out. I've just forgotten to fix this

I'm not sure how quick #593 would be, but I do know UnitAI (which contains all that logic) is a mess. As far as #826 is concerned, it would be trivial to change, but we discussed this in some length on IRC before it was implemented. The thinking was more clicks -> a more general selection. It may not work as well in practice.

Not specific to premake4, but maybe something you'd be willing to look into: http://www.wildfiregames.com/forum/index.php?showtopic=15048 ? The AtlasUI shared lib has an incorrect relative path for gcc targets (apparently from where it's built instead of being in the same directory where e.g. ActorEditor is run).

Will that lose the advantage of using precompiled headers?

Probably the best thing to do if you get stuck or don't understand the code is ask We read the forums often and there's always IRC (#0ad-dev on quakenet). If you spend a short time using Atlas, you'll probably find a lot of things that are missing or could be improved.

What happens if you try to run it?

I'm getting the same problem in Ubuntu with gcc 4.5.2, even without using the -j option (old update-workspaces works fine, btw).

Found the problem, at least in Windows it's a manifest issue, so I copied bits of http://svn.wildfiregames.com/public/ps/trunk/source/lib/sysdep/os/win/manifest.cpp to http://svn.wildfiregames.com/public/ps/trunk/source/tools/atlas/AtlasFrontends/ActorEditor.cpp and now for the first time, I can run Actor Editor O.o