real_tabasco_sauce

yes, but the integers are huge, so there is basically no issues with rounding. I can't tell if isqrt produces floor(sqrt(x)) or some other rounding.

yeah there are also some where you don't have to use units to build buildings and ones where resources are just trickles that you capture. 0ad's style is just more complicated and its the first thing for new players to learn. I think more complicated games, with deep mechanics retain players better. I think this is why AOE2 is much better than AOE4.

@Atrik Calling me a noob and putting random words in bold doesn't make what you have written convincing at all. Now you are also slandering a completely separate idea of mine you know nothing about. In the above you have written a lot of buzzwords but really conveyed nothing (like what the hell do you mean by randomized unit behaviors).

Are you talking about Geriatrix here with the lies? I have never said you try to hide it, I just bring it up from time to time when I see others in observer chat saying what they heard about progui. Often they are superstitious about what other advantages you have. lastly, since this is your only real point for progui, I’ll just say i seriously doubt massively changing the way economy functions to make the game easier is a way to attract new players. Since you are interested, here are some things I bet would get new players interested: performance improvements, new civs, new units/content, lobby improvements, a ranked playlist and system for competitive play, steam support, and uhhhh a campaign. also then you would have to think about the issues of player retention by making the game’s economy fundamentally shallow.

I was clarifying a situation with regards to geriatrix Is it so bad to tell players that this mod exists and how to tell when someone has this unfair advantage mod installed? If the mod isn't problematic nobody would be upset. I am not harrasing anyone, just letting people know how to tell when you and stock use it. Its crazy how mad you get at me for this. Is ad hominem all you have? seriously? You say I am a bad player and that I can't make any statements about the game because I have no game knowledge.

nonrand.mp4

Now that we are back to random arrows, what do you all think? Are arrows any different compared to a26? What things do you find better than with the non-random arrows? What is worse?

Well not to beat around the bush, and not to excuse geriatrix's behavior, stockfish is known to use progui. Apparently its up to you whether or not that counts as cheating. (I consider it cheating)

So sorry for all this random hate thrown at u @Norse_Harold

Ok I had a thought: The same thing happens with LOS range queries. The closest unit is chosen as the target even if the target is just a tiny bit closer than many other targets.Take this as an example: Now compare it to the behavior when we use P=3. Its a bit of an exaggeration to see the effect. I think it would work better at p = 2.

Ok, in order to see what's going on you will need to turn on the developer overlay (alt+d) and then select range overlay. Ok, yeah looks like its working fine. I'll be on later today and we could do a 1v1 on the patch if u like. It would be nice to see how the differences impact things like rushing and raiding, as well as other kinds of fights.

Ok so the way I do it is this: in phabricator(https://code.wildfiregames.com/D5282), click "Download Raw Diff", this will open a plain text file in your browser. Copy the contents of the file navigate to your SVN directory Paste the contents into a new file with the extension '.diff' type 'svn patch ABC.diff' now at this point, some files should print to console with 'U' for updated. bigger patches might have conflicts, but that shouldn't be the case here. Since this patch modifies the engine, you will need to also build the game: https://trac.wildfiregames.com/wiki/BuildInstructions

ok, well the patch is pretty much done and working: https://code.wildfiregames.com/D5282 if anyone can apply it (and build) to test on their system that would be great!

After a couple of combat demo huges, it seemed a little faster, but that's just anecdotal. Also, i don't know if my build was making use of the builtins, so it may be better or worse than what I experienced for some players. I uploaded the latest version (with the isqrt64() replacement).

ok, I got a 64 big equivalent working, and I tested every isqrt() call against isqrtEst64(), and not once was there a difference. Do you think I should just wing it and replace the old isqrt()?

I achieved this in my non-random buildingAI experiements. Tbh I think a faster fire rate would be fine too as an interim measure. This would be of interest anyway for onagers. I could do a round of updates at some point to address the points made here.

Ok, so I was checking the isqrtEst64 against isqrt(), and they are exactly the same when P = 0. However, because I am using SLD2's "SDL_MostSignificantBitIndex32(n)" to get log2, large integers overflow. u64 sqrt_lo(const u32 n) noexcept { u32 log2floor = SDL_MostSignificantBitIndex32(n); return (n != 0) << (log2floor >> 1); } u32 isqrtEst64(u64 n, u8 P = 0) { u32 est = sqrt_lo((u32)n); u32 b = (u32)n; ... The nice thing is the larger values don't occur in fights, I guess they happen in map generation and pathing, probably a lot of other things. As far as I can tell, the patch is working, but I am sure there are more improvements possible. So @Stan` I would need to come up with a 64 bit equivalent to SDL_MostSignificantBitIndex32(n) in order to see if this sqrt approach could be faster than the current isqrt().

yeah ive done some tests and it works pretty well. I need to set up the precision value in the templates, and then test for OOS. Then there's also the performance side of things.

@chrstgtr 2 developments re sniping: https://code.wildfiregames.com/D5282 https://code.wildfiregames.com/D1971

Wow thats huge. I tried replacing the isqrt64() in FixedVector2D.Length() with my isqrtEst64() with P=1 and got teleporting units and a game crash. In theory, the new sqrt with P=1 should be exactly the same as isqrt(), so maybe Ill need to compare the two to figure out what happened above.

Yeah, i think slightly worse, but its hard to say. It would be great if @wraitii could profile it. I modified EntityDistanceOrdering, which is used by all the different range queries, so its possible this version could be used in less locations. Also, I do whole division after finding the square root: u32 r2 = isqrtEst64(d2,P)/(100000*P); but it might be faster to find the sqrt after whole number division.

Just doing a couple rounds of combat demo huge, I found roughly 13-14 minimum fps go down to 11-12fps. The video was at P=10. I added a pseudorandom tie breaker so the fighting looks like this now (P=3): p3tiebreak.mp4 I think 3 is ideal for archers. I bet 2 would be good for slingers/han crossbows and 1 for skirms, melee units. I suppose the next thing to do would be to figure out how the unit templates can determine P. I guess it involves modifying the UnitAI schema and adding P as an argument to the query setup calls in unitAI. Also, if someone wants to apply the patch and test, that would be awesome.

Ok so it works now, the skiritai are not sorted. Square rooting and dividing by 10^5*P pretty much delivers what I showed in the tables above. The video is with P=10 to exaggerate the effects. I wonder now if a tiebreaker would be necessary for more common cases like P=1,2, or 3. Something like a random shuffle if the low-precision distances are "the same". p10.mp4

The game uses integers for its calculations, because floating point are note reliable on different machines, so we need to have the exact same values on each machines else the game will go out of sync pretty quickly. So I suppose what you are seeing are decimal values represented as int. Ok, I can do it if I can just figure out how the integer representation of float is done. Then I would just need to add the necessary arguments to pass the needed precision value up to the square root. I suppose EntityDistanceOrdering would need to accept P as a parameter, and then queries that don't need so much precision could use the alternative sqrt. if isqrtEst is faster than the current isqrt, i guess it would be fine to just use isqrtEst with a P of 1. With p=1 the result is always floor(sqrt(x)).

Ok so the square root function works, its just the numbers involved are still huge. So that's why there is no obvious impact on the game. I thought meters were the fundamental unit of distance, like for entity_pos_t instances, so how does the square of the x component of a vector get this large? 13035623883809. maps are maybe between 1000 and 10000 meters across, but the square of these numbers doesn't come close to the above number, which was collected from some archer fighting.