sanderd17

For anyone wanting to play the game, testing art, or whatever, you can still revert to revision 14949 if you want. Looks like this issue well take longer to solve than first thought.

You'd have to do it cleverly. Not store a list of cubes with their information (position, texture ...), but have a formula of some kind, with a list of exceptions. Memory is a limiting factor if you do it naively. Say you need very little information per square. F.e. a reference to a texture (4 bytes), a position (3x4 bytes)and some other info s.a. a weight and other characteristics (estimate 10 bytes). You'd arrive at 26 bytes per cube (and that's a serious underistimation, as you'd normally need more info per cube). If you then have a 100x100x100 world, that would mean 26 000 000 B = 26MB of memory. While 100³ would either mean your cubes are very big, or your world is very small (100m distance for a man is very small, while a cubic meter cube is a bit big to move around). A bigger world like 1000x1000x1000 would mean you need 26 GB of memory. While most computers that are sold now only have 8 GB of memory. So you'd have to start working with the hard disk (which is painfully slow), or find some other way to store them (f.e. only keep the visible tiles in memory, keep the rest "calculatable" but not stored anywhere).

If you wait a while, it should get fixed. Yves is occupying him with it.

Rpg's would probably work fine. Speed isn't really a problem there, so you could use any engine.

Imo, the entire buildingai should be disabled if a building has no attack. Maybe a warning can be added to buildingai if this happens. We shouldn't waste resources on components that aren't used.

You can see our estimations here: http://trac.wildfiregames.com/roadmap Though I think we'll finish it a bit earlier than those mentioned 10 days. It's always hard to predict a release date from months before it. At that point we didn't even know what features would be in the release. Let alone how long it would take to prepare them.

Cavalry can work (it can gather food), though it's possible the idle button doesn't select them anymore. Deep forest is indeed a bit crowded for the minimap (people can hide below the trees), though on most maps, there's no problem. Wall end snapping isn't really fixed, but you're allowed to overlap wall pieces with unpassable terrain (so it's easier to close off a piece of ground). For the tree gaps, I don't think that's needed, it makes it a bit more interesting IMO.

A known bug with random maps in A15. This is fixed in svn.

Possible? Yes. Will it take very long to achieve? Yes. Our renderer isn't really made for FPS. We have lots of moving objects (units and animals), while a FPS mainly has a very detailed static mesh.

The code is released under GPL. See the comments in every file: http://trac.wildfiregames.com/browser/ps/trunk/source/simulation2/components/CCmpRangeManager.cpp

The CC-BY-SA license is made specifically made for artists so they don't have to worry about the legality of their distribution. Sometimes it's hard to keep track of all source files. Thus the CC-BY-SA license only applies to the published content (and everything derived from that point). Nobody can demand you to also publish the source files (in other words, you risk nothing when losing it). The GPL license is different, that license states that every binary distribution also has to be accompanied with the source, or that the source must always be provided when asked. This would put you into legal problems when you lose the source.

non-profit != CC-BY-SA For CC-BY-SA, you allow explicitly that others can modify and redistribute your work, under any conditions they want. As long as they mention you as author/creator in some appropriate way, and the modified or redistributed work has the same license. By mixing CC-BY-SA and other content, you get into problems. F.e. when you take a screenshot containing mixed content. The screenshot is a derivate of CC-BY-SA art, and thus have to be under the same license, which means it allows modifications. But that also means you are allowed to create derivative data of the non-profit art indirectly. Which is most of the time not allowed. Fun fact, it's even possible to sell CC-BY-SA art, as long as you give it away freely too. But it puts no limit on selling art collections s.a. mods. Some users will buy it for the ease of use, as opposed to downloading all art files separately. http://creativecommons.org/licenses/by-sa/3.0/

you'll have to edit the GUI files. Certainly for those resources being displayed at the top of the screen. I'm not sure for the selection gui or the cost tooltips.

... we're not really focused.

Hi, nice to see new programmers. We're currently working on i18n, and there are a number of small and big issues with it, but at least they're quite well defined (https://github.com/leper/0ad/issues?direction=desc&milestone=1&sort=updated&state=open). If you don't mind downloading the source code again though git, some help on some of those issues would be welcome. Another ongoing issue. Since the new SpiderMonkey version, there's a lot more logging of undefined values. This is to prevent bugs. It would be nice to check for those warnings when they happen, where they come from, and whether it's intended to be undefined or it's most likely a mistake. Fixing the warnings is easy, but that's not our main target, we want to use the warnings to see possible bugs in our code. See http://trac.wildfiregames.com/ticket/2372 Oh, forgot to mention, you can always join #0ad-dev on Quakenet to discuss stuff (most people are around during European evening).

Those [PATCH] issues are mostly issues where the patch is not complete and/or needs improvement. So it's not ready for inclusion. It's marked as PATCH as people know they can continue with someone else's work. The real problem are those marked with the "review" tag. Those patches are supposed to be ready, but are waiting for approval of some kind (code quality, gameplay aspects, ...). Depending on the complexity or the multitude of opinions, it's sometimes hard to review them. And it's something only team members can work on to get them included. While those PATCH issues can be continued by anyone. For the naval support, it's getting better. The code to let the AI plan a path through the water towards the opponent is getting better.

Josh should have fixed those errors now.

My bad, that should be resourceSupply: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/components/ResourceSupply.js

The movements aren't affected by the animations (art and simulation is quite separated).

I guess Petra doesn't like you help her. It's hardly a bug though. A normal player shouldn't help the AI.

If an animation exists (f.e. the stone-mine animation fits for the stone subtype animations too), then you just have to define it in the right actor files (which might be a bit of a hassle). If you don't define an animation, a unit always defaults to the "idle" animation.

We normally don't close subjects when the discussion is finished. We only close stuff when it gets heated.

First note that we have a resources subsystem. F.e. there's food.grain, food.fruit and food.meat. Those subtypes result in other animations (for carrying and gathering), but get counted towards the same total, to not make the game too complicated. To define new resources or new resource subtypes, there are some components involved. There's the ResourceHolder which you need to let entities contain an amount of that resource (F.e. a rock carries 5000 stone thanks to ResourceHolder). Then there's ResourceGatherer to let units gather those resources. You also need to drop then somewhere, that's defined in ResourceDropsite. After you gathered some resources, you also need to buy stuff with it (note that for buying, there are no subtypes used). Buying is defined in the Cost, ProductionQueue and Builder components. After changing the simulation, you'll also have to change the Gui (displaying the right icons) and the art side (adding the animations).

For now, A15 is our most recent release. Only SVN versions are newer. But we're planning to release a new version in a few weeks. @modders. It might be good to also do a release of a mod when 0 A.D. does a release. That way, players with an older version can still download the mod suited for their version. If you keep developing on SVN, you should have a working mod against we do our release too, so it can be released more or less together.

Euh, isn't it just because Artesia is updated to match the SVN version, while shieldwolf plays with A15? A15 expects the old formation definitions (those don't include "formation/", that's how the extra "formation/" got into the path). There's nothing wrong with Artesia code.