aeonios

Our combat system in general is not friendly to the sort of formations that we're trying to make. It just won't work. If we wanted total war style formations we'd need a unit production/unit control system that is more similar to total war. The current aoe-style combat system really can only support simpler aoe-style formations that don't need to stay together when attacking, which makes any sort of formation-based bonuses totally impractical. The devs keep trying to have it both ways with everything and the gameplay is already garbage because of it.

Ok, after looking over it what I found was this: https://gdpr-info.eu/art-89-gdpr/ Because we are not collecting any personally identifying information (e.g. names, addresses, gender, religion, personal preferences, etc) in any sort of structured way and because the only reason that we collect any information is for archiving or statistical purposes it seems that we are most likely exempt from the need to provide legal disclaimers for anything. The law explicitly states that it was created to limit data collection for advertising purposes and the sale or abuse of any such personal information, and there are specific exclusions for trivial purposes like archiving and the implicit sort of records that occur with things like forums. Collecting, eg, system information for statistical purposes to aid in development is also exempt, as long as we don't collect anything that would allow individual users to be identified. Obviously anything voluntarily submitted in public bug reports is also exempt, not that it actually constitutes personal information anyway, but in the case that it does the law does state that users have the right to have such information deleted or restricted at their request, which again is a non-issue as long as forum posts remain editable. Our existing agreements are more than sufficient I think.

I don't think any of that should apply to us. Logs are different from tracking user preferences and personal info, and the only data collected by the game itself is impersonal system info used for community statistics and error reporting. What we collect and the way we use it shouldn't be relevant to privacy laws one way or the other, unless wfg is doing something unscrupulous that I'm just not aware of.

What? How? Where? Well yeah, if you have a limited set of biomes they'll end up being repetitive and samey. That's not what people are complaining about though. It depends. Some maps work better when using customized setups, especially if they're supposed to represent a particular place. On the other hand maps that don't (like mainland, frontier, ambush, etc) are probably better off using random biomes though. That's what the generic biomes are good for, making generic maps less boring.

It's in UnitAI.js. Apparently the reason that animals can't garrison has to do with the fact that garrison orders use an "INDIVIDUAL" state rather than an "ANIMAL" state. I haven't done enough digging to know what the difference is though. It doesn't seem like it'd be that big of a deal to fix either way. Capturing animals is trivial. We already have capturable units (ie siege) so there'd be no difference from that. Range overlays are for drawing weapon/aura ranges. While there might be some merit in allowing fancy range overlays (for auras in particular), it'd still be nice to have a non-footprint sized selection shape.

Why not? Just give it an aura. If you wanted to limit the sheeps per corral you could just make it an aura that affects garrisoned units and limit the garrison count. Also let me know if you have any specific requests for modding features for a24. Separating footprint from selectable is already on my list, and I'll probably have that done by tomorrow.

People are complaining that the generic biomes are ugly. It's really hard to fix that when they're defined as json. The json-defined biomes also present a lot of really unfortunate limitations, like only allowing for 2 kinds of huntable animals and (I think) 2 kinds of trees, as well as preventing the use of more complicated mixtures of layered texture patches and things of that nature. IMO the json files should just point to a js in a separate directory, which could be loaded to provide some basic global variables for common textures as well as a biome prototype with a standardized interface that could provide features like highly tunable (ie specific to the biome) texture decoration, more biome-specific trees and a wider variety of huntable animals, especially for the savannah biome. That would also allow map-specific biomes to merely fill the global variables that the map uses, allowing for easier customization without the restrictiveness of the generic json schema.

A bit of an update since I've had the opportunity to work on my own mod I've gotten a much better picture of engine internals I now have a better idea of how things work and where draw calls are coming from. 1. Unfortunately we cannot drop legacy support unless we can successfully track down the glsl crash that some people are still experiencing, and thus far no luck getting someone with technical knowledge to reproduce it. 2. The reason why a lot of units and buildings take up a lot of draw calls is because they use a lot of props as sub-objects. The props use a separate model and texture from the main object which means that multidrawelements would not do us any good. However for props which are rigid (which is most of them, except for heads maybe, although I haven't paid that much attention to the animations) we could most likely use drawinstanced instead, which would amortize away most of the cost of drawing units/buildings when there are a lot of them. The good news is that those things probably consume the majority of all draw calls, so we could get the total number per frame down to a very small number.

Oh, yeah they sure don't.

That's not really feasible, since the schemas for Attack.js and Armour.js need to be updated separately one way or the other. I think those are the only extra files that need to be updated besides DamageTypes.js in globalscripts though.

Actually you can use circles as well. Ungarrison/unit spawn does seem to end up at the edge of the footprint area though. EDIT: After digging around I found out that both selectable and footprint are hard coded, and there currently isn't any way to define the selection shape to be different from the footprint. It shouldn't be too hard to fix, but even if I do it won't be available until a24. Also I don't know why people keep insisting that damage types are hard coded. Damage types are defined entirely in javascript and are completely moddable, although there may be a few different files that need to be changed for it to work. It's not really any different from resources though.

The graphics stuff is part C++ and part GLSL, with a bunch of xml configs. You can find the C++ part under graphics->renderer in Visual Studio, while the GLSL is in binaries/data/mods/public/shaders/glsl. The xml configs are in binaries/data/mods/public/shaders/effects, although some things are also defined in materials, which are in the same general vicinity. Note that there are a lot of graphics commits backed up at the moment because of the feature freeze for alpha 23 and the upcoming re-release that fixes a bunch of bugs and performance issues people are having.

Yeah the AI is a cheating @#$%, and is still dumber than a rock.

Wheelbarrow techs are only useful if the initial carry rate isn't ridiculously high. I don't think I ever once bothered to get them in DE. The problem is that in the early game you may spend a lot of time waiting on resources to come in to build individual things, so longer waits are bad. Especially when the dropsite is placed right next to the resource so that there's no walking distance, which is generally the case in the early game and even moreso in DE where you have giant tree clusters that run out very slowly and in one big chunk so that the walking distance doesn't increase for a long time. Eh, I don't think all civs have slaves (like the celts). AoK did have a slow P1 but everyone played at 1.5-2x speed so in real time it was about the same as 0ad, which was probably why 0ad was designed the way it was. It just feels more like an artificial wall stopping you from playing well though. Nobody sane would ignore their eco for 20 minutes to muck around with stuff they can't even afford at the beginning of a game. Balancing eco and military is part of what constitutes skill, and placing a block on eco is something I personally find distasteful. True, but playing find-the-builder is irritating to say the least. It's pretty nonsensical to have to select one unit to place a foundation and another to build the building, even more so for combat units. If you're going to separate combat units and workers (which is something I do agree with) then the separation ought to be clean and total, otherwise you're still forcing extra micro that nobody wants to deal with. Well you could do something like the shiny selection circles that temples get, except with like a "no-corn" design. I think the restrictions are still the simplest and most no-nonsense option though. That's an interesting idea, not that anyone ever uses walls. I'm still pretty much a noob when it comes to modding though, so can't really help you there. Eh, I see how that works now. You end up with a lying stats screen this way, but I don't know of any other way to go about that. The engine/base scripts aren't really set up to handle progressive cost schemes. I suspect you could hack something up in js so that it counts foundations properly, but I don't really know enough about all that to have an idea of how to implement it.

Just my 0.02: - I don't like how you're constantly fighting the eco all game. You start out housed with half the number of workers as usual, and then workers take twice as long to produce. Not only that but they also have double the resource carrying capacity which means they take twice as long to return resources to the dropsite. Military buildings cost an arm and a leg in stone but you can't afford to gather it because you simply can't get workers on the field quickly enough, also same with units that cost metal like mercs not to mention upgrades. - I don't like the hard split for producing buildings. Not only is it a pain to find an appropriate builder but if you lose all your initial combat units before you get a barracks up then it's GG then and there because you won't ever be able to produce a barracks. It's also distracting that you have to use your combat units (which aren't good for anything else besides fighting) to build stuff, because it means you can't have them out doing what they're meant for, ie killing stuff. -The anti-farming aura is unintuitive and dumb. It'd be better just to add a building restriction to fields so that they can't be placed near the CC at all, rather than have people wonder why their farms aren't producing worth anything. -It's also kind of unintuitive that you need to get the upgrade to produce a second cult statue, and annoying since it's the only path to p4. -I don't really like the buildable siege catapults. Not only is it impossible to move them but they also barely have any range so you basically have to build them right in the middle of the enemy's base, which defeats the purpose. Also there's a good reason why siege onagers and trebs were separated in AoK. They filled two different roles with one being shorter ranged and more mobile, and the other being a specialized anti-building weapon. Even then the projectile speeds were slow enough that units could be micro'd out of the way most of the time, which is what kept onagers from being op.

Licences for code and art are separate, so if you use your own code then there's no problem with having it be closed source. As far as art goes, everything (including the music) is CC-BY-SA, which means you can use anything from 0ad without permission for any purpose, and even sell it, as long as you make it clear that the art is licensed CC-BY-SA and anyone else is thus free to rip it off and use it for whatever they want as well. See also:

Most melee units have a relative speed of 1.0, while archers are 1.1, slingers 1.2 and skirms 1.4, AFAIK.

After looking at the files you're right. They have a relative speed of 0.9, which is actually faster than pikemen. Siege towers have a relative speed of 0.7 by comparison, which is a little slower than pikemen. Given that only melee units can damage them and given that melee units are generally slower than ranged units, that's pretty ridiculous.

Eh, well that's true but I'm only counting blue units, not mercs and champions. Mercs and champions can't be built in village phase and it wouldn't make sense to allow for it either. It's pretty lame to force an upgrade to town just because there are no units available in village. In AoK where there were 3 age upgrades and the first one was cheap that might make sense, but we only have 2 age upgrades so cutting corners for any phase is bad. All the civs in AoK were basically equal in terms of unit rosters in dark age, not so much in 0ad. Of course I'm not saying that every civ needs to have every unit, but they do at least need basic counters for infantry and cav.

Eh, I'll tell you what the issue is. This is not how parallax mapping works. Parallax mapping is a displacement mapping technique typically using a 16bit gray heightmap and normals are implicitly derived. Trying to derive position from normals is backwards and wrong. It also causes severe sparkling/aliasing artifacts on cretan palm. If you try to add parallax to senegal date (which uses the same textures as cretan) you get the same issues.

If the camera moved then something changed, ie the camera view. In what universe? Sphere requires only one signed distance calculation per frustum plane. AABB requires a lot more complicated math, again per frustum plane. Profiler.txt can't tell you anything that it doesn't know. I don't think there's any info recorded for objects that are culled by visibility testing. Renderer only knows about objects which are actually submitted.

If the game on normal speed updates at 30fps and the renderer is trying to draw 60+fps for smooth camera scrolling then you won't be doing anybody any favors by forcing the renderer to be capped at 30fps. What we would need is a way for the renderer to know that it doesn't need to update animations or object positions if sim hasn't advanced, and then you might get less than smooth animation if the renderer draws right before the sim is about to advance. I don't know how that's usually handled. I don't think a semaphore would work that well either. The renderer has to make a synchronized call to enumerateObjects on the one hand, and then sim has to make a lot of synchronized calls to the renderer for submitting each object. Compared to simply reducing the CPU overhead of rendering I don't know if it'd be worth it given the amount of synchronization overhead that would be required. At the very least it'd require a synchronized queue on both ends. I'm no so sure about that either but I do know that we're using expensive bounding box tests rather than sphere tests and it might potentially have to check thousands or even tens of thousands of objects every frame. At the moment I don't have any concrete numbers because there's no way to collect statistics since visibility tests are done in simulation and sim doesn't have direct access to the renderer, but that's another thing that centralization would allow.

Yes but if render is running much faster than sim then it will sit there and spam enumerateObjects at sim. Synchronizing that to eliminate the wasted requests would be a serious pain. I do however plan on separating submission and visibility testing and centralizing visibility testing in the renderer. I suspect that on large maps the cost of visibility testing becomes very high so using a hierarchal system could improve performance by a lot.

Arg. It is really hard coded in an ugly way. De-hardcoding damage types would be difficult. I'm not even sure how to go about it, but it'd most definitely break everything.

No I mean like currently you can't set a building so that it doesn't decay in neutral but does decay in enemy territory, which is really annoying. At least if you can then I don't know how. I'm not sure if the bonus is hardcoded to only apply to melee or if it's just called that because someone was stupid. It even requires you to set the unit category it applies against to "Cavalry". I'm working on a lot of eyecandy stuff atm. Soft shadows, depth of field and improving random maps at the very least. The current random biomes are pretty fugly so that's another area that I'm planning to improve, but the way they work now (defined in json rather than in js) is too limiting to really fix it effectively. I dunno about ambient sounds. I'm not sure if that's hard coded or if it's baked into the music or what. Assuming it isn't the latter it doesn't seem like it'd be too hard to add as a feature for maps though. Walking sounds seem like they'd be annoying. I'd rather that we had sound effects for farming and gathering berries. I dislike how tree chopping and mining are all you hear when there are workers farming away right in front of you.