- User Since
- Jan 24 2017, 12:54 PM (179 w, 2 d)
Yea I know, this can be improved fairly easily, however didn't want to waste time at it in case the idea doesn't work.
I think I prefer the slower movement, because this is introducing a lot more code (and unitMotion code too).
I find this a worthless argument, if this is better gameplay wise, we should take this. The amount of code is not really relevant then IMO. Though surely one could reduce the number of lines in this patch. But again, don't want to waste my time on that for now.
Fri, Jun 26
Yea, there is an autobuild in the repository, so everything that gets committed will be build. Not every patch will get a build. Though I will try to get a build for this revision from somewhere.
Did you rebuild the game?
Some small fixes
Tue, Jun 23
This works only for contributing code right? Not sure if many artist, translators and others will read this file, but maybe good to include those too.
Probably only some trivial stuffs
Fix some spaces
Browsing D2808, I see you propose a blockchance and some change in the duration. How does this fold nicely in the chosen design here? The design here seems to be that every AttackEffect gets (a) number(s) assigned which reduce the attackstrength by some exponential law. Maybe it is just me, but I don't see how this will work for statusEffects. Neither I see a way to reuse this exponential law design for statusEffects.
Mon, Jun 22
Note that I deliberately avoided the cmpOwnership.GetOwner calls, the need a slightly more subtle care
No reference to bonusesSchema in svn
Fix the issue that formations would try to capture other formation members while they couldn't capture them
I disagree this is an argument, yet if the first is even true (the running gag of this patch is changing templates anyways).
Health and Armour have always been split ever since they are implementing. Browsing the forums doesn't yield any old discussion whether it should be one component or two. So I guess we should argue ourselfs:
The argument for not having a resistance component seems to be: Armour for an attackEffect makes only sense if we have the receiver component. And (very related) the Armour for an attackEffect on works on 1 receiver only. Using some checkrefs could save the vanilla from the useless lines, but mods might end up carrying useless template data around.
An argument for having a resistance component is that two AttackEffect can work on the same receiver, but with a different way of handling resistance. Ofcourse one can fix this in the receiver components too, however this would hardocde the receivercomponents of damagetypes.
Sun, Jun 21
Sat, Jun 20
refs D368, fix included there
With the patch applied runningat 10x or 20x speed returns a segfault. No idea what is causing that.
No longer depend the hotkeys on the attackTypes.
Working on a fix...
Thu, Jun 18
Fri, Jun 12
Most likely it is due to some square-root done in the proper function and comparelength being smart
That is not true, since all players run the code in commands.js
I don't think this is the correct place to kill these commands, they should probably never be send: i.e. kill them in ccmpCommandQueue's PostNetworkCommand. However leaving this here is good two, since an ill-willed player could revert the code from ccmpCommandQueue and still crash everyone.
Thu, Jun 11
ccmpRangeManager.h claims targets and sources are points
Wed, Jun 3
IIRC they reason why rams can attack units is that otherwise one can surround a ram by a few units, making it useless. Currently in that situation (at least most of the time), it will attack the surrounding units, trying to break free. Though it already prefers attacking structures over units (so it only attacks units if there are no structures around).
Jun 1 2020
For the interested reader: D86
Did you also do a rejoin test? We move some serialized data around, and remove a clone somewhere, so that raises a concern (not that I see it trivially broken though)
Needing a rebase
Note that we already have this ordering in intro.txt
The revision should have closed, even though I wrote D1042 and not the full link (there are plenty examples in the commit history where the shorthand does work). However phab also didn't add an edge here, so seems to be some hickup in phab. @Nescio can you close it manually?
May 31 2020
Shouldn't the sele paired tech benefit from this immediately?
Needs a rebase, appears to be equivalent to rP8997
The name of Flight_demo_2 should have been adapted.
Seems like the pmp file is missing, map doesn't load here
All champion chariots similar now. Won't affect gameplay too much, since we only group brit with maur and sele now, instead of with the rest of them.
May 27 2020
Do you have a replay, showing you can actually move your attention away from the dancing unit, without it getting hit?
It also will be very annoying when trying to micro and probably in other scenarios, I can't foresee right away. First thing is when I'm raiding with cavalry. I want to be quick and not have my cavalry suddenly slow down because I didn't click far enough in front of them. When I find an exposed group of units whilst raiding I want to position my cavalry in the retreat route to make them go a longer distance and also right by my units, this patch makes it very hard to do so as I generally will be clicking my units forward small distances. With the patch, I will have to click further away, hope the pathfinder doesn't do something dumb, and then use the "Stop" hotkey.
Again do you have a replay where these short distances are actually used?
EDIT: I didn't test formation patrol dance when posting this. Still very possible and easy to dance with formations. Take however big a group of units (Smaller is better (2 works great)) and patrol right in the middle of the formation. They'll move just as quick as before.
Formations have got the same treatment and short moves in the formation will also move slower, so that ought to not work.
May 26 2020
Comment by Freagarach
fix data.x(z) === 0
Don't recompute formation speeds
Make ternary more readable
May 25 2020
Name unitMotion components of members of a formation memberUnitMotions
One could wonder if rP17208 is still required
Persist => Ensure
Don't create Vector2D for performance
May 24 2020
For sure one can do this, but is it valuable? one needs 100% attention from the player to do so (one can't shift click anymore), so moving other troops got impossible and such
May 21 2020
The design I have in mind is the following:
UnitAI chooses "cleverly" what the unit is doing, other components perform the tasks.
UnitAI should be allowed to let several components perform different tasks (i.e. unitAI could allow a unit to attack and walk at the same moment).
UnitAI can be replaced by BuildingAI, turretAI and whatnot, but all those should be able to access the same "other components" and let them perform the tasks (otherAI components just choose differently what tasks are done)
There are 3 types of information: number of builders, time remaining and speedup by extra worker. Currently the time remaining is on the front page, and the other two in the tooltip. IMO if we add the number of buildings to the front page, we should show all 3 in the tooltip (why would 1 piece of information be in 2 places otherwise?)