Freagarach

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!

Hail to all modders! (@Exodarion, @darkinterloper, @borg-, @Nescio, @Angen, @wowgetoffyourcellphone, @Trinketos, @Stan`, @FeXoR, @asterix, @DarcReaver, @nani, @azayrahmad, @Loki1950 and all those not mentioned (we gotto have a list or something for this).) When working on improving support for armour (D2229) there rose some questions during discussion with @wraitii. I've seen some mods with directional damage support and, because templates ought to be changed anyways, I thought I might as well try to add some support in SVN, or at least make it easier. Template code as it stands: What I propose: The code to calculate the resistance to a specific attack would allow for resistance types to be circumvented. However, the condition as to which resistance type(s) to circumvent still needs to be coded in component files, by you. This leads to the loaded question: do you think this is worth a shot? (For those interested in the actual code and perhaps willing to give some feedback on that specifically: D2229.)

The most efficient way of expanding is by building a civic center, though. That will give you large amount of extra territory. So you can build a civic center close to your beloved stone deposit. That has an extra advantage that your citizens can hide inside the civic centre in case of a raid. The civic center can only be build in the city phase. Some civilisations can build a military colony in the town phase, however, which is a "smaller" version of the civic center, with less territory influence.

It (the feature of diffent stances) was actually on my ToDo-list for rainy days (which we have quite a lot here in the Netherlands). Happy to take a look at your patch of course, just ping me when you've got something