historic_bruno

Hi, it's a known problem of official releases.

I never claimed they were impossible problems, I said: "it gets ugly in a hurry if we want full 3D terrain. IMO this raises more problems than benefits." And I'll stand by that statement until someone cares to demonstrate that it's as simple as zoot says (not the rendering alone but the integration with gameplay) Though I should also mention that I'm not passionate about cliffs at all, we come close enough with the current simple height map for my liking. The texturing is ugly but myconid has shown that can be improved -- with no effects on gameplay at all, which makes me happy

You mean something like http://trac.wildfiregames.com/wiki/Manual_Units and http://trac.wildfiregames.com/wiki/Manual_Buildings (properly updated)? I know 0 A.D. is a historical game but let's not reinvent the wheel

Eww, that's really ugly But I like the concept, we can certainly make it look better.

As I said above, not only the pathfinder, but most other game logic is 2D as well. We've never planned to have true 3D terrain or movement. I thought I already did, but here are some graphical depictions brought to you by MS Paint Here's how terrain works currently, with 2D height map: The brown rectangles are structures, though you can substitute other game concepts. The way obstructions (and thus pathfinding) work, the difference in height between the two buildings is ignored since it's a 2D obstruction map. Most of the time this works well, the only time it doesn't is when you have a building extending off a steep hill, it might block buildings underneath. But we don't allow buildings to be built on a steep hill so it doesn't cause much issue in practice. Here's what you're proposing: As you can see there are two buildings whose foundations only differ in height. If we still have a 2D obstruction map, then it's impossible to build both of these buildings because the one foundation's 2D obstruction would block the other And obstructions are just one example, as I said, all(?) other game logic is 2D including territories, pathfinding, vision/LOS, and range queries, so it's obvious to me anyway that we would need to extend them all to be 3D or pseudo-3D with special cases for this vector field terrain. How else might it cause a problem? Well imagine the brown rectangles are units. One is a healer and one is a wounded soldier. Let's say the cliff is some ridiculous exaggerated height, maybe 200 game units. Well because the range manager is using 2D data structures, the healer and wounded soldier are almost on top of each other, therefor the one is in close range of the other (2D). Obviously the healer shouldn't heal the wounded soldier because it's out of 3D range, but it doesn't know that Territories are another example, say your territory extends under the cliff to where the lower brown rectangle is. I come along and want to build on top of the cliff directly above, but I can't because territory manager uses a 2D data structure and ignores the cliff's height

Well if it's just one tile stretched instead of several, I guess that would work, it would mean separate logic for handling position under the hood compared to what's visible in world. I was thinking you might have several tiles overlapping instead of stretched. We could also make cliffs a purely visual effect and not allow pathfinding, territories, or building on the stretched part -- less than ideal.

I didn't know that (having never played AoM), sounds like a fine idea to me.

I'm not sure about that, obstructions are all treated as 2D currently, but big overhanging cliffs mean you have different levels of obstruction varying by height (it's 3D). As an example, consider a cliff with a building on top right on the edge, a unit should (intuitively) still be able to walk, build, etc. directly under the cliff, but if we only have a 2D obstruction map, then the building's obstruction would block them. The converse is true as well, I have this big nice cliff to build on, why am I blocked by a house hundreds of meters below? It would affect not only obstructions but territories, vision, and range queries are probably all simplified as 2D data structures currently. I think it gets ugly in a hurry if we want full 3D terrain. IMO this raises more problems than benefits.

I would like an in-game updater though, only not tied directly to SVN trunk

A map editor for mobile devices would be even lower priority than porting the game itself to iOS or Android, which is not even on our radar Porting Atlas might be technically feasible with difficulty, especially because of wxWidgets which is a massive library for the UI, but would it be usable on a mobile device? There's a lot of small UI elements which are designed for mouse and keyboard input. If not, something else would have to be designed from the ground up. Though our maps have a fairly simple format, so writing some other app to manipulate them is possible as long as you adhere to that format. What about a web app that would work on desktops and mobile devices? Philip has done some demonstrations in the past that show map and game data can be displayed on a web page using HTML5. With WebGL you might even be able to get a full 3D environment for editing maps. Random maps would be even simpler, as most of the code for generating random maps is written in JavaScript, all that's needed is a UI to edit the maps and some rendering code to display the results (probably a simplification in 2D). The output is already JS arrays and objects, no XML or binary data parsing is required.

Not in this case, at least I don't know about the edges of the map.

The unit portrait currently shows generic name and tooltip info: The "counters" stuff is manually typed in the tooltip field. The only other textual information we could show is the history, rollover, and specific name fields. History and rollover can be quite lengthy, here's the Celtic spearman as an example: <History>The spear was the main weapon of the Celts, arming the bulk of their forces. The average Celt would only have to take up his long spear and body shield to be ready for battle. While armor was rare the rabid fighting spirit of the Celts more than made up for in vigor what was lost in protection.</History> <Rollover>Probably one of the most primitive units in the game. Fighting with a sharp object at the end of the pole didn't require a lot of technology to develop. It also allowed the human to distance themselves from their attacker. As time passed the spears got longer and longer. Started with a fighting style similar to using a quarterstaff, then to using them in numbers as a 'pin cushion' vs. humans (sarissa in a phalanx). Later it was developed to combat cavalry. During the medieval period it evolved to the pike. These units tended to be armoured as heavily as possible.</Rollover> I think that's beyond what most people want to read in a tooltip. Of course we could shorten those fields in the entity templates, at the expensive of valuable info, that's something that needs to be decided (how and if we plan to use them and their max length). I personally would prefer leaving that info for some other UI window, maybe a "History" screen like in the AoE/AoK series. Once you've read it, do you really need to see the in depth history every time you hover the unit portrait? IMO it would become quite ugly. The training tooltips are a good demonstration that mixing arbitrarily long text + numeric stats doesn't work well in practice: It would be even worse if we added more text. Whereas if we have a single tooltip with textual info and a single tooltip with stats only (not all but the most important ones) then it looks tidier: Another possible idea: we could move stats to the unit portrait tooltip, and then have a separate "?" or "i" icon which provides description and history. In other words flipping the two as they are now. I think it's more clear the way it is now though On the subject of training/construction tooltips, their style needs to be updated to match the new unit panel.

Nice job, when do we get them in the game?

I would like scaling as a built-in function of the GUI engine, but there are probably enough higher priority issues that it won't be done for some time (if ever).

One problem I noticed is there are a bunch of females standing around. I investigated their UnitAI state (open the Developer overlay with Alt-D, check "Display selection state" and select something) and it said "gathering". From the gather target entity ID I was able to find what they wanted to gather. It turns out that map generates some chickens inside the foundation of the civil center (use Alt-W to toggle wireframe mode to see this), and because they are the closest target to the civil center dropsite, all these workers are trying to gather from it but failing. That in turn economically cripples the AI. It's just a bug in the Deep Forest script, I'll create a ticket for this. Thanks for reporting it

Looks great IMO we need to show attack type (melee, ranged, charge) in the stat tooltip, since some units can have multiple attack types, and there's currently no indication of attack type other than what can be inferred from the unit appearance or description. See the training tooltips for examples and the logic to implement it. Eventually the training tooltip stats will go away because it's overkill and ugly, to be replaced by a separate reference window, but it can serve for now as an example of what to include in the unit panel.

Saved games work for me on Windows and Ubuntu. Can you try deleting and reverting that file (gui/savedgames/load.js)?

The simple case would be something like adding prop points to existing wall models such that a unit would move "onto" the wall. There's currently no mechanism in the engine for doing that, as far as I know, props have to be defined in the actors. The complex case would involve pathfinding, a different pathfinder than normal unit movement, so that a unit would walk along a predefined path, up a staircase or in a door, and out along the wall itself. In both cases the unit would need to be able to interact with the world and also be targeted by enemy units, so it adds a lot more complexity for a mostly visual aspect.

Sounds like a good idea. One thing we can do is link to http://trac.wildfiregames.com/wiki/Basic3DImplementation, a tutorial which Pureon has been working on recently, as an example of how to use Blender to create game content I definitely agree about mentioning areas of contribution, this fits in with recent discussions over the art department's future, etc., it might be nice to link a list of possible art tasks broken down by category, which could be updated without contradicting the BlenderNation info. Zaggy1024 would know some good details about the animation side of things. He uses some fairly advanced features of Blender and has encountered and solved a number of issues along the way

Hmm, Cygwin doesn't sound like an advisable way of checking out the source code, though I can't say if it's to blame for this error. Are you using the latest version of Cygwin? Perhaps more helpfully, can you check the Windows event logs for more details on the access denied error?

Very nice At the moment, we want to review patches for http://trac.wildfiregames.com/ticket/1493 and http://trac.wildfiregames.com/ticket/1497 which I believe are prerequisites for some of the enhancements.

With all due respect, I don't think that would make much difference. There are lots of arbitrary ways to organize and we can produce all sorts of fancy tables, graphs, and documents which no one will ever read but which need time for maintaining. The critical point is this: as a volunteer project, we simply can't dictate what people choose to work on, and if someone doesn't care to work on e.g. advanced AI or unit conversion, does it matter if it's classified core or non-core, high or low priority? Similarly if someone wants to work on it, does it matter if it's core or non-core, high or low priority, or if we preferred them to work on something else? If they work on it and make progress, it's better than if no one worked on it. The most we can do is make suggestions and motivate, which we do There's another complication. It's not all about new features or even improving existing ones, but there are a substantial number of bugs, some higher and some lower priority (some as a result of recently added features, etc), which take time away from strictly focusing on "completing the game". Though depending on a bug's severity it might prevent completion of the game. We're not so much focused on bug fixes at this point but they frequently arise and need fixing in the short-term (something breaks the build or the game stops working on OS X, etc). I think for now the combination of http://trac.wildfire...ayFeatureStatus, http://trac.wildfiregames.com/report/3, common sense, and asking a developer is a good way of finding out what's important or not (doesn't include art tasks, as stated above they haven't used Trac or public forums, this may change out of necessity - we'll see) There are about 20 open tickets with a "review" keyword, but not all are needing immediate review. Some are postponed for various reasons (read the comments to see why), some are very low priority tbh and will naturally take longer to get around to them, some need a more detailed review which could take hours, while some need the expertise of one individual who might be especially busy atm We just happened to have a flurry of patches over the past months but that hasn't always been the case. Meanwhile we have to push forward with other things as well.

It's not realistic though, I mean a trained infantryman + captured wild horse doesn't make a trained cavalryman by any means. So you'd basically have an infantry unit handicapped by trying to ride a wild horse Instead of that, it seems easier and more accurate to train a cavalry unit -- where "training" abstracts several related concepts like conscription, paying/hiring the unit, acquiring equipment and actual combat training. Though capturing wild animals is planned for herding/corralling at least for resources, but I could imagine other benefits tied into that: say you capture N horses, it might increase your cavalry production rate or something.

Who said our decisions don't weigh public input? I'm sorry if that's what you take away from this discussion, as it's not true at all. It takes all of 30 seconds to create a new topic or post on the forum, and people are free to do so on any topic related to 0 A.D. Often a developer reads it and comments if they have time, sometimes it becomes a lengthy debate. In this way a number of things have already changed about the game, new features added and existing ones changed. It's not like you would be banned for opening a topic on triggers and debating their importance to the game If you made a strong enough argument, it might change the prevailing view. Even if we put every decision to an open vote, I don't see it speeding development, I would expect rather the opposite. People are more likely to consider only their own limited personal preference and not, say, the resources the project has available, technical feasibility (some things are hard to explain/understand), and long-term goals. You'll just have to trust that the developers are reasonable and competent enough to make decisions on behalf of the community and for the good of the project, as evidenced by the results of those decisions

(this is not a reply to zoot's last post ) You need to appreciate 0 A.D. as a free open source, volunteer-driven project with only one developer who has received compensation for his work, and even he has significant outside commitments We're not organized like a game studio, maybe 8+ years ago it would have been good to take that approach, but back then we weren't FOSS either so it's a moot point. I believe we have been FOSS for just shy of 3 years? In that time we've completely rewritten the core of the game (with significant benefits); art and music have been mostly revamped from late 90s to 2010s standards. There's nothing wrong with an evolving vision of the game. Some things you simply don't know whether they will work until you try them, and on closer inspection they may be a really good or really bad idea. In that sense, 0 A.D. is not solely concerned with finishing something ASAP though that's nice, but also providing room for research and experimentation on new ideas and techniques, so that when we reach beta, we have a bunch of really good, thoroughly analyzed ideas instead of a few decent ones pieced together with hacks (a constant struggle to find that balance). Also it helps to keep developers interested since we aren't being paid or contractually obliged to contribute, little side projects and experiments are one way of keeping things interesting. That shouldn't be confused with not having a focus. I don't feel that we strictly need to "accelerate" development, it seems everyone who is working on 0 A.D. is already doing the best they can with the time/expertise/interest they have. We have up and down periods of development, but I'm sure that would be the case no matter what high level decisions are made. And I'm constantly impressed by our community contributors who help us complete the game, they are dedicated, knowledgeable, and willing to take on technical challenges. Probably the "last resort" is to cut the features and aspects that at least bring 0 A.D. on a level with existing RTSes (e.g. multiplayer, AIs, naval warfare). Actually I see no reason why we can't go beyond many of them (since we don't arbitrarily limit ourselves) - which would be a coup for FOSS[oftware]. You say people won't play an incomplete game (which is debatable given how many people download our alpha releases - 120,000 downloads this year from SF alone, we could get Philip to generate updated usage stats to see how that translates into actual playing ), but are they more likely to play a game with substantially less features than the average RTS? Why? I think people don't mind playing an incomplete game as long as we update it regularly and each update provides a noticeable improvement. Further, open source communities seem to thrive when people are willing to use and test "incomplete" software. On the programming side of things, the staff forums are surprisingly little used. It's rare to have a technical/design discussion there. We much prefer active discussions in IRC, forums, and Trac. IRC logs are now publicly accessible so even that is open. Certain planning decisions are made in private because it's not really helpful to have everyone give input on every decision - some things are best left to the team to reach a consensus. Even those decisions tend to filter to the public view, leaving not much that is exclusively private. The art side is a different matter, since they've had a certain approach that has worked well enough for years (likely from pre-FOSS days). They may re-evaluate that approach in the future for various reasons. We're basically all in favor of open development though BTW, http://trac.wildfire...ayFeatureStatus makes it pretty clear (I hope) that not everything we want to do is listed because there are many minor features and bugs to be resolved (http://trac.wildfiregames.com/report/3 is just a taste), but also that it's not set in stone. I can't think of a reason why we'd outright reject someone contributing triggers for part 1, as long as it didn't distract from what we consider higher priority. And if everything else was finished, why would we delay part 1 for e.g. advanced water effects if that proved too difficult -- it's a low priority feature. So you see, it's fluid.