- User Since
- Jan 24 2017, 12:54 PM (213 w, 2 d)
Sun, Feb 7
Sat, Feb 6
Besides the disagreement in the revision, also conquest structure and nomad can be considered broken.
Jan 19 2021
You messed up the height. Prior to the commit the 3d position was linearly extrapolated, so we assumed a constant slope. The new calculation uses the actual position, so we better use the actual height at that position which can be different at different positions. You now assume a horizontal surface. You do need to go through the fuzz of computing the height from the position component (see earlier diff), but add it manually outside the UM.
Jan 18 2021
No the issue is not fixed here, since the update function is not used by the unitai component (or anywhere really).
Jan 16 2021
Jan 15 2021
Formations need fixing.
Dec 31 2020
Faster rates are unrealistic. Try it yourself rotating 180deg in .5 seconds is already pretty fast (which is about what 6 means here). The fact it is harder to retreat,is completely realistic. And yes it changes gameplay, but it is a feature not a bug.
Dec 30 2020
Requestign abandonment, completly unrealistic, looks horrible etc.
This has been proposed several times. Didn't search any logs, hope you did. Personally no opinion.
Make sure idle states return to NONE movement state. Remove the faceTowardsTarget state, since we can just tell stopMoving whether it should turn a bit.
Dec 29 2020
Remove some redudant template entries
Ah right, but that should be fixed indeed.
Did this intentionally. A bigger tower has the upgrades for all towers, makes perfect sense to me. At a sentry one is lesslikely to try out new things and do research than at a bigger tower, which can have more resources. AFAIK we also have some persian tech in the cc affecting wonders, perfectly fine too imo.
Ofcourse we can rescale everything. And yes buildings are much to big compared to units. But related things, especially values of the same component, should be scaled in the same way. So since we have ranges which can be thought of in meters, we should consider the unit to be meters and work with that.
Our attacktimes make perfect sense, in seconds.
Archers don't fire at 60 hertz. I'm not sure what your point is either.
You can't do like that? Search in some prominent video platform, ppl will perform it. Ofcourse in battles with groups of archers, they would synchronise shoots and thus shoot slower. But our units are mostly individuals, so they would shoot much faster.
Thats entirely the point, the speed vector can change. But the length of it is not the relevant factor, the direction is much more relevant.
The opportunity to change course does matter and this is largely determined by turnlength
And that makes it not a great backbone for a fix, since it's ultimately arbitrary.
You mean changing arrowspeed is?
Increasing projectile speed reduces time-to-hit, which of course increases the likelihood of a hit.
I won't oppose that, I merely say its not the correct way to go about it.
Dec 28 2020
Haven't seen any comment on the diff...
I don't understand why you say that. Reducing unit movement speed will completely change the feel of the game, and the units are entirely arbitrary. It's not like our "meters" are any realistic right now? "Realism" above can only refer to ratios of unit walk speed to arrow speed, and the change here indeed makes it more realistic.
Our ranges make perfect sense, in meters. Our attacktimes make perfect sense, in seconds. That are the values one should consider for realism in this case, not another concept as motion. Secondly iirc you have said multiple times you found the game to fast, you just missed an opportunity...
The claim dancing is fixed by this is false, since dancing had been made impossible prior.
I factually demonstrated that faster arrows help with dancing (see ticket), and now you're just asserting that dancing is impossible when actual players have raised concerns on the turning diff. I don't think we can actually ignore other factors.
Players have reason concerns about issues already present in the game, just highlighted by the turning. That is not turning fault, is the fault of other bugs (and yes we should fix those).
Ratio with unit speed is not the interesting value. Turnlength much more relevant for the problem at hand, if there is any problem left.
Except it's not ? Turn lengths could be 10ms, and fast units with slow projectiles would lead to dancing.
UnitSpeed should be compared to spread: both determine a distance by which we will/can miss. The arrrowSpeed largely determines the time till hit, by which predict the estimated target, the speed doesn't matter in this (we know the speed so we can account for it). The opportunity to change course does matter and this is largely determined by turnlength. Do note that the shorter the turn, the worse it gets.
Dec 27 2020
Expressed my concerns many times. Assuming m/s unit this makes arrows fly 360km/h. According to some quick search arrows had speeds between 150-200mph when leaving the bow. This will yield 66-83m/s. Considering some friction, to first order, you should lower these speeds further. Also consider that this is the horizontal speed so there is a factor cos(pi/4) in the equation too. So the original values made much more sense to me. If you wish to compare with unit speeds, you should rather lower the unit speeds.
agreeing with the code, but unelectable as reviewer.
Dec 26 2020
There are two things:
- If one uses the unitMotion overlay one can observe that the computed position are "catching up" with the target every turn. So we only look in the future, if you want to call it like that, because our pathfinder is running async (which we should do ofc) and thus the new target will only be used for actual walking the next turn, when the target has made its move. So effectively we are moving without any knowledge of the future. IRL the pathfinding would happen instantly (no need to look on a map where the target is, if you see it...)
You haven't even read the whole post. Read the first sentence again, and you see it is total nonsense you write now.
Don't see how this is cheating: if you see someone walk, you can tell if he is going to take a turn before he actually makes a turn. Also you know someone is gonna stop if he is going to bumb into something. Notice we do not read of next orders given to the entity (that is arguably looking into the future), just use the path the entity already has.
fix the indents
Dec 25 2020
IsPotentiallyMoving will give some more love, need excerpts from D3225 before
don't early return in moveTo
Acceleration helps because the unit will stop at each waypoint and goes much slower on small segments and thus is much more likely to get hit.
k, got another option, havent tested it: we change the two instance of cmpControllerMotion->IsMoveRequested() to cmpControllerMotion->IsPossiblyAtDestination().
The isMoveRequested function changed is only called from unitMotion. Why the change is required is that otherwise no movesucceeded and moveFailed messages are send to members when a formation is in rotation state, even when its not rotating anymore. This is not the unitAI fault, its unitMotion not sending messages it should send. Also the other usages of the function, actually don't want to know if the moverequest is not NONE, but whether we are potentially moving, other moverequest which for which there is a clear destination, can always be added to the new function.
no other instances of phaseSort found
Please close the revision, bots are not liking me apparently
Not exactly what I mean: +5% +15% will yield +20.75% if I am not mistaking
Feel free to try the attacked handler I posted above. That allows the turning back, reduces new orders being send and fixes the most prominent case of the re-turning (might not work perfectly in case of many attackers)
reads correct and complete
front doesn't fall
Also for the shift laggyness, there is D3230, ought to be committed soonish
Looks good, didn't test
remove position from buildingAI
Yeah formations are failing on member death. This patch only highlights the issue, see D3236. We should fix that.
We can buff the accelerations a bit maybe. Only doing the cutoff is a no go considering dancing, since one can try "rectangle dancing" then
Dec 24 2020
elephant archer has 4/3 armour. Can agree on the 2/2 propoed by borg also health ==200 seems good.
Certainly agree on making it a % instead of a flat value. Not sure If I like the nuking of the pop bonus on plain wonder. Yes they have other advantages too, but the main reason to build it is the pop bonus, so I did keep some bonus for plain wonders too. Maybe 5% on plain wonder, 15% on tech?
negative decimal example
Reviewed By: borg too
Templates need some update
Allow negative resistance
This is meant for ppl not having wx installed, but do know how this script is ran. Or is it run automatically somewhere? Can't ppl just use the wx provided installer?
What happens for newer versions of wx?
Superseeded by D681
Dec 23 2020
I don't reproduce the issue anymore. I don't see any time gap between two consecutive batches, nor on the first batch. Maybe it got fixed in the mean time. For now I will abandon the patch, please reopen if the issue persists.
Remove some unneeded health code
Let units hang in ROTATE (renamed to ROTATEPOINT). This should make D2870 relative simple by adding a ROTATEENTITY.
This does mean we need to adapt the IsMoveRequested function. Maybe it needs a rename...
unit_actions.js/input.js give the order in gui, however it does it for the whole selection at the same time (as it should btw). So we arrive in commands.js with 1 order for many units. There is no guarantee the all will do the same (they are different units). Commands.js just pipes it through to unitAI (one could handle it there, but commands.js is not made for doing anything behavuour related). So one gets in the unitAI and thus propagates the variables. Also notice the attack commands send by the gather state that must not capture (we want to kill the animal), so we should handle it in the UnitAI.
So then you are equating the ROTATE state with NONE in some cases and and not in other cases... You will loose the NONE <-> not doing anything which is assumed all over unitMotion
An attack type can have a projectile or not. When it has it will use the code which currently falls under "ranged", if it doesn't it attacks more like any other type.
Front doesn't fall, change is for the better
hmm ok, see the issue: clickspam around a unit to another side of an obstruction. The problem here is that we don't know the actual path yet when we start to move. For the first turn we just try to move in the correct direcion, which can be wrong. Hence we try turning there too, which wastes some time, and thus we move slower/not at all.