wraitii

I'd be 100% fine with that. The GLSL support is indeed most likely not perfect and the renderer really could use a bit of work anyhow. Though still, I'd rather see you working on some other things in your to-do list first.

I think this is a legitimate issue that can only be truly solved with hard data: we need to know who doesn't support Glsl "fully" in the 0 AD player base. We're currently only requiring GLSL 1.10. Apparently some semi-old linux machines have trouble with them. If that's not fixable by updating the drivers and the number of people running such machines are high enough (~5/10% of the total), I think we'd have a good reason to keep ARB, despite whatever pain it might be. Secondly, I think that this won't necessarily allow us to do much fancier stuffs in the GLSL shaders because fancier stuff require newer versions of GLSL and OpenGL. Though it's probably much less of a hassle to have different GLSL scripts for different versions than different types of shaders altogether. Finally, I stress that ARB is indeed old, deprecated, and that it's already not up-to-date with GLSL in 0 AD's current codebase. I also agree it adds a lot of code in the C++, I've run into it once in a while and it's not too nice.

Hi Niek, It's good to see new developers interested in the project. AI development is actually very undocumented, as nobody took the time to document it properly (in part because it changes a lot, and fairly often). There are a few things on the Wiki though here. As lead AI developer (de facto), I'm working on Aegis (in the AI file, it's currently qbot-wc). I'm currently rewriting a lot of code on that too, so it's probably best for you not to start with that bot. If you want to get used to the code, check out how qBot works (in the AI files, it's the "qbot" folder, which includes the "common-api-v2" folder). If you have any questions, PM me or try to catch me on IRC (#0ad-dev) (it's not out of place, and there's no real place to ask this unless you want to post a proper application, in the dedicated subforum).

Updating the status. Major features: -we have exponential armor -we could probably get the MP lobby in "shortly". -I think Josh| is working on the Options menu, but I have no ETA on that. -Running/Charging, Capturing Buildings, Trample Damage and conversion seem out of the equation. I think the new music is sort of in. No idea about elephant animations. Bugs: -Ranged units turning bug is I believe fixed. Performance wise; We could probably quickly get in Kuranes' pathfinder patch (perf difference ranging from 5% to 15%, apparently, but it's better than nothing), and the RangeManager optimizations, which would improve that component's speed by about 900/1000%. RedFox wants to commit his shader rework as soon as possible. No idea on possible performance improvement (I mean it's most likely faster, but I don't know by how much). There are several other patches for performance, but those are trickier/impossible to review, which is annoying. Other stuffs: -we have a quite advanced attack notification patch, would be good to get into A14. -we also have a (working, iirc) patch for giving elevated units a range advantage. Might want to commit or not. -indefinite farming is being talked about, as well as regenerative resources, and new fishing behavior. -new corral features are also being talked about. Overall, as we ought to be in feature freeze, I'd say push back. Edit: Ah, also we have several OOS errors with AIs in MP but that'll have to be sorted out when I finish rewriting Aegis' core, which should be possible this week.

Yves, with so much work put into understanding the logic behind Spidermonkey, do you think you could write a (as comprehensive as possible) guide to good JS use in 0 A.D., what to do vs what not to do and things like that? Or is that out of your scope? (obviously after you're finished with this) I'm asking because I haven't really found serious resources about JS optimizations and it really varies form compiler to compiler so having a specific list of "Dos and Don't's" would be pretty cool.

A few you might use (second one might require photoshopping the black lines on the horizon):

Matter of fact, I'd like this: it sounds like a good idea to gradually replace resource gathering. We could task units to the blacksmith to create metal (perhaps with a wood->metal conversion that would be improved by technology?) instead of going to mine. The problem is that this would still mean a huge need for wood, which is quickly becoming a limiting supply in the later game. Not sure what to do against that. Perhaps some kind of "farm" building that would give out wood (start depleted, very slow repletion, can only be harvested when full or something). Obviously the market is another way to replace resource gathering late-game but it's not always usable and I think it would be good to have alternatives. I kind of like the idea of having "specialist" buildings too, but that might make this all too "Anno"ish.

I think the roof looks weird, for what it's worth. I'd expect it round, or sloped in one direction only. Though if it happens to be historical, keep it like that.

Second solution still is per-vertex so still requires subdivision (unless we use geometry shaders but those are not really supported widely). Basically there's no way around it: if we want a mesh to conform to the terrain, we'll need clever subdivision.

Generally I think for any object that would be aligning to the terrain in a "smooth" way (think field or wall), we'd need to adjust the mesh at placement, which is reasonably efficient. The problem is that the meshes will need subdivision (probably). If we do not want to adjust the mesh itself, we could give each vertex a "height displacement" value and the vertex shader would move the vertex accordingly, it's basically the same but it avoid changing the mesh (though not the mesh object, so I'm not sure it's actually interesting).

Pureon: cool screenshot at Mediterranean Coves Jeru: Just seen that... It reminds me I need to like that FB page

I'm not quite sure how you might have gotten that first error, it sounds quite buggy and very much like something that shouldn't be able to happen. I've fixed the error with Iberians on my repository though.

Made the water specular stand out more. Might be a bit too much right now at some angles (both sun and camera), I'd like some feedback. A sunset screen: (compare with older things).

Edited the front post to give out my full name (I've been thinking of doing it for a while, and finally decided in favor as I'm now moving into business school. After all, this is a serious project which I'm proud to be associated with) and I added myself to the programming list too (I was listed under AI), hope it's alright.

Some discussion that revolves around two tickets: -The already committed "limit to the gatherer count per resource" (1387). -The yet-to-be-committed "display the number of workers on resource X" (643). I think those two are linked and I'me putting up a discussion because there are a few design issues right now (and I should now, I committed the patch for 1387). So right now each time a gatherer is tasked to a resource, it will be added to that resource's "gatherer count". If the resource is "full", the gatherer tries changes plans. For convenience's sake and help for the AIs, I've made it so that when a unit is returning resources but will come back to gather, it's still "assigned" to that resource (this avoids units coming in and "stealing" your spot, and does help the AI as it has a real count of how many units are gathering, and won't assign thousands of units to the same tree just because others are returning resources). There is no discrimination between players. It is all handled automatically by unitAI (there is possibly a few missed cases though, in particular there is a ticket opened for some cases where apparently the units aren't removed properly). Two problems: -it's not entirely logical: if units need to go really far away to deposit their resource, it might be better if they were removed from the "gatherer list". Basically i think it might be better to simulate a unit being in voice range to say "No I'm working there, go away", ie have a maximal range after which the unit will be removed from the list even if it's returning there. This should probably also be true for units that are tasked to gather something from afar (if you order a unit to work on a tree on the other side of the map, right now, its spot is taken immediately. Not really good. Particularly for the reason below). -It's gameable. Since there is no distinction between players, a player can very much prevent other users from gathering somewhere simply by tasking units to it. In particular, right now, with enough dedication, you could task units on an enemy's mine very far away, make it full, preventing the enemy from collecting, and never actually going to collect. This would be fixed by changing the behavior to have a maximal range though. Still, it might be better to make this limit per player, perhaps? So questions: -should there be a maximal range for the behavior or should another system be used (weak link/strong link or something?) -should it be split between players to avoid gamey issues and some other odd cases? Now it's linked to #643 because I believe we could simply use the same unitAI system to add the gatherer to the "gatherer count" for that resource there. Only we need to agree that a gatherer returning resources is still gathering (and here the maximal range might not apply). I would advise against not counting gatherers returning resources at all. This means AI would need to count on their own again, which is slow and inefficient and ugly and not safe and so on.

Those are absolutely mindblowing. I think they're a huge improvement over your earlier tries (mostly because they look less "blurry"). Not a fan of the "tilt shift" for the fisherman icon though.

Thanks for reporting this, I'll look into it as soon as I can (which should be sometime next week, my orals will be over and my FM13 addiction should have lowered by then).

Generally speaking, this is a fairly surprising turn of events

Basically I think it changes the shading method from using surface normals (blocky) to using vertex normals (as does the game, which gives an illusion of smoothness regarding lighting).

Agreed. Looks just a little thin to me, but otherwise it seems like it will look pretty good. Recommend you use "set smooth" in Blender to get a better approximation of the end result, though I think you need to remove it to export the collada files.

Aegis is in a state where if you let it play, it's reasonably skilled. On "Medium", I believe, it doesn't cheat. hard/very hard make it collect more ressource, easy make it collect less, and there are a few other changes too (I'm pretty sure it starts attacking later and builds fewer military buildings so it recruits units slower. Not sure about different army sizes though). Work on AI is very much still planned, however, but progress is stalled right now (I'm mostly doing it and I'm focusing on something else). Aegis can be overwhelming for a beginner player. I suggest playing very easy until you feel more at ease with the game. It's not really too hard to defeat once you get to know it.

I think we already model-swap airplanes between air and ground mode. I would suggest adding an "multiterrain" component of some sort that would specify how to handle air-land, land-water or air-water transitions (same model? What template animated transition?)

This is sort I a side request but I'd like it if the animation guide was going into slightly more details. I have tried and failed to load an animated mesh into 0 ad and it's really hard to figure out why. Anyway, good job! I'd like to see the Nile crocodile myself, looks like it could fit some maps

From my experience, in our genre, more is usually better. There are two reasons not to have more civilizations: -if two civs are really similar (gameplay-wise mostly), they could be scrapped. -if it introduces unbalancing. Right now I do not think we have the first issue. Beyond art beeing fairly different, the "sister" civs play slightly differently ( most notably the Greeks) which is welcome as it offers more playstyles. As for the second one, it's mostly ok. Given historical accuracy constraints, I think 12 is a really good number already, and it keeps things interesting.

Do note though that if you can without much loss of detail reduce the number of triangles, you should try, it will be faster (ever so slightly) to render