sanderd17

A hippo also lives in the water, but doesn't swim that often. They mostly walk on the shores, or walk/swim on the bottom of the lake or river so completely under water. They also have about the same speed in water as on land (well, comparable to other animals, a bit slower in the water). So as they stay mostly with their feet on the ground, it's possible with the current engine. Crocodiles on the other hand have two very different behaviours. Swimming is very speedy, and they often wait for a prey, while when they're lying in the sun, they're slow, and won't attack someone (unless they're being attacked). As for which species, Nile crocodile (http://en.wikipedia.org/wiki/Nile_crocodile) and Indian crocodile (http://en.wikipedia.org/wiki/Mugger_crocodile) seem to fit best in the current set of factions.

Great work with the oryx. If someone can now draw a nice texture for it, we have a great new animal. Crocodile is indeed an interesting animal. It can move in water and on land, doesn't move a lot on land, but is fast in the water. And when in the water, it should float with almost the entire body under water. I'm thinking, for the sake of simplicity, we could have two models. As they behave so different. So in Atlas, we could have water-crocodile and land-crocodile. Water-crocodile attacks could also be nicely animated with water splashes. So definitely in interesting animal to have. @Micket, this doesn't matter for modelling though, the model would just be in the game twice. With different animations and speed stats.

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.