wraitii

Definitely graphics related. Are your drivers up to date?

Yeah, fixed too.

You're referring to the fact that units sometimes glide at the very end of their movement? If so yes it's a bug, and it's fixed/it will be fixed in my ongoing UnitMotion rewrite which will land whenever.

You're correct afaik. I think we could also use a sphere/elipsoid bounding box, which would probably be best for a building such as this.

I can confirm that I have the bug fixed on my end, I'm just waiting for a formal report from someone on Windows and *nix that it works and that nothing is obviously broken, and then I can commit it. I need to check for repackaging options. There might be an easy-isa option, or I'll need to repackage the whole thing.

Regarding code and bridges: I actually believe a walkable mesh would be far easier to do than changing terrain. Changing terrain sports a number of drawbacks which I am very reluctant to get into. A walkable mesh would imply a new component, and tight integration to the pathfinder, but in itself nothing there sounds impossible, and would in theory allow ships and units. Since we cache the obstruction maps, nothing there is insane so long as the update isn't too difficult. We could also add gates to their sides and stuff. It would be a little slower, but it wouldn't be by that much. However, the pathfinding problems of gates still apply: closed bridges currently would be seen as utterly impassable. The feature is also not really that interesting, since most bridges won't be high enough to let ships through. Have to agree with draw bridges there (though how realistic are those for the time period?). I generally don't see handling height as relevant, that would just add passability classes for a super special case which is annoying.

That is "normal", passable terrain is defined by the slope of the terrain and not the terrain texture - contrarily to most other RTS games (and to be honest maybe we should change it). In that case probably you are going over some impassable terrain with your wall.

Hm, the water settings you posted above are good. I notice some artifacts in the reflections though. What map-specific settings do you use? Water waviness? Water type? This map looks like it would benefit from much smaller waviness and water type "lake" or "clap".

Are you running the water on highest settings?

How about "Vox Populi"? Kind of fits the FLOSS world.

My chauvinism forces me to suggest Vercingétorix

Hm, you guys were right, the code was completely bonkers. I should have fixed it by now, let me know after the auto build if you find bugs New format if you want props to sync with a main actor: <animations> <animation file="infantry/general/inf_02.psa" name="Death" id="death1" speed="250"/> <animation file="infantry/general/inf_03.psa" name="Death" id="anotherdeath" speed="250"/> <!-- ... --> </animations> To clarify: -no need to use named variants, just put all your animations inside one <animations> block. -"name" now must refer to an animation type (e.g. "walk", "death", "idle"). -You can use frequencies as before. -"id" is now the parameter used to sync across props. If an animation has an ID, all props will try using an animation with the same name and ID. You may have several animations with the same ID. I'll try adding tests for this later because it's quite annoying to check manually.

Hey, thanks for your interest! This is planned, but it's not as easy as you'd think. That actually sounds like a pretty good idea. We've been thinking about this a little more, but I don't see big changes coming. We have been quite unable to figure out how to implement formations. Don't expect too much on that angle for now. This would be possible but there's a few limits: -size of the Javascript memory - some maps already run into this, I've been thinking about making it configurable for people that want more. -it would lag horribly. I don't think we can go realistically beyond 200/300 units because it would become unmanageable for the player.

I'm not sure what the procedure would be, but it would be interesting to give them 0 A.D. I remain unconvinced that machine learning can efficiently learn to play an RTS with current technology, but who knows.

Honestly I think for very easy we should put it at 0.1 or 0.2

Have to agree that some more player color would be nice. Suggestion (nb: don't necessarily do all 3) -color a band around the legs -color the tip of the tusks -paint something on the front. It also looks quite golden and not bronze to me but maybe I'm just seeing things The howdah also looks like it's quite far back? Is that historical?

As far as I remember they were indeed deprecated (I remember for Corsica Vs Sardinia running into that problem, but it made more sense for that particular map so I ignored it). The "biggest" problem with circle maps is that sometimes you need bigger maps to make them work compared to square, but I don't think that really warrants keeping them.

I would be interested in an economic mod that plays a little more like Anno. With the resource agnostic mod in, we could even add a little complexity.

I never realized how strong the women were in the new meshes haha. Amazing work!

Looking at range queries. It's about 10ms to execute active queries in the late game, because we have 500 active queries. In general, parabolic/global/regular queries are about as much time, though their slowness varies. For general queries, we might gain some ms by actually checking for max distance before we check for component existence, since that seems to be slightly more efficient. The good news is that the subdivision Move/add/remove are mostly irrelevant in terms of computation time compared to the other stuff. We might be able to speed up queries by just checking against units that moved this turn. This needs to be tested and probably needs to be optimized spatially a bit but could be interesting.

Fairly more comprehensive profiling. The three attached graphs are a very smoothed, less smoothed, and proportional plot of the same game. As you can see, we have the occasional spike in LongPath, probably when we move many units not in formation. ShortPath also occasionally spikes when units move around, and particularly when they combat (which can be detected because Timer, which is the JS component mostly used by unitAI, spikes too). But as a general rule, the longest call is the update of Timer.Js, which afaik is mostly the gathering, repairing, and combat timer. (NB: profiling are exclusive, Timer is part of Components in the above graphs).

Some more detailed profiling, based on a 2V2 provided by Elexis (which is basically using rev ~ Alpha 21). This is an MP game so turn rates are 500ms. All analysis done using a custom profiling script that outputs per-frame data and R. First we can look at the whole thing, smoothed. "Components" is Update Components, the rest are various pathfinder related things. I don't profile long-range at all here. Then unsmoothed: as we can see there are several very high spikes. Indeed R tells over over a third of turns are over 50ms, over 80% are above 20ms (which is 50 FPS if we ran a turn every frame - obviously we don't). The SP turns are about 200ms, also 50 ms per turns means already quite a slowdown. We can do some fancier things, such as find the average breakdown for buckets ( <20ms, 20-50ms…): As you can see, the short-range pathfinder is hardly the number 1 cause of lag. The number 1 cause of lag is in fact updating components. I'll profile some different things with this replay and upload a new post for more info.

Been looking at the Combat attacking timer using Combat Demo Huge. The component update itself is around 100ms/turn at peak, so the pathfinder is not the only issue there. Specifically on the combat timer, finding new targets is by far the slowest, then it's a combination of the rest. Could be optimized by removing redundant checks, mostly, and improving QUeryInterface I guess. A particular source of slowness is TargetKilled, because of the two calls to the statistics (I think the query interface through player ID are particularly slow). Interestingly, the slow part of finding new targets is the JS AttackTargetByPreference more than the cpp, which is reasonably quick in comparison.

Are you working on those to upgrade our 'rise from the ground' stuff? And if yes, could you also add the scaffolds as actors?

Re 3D-mesh mountains: I do agree that something like this would be good for the game, it would allow us to give more details to the terrain where it is currently quite annoying to do so. Likewise for cliffs. I'm thinking maybe a better solution however would be some sort of 3D-decal, where we have a model of "pikes and rocks" that just overlays the terrain dynamically, so you can have details for various types of mountains instead of making them similar. More like a special terrain tile than a mesh. Though for cliffs you should be able to get away with the "follow height" actors.