sanderd17

As far as I see it, the trac is shared. You can create a trac ticket, and set the component to "Art & Animation" when you want to report a bug or enhancement there, or when you want to get a certain thing into the game. But it looks like most artists aren't used to a trac system, so it's mostly used by the developers. And the source code is also shared. The original .dae files can be found in the source tree: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art Or you could use SVN to check them all out at once (so you don't have to download each model separately). That's about all I know.

It gives some nice results. Here you see a screenshots where skirmishers were attacking other units below them, but the other units had to run up the hill to attack back the skirmishers. The skirmishers were rather safe. There is still a problem with the implementation I've noticed.Something I haven't figured out results in an error. Oh, and this is the trac ticket with the patch so far: http://trac.wildfiregames.com/ticket/1960

The forum is more for talking. If you want something (that has been discussed) to be done, you need to use trac. Trac is better for assigning tasks to people, and making sure they get done.

I wouldn't know. I don't even know if that camera code does something. As the starting point for the camera is different per player, while there is only one camera starting point. But take a look at the map "Laconia 01", that has a camera view per player, and it seems to work.

@Lion, I think, if you have sounds you would like in the game, you can always create a track ticket and ask for a particular sound to be included. There are ways enough to share sounds. You have generic cloud sharing services s.a. Dropbox, or sound sharing services s.a. SoundCloud.

Not in Atlas, but open the XML file in a text editor, and you can change it there. It's one of the first lines.

I think big screenshot only saves it in an uncompressed format, so you can see all pixels as they are on the screen. To zoom further out, just go to Menu-> settings. Enable developer overlay. In the developer overlay, disable camera restrictions, and if you don't want the developer overlay in your screenshot, disable that again in the settings. You could also use Atlas to take screenshots, instead of doing that in the game. EDIT: But quantumstate beat me to say that EDIT2: Square screenshots are just where the map is square. Some maps are round, some are square. You can't just make a map square, because it's normally not nicely textured in the corners, and there are no other things s.a. trees.

Won't you need a bit of new Atlas UI anyway? I'd not only like to place it, but also to edit them (move them around, delete them). For that purpose, they must be visible in Atlas, but preferably not in the game. So Atlas should also have a little "toggle emitters visibility" switch. But that'll be an easy-to-add menu item.

I'm now getting these kind of warnings with the latest revision: Something wrong?

Better version of the file: https://dl-web.dropb...WbUlIMEcNKHovdw Me wanting to add ballistic trajectories saw that there were some problems. I brought sqrt(2) twice in the calculation, instead of once. So in the end, it differed a factor two. The correct test to see if units are inside the range is this: (t.x - s.x)² <= 2*range*(s.y + range/2 - t.y) (I also changed some numbers to different ides, to avoid divisions and extra operations) or in 3D: (t.x - s.x)² +(t.y - s.y)² <= 2*range*(s.z + range/2 - t.z) This means realistical units can only shoot half as high as they can shoot far on flat terrain. The ballistic trajectories added are done via the numerical method to solve a root for a bi-quadratic function. I could have done it by hand, but to calculate the real trajectories, you get complicated functions, with lots of operations. So probably not doable in the game for every arrow. Using the numeric methods in the draft does mean that, if the unit is almost out of range, it won't find a trajectory. And there are also some sign problems (S can only shoot upwards and forwards, not downwards), so sometimes you have to imagine the mirrored trajectory. You would need this to calculate obstructions though (I heard people want walls and buildings to obstruct arrows), so I'm not throwing it away for now. But the complicatedness of the real traject shows in some way how really simple a basic range check is. @K776: what's the best time to be on IRC? When are the most developers active? @Zeta1127: You can easily add custom height bonusses. If you change the check to (t.x - s.x)² +(t.y - s.y)² <= 2*range*(s.z + heightBonus + range/2 - t.z) Then it will be exactly like 's' is always 'heightBonus' higher. @alpha123: It uses exact physics (hopefully now without mistakes), so the hight a unit can shoot is certainly limited (to exactly range/2). ballistics.zip

Ah, so Gaia is enemy? It's now clear to players, so I don't think it needs an exception.

In real life, ranged units have a bigger range when they're on higher terrain. This isn't the way in 0AD currently. I made a little test file in GeoGebra: https://dl-web.dropbox.com/get/Public/ballistics.html?w=AADi1kWPjqurVoqz9VK8_xLRdovP4XtWbUlIMEcNKHovdw (the original version is added as attachment, just rename .zip to .ggb and open in GeoGebra). You can drag around two units (S and T) to change the distance from each other and relative elevation, both have a minimum and maximum range. You can change the ranges by dragging them over the x-axis. And there are checks to see which unit can hit which according to the formulas explained below. I took a paraboloid (or a parabola in the 2D program) to calculate the maximum range of a unit. The height a unit can shoot is the same as the distance a unit can shoot to a target on the same level. So that defines the parabola, where s.x and s.y are resp the horizontal and vertical coordinate of the shooter. f(x) = -( (x - s.x )² / range) + range + s.y But the code to check if a target (t) is inside the range of a shooter (s) is just as simple. -(t.x - s.x)² / range + range >= t.y - s.y or in 3D (with z the vertical coordinate): -((t.x - s.x)² + (t.y - s.y)² )/ range + range >= t.z - s.z Of course, checking if the target is outside the minimum range is just reversing the inequality. So I wonder, if the formulas are that easy, are there other reasons why the ranges are still with a fixed distance instead of a paraboloid? I'd like to test this in game, but I have no clue where I can find the range calculation. So if someone wants to give me a clue, please do. ballistics.zip

Just a bump. Not trading with enemies, but trading with neutral and Gaia is perfectly fine for me. Should I make a ticket on trac before this gets forgotten?

Most animals from that list just don't exist in the game for the moment. I you want to check that, just search for the name of the animal in the Atlas tool (scenario editor). If you don't find it, it's missing. The other animals are mostly lacking animation (they just glide forward instead of walking). Some (like the tiger) are even still missing textures.

I looked at it a bit closer, and in the unit status position, I saw that the x and z coordinates were still changing (should z change for something floating? Or is y pointed upwards?). But it only changed with about 0.0001 units per second. Meanwhile, I've also had some ships that started the trading route quite well (going up and down a few times), but then got that same problem of being stuck, but on the market on the other side.

I thought about a pathfinding issue, but why doesn't it deliver the metal when it arrives at the second market? Is that also because it doesn't find a global path back? And then how does it find the first route (from the first markef to the second one) as a beginning? It all seems a bit strange. Maybe I should just wait for the new pathfinder.

As you may know, I was working a bit on a map. It had a big sea part, which I wanted to use, so I thought I'd create a dock on the other side of the sea, where the players can trade with. That's how I found most bug I reported lately. Anyway, there's one particular bug that I don't even understand. I don't succeed to create a minimal example of it, as it only happens in the map I created, and only when you follow the right steps. I've added the pmp and xml file in a zip to the post, so you can also test. Steps to reproduce: start playing as player 1 (Britons), you can set the bot to unassigned upgrade to town level Build a dock on the british side of the ground, about as far as you can from the Gallic traders (to gain more profit) Set the rally point of the dock to the ally gallic dock, on the other side of the map Create one mershant ship Normally, when the merchant ship is created, it should automatically start trading with the Gauls, but this doesn't happen. The ship just stays where it is. Try to move the ship around, that works without problems. So I think it's not a pathfinding problem Try to manually assign a trading route between your dock and the Gallic dock The ship starts trading, but when it first arrives at the second dock, it just stops. I've included a screenshot with the state when the ship arrives at the second dock. No matter what I do,I can't get the ship to deliver its metal. As said, I've tried creating minimal examples, but that doesn't work. Even if I place the dock and merchant ship in Atlas instead of letting player 1 build it, the ship wants to trade. But other simple things I do, like saving the map again don't change these buggy results. Is there someone willing to look after such a strange bug? I'm using a build from yesterday btw. HadriansWall.zip

I couldn't find anything on trac, so here's the ticket: http://trac.wildfiregames.com/ticket/1953

it's rather easy to do manually though, just copy paste one of the player hashes in map.xml. And you have an extra player.

Right, I added that. It's also the case when you load an existing map without playing the simulation a first time. Alternative steps to reproduce: open atlas load a scenario map change the number of players (add one) run a simulation It gives about the same problems when running, although no error when changing the number of players.

In Atlas, you can't change the number of players after you've set it. Steps to reproduce: Create a new map, and set the number of players to 2. Give both players a CC Start a simulation game Reset the game Add a third player, you get the following error: WARNING: JavaScript warning: simulation/components/TechnologyManager.js line 245 reference to undefined property "structures/athen_civil_centre" WARNING: JavaScript warning: simulation/components/TechnologyManager.js line 258 reference to undefined property "Structure" WARNING: JavaScript warning: simulation/components/TechnologyManager.js line 262 reference to undefined property this.typeCountsByClass[classes[i]] ERROR: Script message handler OnGlobalOwnershipChanged failed ERROR: Script message handler OnGlobalOwnershipChanged failed ERROR: Script message handler OnGlobalOwnershipChanged failed ERROR: Script message handler OnPlayerDefeated failed ERROR: Error in timer on entity 1, IID 48, function ProgressTimeout: TypeError: this.typeCountsByClass[classes[i]] is undefined ([object Object])@simulation/components/TechnologyManager.js:262 ([object Object])@simulation/components/Player.js:537 ()@simulation/components/EndGameManager.js:86 ([object Object],0)@simulation/components/EndGameManager.js:58 ([object Object])@simulation/components/Timer.js:93 If you now start a simulation game again, Player 1 gets a negative population of max population, and is defeated immediately. Until now, I haven't found a way to add a new player.

When you select your own market/dock, and you point to a dock of a neutral or enemy player, then you get the tooltip "click to establish default route for new traders, gain xx metal". But if you set the destination point and create a trader/merchant ship, the trader/merchant ship just goes to that market/dock and stops there. So it's not possible to trade with enemy or neutral players (the same goes for gaia markets). I think it should be possible to trade with enemy, and certainly with neutral and gaia markets/docks. It's your choice if you want to send the trader to enemy territory. And it could give some interesting maps if they start with a gaia market or dock. So people can fight to defend the trading route, as markets that don't belong to you make you earn more money. If you think it shouldn't be possible to trade with enemy or neutral players, or with gaia, then the tooltip should at least disappear.

Thanks for the nice comments. Triggers and alternative ends would indeed be awesome, but take your time. And there is quite a lot of eyecandy present in the map, some eyecandy palissades (on impassable terrain, so there was no point to make them attackable or selectable), a few pigs on a muddy terrain with an eyecandy drinking thing, a troop of wolves around a blood stain, and little things like that.

Here's a new scenario map I made. It's not historically correct, just loosely inspired on the theme of Hadrian. You start with Britons on one side of the wall, Romans on the other, and when someone breaks open the wall, the attacks begin (unless you use a clever trick, then the attack can begin before you break open the wall). It's really a turtle map. If you're patient enough to build a good army, you'll win. As the AI can't handle it, it's listed as a naval map, but there's also a version of the map with gaps in, which can be played by the AI. To make it, I started from a random migration map, but got rid of that concept of migration. I kept a lot of the trees, but replaced almost everything else. Some special things: A well guarded island with lots of treasures. It takes a serious investment to get them, but I think it's worth it. The Romans have an easier job with their quinqueremes though. Lots of wildlife (so watch out, the AI loses on average 10 units to gaia) Lots of food around to hunt and forage (you don't really need farming) Lots of fish (but watch out for the island) A little waterfall (I think it looks good, give your opinions on it) Both players start on a motte, so you need to build some mills and farmsteads, as your cc is hard to reach. HadriansWall.zip

I don't mean to add new units, just female looking actors for existing units. The actors are picked randomly (so you have some variation in clothes and hair color), but for some units, gender in't important, so you could also have a female actor for it. I agree with the walls part, the problem is that walls for other factions are mostly symmetrical, while such ramparts are extremely assymetric. I think walls should be assymetric (there's always a side of the wall with entrances etc), but not everybody agrees.