historic_bruno

But how, I can't even get it to run? If it's something we use, then that needs to be fixed...

Suppose I have a ship loaded with units, but the ship is attacked and sunk. Currently, I believe all units on board will be miraculously left on the floor of the sea, unharmed. I'm trying to fix ungarrisoning as part of #893. Garrisoning and transporting are all jumbled together, which I don't like, but maybe that's sufficient for now. The question is what should happen if a ship is sunk? Perhaps units who are near to land could be "shipwrecked" so they survive, but if it's too far away they die (say, more than 4 tiles which is the current max spawn radius). Or we could be pessimistic and assume they all die. Anyway, I think we'll need some kind of flag in the template like <GarrisonShip/> so this behavior is forced for ships and not buildings.

Make sure your SVN checkout/update completed successfully (it will say "at revision: xxxx"). Also make sure your build completed with no errors (warnings are generally OK). No error or warnings when you run the game? Does it seem anything like this? Maybe a screenshot can show what exactly you're seeing.

Welcome back, hope you had a good holiday That sounds fine by me, I don't understand all the internals of Premake by any means, so my patch was more of a workaround. A proper solution is even better. I can test your patch on Windows and OS X, but my virtual Ubuntu machine has some problems running the game. And if anyone else is brave enough to test, that's good too Sounds like the /DELAYLOAD issue mentioned above. If you want to try the latest SVN revision, I've disabled delay loading of OpenAL. (Of course it will require update-workspaces, too.)

I don't think either of those tools are being used anymore, so they probably haven't been maintained. In fact, I mean to delete ColourTester soon, since it has no use. The Actor Viewer mode in Atlas is a rough approximation of those tools, though as far as I know, we have no UI for editing entities.

If it takes up too much UI space why not change the UI? Like make the specific name small and the generic name big. But I agree the generic name should be the most obvious for those of us who don't study ancient languages

Also, builders have to reach the dock, so the back of the dock (the part that faces land) can have at most a depth of 2m, but the front must be able to spawn ships, so it must have a depth of at least 1m (see simulation/data/pathfinder.xml for these definitions). Probably rather than hard-coding these values, they should be tied to the unit passability classes.

Yeah I've already got a fix for this (hopefully). Basically it was only including 3 tiles on either side of the land/water boundary, but now I'm making it so that all the water and the first 2 tiles of land are counted. This should make the dock placement a bit looser and also allow bigger foundations. Yeah this is a tricky problem, I noticed some maps like Siwa Oasis have this (near player 1 starting area). There is a difference between what the renderer detects as being "underwater" and what a simple test like GroundHeight < WaterHeight reveals. But due to the terrain sloping, it could be that 1mm actually turns into a lake or river. Maybe it's enough to add some tolerance to the calculation, I'll test and find out.

Well I'm not sure which restrictions you're referring to, but for example, I envision territories and maybe build limits being options during game setup. Then you could play a less restricted style of game. I think territories and their nuances will be one of 0 A.D.'s main features, once we iron them out. The only other ones are obvious like not building docks in the middle of a desert or a house on the side of a cliff

I think it's a valid suggestion

Yeah, boggy maps are a bit tricky, because shores aren't as well defined I'm thinking you're right, a dock shouldn't strictly have to be built on "land", but in shallow water. We had a concept like this for fixed territories (see http://trac.wildfiregames.com/ticket/687) but it has now been mostly scrapped. New territories are experimental, only time and feedback will tell if what we have now works This makes sense to me and is now quite easy to implement, it's just a matter of editing a few templates.

Well there was no snapping in AOK and the water texture appeared differently to indicate depth I mean, the placement preview "ghost" will always appear red if not allowed to build, but how does the user know things like water depth?

Here's a demonstration of the shore building restrictions for docks, as seen in Atlas. You could build them anywhere that's not red: It shows the following: 1. Foundation obstructions (other buildings, trees) 2. Distance from shoreline 3. Slope of terrain I think a map's terrain should reflect some of these criteria, so it's more obvious where a dock can be built.

I changed it to work this way, since it's more explicit Actually I made the MinDistance and MaxDistance elements optional which seems to work fine (a simple undefined test in JS), if both are omitted nothing happens BuildRestrictions is so-named because the component handles several types of restrictions (terrain, territory, obstructions, alignment). Philip explained the technical reason, but I think it's clearer that each limit has it's own unique name like PlacementType, Territory, Category, etc. If a certain building needs more complex restrictions, then maybe it's best to add a new element and/or handle it in the code, rather than complicating everything else.

Now that we have territories, we need more build restrictions. So I've gone ahead and got this working for territories as described in this post. This got me to thinking about other limits and restrictions we want, and it seems like a good time to fix those I've found a few build limits in #687, are these still valid? One new restriction is related to distance between civ centres. So I thought maybe we'd want similar restrictions for other buildings, why not make it flexible? So here's the scheme I came up with (to be added to the affected entity templates): <BuildRestrictions> <Territory>own</Territory> <Category>CivilCentre</Category> <DistanceRestriction> <Category>CivilCentre</Category> <MinDistance>150</MinDistance> <MaxDistance>300</MaxDistance> </DistanceRestriction> </BuildRestrictions> That means the civ centre can only be built in the player's own territory (except it has special allowance to build in neutral territory), and it has to be at least 150 and no more than 300 units from another civ centre owned by the player (just an example, we may not want MaxDistance in this case ). Is this too complicated, too much functionality we won't use or does it make sense? If there are any other planned distance restrictions, feel free to list them.

Right, I don't think building in ally territory should affect borders - only building in your own or neutral territories.

I didn't see any discussion of diplomacy yet, which is OK since we don't have proper diplomacy yet. But some scenarios have fixed teams, and we were discussing on IRC how to handle ally territories. The thinking is buildings except civic centres should be allowed in allied territories (without suffering loyalty drain) This creates an interesting tension between players IMO, as when alliances shift, and allows cooperative defense. Meanwhile civic centres would only be allowed in your own or neutral territory. Proposed territory building restrictions: Own Ally Neutral Enemy Civic Centre X X Fortress X X Barracks X X Scout Tower X X Temple and Market X Mill and Farmstead X X Farm Fields and Corral X X House X Dock X X X Walls X

There was a discussion in IRC about importing the game's models into Blender (.dae COLLADA files), some people are having problems with this. I installed Blender 2.58.1 to see what the process looks like. The built-in importer gave a message "cannot create image" but silently failed otherwise. I'm not sure if it's a known problem, but apparently the importer doesn't like the absolute path(s) in <library_images>, so I removed that element from the test file and also the reference to it in <library_effects>. Then the file was able to import. Looks like a bug in the importer maybe, does anyone else have this problem?

What's the point of this tool and when's the last time someone used it? Just asking because it doesn't run properly on my computer, and I can't see its purpose since we have the actor viewer in Atlas If there's no point we can delete it per http://trac.wildfiregames.com/ticket/666

Huh? How does the language of the entry determine notability of the subject? The only reference I see to language in that guideline is "sources may encompass published works in all forms and media, and in any language," which seems to confirm that. It would be ridiculous to claim, for example, that a famous event didn't occur in e.g. German or Finnish, just because it happened in an English-speaking part of the world.

I actually like this idea, you could capture your opponent's livestock (which is quite realistic) whether dead or alive.

We look forward to hearing more Also for very technical discussion and (sometimes) instant feedback, try joining our #0ad-dev IRC channel on QuakeNet.

How long have you been seeing this?

Yep, this was discussed a few posts earlier The border graphics will definitely improve.

You've never bought meat? ;D