Alpha26 feedback and suggested changes

[real_tabasco_sauce]

1 hour ago, Silier said:

Will not work if you place tower at hill. It wil not be 13. You cannot make it constant. its constant 13 only on flat terrain. Additionally if you place tower lower it will be minus x.

right, but my point is instead of starting at +13, start at 0, with 13 already accounted for by the towers range.

ie 73 (+2), 73(-6).

[wowgetoffyourcellphone]

17 minutes ago, real_tabasco_sauce said:

right, but my point is instead of starting at +13, start at 0, with 13 already accounted for by the towers range.

ie 73 (+2), 73(-6).

I can't understand how this is hard to understand. I feel like this conversation is two chat AIs talking past each other. Thanks for fighting the good fight.

Edited April 8, 2023 by wowgetoffyourcellphone

[hyperion]

1 hour ago, alre said:

Do you mean the circles visible around selected towers? Because those cannot be reliable with this engine.

Well, they wouldn't be just circles anymore. There was a patch for a more accurate range indicator at some point, don't ask me what became of it.

 

1 hour ago, ChronA said:

I think the point is, if towers always have a +13 elevation bonus on top of whatever they get from terrain, why not just bake that into their default range? It changes absolutely nothing about the game balance, but it makes life easier for data miners and makes the stat card more accurate at a glance to the thing people actually care about.

Because it wouldn't be correct in the general case as was pointed out, whether this is of concern we can argue about. Just because some people don't understand the relation between elevation and range isn't a sufficient reason in my eyes to throw away what we have tho.

 

 

 

[real_tabasco_sauce]

2 hours ago, hyperion said:

Just because some people don't understand the relation between elevation and range isn't a sufficient reason in my eyes to throw away what we have tho.

@hyperion you think i don't understand parabolas? That's a pretty cringe thing to say.

In the above, green is the real range of the tower.

Below, you can see the average bonus range is 13. How would it be ANY different to say instead:

"basic range: 73"

"average range bonus: 0", with the 13 meters already taken into account?

I am not saying this is a catastrophic bug, but arguing to maintain the status quo is pretty embarrassing.

[Stan`]

2 hours ago, hyperion said:

. There was a patch for a more accurate range indicator at some point, don't ask me what became of it.

https://code.wildfiregames.com/D1800

[Palaiologos]

2 hours ago, hyperion said:

Just because some people don't understand the relation between elevation and range isn't a sufficient reason in my eyes to throw away what we have tho.

Please explain this relation since I have trouble comprehending. Shouldn't the default simply be "baked in" at 0? The additional height is not accurately reflected in the range or it is???
And, as @ChronA states, "it changes absolutely nothing about the game balance". Agree with that, however, it does have importance "strategically" as a "deterrent" feature with plenty of evidence supporting this from players successfully utilizing them. Example being that one can verify, (being able to visually confirm the ranges aura) before deciding placement location is of importance.

[hyperion]

5 hours ago, Palaiologos said:

Please explain this relation since I have trouble comprehending. Shouldn't the default simply be "baked in" at 0? The additional height is not accurately reflected in the range or it is???

A hopefully simple example:

Little Alice and little Bob are playing ball on top of Eiffel Tower. When passing the ball to Bob he fails to catch it and Alice shot falls all the way to the ground. Grown Robert picks up the ball, and has he is a grown up he has further range and is able to throw the ball all the way back to where Alice is if she where on the ground. Is Robert able to pass the ball back to Alice?

[Silier]

This is check if entity is in parabolic range.

x,z are posiotions

range is basic attack range of entity

sqrt(x*x+z*z) <= sqrt(range^2 - 2range*y)

y is high difference between two entities

The thing you see in tooltip is the difference between basic range and the average range where unit could be in parabolic range.

Now give me mathematic prove that with height ( y + what is in template  ) from tower template and basic range (range) will "always" give the same result as with (y-what is in template) and (range+13)

Edited April 9, 2023 by Silier

[wowgetoffyourcellphone]

okay, that's fine, but the range as given to the player is just a distance by which the entity will engage with enemy entities. It's a "behavior distance" or something to that effect. 

Edited April 9, 2023 by wowgetoffyourcellphone

[ChronA]

An alternate take: since in the case of towers we are explicitly simulating the added elevation of the projectile release point for the range calculation, why aren't we doing the same for other units? In 0 AD's screwy size scaling humans are something like 4-5 meters tall! That means any projectile thrown or shot from an bow should have an elevation bonus of at least +3 m, horse archers should be around +6 m, and elephant archers should probably get something like +10 m! But no, for these units the elevation advantage is baked into their baseline range (last I checked) or else ignored entirely. Can we at least be consistent? 

[real_tabasco_sauce]

On 09/04/2023 at 12:18 AM, Silier said:

(y-what is in template)

Should just be y, not (y-window height)

In any case, you shouldn't even need to reconsider the actual targetIsInParabolicRange function. I am not suggesting this either.

the only things to change are the tooltips and more importantly the range overlay. I'd say the range overlay doesn't have to be the actual range, which appears to be costly, but maybe just basic range+ average bonus range.

This will be right most of the time instead of being wrong 100% of the time.

If using average bonus range is also unfavorable, then one could even just use the parabolic range evaluated for perfectly flat conditions (13).

Then for the tooltip: range+13 bonus range -13, this does hold true for all average ranges.

Edited April 10, 2023 by real_tabasco_sauce

[Silier]

i am out of this, its no point

[real_tabasco_sauce]

5 minutes ago, Silier said:

its no point

its fine if you won't help. But there is definitely a point.

[BreakfastBurrito_007]

its point +

[Stan`]

17 hours ago, ChronA said:

 In 0 AD's screwy size scaling humans are something like 4-5 meters tall! That means any projectile thrown or shot from an bow should have an elevation bonus of at least +3 m, horse archers should be around +6 m, and elephant archers should probably get something like +10 m! But no, for these units the elevation advantage is baked into their baseline range (last I checked) or else ignored entirely. Can we at least be consistent? 

Getting a bit tired of that argument, but for the sake of it they do have an elevation bonus. (And it's easy to check) 

trac:template_unit_cavalry_ranged_archer.xml#L17

trac:template_unit_champion_infantry_archer.xml#L17

15 hours ago, real_tabasco_sauce said:

Should just be y, not (y-window height)

Why? 

 

[ChronA]

Huh... So they do! Points for consistency then. It seems to be a new feature since the last time I looked heavily into unit stats. I'll try to avoid making such authoritative claims in the future unless I fact check them first.

[real_tabasco_sauce]

8 hours ago, Stan&#x60; said:

Why? 

well between (y+window height) and (y- window height), two factors of window height have been subtracted. So any range bonus from the second approach would be too small (15 meters below ground).

Anyway, I think the issue can be better addressed superficially:

Where is the "average range bonus" calculated for the tooltip? it seems to me, a much better range overlay would just be adding this value (already calculated in real time) to the range for making the range overlay.

In the placement tooltip, one could add this value (evaluated for flat conditions, 13) to basic range and subtract it from the calculated average elevation bonus.

Then in the tooltip for the template, one could add 13 instead of keeping 13 in parentheses.

The only issue with this approach is that the range overlay is still not the non-circular true range, but it is close and should be less computationally costly (using already calculated values).

[Stan`]

On 11/04/2023 at 5:02 PM, real_tabasco_sauce said:

well between (y+window height) and (y- window height), two factors of window height have been subtracted. So any range bonus from the second approach would be too small (15 meters below ground).

I'm sorry I still don't get it. Why do we have -windowHeight?

On 11/04/2023 at 5:02 PM, real_tabasco_sauce said:

already calculated in real time

I don't think it's calculated in realtime, but rather when it's used to actually attack.

You should see most (if not all) occurrences of that value usage here https://code.wildfiregames.com/D2016

[real_tabasco_sauce]

7 hours ago, Stan&#x60; said:

I'm sorry I still don't get it. Why do we have -windowHeight?

Oh, sorry. I am afraid this was a bit of a tangent. This is where it came from.

On 09/04/2023 at 12:18 AM, Silier said:

Now give me mathematic prove that with height ( y + what is in template  ) from tower template and basic range (range) will "always" give the same result as with (y-what is in template) and (range+13)

 

7 hours ago, Stan&#x60; said:

I don't think it's calculated in realtime, but rather when it's used to actually attack.

You should see most (if not all) occurrences of that value usage here https://code.wildfiregames.com/D2016

When I say calculated in real time, I mean the "average elevation bonus". This appears to be calculated during placement of the tower:

So is this maybe done in GUI?

[Gurken Khan]

The description for the Nubia biome always strikes me as wrong; "a dry climate in which only the hardy Baobab tress thrive". While in fact you get more wood from Date Palms and Acacias. (Still not enough for me to actually play those maps.)

[Gurken Khan]

It's probably due to gameplay/balancing reasons, but I find it really unrealistic that worker elephants can't do any damage. Anyone who has ever seen an elephant lose its temper knows they are nothing to trifle with.

[Yekaterina]

1 hour ago, Gurken Khan said:

It's probably due to gameplay/balancing reasons, but I find it really unrealistic that worker elephants can't do any damage. Anyone who has ever seen an elephant lose its temper knows they are nothing to trifle with.

You are right. In fact I doubt that any elephant would be capable of building a palace alone just using its trunks. However, a worker elephant which has an attack value is simply too OP. Even at this point it is already a strong meatshield in both early and late games. I was able to repel vinme's sword cav rush by baiting his cavalry onto my worker elephant, then shoot his cav with archers while they take forever to kill the elephant.

In a large melee fight, the worker elephant is an automatic lure machine, much like hero dancing. I can't imagine allowing this unit to be any more OP.

[Gurken Khan]

My Oikos doesn't have a flag:

 

logs290423.zip

[wowgetoffyourcellphone]

10 hours ago, Gurken Khan said:

My Oikos doesn't have a flag:

 

logs290423.zip 60 kB · 0 downloads

@Stan` Should I fix this tonight or way until after after?

[Yekaterina]

Regarding the tower fight:

1. Just draw the blue range circle at the tower's actual maximum range, whether it's 60 or 73m. On bumpy terrains I would expect the maximum range to be different in each direction, and it would be great if we can visualise it, so that we know exactly where our units shouldn't go. 

2. in the GUI, just say: the range of this tower is 70m. Yes, an archer can shoot 60m but the height of the tower adds an additional 10m. But this reasoning can be left behind in the dev process. The actual interface can just abstract it to a simple number: 70m.