wraitii

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

I think that's a fair aim. If there is any indication that esr24 will not be too different from v22, I say go for it. Multithreading and stricter compiling are two very good points imo.

I'd agree with historic Bruno. If it seems like we can't really get more out of v17, then we should not upgrade at all. But if we can get more from v22, then it's interesting, even of right now potentially buggy. At the very least, your work wouldn't be most and could serve a a framework for a future upgrade once it's stable

I think it's a planned feature that never got implemented, but still should be someday.

I think the issue is that it's in the C++. But CcmpVision handles technologies already. Using the exact same stuff, here's a patch that appears to be working for that (just create a tech and try it). However I'm not sure if that resists serialization (which could bug in Vision too). Also in that component there's walkspeed, runspeed, and "speed", which seems to alternate between both and I'm not really sure what it means. UnitMotionTech.patch

Interesting bottleneck you found here. And great work so far, it's been a very interesting read!

I think if someone is willing to take the time, having the pathfinder as a separate library could be interesting in regards to "this could help the rest of the free gaming community, and probably more". Discussions about pathfinder are however usually fairly sterile, because there is a huge difference between theory and reality in that aspect. Crowd stuffs could be interesting, particularly as your description makes them "simple enough". It seems to me that pathfinding in RTS could use 4 steps: -Accessibility checks: as far as we know (we being the unit that moves), is the target accessible or is it not? If inconclusive, assume it is. Philip had implemented that with squares that were connected to each other. (I personally implemented that in JS for the AI using a flood-fill that's never updated after game start.) -Long-range pathfinder. Returns a few waypoints for avoiding big obstacles. This can also be set up to avoid forests, coasts, stuffs like that. That's the thing I JS-coded in the AI and that is inefficient there (also because it's fairly unoptimized. It's fast enough only because I downscale the map by a factor of 3). I believe that's were A* + JPS shines. -short-range pathfinder: get the path to X, where X isn't far away. And on top of that, we could add some crowd stuff in case there are many units around to make movements more fluid. This might make units slightly lose track or where they want to go, but with proper tweaking (and some units perhaps stopping), I'm sure it would get efficient enough. But it means work. Lots of annoying work, as pathfinding never really works properly. As for formations, I think the theory was that they would resort to snaking in a column (fairly un-cohesive) if moving over long distance, mostly eliminating the issue of rigid formations getting stuck but leading to some pain with short-range pathfinding (this is where crowd movements might be able to shine). Then as they get in formation, they should basically be treated as one big unit. Individual movement in those cases could probably be made simple enough to handle rotation and a few other cases (turning around, turning 90° right…) That's how I see it. With crowd movements, perhaps (only speculating here), if we add buildings to them, we could have a fairly imprecise short-range pathfinder just to avoid getting stuck in a few edge cases (such as having to make a u-turn to get around an obstacle). Tuan Kuranes: am I right in believing that crowd techniques basically loop over units and adjust their orientation each frame (or about each frame perhaps)? (and secondly: are you French?)

I think this is a known issue with the wall placement things, which is (as you noticed) not too easy to fix. It is something that's on the To-do list of things to fix, though. I'm not sure I understand your idea of gradient walls. Do you mean an automatic tool to create walls at a given height around a hill?