sanderd17

Nice blacksmiths. But I think the eye-catcher of the building (the fire with the chimney) is a bit too similar for both buildings. Maybe try getting the chimney into an other part of the building. Or try a square chimney or fireplace. Also, the chimney should probably reach as high as the roof top to make it more credible.

I mean, when the selction between Building and Unit is made, a function is used to get that range. Instead of just using a boolean switch, I've added the angle as an argument. For units, the angle is 0, and for buildings, the angle is 2PI. There is currently no turret support, but if it ever comes, you can query any other angle, and it will calculate the mean range over that angle. Is good to me. Well, if you enable the range overlay in debug mode, you can see those circles (at least for the buildings, it only shows the vision range for the units). They're just not very pleasing to the eye. So the code to get the coordinates exists. It's just a matter of drawing it nicely (which isn't for me either). And it could be a bit CPU intensive too. Although that wouldn't be a problem if you can only show it for one unit at a time.

The bonus range is the mean range for buildings, or the range in the direction of the unit for untis. I've made it adaptable, so f.e. units with turrets that can only turn for a limited angle, can query for that angle, and it will take the mean over that angle. When should I use the "mean bonus range" terminology? On the building placement tooltip? Or on the attack selection hoover? I'm not good with UI design. So if could suggest the UI in more detail, that'd be great.

Well, it works. But for me, it's not a fluent animation. The unit still turns to the rotation where he stopped before. And then jumps to the right rotation. While the selection arrow for the cavalry turns gently. Certainly not a release blocker anymore. But something to investigate. Could we keep the ticket open until there's a better solution? But change the priority.

Btw, the patch with all the gui stuff (can be seen in these screenshots: https://plus.google.com/photos/105567941221792569561/albums/5887468574070508289?authkey=CIni7qimwKC8fg) is now in trac. You can test and comment if you like. http://trac.wildfiregames.com/ticket/1960

Looking good so far. Be sure to have enough joints to let it walk (https://www.google.be/search?q=walking+nile+crocodile&tbm=isch), and when swimming, the legs should be next to the crocodile body.

Hehe, it looks like the forums are going well again. Lots of new posts

Since when can battering rams attack units? When I try it, it can only attack buildings.

I can only agree with a translation method that allows existing tools. There are really lots of PO translation tools. So if that can be used, it would be best. PO isn't the only one. Android and IOS also have their own file formats. But PO is certainly the best known. I've translated software before. And normally, translation projects only gain followers when a standard service can be used. Translators don't like checking out an SVN, or editing a file in a text editor they're not used to. The number of translation tools is quite big. And there are many different features they offer. Some are open-source, and can be self hosted. Others provide automated syncing with a repo. Unless you can make all those tools yourself. I'd go for PO files. Also note that sometimes, translators want a context (it's hard to translate a single word when you don't know the context). Or strings can have variables (you can't split them up, as the order of words might be completely different). This can all be done in PO files.

The torches thing would look great, but requires a LOT of work. Every unit will need to have an additional attack animation. Dropping resources is a bit too micro-management to me. I prefer the more automated things. You also fear to end up with a map full of little drops of resources. For the battering rams, I also don't like the capping. What will you do to compensate other factions (like the maurians with their elephants, or the Athenians with their catapults). What could be done is something like "diminishing returns" for each battering ram. Such that each added battering ram will do less damage. This looks natural, as the first battering ram can find a good place to hit (a door f.e.), while the subsequent rams find worse places. For the morale stuff, some of it might be good. As currently, the battle phase is too short compared to the build phase. The morale could fix that slightly. So no extra morale for big groups (they'll win anyway), but extra morale for fighting on your own ground could be given (if you assume the attacker is stronger, thus giving more power to the defender would balance it better). On the other hand, that could also be achieved by building a better defended base (that is already a home-advantage). I'm a bit undecided about it.

All gates are controlled by the same code. So it's one and the same bug.

If you go into developer mode (enable it via menu->settings), you can disable camera restrictions. It takes a lot of aiming, but it's possible with the zoom wheel and CTR+W/CTRL+S to get a FPS-like viewing perspective. For the controls, it's just a matter of re-mapping the keys. The biggest problem are the graphics. Currenlty, the models aren't detailed enough to always play on this zoom. And the animations aren't realistic enough either.

For your arrows, I've never programmed on the GPU. So that's nothing for me (yet). And about the buildings. It's not possible to only make half of a building visible. This is because the inside of a building is not textured (it's completely transparant in fact). So it would give strange problems with being able to look through the walls. Currently, the building is made visible when the tile in the middle of the building is visible.

It has been noticed, but there is no solution yet: http://trac.wildfiregames.com/ticket/1796

I think units moving around freely would interfere too much with gameplay. Certainly if you can kill them. Something that would maybe be nicer are animated units on the building grounds (with of course, different variations). Like a blacksmith walking around in the blacksmith building, going inside sometimes, hammering the anvil other times. Or a woman sitting on the civil center court, making some clothes, also going inside sometimes. A merchant in the market going from side to side, waiving with some objects. If it could react to the environment (fleeing inside when under attack, doing a shooting animation for defensive buildings) it would even be better. These units would die with the building btw, and they can't be attacked separately. But there is much more important eyecandy to be done than just this (s.a. more animals and plants).

Wohoo, nice report. Also, congratulations to alpha123. He's a great programmer.

Agree with that. But it could be used as a base to work on I guess?

Content creation happens mostly by the artists. While improving the game (reducing the lag etc) is done by programmers. There are only a few people here that do both. Most are specialised in one or the other. So having more content doesn't take time from improving it technically. Unit formations don't work now. Period. But they're related to the pathfinder. And a new pathfinder should be coming soon. Once that pathfinder is a bit optimized, we can think again about formations. Some formations should give a speed bonus, others get a combat bonus. A formation could also be bonused against another formation, and some sides of the formation can be weaker. But as I said, this can only be done when the new pathfinder is in. The swing of the sword is just an animation (and not something we want to focus on, you don't want to control how a single unit swings its sword). So that won't change. But when the new pathfinder is in (again), routes through forests could be made slower for some civilisations than for others. There have also been discussions about vision range based on obstructions or terrain elevation. So yes, we're working on it. And if you can help, you're always welcome.

Hmmm, just noticed there is a crocodile model in game (just completely untextured, so not ready at all to get in game). And I don't know what kind of crocodile it is. http://trac.wildfire...rt/actors/fauna

Triggers should be coming soon, they have been discussed for a while, so now we just need someone to implement them With triggers, a lot of different game modes will be available. Btw, if you just want to admire the artwork, do a game against demo bot. He'll just send a 9-people big army every time it's ready. So it's easy to counter that, while you can still see the strengths of all units and buildings.

That's a strange thing with those locals. I have them set to en-GB, and it works, but it should work for all settings.

There have been a lot of changes to the music stuff. Did you try to do a completely clean compile (also cleaning the workspaces)?

I've been thinking about stuff, and this are the results: Shooting range A little update on the shooting range: For me, the patch is ready for inclusion. It now even draws the right ranges in developer overlay (yay). Though a bit imprecise, but good enough I think. https://plus.google....=CIni7qimwKC8fg (green lines are drawn by the software, I drew the yellow highlights by hand) You even see little bumps or holes influencing the ranges (with the iberian towers), if the elevation differences are bigger, the range is completely deformed (see the towers on the ridge). And it turned out to be more of an elevation disadvantage to low units, than an elevation advantage to higher standing units. But anyway, ones disadvantage is another-ones advantage. Line of sight, the formula Now, I've been thinking about line of sight based on elevation and obstructions. This is a lot more difficult, as it's not the highest unit that has the most advantage (I can see the a village from the top of a mountain, but I can also see the mountain from the village). But elevation has some play in it. You can hide behind a cliff or mountain. So what I've been thinking of, is calculating how big a square meter seems when you stand somewhere. First of all, the appearance of size diminishes squared with the distance (imagine you're in the center of a sphere, double the radius, the surface of the sphere will be 4 times as big, but still fill your entire view). Next to that, it also depends on the angle at which you're looking at it. To be exact, it's directly proportional to the cosine of the normal on the surface and your viewing direction. But, if there's a building on it, you aren't watching the ground any more, so you should take an other angle, so if there's a building, I'll just take this cosine = 1. Note that the cosine is equal to the dot product between normalized vectors. To summarise, checking if one tile can be seen is done by the following formula: V * N / dist² > value or for a building 1 / dist² > value Where V(x,y,z) is the normalized vector from the point you're watching to your eyes, and N(x,y,z) is the normal on the surface, also normalised. And * is the dot product. N can be pre-calculated, as the terrain always stays the same, and there's just a finite number of tiles you're able to see. Calculating V is more difficult, as for normalizing it, you need to calculate the length, which implies you calculate a square root. Next to that, you need to give the unit a height, so his eyes are above the ground. If his eyes are on the ground, he can't see flat terrain, as the cosine would always be zero. I was thinking about first taking a generic 2m for a unit (some average between cavalry and infantry), and 5m for a building. Later on, I'd like to see a <height>x</height> property in the xml files, to give a better interpretation to the viewing ranges, and it could also be taken into account for the shooting range. Next problem is the 'value'. That's some property of a unit, but we still need to interprete it. Say you have flat terrain and a unit with height h, it should still be able to view its normal range. So we calculate what the value should be. V ~ ( -range, h, 0) (vector from a point at distance range, for a unit with height h) V = (-range, h, 0) / Sqrt( range² + h² ) (divide with the length to have a normalized vector) N = (0,1,0) value = N * V / dist² = h / (Sqrt( range² + h² ) * range² ) As you see this is again a formula with a square root, it should best be cached (there will be a lot of units with the same height and range). Line of sight, the algorithm Until now, we have two extra caches, and still a lot of extra calculation work. Calculating V still requires a sqrt calculation, and some 15~ish native operations (addition, multiplication ...) for the whole comparison (according to a fast count I did). While the current circular comparison only requires 4 native operations. Also, the current comparison has a very regular patter (a simple circle), and this is used to optimize code. While there's no pattern to be found with the method explained above. So there's only one way to solve this (at least as far as I can see it now), that's getting rid of unit based LOS updates to get rid of most checks. And use a continuous fill algorithm. For the entire region. The algorithm would need two usable collections (arrays, hashes, attributes of a tile, something else) per player. Those are "VisibleTiles" and "BorderTiles". And two collections (TilesToCheck and CheckedTiles) to work with. As initialisation, all tiles with a building on it, or a unit standing there, owned by that player are added to the "TilesToCheck" collection. Since we don't need to have a single point, we also need that CheckedTiles collection to not do double work. Then we loop through the "TilesToCheck" collection until it's empty. The tile is checked for visibility via the formula mentioned above, for all units and buildings around the tile (all units and buildings in general, or use some selection to only test the nearest ones) If the tile is visible and not yet in the "VisibleTiles" collection, it is added to that. It is also removed from "BorderTiles" if it was in there. If the tile is not visible, it's added to "BorderTiles" and deleted from "VisibleTiles" in case this was needed. If the tile changed state (e.g. from Visible to Border, or the other way around), all the neighbouring tiles are added to the TilesToCheck collection, unless it was part of the CheckedTiles collection This tile is added to the CheckedTiles Collection Once it's initialised, at each simulation step, we just need to copy all the BorderTiles to the TilesToCheck, and let the loop run. The border of the visible region will be adapted as units move . All the tiles inside the region won't need to be checked anymore, and all the tiles further outside the border also won't need to e checked. In the best case (when the border doesn't change), you only have to test all tiles on that border. There are some problems with it though. The algorithm won't notice created holes. If you all start in one point, and the units spread out, so that the center point would become fogged again, the algorithm wouldn't notice that. I have no I idea how many times this happens, I assume not too often, and I don't think it's a big problem (any enemy units that got there had to pass your vision line anyway). So I would probably leave it that way. A nice addition would be the "Don't look though walls". When you see the tile that became visible had a building on it, you could just make the tiles with the building visible, but don't add them to the "TilesToCheck" collection, or to the BorderTiles. So that way, further tiles won't get checked and you won't be able to see further through the wall. Now, this would only work if the wall is long enough. When a unit's view range reaches a tile at the end of the wall, the fill algorithm would go around it and start filling behind the wall anyway. It might or might not give a strange effect. That's to be investigated. (anyway, one more reason to build long walls So, I'd like to hear your thoughts on the feasibility of this (getting rid of Unit based LOS) and how this would affect the rest of the game (e.g.single units can't suddenly get an enemy in their view, or at least, this can't be tested). And to Lion: Of course you love Archers. But Leper said there were already too many Archers working on the 0AD.

Being not-commercial is not dependent on the license. You're just not-commercial if you don't sell the game. Next to that, "non-commercial" isn't part of the exceptions. So being non-commercial has no value here whatsoever. Instead, saying the project is used to learn and study a subject does make it fall under one of the exceptions.

If you take an easy map for the AI (lots of empty space between the obstacles, almost no water and few mountains), then it's actually quite playable. Also avoid factions that are difficult for the AI. Aegis tends to get stuck with the Maurian elephants, and can't manage the Athenian rock throwers. Anyway, if you just want to design nice maps, you can also do that in Atlas. They'll sure be playable in the future.