real_tabasco_sauce

In sniping testing with @guerringuerrin, 11 40 vs 40 han xbow fights with P = 2 resulted in a mean victory of @real_tabasco_sauce +1.9 soldiers remaining (I was sniping, @guerringuerrin did attack move). In our vanilla control, sniping won all 5 battles, with an average of 12 remaining soldiers. So we have partially succeeded at least in the case of crossbows in making sniping less impactful.

Now I don't know much about that game at all, but this sounds like a bad idea. It doesn't sound very beginner friendly. Eh, I wouldn't say that: in this case its a handful of players that want to use this mod. I am perfectly confident in 0ad's design and I think very, very few see fit to automate the economy to that degree. I see what the author said about "fighting the UI." In this case, we have stuff like freehand which adds functionality to make the game less click-heavy. However, progui reduces clicks by eliminating the need for those tasks to be taken by the player.

1. You blame me for the controversy when the mod is what is controversial. 2. My arguments and reasoning against progui are "provocations" now? Do they provoke you because they are good arguments? i'm sorry about that. The only real provocations I see here are you insulting my intelligence:

How can you say I harass players if you haven't played in a long time??? I have done 0 harassment on anyone. There are many players that do harass the 2 progui users I have seen in multiplayer, with many many insults and unfounded assumptions about progui. All I have done in the forums and in team chats is present arguments against progui or just show people how to spot when people are using it. If someone comes in and says I have no right to my opinions because I am a noob, I defend myself. its as simple as that. Again, if you haven't played in a long time, where is this idea that I am berating progui players in every game? I have played about 40 to 50 games in total this year and spectated about twice as many. Quite a few of those games were with atrik and I think only once did I have an argument with atrik, which was because he said I am a noob and can't have an opinion on the matter. For the most part its been smooth sailing despite our different opinions. Its really only been recently that @Atrik started insulting me as you can see in the forum threads, which surprised me. lastly, it is against the multiplayer terms of use (item 8) to purposefully gain an unfair advantage in multiplayer. There is nothing wrong with the mod itself, its just morally wrong to use it in competitive play. Now here is my final stance on the matter: Hosts have every right to refuse a player if they are known to use progui or other cheats like map reveal. Its all an honor system, so if hosts don't really care, its no big deal.

The only people not making mistakes are the people not trying anything. I'll admit bolts are op now, but the way forward isn't to restore 10 second pack times XD. I am working on the next steps to improve the situation.

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.