- User Since
- Jan 24 2017, 12:54 PM (201 w, 2 d)
Thu, Nov 19
To get to the original situation, one should add the size (== half diagonal length) of the gate to the range. As gates tend to be rather long and thus have a large size, the reduction was done to make gates close in roughly the same situations. Now if you take the brit gate: 37x8, you get half diagonal of (just under )19, so in fact the range got slightly bigger there (similar values are true for the other gates).
Wed, Nov 18
The problem here is that IGUIButtonBehavior is never called when setting the style. While this fix works for the given problem, it is a result of a more general problem: setting styles on buttons does not update the button behaviour. I would somehow be nice if the cpp could solve our problem. I.e., some message is send when a new style is added. Not sure if this is worth it though.
Big thank you, @Nescio, your comments and questions have improved the code and strings tremendously.
Tue, Nov 17
Testing verifies sounds are heard, also for observers (when viewing a player). Defeating sound work (sim is processed before gui, the g_ViewedPlayer didn't change yet when the sound is played).
Observer not viewing a player don't hear anything => probably wanted, certainly not possible i the current design (also would need new sound).
Indeed, especially since a different context can mean a different translations.
Mon, Nov 16
Annoying indeed, but it is how getText works...
To be more precise: the default context is defined in the messages.json file, the tooltip.js string indeed needs to match this string (that way we can retrieve the correct string). Therefore changing the tooltip.js line doesn't cause any retranslations. Changing the string only in tooltips.js, will result in non translated strings. Changing the string in the messages.json, WILL cause retranslations (and to see the translation ingame one also needs to change the tooltips.js string). I hope this is somehow clear...
Sun, Nov 15
try on fixing tests (everything works here)
Add test of removing handlers on handlers. Note that the removed handlers are not called, since their m_EventHandler is deleted (this is how it was before too).
Sat, Nov 14
I rather be too much verbose than to less in this case. We actually want some identifier for the way of attacking, not necessarily the weapon (“A single-edged sword.”) or the act of attacking (“Attack using a single-edged sword.”) and I wouldn't be surprised if there were languages who would make a difference between this.
The order of calling is ambiguous anyway, so changing it is fine.
How about this?
Fri, Nov 13
Better name suggestion are welcome
Lets loop another time through all entities, hardly a way around it though.
Either make it mandatory, or say that a unit with no cheertime shouldn't cheer (several ways to do this, either pass the time in the order and not send the order if no time, or finishorder on enter, or discard the order on order.Cheer)
Actually can't easily remove the slaughter thingy, since it is processed through the code. On the topic on whether it will be shown: #252 will abstract the notion of attacktype, so there won't be any difference between the attacktypes. Don't worry slaughter won't be able to instakill everything, we have restricted classes for that. Showing the restricted classes might be something to consider.
Maybe I remove the slaughter thingy, since it is adding dead code here. I find it somewhat bad that it is not displayed. IMO it should just be displayed along side the other types (I actually do this in #252). Changing one template there won't hurt too much (especially since we need to change that template then anyway).
Thu, Nov 12
see #4000, buildingAI currently takes preceding (adding other attacktypes to those entities will not do anything)
Fundamentally there is no difference between melee and ranged attacks. So if buildingAI were to use melee attacks (which it is hardcoded not to do), this patch would change stuff. As buildingAI does not have melee attacks, there is no change. UnitAI attack logic is not directly affected, so for unitAI ents, there are "no" changes (there are some other slight changes, like I expect units to look for targets further away now)
Wed, Nov 11
No idea which patch it exactly comes from but doing a clean build with D3085-95 applied, gives me
Lower gate opening range which was much too high now.
Did you intentionally remove the rebalance changes from an earlier patch? (Can be committed separately, I don't mind)
Testing confirms this works as expected. Just some comments on the comments, should be trivial to fix those.
Tue, Nov 10
To account for sphere sizes, we can treat them as squares (Size•Size) and do this:
inrange(max(d-size, 0), h-size, range)
That is not what we want to check. The size does not have a vertical factor afaik, so you want inrange(max(d-size, 0), h, range)
Mon, Nov 9
Sat, Nov 7
The clue in finding a correct parabolic range check, is not finding the check, it is finding a fast check. Write d>0 for the distance, s>0 for the shap size (so sourceSize+targetSize), r>0 for the range and h for the height factor. Notice for computing d we need sqrt, while we can compute d^2. Now assuming all obstructions are circles, the following check is completely sharp: sqrt(r^2+2rh)>=d-s. However we want to avoid sqrt'ing for performance. An equivalent check is r^2+2rh>=(d-s)^2 || d^2<s^2 (square the previous relation but be careful with negative values). Writing some stuff around this is equivalent to r^2+2rh-d^2-s^2>=-2ds || d^2<s^2 and flipping the sign gives d^2+s^2-r^2-2rh<=2ds || d^2<s^2. Again squaring gives the equivalent relation (d^2+s^2-r^2-2rh)^2<=4d^2s^2 || d^2+s^2<r^2+2rh || d^2<s^2. This can be computed without sqrt, but one should be careful with overflows.
We can't use the node key directly, since that cannot be translated.
Wed, Nov 4
Nov 2 2020
As I've noted inline, I've updated the code once more because I need to account for the fact that size is the diagonal size but I don't know the 'smallest' side, so I can't account for the 'querier size' in the minrange case and the 'target size' for the maxrange case. I think everything is correct this time around.
Oct 29 2020
Not all rotation is done in unitMotion, only on the first turn, when m_TurnTime is enabled
Oct 28 2020
Oct 26 2020
@return ratio between the value of the slider and its actual size in the GUI value is clearly wrong, whether you call it misleading or whatelse, misleading comments are just as much telling lies about the code.
no will to relook at. Eyeballed through all commends in the unitAI, found a few, otherwise mehing
Oct 25 2020
Don't really see the relevance
(though I don't really understand why you need it, if you could provide an example - haven't figured it out really from the diff before either)
See revision summary for example. More generally, the current script sees any string between the brackets after translate even if they are not really translatable strings, but rather strings used for array/object/inlined function construction or (as the example) for accessing array/object values.
Oct 23 2020
Oct 22 2020
Oct 16 2020
split object definition over several lines
Oct 13 2020
Oct 12 2020
How is the behavior for Width==0 defined? The Width usually refers to the horizontal size of the guiObject. Having Width==0 work as nowrap doesn't work due to L235/L240 in cGUIString.cpp and we have to do something is Width==0.
I suppose the lobbybot readme needs some updates too
Oct 10 2020
Oct 5 2020
Some probably should have been added in rP23182, for some others times changed.
Sep 29 2020
These Width == 0 checks are nagging me a bit, they seem to have some undefined behaviour.
Better noWrap handling
Yea, was messing up stuff