- User Since
- Apr 5 2019, 7:29 PM (65 w, 21 h)
Fri, Jun 26
With ~400 entities timings go from ~1600 μs for the postMessage to ~500 μs for the postMessage including builders query.
Remove duplicate call.
Use let by scoping.
Fix population cheat. This adds 500 to the limit instead of replacing since that seems kind of weird when playing with high population capacities.
This would actually be an issue with how the cheat is applied.
This should actually be more performant (in the short run at least) since entities like sheep (non skittish, non attacking) do not have a query anymore, and healers have one (unused) query less now.
Thu, Jun 25
Let sele-tech benefit.
Some var -> let in the vicinity.
It's a bit of a pain to quickly click on them now, perhaps show five at a time and increase the size of the arrows?
Can't we show GAIA kills and such?
The rest of the file is not consistent in its use of periods. Or it is: use one after each sentence but not when the sentence ends with a link or command of some kind.
Wed, Jun 24
Remove this.IsHealer() from UpdateRangeQueries.
Formation behaviour ought to be in UnitAI, one can disband formation temporarily when close to gathering point, perhaps?
It's not really consistent in the rest of the file ;)
Tue, Jun 23
The schema proposed by @bb seems indeed more extensible.
Thanks for the review and commit @bb :)
Mon, Jun 22
- Reenable capture resistance.
- Changed tooltips (they're really bad).
Ah, yes, such an sanity check would indeed be good. Too bad they would need to be in sync then (the presence of an animation and the check in UnitAI).
If we want anything not to cheer then we can disable/remove the animation, right? Monkeys celebrate, probably other animals do as well.
- Removed Capture resistance (unused).
- Removed SE-resistance (D2808).
Sun, Jun 21
- Check for msg && msg.data && msg.data.added.
- Some styling.
- Setup LOS query only when needed.
Well, the idea is: don't switch states when we're not supposed to.
Sat, Jun 20
Possibly fix the underlying cause.
Query UnitAI directly.
Fri, Jun 19
The ticket states they were removed to save a lot of ad hoc work for translators prior to A20.
I think the point was not the loss of context to developers, but to the user. One of the goals of the game is to make people interested in history/"teach" them about it.
While I, to some extend, agree with tooltips being concise, I think the point of learning more about the past whilst playing is not to be ignored.
That would be ideal indeed. Casual players could take their time to read them while competitive players can quickly see what an aura does.
Small cleanup of comments.
Thu, Jun 18
- Some comments.
- Also change filter in BuildingAI.
Altered some comments.
And the xml.
(I should do more things in one update.)
Actally remove the deprecated AllyEntityCommand.
- Fix defensive animals (perhaps an extra stance?).
- A tad more cleanup.
- Combined natural behaviour.
- Deprecated IsAnimal() and IsDomestic().
Wed, Jun 17
Tue, Jun 16
Resistance in cmpResistance.
Underlying problem ought to be fixed.
Top right: Edit Related Revisions...
Check for controll all in GUI.
- Remove unnecessary TurretHolder-queries in GarrisonHolder.js.
Mon, Jun 15
Notice that renaming an turreted entity to an entity which is not allowed to garrison at all is broken, before and after this patch.
Send message when turrets change and react upon that in BuildingAI.
- Plural translation.
- Also buildings may be uncontrollable.
- Remove debug uncontrollability female citizens.
- bool -> controllability.
I know @elexis had a working version?
I don't think I managed to get further than a ticket (#5613) actually.
A quick and dirty method for health decay is easy. The hard part is probably implementing it the correct and most extensible way ^^ (I've been playing around with upkeep and when unable to pay that (Gaia doesn't pay): health decay.)
Fri, Jun 12
Initially there was only Health, rP1302 seems to have introduced Armour.
There are two types of not being able to respond to a particular command:
- The *entity* can't "physically" do that, e.g. a champion gathering, which is checked in the g_UnitActions.
- The *player* is not allowed to issue the order to that entity. In case of an observer, nothing happens, which is to be expected. In case of an uncontrollable entity the player may still think the entity is under their control so that is not expected.
No, since that is filtered ^^
Also the control all cheat doesn't work anymore.
But if you have a bunch of units of which one is not controllable, you won't see the cursor anyways?
Verify whether selection exists, while at at.
Check only at necessary places to avoid double looping.