real_tabasco_sauce

ok, heres an idea: Let the carry capacity upgrades in the storehouse have a flat bonus to construction speed. Why: Wicker baskets, wheelbarrow, and cart are fairly underused, since in many games it is preferable to just build additional drop sites when gathering becomes inefficient. I think it would be great to add a small bonus to construction speed to each of these, something like 10%. It is perfectly realistic, and could add more options for civs that find themselves in need of many buildings. just a thought, and it would be easy to do in the com mod.

How slow? On a good machine it's about 2-4 mins. I meant the game once it is built. For me, the build process is quite fast, under a minute. in game, we are talking 1 to 4 fps as soon as I start moving the camera. on anything but windows, yeah that's (hopefully) because I don't yet have code to use the GCC builtin.

Also, my windows build with VS was very very slow without any changes at all. Is that the case for others?

https://code.wildfiregames.com/D5282 it built, but didn't do anything.

This sounds like the regicide + garrison hero infinite loop. If that's the case, it may be fixed by getting the community mod in the mod downloader, but you could also turn off the garrison option in match setup. @Norse_Harold is more familiar.

Ok, I like the looks of this approximation: (from https://stackoverflow.com/questions/4930307/fastest-way-to-get-the-integer-part-of-sqrtn/63457507#63457507 and https://stackoverflow.com/questions/34187171/fast-integer-square-root-approximation) #include <algorithm> #include <array> #include <iostream> #include <string> #include <vector> #include <math.h> #include <time.h> unsigned char bit_width(unsigned long long x) { return x == 0 ? 1 : 64 - __builtin_clzll(x); } unsigned sqrt_lo(const unsigned n) noexcept { unsigned log2floor = bit_width(n) - 1; return (unsigned) (n != 0) << (log2floor >> 1); } unsigned sqrt_newton(const unsigned n, unsigned int P) { unsigned a = sqrt_lo(n); unsigned b = n; // compute unsigned difference while (std::max(a, b) - std::min(a, b) > P*P) { //P*P reduces iterations of while loop when using higher P. //printf("iteration\n"); b = n / a; a = (a + b) / 2; } // a is now either floor(sqrt(n)) or ceil(sqrt(n)) // we decrement in the latter case // this is overflow-safe as long as we start with a lower bound guess return a - (a * a > n); //could remove - (a * a > n); if using low precision. } int main() { unsigned Nums[29] = {27,28,29,30,31,32,33,34,35,36,37,38,39,40,44,45,46,47,48,58,59,60,61,62,98,99,100,101,102}; int P = 5; clock_t tStart = clock(); printf("Range value\tEstimate\tExact\n"); for (int i=0;i<29;i++){ unsigned test = Nums[i]*Nums[i]; printf("%i\t",Nums[i]); printf("%i\t",sqrt_newton(test,P)/P); printf("%i\n",(int)floor(sqrt(test))/P); } //printf("Estimate: %i\t",sqrt_newton(test)/P); //printf("Exact: %i\n",(int)floor(sqrt(test))/P); printf("Time: %.9fs\n", (double)(clock() - tStart)/CLOCKS_PER_SEC); } results: P = 1 P = 3: P = 5 P = 10: The only issue I found is that with 5 >= P >= 9, there are a couple points where the estimate is higher than estimates of larger ranges. (see P = 5) I could just go ahead and use this and see what happens. (id have to figure out the windows build process first).

I was curious so I did some testing in this c++ reference: https://en.cppreference.com/w/cpp/algorithm/stable_sort and it seems like stable_sort() is faster when there are redundant values, but when they are made quite different on purpose, sort() is faster.

int CompareLengthSquared(u64 cmpSquared) const { u64 d2 = SQUARE_U64_FIXED(X) + SQUARE_U64_FIXED(Y); // d2 <= 2^63 (no overflow) if (d2 < cmpSquared) return -1; if (d2 > cmpSquared) return +1; return 0; } https://code.wildfiregames.com/source/0ad/browse/ps/trunk/source/maths/FixedVector2D.h#:~:text=int CompareLengthSquared(,} ok so, yes the precision for lengths is 1 meter, but the differences are found for x^2+y^2, so for a 70 meter range archer, 1 meter out of up to 4900 is very little. So basically, the precision when sorting lengths gets higher the farther away the unit is: a single integer represents a range differences of 0.014 meters near 70 meters range. The relationship looks like this: The only thing is the relationship needs to be a parabola, so you can't just do (x^3/Px^2) because this would incorrectly rank units distances. I suppose the thing to do would be to use an integer square root estimation algorithm, and then integer division by the precision value. Then, the profiling would be needed to see if the potential improvements to sorting would be worth it. Even if its pretty similar, I think the impacts on the overkill situation would be nice. https://stackoverflow.com/questions/34187171/fast-integer-square-root-approximation

Weird that it doesn't work in single player. Did you enter it in gamesetup or after the game started? I'll give it a try later.

If the turn rate can be changed in JS, then maybe @Atrik idea of doing a quick mod to test it could be worth. The only question would be if there is a way that the host can communicate the selected turn rate every time a new game starts. Else the mod would have a hard coded turn rate, which would not allow us to test different values on different games. well looks like you wouldn't even need a mod to do this. You could do the following (and I'd be curious on the results): Set up a match with combat demo huge (in scenarios, demo maps) and choose different values with Engine.SetTurnLength(x); @phosit are the backticks included when typing this in the js console?

Discussion about the overkill situation brought me to this vague idea: consider more units at an equal range, so that units spread out their damage a little. Ideally, a target precision value could be stored in the templates (higher for archers, lower for skirms for example) and then used to influence the 'EntityDistanceOrdering' on certain calls to the range manager. (Things like choosing the closest unit don't need to be super precise and maybe shouldn't be wrt overkill). https://code.wildfiregames.com/source/0ad/browse/ps/trunk/source/simulation2/components/CCmpRangeManager.cpp#:~:text=class EntityDistanceOrdering,}%3B Perhaps some replacement for .CompareLengths() could be used with an optional precision value (0.1,0.5,1,3,5,10). Since stable_sort is used, maybe this would also be faster with more 'equivalent' values?

Keeping in mind I am by no means experienced here, I don't think you can expect a 1:1 effect on performance by changing the turn rate. So a 2.5x slower turn rate does not necessarily mean a 2.5x improvement in performance. Perhaps some tweaking of the turn rate would be fine (has 250 ever been done?), but I don't recommend going all the way to 2 turns per second. Also, the situation with collision size and pathing is interesting: in https://code.wildfiregames.com/D4970, we went back and forth with different values for pushing and found that the pushing situation is directly in conflict with pathing: preventing overlap directly makes pathing more awkward and making pathing less awkward requires overlap. I would totally support something like https://code.wildfiregames.com/D5037 which would allow for less overlap, but it would introduce some extra performance cost.

https://code.wildfiregames.com/rP25001 in here are the reasons for the change back to 200ms.

I am not sure what you mean by the second half here, but I would be fine with either disallowing winning players to flare or re-activating the button and UI icon.

hm, maybe try deleting that empty folder, and anything else in the mods folder that might be related to the community mod.

I think that looks really good. Personally, I'd recommend using a slightly different color for the dirt mound part because it is very similar to the color of the stones.

I'm not sure but IIRC units have preferences with regards to their target e.g. the Elephant class. Oh no, I was asking about the rangefinder (maybe its the rangefinder..). Ie, say 2 units are exactly the same distance away from my archer, how is the tie broken? Even if it isn't wanted for building AI, I think it might be helpful for a number of reasons to have a "coarse" rangefinder for situations like these, ie finding the unit's position to the nearest x meters where x could be 5, 1, 0.5, 0.1, etc. Then maybe x could be a property in the templates. For instance, archers have a bit of a problem with overkill, so you could set X to be 3 or 5, so that they more often choose different targets. Then for short range units, something like 0.5 could be used. In buildingAI, it could inherit an array of the closest units and target randomly from those. That way with the fort you could set x to 5 so that the closer units are shot when they are farther away, but when the fort is surrounded, you kind of have a "fire at will" appearance, shooting the closest at random. might be kind of a mess though for buildingAI, because a ton of functions would probably need to use arrays where they don't already.

yeah I tried to set up a pause between firing rounds, but I couldn't figure it out. I think it would improve readability and the micro options. Anyways thanks everyone for the ideas for improvement. I'll use these ideas to better refine the non-random approach the next time I introduce it sometime in a27.

I was thinking something like this would be an elegant way to achieve this effect:

So is it a realism argument? Missed arrows damage nearby units. To be fair, the accuracy pretty effectively accomplishes this, especially for forts. Also, the natural movement of units often spreads damage over a handful of units, as the "closest unit" changes often. If the player notices this (not easy, to be fair) keeping that unit in motion will dramatically improve its survival and even decrease the effectiveness of the building arrows. So there is ideally a nice back and forth should a player use the manual targeting like this. I suppose a max number of attackers value could be used sort of like something @wowgetoffyourcellphone proposed a while ago. IMO this approach is heavy-handed. One idea I brough up on overkill discussions was this: add a new range query for determining the closest unit with a flexible degree of rounding. In these large scale battles mentioned by @Feldfeld, what is currently "the closest unit" could be 2 to 5 units, or maybe more. @Stan` is there already some sort of tiebreaking mechanism when two targets are exactly the same distance?

AFAIK, ships will currently try and aggro enemy ships. Yeah the only practical difference is that the Building AI is a stream of arrows (or a multi-arrow blast :D) that can be done while moving.

ok so basically unitAI is responsible for just about all the entities, so ships and siege towers have UnitAI. BuildingAI is responsible for the building arrows. in @wowgetoffyourcellphone's work, they no longer have anything to do with buildingAI, and instead behave like infantry, cavalry etc. By default they will target the first enemy they see unless you give a specific target, just like regular units. I think the ship classes do an excellent job on emphasizing ship positioning: Keeping vulnerable ships protected, flanking with ram ships, massing arrow ships together, raiding fish with scout ships. The main thing is that ship gameplay won't be a total snooze fest XD.

not sure what you mean with this. The ships are now like any other unit, (archer, pikeman, etc) in that they don't have buildingAI. So there is no buildingAI to be had. im sure there will plenty of strategies and micro involved.

They are, the rework makes ships behave like proper units rather than water siege towers. And they have classes: scout ship, arrow ship, fire ship, ram ship, siege ship.