- User Since
- Jan 24 2017, 12:54 PM (235 w, 6 d)
May 19 2021
Should be rather easy, keyevents for those keys are send just as well AFAIK. The key names are UpArrow, DownArrow etc.
May 12 2021
Please redo your math. If you do 0.9^x you are making everything more easy, more performant and you get 0=undefined= immume, so no damage being dealt. Makes total sense to me. Just have to rename stuff and work out the gui.
Not all usecases will iterate this particular object. One might iterate an attackers attack object instead, and turn into trouble. In fact this is exactly what we do in current SVN,. So this revision is turning an iteration which does exactly what is being expected, into one which has likely breakage.
If you wish all damagetypes in each resistance instance (first consider performance), then fill up the missing entries from the damagtypes globalscript.
Further, and as you can see, this only changes a single file, so I think the risk is limited, and we have tests now, so the risk is further limited.
Not an argument. Anyone working with the code might come to a conclusion that we need to do some checks in another file. Also within one file the risk is huge.
Overall I'm not too concerned
Edit: also, you would lose the whole point of the diff
Well, that could be a conclusion.
Couple of random comments:
Notice that atlas uses alphabetic ordering instead of the guiorder => meh out of scope
May 10 2021
Mar 26 2021
That is a feature not a bug. Keydown should repeat, keyPress should fire just once. StopUnits has been explicitly discussed to be keyDown (hence repeating), (One reason being ungarrison, another being units going the attack)
Mar 8 2021
Feb 7 2021
Feb 6 2021
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