If you select food to sell, you should get a number on the coin? If that is not the case, please report :)

You're right, I mixed up, selling works fine. My problem is actually with the buying part. Instead of bartering a fixed 100 silver and getting +409 food in return, I want to buy 100 food and pay only the silver equivalent.
For comparison, if you go to the supermarket, you don't want to know how much bread you can get with €100, you want to know how much one bread will cost you.
Basically, there is a fundamental difference between a barter-based economy and a currency-based economy.

In D1957#83317, @Nescio wrote:

What I don't know for sure is what causes the errors (D1846, D1957, me including them, some other file in my mod, or something missing in A23 compared to A24, something else).

Thanks for the report! I reproduced this and found the errors. Mentioned in D1846.

In D1957#83317, @Nescio wrote:

• the barter and trade window width apparently only takes the tradable resources into account and overlooks the barterable resources need to be displayed as well

Overlooked by me ;)
We need to check whichever is largest.

Alternatively, keep the resource amounts fixed at 100, and display the currency equivalents:

     || 100 food  | 100 wood  | 100 stone | 100 iron
buy  || −a silver | −b silver | −c silver | −d silver
sell || +w silver | +x silver | +y silver | +z silver

So I tried out incorporating D1846 and D1957 into my 0abc mod; silver has
"properties": [ "barterable", "currency", "tradable", "tributable" ],
the other four resources only [ "barterable", "tributable" ]. Also, silver, food, wood, stone, and metal have a "truePrice" of respectively 100, 20, 40, 60, 80 (to correspond to the fact they have different gather rates).
When launching a game, building a market, and opening the trade window, this is the result:

• the -100 numbers on top of the sell resources are not really meaningful; what we actually want to know is how much silver we get if we sell 100 of a resource
• the barter and trade window width apparently only takes the tradable resources into account and overlooks the barterable resources need to be displayed as well
• the position of the currency resource silver is a bit odd; perhaps we should have three rows: select currency (in case there are more than one), sell resource for currency, buy resource with currency
• and a js error:

ERROR: JavaScript error: simulation/ai/petra/diplomacyManager.js line 412 SyntaxError: missing ; before statement InitGame@simulation/helpers/InitGame.js:57:1
ERROR: Failed to load script simulation/ai/petra/diplomacyManager.js
The line in question is:

requiredTribute = gameState.ai.HQ.pickMostNeededResources(gameState).find(res => tributableResources.indexOf(res.type) != -1));

What I don't know for sure is what causes the errors (D1846, D1957, me including them, some other file in my mod, or something missing in A23 compared to A24, something else).

Successful build - Chance fights ever on the side of the prudent.

Proper checking for Vector3D.

Successful build - Chance fights ever on the side of the prudent.

• Created FF under "Projectile".
  • Updated templates accordingly.
• Refactored splash data.
  • Updated tests accordingly.

Successful build - Chance fights ever on the side of the prudent.

comments

In D1993#83291, @Krinkle wrote:

Hoping to see this land relatively soon to avoid merge conflicts, after that I'll move on to the next area to lint :)

Hoping to see this land relatively soon to avoid merge conflicts, after that I'll move on to the next area to lint :)

Successful build - Chance fights ever on the side of the prudent.

Some rather minor fixes.

Successful build - Chance fights ever on the side of the prudent.

In D1950#83264, @Nescio wrote:

By the way, <FriendlyFire> is wrapped inside the <Splash> node, but shouldn't it be applicable to non-splash attacks as well? E.g. an archer shoots an arrow at an enemy, but the projectile spread causes it to land on another unit of yours right next to the target, then it would be nice to have if that one was wounded, for realism.

By the way, <FriendlyFire> is wrapped inside the <Splash> node, but shouldn't it be applicable to non-splash attacks as well? E.g. an archer shoots an arrow at an enemy, but the projectile spread causes it to land on another unit of yours right next to the target, then it would be nice to have if that one was wounded, for realism.

In D1950#83262, @Freagarach wrote:

In D1950#83259, @Nescio wrote:

<Delay> could also make sense for melee attacks, e.g. a unit who plants bombs.

That would need a "Projectile" as well right? Nevertheless I do agree that "Delay" could be useful.

In D1950#83259, @Nescio wrote:

<Delay> could also make sense for melee attacks, e.g. a unit who plants bombs.

That would need a "Projectile" as well right? Nevertheless I do agree that "Delay" could be useful.

<Delay> could also make sense for melee attacks, e.g. a unit who plants bombs.

For reference this was a WIP while I was working on the full system https://github.com/0ad/0ad/compare/master...bb-bb:t252_secondAttack. I have a little better version iirc, but that needs a rebase before uploading.

In D1950#83214, @Nescio wrote:

Ideally different projectiles would also be able to have different damage, therefore what is eventually desirable is support for multiple ranged attacks, e.g. a fortress able to fire both arrows (long range, low damage) and javelins (shorter range, higher damage).

In D1950#83247, @Freagarach wrote:

Easier with D2002?

In D2002#83250, @bb wrote:

I indeed have a branch for the secondary attacks, which also generalizes the attackTypes. That branch is pretty much a more or less complete version of this revision, I will update that branch to current svn soon, but that will come after my exams of next week...

In D2002#83250, @bb wrote:

(,,,) which also generalizes the attackTypes. (...)

Hmm, I did not get that from your diff. I might overlook it I guess.
Feel free to take over this diff if you want!

I indeed have a branch for the secondary attacks, which also generalizes the attackTypes. That branch is pretty much a more or less complete version of this revision, I will update that branch to current svn soon, but that will come after my exams of next week...

Please correct me if I'm mistaken, but currently ranged attack has everything melee attack has, plus <Delay>, <ElevationBonus>, <Projectile>, and <Splash>.

In D1950#83234, @wraitii wrote:

The correct way forward is probably to define the common schema of melee attacks and projectile stuff somewhere, then re-use that, instead of duplicating the schema so much.

Easier with D2002?

Thank you for the clarification, that sounds great!

In D2002#83231, @Nescio wrote:

What does it do? Won't different attacks conflict? And how do units know which one to select?

In D2002#83231, @Nescio wrote:

What does it do? Won't different attacks conflict? And how do units know which one to select?
Also, wasn't @bb working on something similar?

According to the ticket, @bb was working on it three years ago. I think this needs to be seen in conjunction with D1595 and #252.

In D1950#83233, @Freagarach wrote:

So we need a "Range" node in the "Attack" *and* a "Range" in the "Projectile"?

We would

But currently the chech whether a projectile can be launched is performed only once, so we would need a check per projectile I guess?

Yes it's a paradigm change, introduced mostly by D1171 a said above. Launching multiple projectiles is unsupported, but it could/should be added. But I think it'd be better first to make Projectile handle more things.

In D1950#83213, @wraitii wrote:

Forgot about melee attacks... But my above point still stands that we might want attacks that generate more than one projectile, and then these projectiles could have different range behaviour. We might need range at two different levels again.

I suggested it because most mods are based on A23, this patch has already broken support for them, requiring them to be updated when A24 is released, so now would be a good time for regrouping other elements.

Very good point. Might be worth it indeed.

So we need a "Range" node in the "Attack" *and* a "Range" in the "Projectile"?
But currently the check whether a projectile can be launched is performed only once, so we would need a check per projectile I guess?

What does it do? Won't different attacks conflict? And how do units know which one to select?
Also, wasn't @bb working on something similar?

In D1950#83214, @Nescio wrote:

Ideally different projectiles would also be able to have different damage, therefore what is eventually desirable is support for multiple ranged attacks, e.g. a fortress able to fire both arrows (long range, low damage) and javelins (shorter range, higher damage).

Successful build - Chance fights ever on the side of the prudent.

Ideally different projectiles would also be able to have different damage, therefore what is eventually desirable is support for multiple ranged attacks, e.g. a fortress able to fire both arrows (long range, low damage) and javelins (shorter range, higher damage).

Forgot about melee attacks... But my above point still stands that we might want attacks that generate more than one projectile, and then these projectiles could have different range behaviour. We might need range at two different levels again.

In D1950#83191, @Nescio wrote:

I suggested it because most mods are based on A23, this patch has already broken support for them, requiring them to be updated when A24 is released, so now would be a good time for regrouping other elements.

Partly agreed, but (, I think,) modders are already converting their mods based on SVN.

Melee attack also has range, but no projectiles. You're right, it has no immediate gameplay effects, it would just be a more logical grouping in the xml files. Currently there are already separate nodes for <Bonuses>, <Damage>, <Projectile>, <RangeOverlay>, and <Splash>. I believe <RangeOverlay> is based on <MaxRange> and <MinRange>, so it would make sense to put those (and <ElevationBonus>) inside the same node, and rename it to simply <Range>.
I suggested it because most mods are based on A23, this patch has already broken support for them, requiring them to be updated when A24 is released, so now would be a good time for regrouping other elements.

In D1950#83187, @wraitii wrote:

One question is what to do with range - range implies projectile, should range be moved to the projectile? Possibly if we want one attack to send multiple projectiles with different behaviour. So maybe then do it. If it's just to group with no gameplay impact, I don't think it's worth breaking mod compatibility.

In D1950#83186, @Freagarach wrote:

In D1950#82844, @Nescio wrote:

Thank you for this patch. Next question, should we also have a <Range> node? E.g.:

That is up to the dev's I guess. I think it is pretty, but is it useful? Useful enough to agitate the modders again?

In D1950#82844, @Nescio wrote:

Thank you for this patch. Next question, should we also have a <Range> node? E.g.:

That is up to the dev's I guess. I think it is pretty, but is it useful? Useful enough to agitate the modders again?

Successful build - Chance fights ever on the side of the prudent.

• Simplified "FaceTowardsTarget" function.
• Generalised "ShouldChaseTarget" function.

Successful build - Chance fights ever on the side of the prudent.

"DeathDamage.js".
@Stan I do not think the lowercase damage is a typo, see comment at commit.

Successful build - Chance fights ever on the side of the prudent.

• this.Config.DamageTypeFactors.
• Added missing "/".

Successful build - Chance fights ever on the side of the prudent.

• Updated "Sound.js".
• All "gender" -> "phenotype".

some comments

Successful build - Chance fights ever on the side of the prudent.

Due to the state of D1938, this has become obselete :)

• Simplified armour checks.
• Taught AI where to look for armour.
• dTTT in "Tooltips.js".
• Some "var" to "let".

Thanks, I guessed that was possibly the case, but I wasn't sure.
Anyway, to avoid future confusion, I've inserted a tiny section in the CC:
https://trac.wildfiregames.com/wiki/Coding_Conventions?action=diff&version=42
Feel free to correct, or revert if I wasn't allowed to.

Most of the time Anything between {} is part of an object. anything between [] is part of an array

Sorry, I'm not really familiar with js, nor can I safely say I know exactly the difference between objects and arrays.
What I did is follow D1953#81077.

spaces inside brackets, e.g. [ "Ship" ] instead of ["Ship"]

(The JS code has these spaces for obejcts but not arrays, Coding_Conventions#JavaScript recommends it for objects but doesn't speak on arrays. So if you would want to make it more consistent, JS arrays be updated too or those spaces ommitted. I suppose one can add that to the CC so that people don't have to become familiar with the large codebase in order to be able to apply the consistency rule of the CC.)

Successful build - Chance fights ever on the side of the prudent.

Forgot a few lines in "Headquarters.js".

In D1938#83103, @Angen wrote:

common-ai is supposed to be independent from any ai created upon it.

what do you want to do ?
did not damages.js work?

Successful build - Chance fights ever on the side of the prudent.

Could not stand not figuring out the PetraAI.

Successful build - Chance fights ever on the side of the prudent.

common-ai is supposed to be independent from any ai created upon it.

This would allow enabling special resistances in the future - a unit invulnerable to some damage type shouldn't be killed even if the attack is "instant-kill".

Sounds great (e.g. structures immune to pierce damage)!

In D1938#83100, @Stan wrote:

Well if you can fix the ai that's nice.

Hmm, I'm trying, but it doesn't go smooth ;)
I'm using the "config.js" since that is the most logical place to store the "damage importance values", IMHO. But it seems that I can't call that "config" from "entityExtend.js". Many (other) managers are started with the "config" as an element in it's function.
I think it is best to leave it at this for now.

Well if you can fix the ai that's nice.

Successful build - Chance fights ever on the side of the prudent.

Helptext in helper :)

In D1938#83088, @wraitii wrote:

Looks good - I'll test when I can and commit it.

Should I also try to fix "PetraAI"? It currently has the "damageTypes" hardcoded in its "entityExtend.js" with an importance factor.