Freagarach

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?

The elevation adapted range depends on the surrounding terrain. So the number in the template is acutally the attack-height offset (the point from which the projectile is actually fired), which is used to calculate the "real" range. (I made a diff a while ago to rename it: D2016.) I hope this clarifies it for you :)

Update: It is in vanilla now! One can remove a property from the resource json file to prevent it from being bartered, traded or tributed.

Do you have a link to a public repo where your code lies? That would make debugging a lot easier (and you don't have to upload every changed file here on the forum) :) In this case, you did remove the ability to build stone walls, but as you mentioned Now, the engine tries to remove wallset_stone from the template of those Spartans, but that (wallset_stone) is not there anymore. Like trying to get money of an empty bank account. That is what is causing the warnings. To fix it, you can remove those lines (those being: "-structures/{civ}_wallset_stone") from the Spartan templates.

If I'm not mistaken, the game sees those as being multiplayer, so you'll have to select either multiplayer or singleplayer/multiplayer.

Aye, this is for armour only. This would allow for a modder to circumvent specific resistance types. An example: The downside of this is, when we include it but noone uses it, that it means more code to maintain, more chance for bugs, for no benefit. I hope this clarifies it a bit @Trinketos? Otherwise feel free to ask! Anyone who is constructively participating on the forum is, IMHO, a contributor. But if you still want to be edited out (because you're no modder?), I'm willing to do that.

This is spot on That (a percentage of damage based on the position) is currently not implemented, but is not that hard (see @Angen's battalion mod). What I envision is that a unit attacked from the front has a ~95% chance of using the shield to block damage (when not preoccupied, perhaps) and decreasing that percentage to "0" at the edges of the LOS of a person. But that has to be coded in seperately in "Attacking.js". (D2175 combined with D2182 and properly working formations, as @Alexandermb noted.) Glad to be of service!