wraitii

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?

We could allow to upgrade palisades by simply having a button that removes the palisade and places stone walls in the exact same position. Would avoid having to destroy+replace.

Is there somewhere a description for that (and if not, could you describe what you mean)? Seems like it shouldn't be too long to do.

We need to consider performance though. If we go the whole way, a batch of archers firing might just slow the game down too much (unless using some stuffs like what Philip designed on his new long-range pathfinder this can be checked easily). Dynamically creating a 2D map for each unit is, imo, too slow, particularly as it would require a range query or more for each unit/formation.

So far, we have exponential armor and blacksmith (WIP), right? I think the multiplayer lobby also got a huge step forward, what's the progress report on that? I also think trample damage is worked upon. If all those got finished, we'd probably have a decent A14 already.

Exactly. Basically it handles a lot of maps in one go, and JS is not exactly perfect to do that. I'm considering switching some stuffs to c++ as part of improving the AI. I want however to be sure that the added cost of memory transfers are not bigger than the increase in computation speed.

That function should be disregarded when profiling. It does big 2D image manipulations that really shouldn't be done in JS in one turn. I'll try to find a way to even that one out whenever I can.

Tuan kuranes: that's pretty spot on. I'll just add that right now getinrange sorts the unit for no really good reason(in some cases), and a speed up can be obtained from removing that (though that could be linked with returning duplicates, which for rendering might or might not be annoying). One thing though: your idea about frustum culling could lead to trees or tall objects popping up in front of the camera, which is bad.

Should have made myself clearer: I meant a quadtree with a final "top/bottom" branching, for stuffs that are only near the ground. This could be useful for refraction/reflection culling for the water, for example, and in a few odd cases. Not too interesting, I have to admit. Frustum culling is currently done by checking the bounding box of every renderable model against the frustum, afaik.

I wouldn't rule it out. If it's not too expensive (I'm speaking CPU-wise here), we could use it to have better frustrum cullings (such as removing bushes that can't be seen but not big trees or something). It would probably need to be slightly clever, though. And it'd indeed be nice to have. But if it leads to a somewhat significant slowdown, then scrap it.

We do use a basic subdivision system (not a quadtree because we don't navigate nodes, we directly access the right square using a vector, I believe) for notably the range manager and the obstruction/path finding managers. It's somewhat efficient, though there are inefficiencies that Could be fixed. The problem is that each manager keeps his own and the simulation as a whole doesn't, when it really should. I'd advise looking at the obstruction implementation: it keeps static objects (no need to update them) and moving objects (need to be updated at a cost). The game can use events for updates. Overall, a new quadtree/octree ( I'm thinking it wouldnt cost muuuuch to make it an octree, not sure it has a point though) would need to be owned by the simulation (perhaps a manager) and shared for all stuffs that could use it, in particular the renderer for frustum calls.

I think you get artifacts because you consider points and not surfaces, which is what you actually ought to consider. Diagonal points can make a lot of difference in the water flow, and this is probably where your results are wrong. Your current implementation simulates constant raining, which should give a good enough result but would be better if you kept the water map over every frame, I think (twist it though, because given your algorithm it would be much too strong. You'd need to lower the strength). In that case, you need to lose some water (multiply WaterFlow by an arbitrary constant). For the rest, seems good.

The basque words sounds like a Basquization of the roman word, though, so I'd advise using something else.

That's looking pretty good . I'll be on holidays for the rest of the week so I'll give a look at your code this week-end/on monday (public holiday in France).

Some interesting stuff: your line 674 is actually required and does all the work. I tried *0.5 the waterDrain variable: now it did nothing. Setting it to 2 gave odd results. 5 gave the same. Looking at your code, it doesn't seem too sane: first you only move the ground for x+1 and y+1, might want to do it at least for w-1 and y-1 too, if possible all 8 corners. Secondly, the way you calculate the water drain map seems alright, but it has a side effect: it seems to me like in the current implementation this means all water will flow down to the lowest point on the map (locally), with no respect for possible pond formations… You need to take into account the water height when calculating height difference, I think it would alleviate the effect. Furthermore, you should make each square retain a little water (percentage) so you will get some rivers as you can keep track of where water runned before going down. If you then use my method of recreating the water drain using the first water drain distribution, you should get really good results. Otherwise seems fine. edit: or keep adding water each frame uniformly as if it was actually raining, losing a little every turn too to simulate absorption.

FeXoR: I don't think you posted the files. What do you mean by the "resonance"?

I'm not sure you can create riverbeds unless you make rivers remove some amount of ground, and make them remove more stuffs the deeper the water is (linearly, likely) so rivers will tend to dig. Given you avoid multi-step, I can't think of much better. Perhaps try to run a little rain/wind erosion first, to get a better map.

Some better concept for the fishing boat. If this is good, I'll give a definite go at proper UV-ing/texturing (using free textures, could somebody point me to some website for that?) and animating (getting a crash loading the rigged model into the game for some reason). (I'm pretty sure the reed texture I've used is bamboo, so papyrus would probably be a bit less yellow, more like in the first one though). edit: obviously beyond any mesh change that would be required.

I think the fact that the water is flat doesn't help you with not seeing riverbed, which with such a function would be at different heights. I suggest you try this erosion on a tilted plane with minor differences in height level and check how it looks like.