Freagarach

https://github.com/0abc/0abc-a23 will come the closest I guess ;)

Dismounting will probably be a side-effect of the subunits patch https://code.wildfiregames.com/D1958.

Indeed what @fatherbushido said, it can also be seen there that that feature should already be present in vanilla? It is defined in templates/special/filter/foundation.xml that foundations start with 1 HP. One can set the health in Foundation.js in the function InitialiseConstruction. E.g.:

@gameboy, thanks for the report! I've localised it to around turn 3723 and that it seems a PetraAI bug to me, but more investigation is needed.

@gameboy, do you have a approximate time (after start) when this occured? (That makes searching for it a lot easier for me, so no necessity.)

Great to read that you've fixed it :) Would you mind sharing the cause and the fix, if I may ask?

In "gui/session/chat" there is a file called "ChatMessageFormatSimulation.js" in which, I think, you could remove " || msg.player != g_ViewedPlayer && !g_IsObserver && !g_Players[msg.player].isMutualAlly[g_ViewedPlayer]" at line 91. Perhaps you'd also need to remove line 270 from the "TechnologyManager"-component (it defaults to all players). This should allow the phase completed notifications to show to all players, for the start and abort notifications remove the appropriate lines in the "TechnologyManager"-component (just a few lines further). I hope this helps, otherwise I'll have to look more closely ;)

D2426.

Yep, that's a bug I'll try to find out when it was introduced and notify the author. There is a way to change that, but I think it would introduce nasty side effects (units attacking units in FOW). You'd probably need to play around with the "GetQueryRange" function in UnitAI. As one can see now it takes the minimum of the vision and attack ranges. (I was thinking about splitting the ranges to make them less dependent, but I think it is hard to get right.) Not much more to say than: "Yes." Work has been done on this but probably the best solution would be subunits; the rider being able to attack independently from the movement of the horse. That would allow the horse to keep following the animal whilst the rider attacks (Total War style).

It took some time to figure out but this seemed to have happened: When pressing "Stop" on an unit one sends it to the IDLE state. In that state there is a timer (set to fire on the next turn) to attack units which are close. There is also a listener that fires when there are new units entering the LOS of the unit. When that listner fires, it immidiately switches out of the IDLE state to attack the nearest new unit. In this case, there was a LOS update on the same turn as the camel archer entered the IDLE-state, therefore the abovementioned listner switched the camel archer out of the IDLE state before the timer could fire and the unit started to attack the nearest newly visible unit (the slinger gathering stone). I hope this clarifies it? Otherwise, please ask

Got a replay for that?

One could pass the type of attack from the Attacking-helper to Health.js TakeDamage, then via Reduce and HandleDeath to CreateCorpse and one could select a attack-specific animation there (at "// Make it fall over"). Note that this will not be able to specify which kind of projectile (arrow, boulder, stone) would be the COD.

D2411 D1977 By @Angen (You may use the phenotype to make them workers?)

IMHO, the animation ought to be enemy proximity-related. However, that might be costly performance-wise, so we could make it UnitAI-state dependent. I do not think the stances should influence the variant: If you're gonna attack an enemy you will look the same, regardless whether your orders were to charge on sight or wait for the enemy to close in (provided unlimited stamina ).

I can also lend a hand in creating/reviewing the diffs (in the coming weeks at least). Just let me know if I can help

Hi @rber, thanks for your interest here The change is indeed mainly for modders, in vanilla there are no units planned that deal both capture and damage at the same time1. We also thought it would be strange behaviour. The idea behind the change was to have less hardcoding and easier extension of what effects could occur when attacking a unit. I hope this clarifies it for you? Otherwise, feel free to ask

Why would you lead them to download a flyer instead of visiting the website? The flyer exists to lead them to the website, right? Then why not bring them to it immediately

Thank you for your report @gameboy! The author of the commit causing this has been notified.

@Nescio I saw on your feature wish list that the distance limit for buildings applies to all players? In `BuildRestrictions.js` after line 242 add: let players = Engine.QueryInterface(SYSTEM_ENTITY, IID_PlayerManager).GetAllPlayers(); Then at lines 255 and 267 (the range queries) replace [cmpPlayer.GetPlayerID()] with players . That should do the job

Well, it is hard to put in place nicely Since the visual attacks do not always coincide with the actual taking damage (which would be the trigger for this animation) it would be hard to time it right. Also, when the attacked unit is playing an attack animation of its own, it would be interrupted by this animation, which would look weird also. I actually had such thing in my mod, where a unit could block damage, thus also resetting the attack; this animation would fit perfectly in there All these animations make me wish D1496 gets a rebase ^^.

As a purist I would say: "−20% attack repeat time", since that is unambiguously what the modification does. For the general user, however, I would go for "+25% attack rate". (Another suggestion, not necessarily a good one, is "-20% attack interval", which sounds odd but I wanted to throw in the interval ;) )

Hi @gameboy! We have not solved this problem yet, sadly. We will let you know when we have! In the meantime, you can ignore this specific warning. You are of course still encouraged to report other warnings and errors :D

Thanks very much for the replay! The problem has been identified! Always thanks for testing as well :)

I could not reproduce it, so I would like to see the log and replay, please :)

Hi @gameboy, thanks for testing! Can you attach the replay and interesting.log, please?