Forums

I did this to the UpdateColor function :  UpdateColor() { // warn("UpdateColor"); let cmpFoundationOwnership = Engine.QueryInterface(this.entity, IID_Ownership); if (cmpFoundationOwnership) { cmpFoundationOwnership.SetOwner(cmpFoundationOwnership.GetOwner()); } warn("Owner : " + cmpFoundationOwnership.GetOwner()) let cmpVisual = Engine.QueryInterface(this.entity, IID_Visual); if (!cmpVisual) return; const color = QueryOwnerInterface(this.entity, IID_Player).GetColor(); cmpVisual.SetVariable("colorr", color.r); cmpVisual.SetVariable("colorg", color.g); cmpVisual.SetVariable("colorb", color.b); // warn("red : "+color.r); // warn("green : "+color.g); // warn("blue : "+color.b); } I try to SetOwner at this moment but I think i'm doing it bad. I saw this function comes from a .cpp compoment and is quite simple. But how can I SetOwner the final building AND the foundation AND the preview ?  I'm testing many things but I don't understand why when I print the owner of my 2 civil_centre at the beginning of the game I have this :  It seems like the owner is changing 3 times before getting the right owner, maybe that is the problem Moreover, I'm not the best programmer in the team, that's why it's harder for me to understand these things, sorry for being a noob (Steph is not available)  

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.

Regarding the new Vulcan improvement on performance, we are all eagerly awaiting for it, hope the new alpha sees the light soon. But I think this proposal does not get invalidated by this. I am sure we all can agree that 0AD will never run fast enough in the foreseeable future. We are already orders of magnitude away from optimal performance in TGs, especially in big battles where a single turn can freeze up to 10 seconds, when it should take 200 miliseconds. That's 50 times slower. And if, by some miracle, surplus performance was available, we can always find new ways to make use of it, for example: We could revert the collision sizes to previous normal values to make units behave in more realistic ways instead of lumping together like they do now. We could play larger TGs, like 5v5, 6v6, etc. So a simple  tweak that could potentially increase performance by 2x or more should not be ignored in my opinion.  

Thanks real_tabasco_sauce for pointing to the reasons for the change back to 200ms. On the one hand it would be nice to see real data about the effect on performance by the change in turn rate. I haven't seen the benchmarks Feldfeld mentions. If someone can point to them that would be nice. My own experience says it was bad for large TGs in general. On the other hand what could be a better benchmark than to allow the community itself to change and test this in real TGs. To make it possible, the host should be able to tweak the turn rate (maybe a settings option). Also the game should report the real speed the game is running at (as a moving average for example). Lastly the player responsible for slowing down the game should also be identified. This way, several games that include this "slow cpu player" could be ran and conclusions drawn after a few days or weeks of testing. Doing testing over time on real TGs is way more solid that a few "laboratory tests" we could come up with. Also way more brains could be involved in observing the advantages and disadvantages of higher or lower turn rate values. Remember that performance issues can happen for different reasons, as unit placement and terrain will be different on each game. It's not a one-dimensional problem. For example, currently we know that if cronelius is playing a 4v4 TG, and the game makes it to late game, the actual lobby time will be between 2 and 2.5 times higher than the actual game time. In other words, the game will run between 0.4 and 0.5 the normal speed. That's more or less a rule.  If we could already experiment with the turn rate, it would be possible to find out almost overnight which setting makes more sense in these type of games. On the other hand, In 1v1s it might make more sense to use a different setting.

Well ent is not defined, and your setting the player to itself ^^ so it wouldn't change much

It's done in the foundation.js component. Basically your building goes through 3 filters preview| foundation| and nothing

ASWĀR (Middle Persian) “horseman,” Old Persian asabāra, Parthian (Nisa) ʾsbry, Persian savār and sovār. In Old Persian asabāra designated the horseman as opposed to the foot-soldier. Thus Darius says (DNb 44-45, Kent, Old Persian, pp. 139-40) “(as) a spearman I am a good spearman both on foot (pastiš) and on horseback (asabāra).” The same concept is expressed by “man and horse” (asp ud mard, heterographically Mid. Pers. GBRA W SWSYA, Parth. GBRYN W SWSYN) in the Sasanian inscriptions (Kirdēr at Sar Mašhad and on the Kaʿba-ye Zardošt and Narseh at Paikuli), where the word aswār is not found. In the Zoroastrian Pahlavi books aswār also designates only the “horseman,” and it is not till in the later, Arabic sources that the term is said to have a more specialized meaning, cf. Ḵᵛārazmī, Mafāteḥ al-ʿolūm (ed. van Vloten, Leiden, 1895, p. 115): “al-asāwera, plural of al-oswār, i.e., horseman, because the Iranians give the name oswār only to a brave, heroic, famous man.” The terms aswārān or aswāragān (Christensen, Iran Sass., p. 265 n. 4) do not appear to be attested in the sense of the arabicized asāwīrāt “knights” (see Asāwera) in the Sasanian Middle Persian literature, where the warrior class is the artēštār(ān) (q.v.). Note that the reading andarzbed ī aswāragān in the Kār-nāmag, proposed by T. Nöldeke in his translation (Bezzenbergers Beiträge 4, 1878, p. 62 n. 3; cf. J. Darmesteter, Le Zend Avesta I, p. 31 n. 17; M. Boyce, The Letter of Tansar, Rome, 1968, p. 41 with n. 4 comparing Ar. moʾaddeb al-asāwera), is an emendation of the manuscript’s andarzbed ī wāspuhragān (see H. S. Nyberg, A Manual of Pahlavi, Wiesbaden, I, 1964, p. 11 l. 19 and II, 1974, p. 94).   In modern times the Borhān-e qāṭeʿ (ed. Moʿīn, I, p. 135) reports that the term asvār is used in the language of Gīlān to designate a group of soldiers of the lowest rank who carry axes and wooden clubs with which they strike each other on the heads. This kind of battle they call asvārī. Source: https://iranicaonline.org/articles/aswar-middle-persian-horseman