Page MenuHomeWildfire Games

Trade gain related to the current map size
ClosedPublic

Authored by mimo on Sep 6 2017, 6:29 PM.

Details

Summary

The trade income is actually calculated on the linear distance between the markets without taking into account the map size and the proportional amount of resources generated, thus the weight of the income and trading with players.
By scaling the trade income with the map size, the trade income won't get higher priority over gathering, which should be the primary source of resources, and will allow players to benefit from shorter trade route in smaller sized maps.
Here is a table showing the current and the proposed values took from tests made in random generated Polar Sea map and compared with and without the unlock of trade improving technologies:
EDIT: gain suggested by mimo gain rate on map diameter 0.778.

Test Plan

Apply the patch, start a game session ( usally Polar Sea works fine because players start with market ) and check the difference of resources the trader is carrying from market to market.

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
mimo added a subscriber: mimo.Sep 6 2017, 8:59 PM

First, i've not understood what the numbers in the table correspond to. Could you define them?

Then, i agree that some scaling of the gain with the mapSize would be better, but i'm more worried by the square increase of the gain which is not good and should have some kind of saturation. If changing the gain, better do both changes.

I've not completely made up my mind, but my current thinking is the following: the current gain is A*d*d, but the important number is the effective gain by unit of time which is proportionnal to A*d (as time to travel is proportionnal to d). If we want it to saturates, a simple function is A*B*tanh(d/B) which looks like d for small d, and is more and more attenuated when d increases. A simple case would be to just take B=mapSize, in that case, doing a travel across the full map would decrease the gain by tanh(1)=0.76 while a travel along half the map would nearly not be affected as tanh(0.5)/0.5=0.92. Thus the effective gain would be A*mapSize*tanh(d/mapSize). [Of course, other values are also possible depending on what we want, taking for example B=1.5*mapSize would give instead an attenuation of 0.87 for a travel along the full map].

Then if we add your proposition, and scale A with mapSize (keeping the current value for medium maps), i.e. A -> A*1024/mapSize, the final effective gain would be A*1024*tanh(d/mapSize), and the gain itself A*1024*d*tanh(d/mapSize)

binaries/data/mods/public/simulation/helpers/TraderGain.js
44

The comment in the gainMultiplier Schema of the Trader is no more true, should be changed accordingly.

elexis awarded a token.Sep 6 2017, 8:59 PM
temple added a subscriber: temple.Sep 6 2017, 9:48 PM

I spent some time thinking about trading a few months ago. I didn't quite have a complete solution, but here were my ideas:

  1. Traders "gather" or load up from markets in the same way other units gather resources (there's a gather limit too).
  2. Territory area determines the traders' capacity.
  3. The gain is linear in distance rather than quadratic, and is calculated when the resources are dropped off.

Because there's a loading time (and gather limit), it's better to have markets far away from each other. But because the gain is linear in distance, it's not as important to have markets as far away as possible. This addresses mimo's comment without adding "weird" functions like tanh. It's more transparent to the player as well.
Also, because capacity is related to area, it implicitly scales by the map size. Again, I think that's more transparent to the player about what's going on than putting the mapsize in the gain formula.
I'll post on the forum when I get some time and can gather all my notes.

For now I think this is a nice improvement (I didn't check the actual numbers), should help on pizza maps. For reference, AOE2 and AOM use gain = const * dist * (dist/mapsize + const).

In D879#34327, @mimo wrote:

First, i've not understood what the numbers in the table correspond to. Could you define them?

The numbers in the table correspond to the total amount of resources carried by a trader per trip in a route between own market, let's say south side of the map, and an ally player on the north side of the map. The amount is the sum of the trader gain + player international bonus + target player international bonus ( i don't agree on that formula because international trade bonus is a reward by itself with no need to donate resources to the target market owner. The syntax in the tooltip " ( GainNumber + international bonus , international bonus "Targetplayer" ) " is confusing ).
Without Tech is the amount of resources carried by a trader.
With Tech is the amount of resources carried by a trader modified by +25% mov speed +25% trade profit +10% international trade bonus.

Then, i agree that some scaling of the gain with the mapSize would be better, but i'm more worried by the square increase of the gain which is not good and should have some kind of saturation. If changing the gain, better do both changes.

I didn't understand this comment. Do you mean an arbitrary constant variable to multiply by mapSize?

FeXoR added a subscriber: FeXoR.Sep 6 2017, 11:56 PM

@linear gain: Then I'd always chose the shortest possible trade routes since it's the same amount of resources per time and trader no matter the distance ... and nearly no risk involved.
@square is to much: What about an exponent about 1.5?

In general I don't understand why the map size should play a role here. Because it's less likely an enemy stumbles about a trade route on large maps?

mimo added a comment.Sep 7 2017, 8:16 AM
In D879#34358, @Grugnas wrote:
In D879#34327, @mimo wrote:

Then, i agree that some scaling of the gain with the mapSize would be better, but i'm more worried by the square increase of the gain which is not good and should have some kind of saturation. If changing the gain, better do both changes.

I didn't understand this comment. Do you mean an arbitrary constant variable to multiply by mapSize?

Isn't this explained in the following lines of my post? Or maybe what was not clear is that the second part of my sentence (my worry) was not connected to your patch, but to the current distance square increase of the gain.

mimo added a comment.Sep 7 2017, 8:27 AM
In D879#34359, @FeXoR wrote:

@linear gain: Then I'd always chose the shortest possible trade routes since it's the same amount of resources per time and trader no matter the distance ... and nearly no risk involved.
@square is to much: What about an exponent about 1.5?

no, exponent < 2 would give too much steep rise at small distances, that's why i proposed this d*tanh(d) which keeps the current behaviour at small distances (slow rise, which i think is very good), but damper the very fast rise at large distances.

In general I don't understand why the map size should play a role here. Because it's less likely an enemy stumbles about a trade route on large maps?

let's say that typically you have two teams controlling half of the map, the current gain from trade is much bigger on large maps than on small ones, and i agree that currently it is too large on the biggest maps compared to resource gathering. Thus the need for scaling. Then should it be proportional to mapSize as proposed here, or only to sqrt(mapSize) or whatever, i've no strong opinions.

Agree that capping (not done in the proposal) is more important than taking care of the size of the map.
Agree that tanh or any logistic function will do that job.
Agree with mimo.

Grugnas added a comment.EditedSep 7 2017, 12:34 PM

Agree that capping (not done in the proposal) is more important than taking care of the size of the map.

I am not sure if the trade gain should be capped as long as the player has no info about the trade income before he places the market and estabilish a trade route to the target market and this would be just confusing and perhaps would require players to build many markets in order to "get the best spot" where to place own market.

Agree that tanh or any logistic function will do that job.

I must admit to have no experience at all with such function but seems promising, I will try to get some info about and perhaps upload a new patch with the suggested formula and compare with the only map size scaling.

EDIT: changing the formula based on the suggestions of @mimo i got this one:

	let distanceSq = firstMarketPosition.distanceTo(secondMarketPosition);
	let cmpTerrain = Engine.QueryInterface(SYSTEM_ENTITY, IID_Terrain);
	gain.traderGain = gainMultiplier * cmpTerrain.GetMapSize() * Math.tanh(distanceSq / cmpTerrain.GetMapSize()) / 10;

i got those differences compared to the proposed values affected by NO techs which perhaps don't suit with what is the suggestion intent (now i am even more confused) :
Tiny size: Trade income increased by 26,9%
Normal size: Trade income increased by 18,5%
Large size: Trade income increased by 16,4%
Very Large size: Trade income increased by 22,8% (this seems to not fit because it should be lower than 16,4% )
Giant size: Trade income increased by 17,7% (this seems to not fit because it should be lower than 16,4%)

elexis added a subscriber: elexis.Sep 7 2017, 1:41 PM

Agree that capping (not done in the proposal) is more important than taking care of the size of the map.

Disagree.
It's not only a problem that the gain is too big on normal and larger maps, but its also a problem that its too small on small and tiny maps.
Isn't capping implied in this proposal, because the trade gain will never exceed the gain defined by default mapsize in here?
The good part about having the maximum trade gain proportional to the mapsize is that it is equally worth on all mapsizes.
So a simple cap or a switch to a different function without factoring in the mapsize is insufficient as it doesn't address the problem with smaller mapsizes.
The distance between two markets shouldn't be the relevant factor, but the distance proportional to the mapsize.
(I had that opinion before I saw aoe2 doing that mapSize scaling too https://youtu.be/o2oT-zjYKoE?t=6m46s)

I didn't understand the problem with the square. The effective gain is the gain/minute, so theres a much bigger number shown in the tooltip, but its divided by the time the cart has to travel, so the profit still increases linearily (as it should), no?

Nescio added a subscriber: Nescio.EditedSep 7 2017, 1:44 PM

x*tanh(x) behaves basically as (quadratic) x^2 for 0<x<0.5 and quickly approaches (linear) x for higher values of x. It is an interesting suggestion and certainly better than the current x^2.

Personally I've first considered (and rejected) sqrt(x) and then tried out x+x^1.5 instead, which is not perfect, but works as a compromise between linear and quadratic; trade income (i.e. gain/distance) improves with distance but not as steeply as with x^2. Furthermore, short distance trade could be a reliable form of income (which is currently not the case), although long distance trade remains most profitable (optimum is maximum distance).

For comparison:

xx^2x*tanh(x)x^0.5x^1.5x+x^1.5
0.010.00010.00010.10.0010.011
0.030.00090.00090.1730.00520.035
0.10.010.010.3160.0320.13
0.30.090.0870.5480.160.46
110.76112
392.991.735.28.2
10100103.163242
30900305.48164194
100100001001010001100
3009000030017.351965496
10001000000100031.63162332623
elexis added a comment.Sep 7 2017, 3:17 PM

(Extending on my previous comment), if a player has an X percent longer trade route, he has to defend X percent more distance, so it seems reasonable to me that he would get X percent more resources per time, no?

temple added a comment.Sep 7 2017, 3:27 PM

Just to help out the discussion, the important thing is the rate, not the gain. Trade carts have a 9.5 walk speed, so the time to travel between markets is dist / 9.5 (assuming a straight line). The gain multiplier is 0.75, and there's an international bonus of 20% for each market, or 40% total. On mainland for example, the distance between cc's are 0.27, 0.49, and 0.65 of the map diameter for allies 1-2, 1-3, 1-4 in a 4v4. Here's a table comparing the rate = gain / time for a few different gain formulas.

a22	gain.traderGain = gainMultiplier * distanceSq / 10000;
grugnas	gain.traderGain = gainMultiplier * distanceSq / ( 10 * cmpTerrain.GetMapSize() );
mimo	gain.traderGain = gainMultiplier * 1024 * distance * Math.tanh(distance / cmpTerrain.GetMapSize()) / 10000
aoe2	gain.traderGain = gainMultiplier * distance * (distance / cmpTerrain.GetMapSize() + 0.3) / 10000

	1-2	1-3	1-4	diameter
				
tiny	0.137	0.253	0.330	0.511
small	0.205	0.379	0.495	0.766
medium	0.274	0.506	0.661	1.021
normal	0.342	0.632	0.826	1.277
large	0.410	0.758	0.991	1.532
vlarge	0.479	0.885	1.156	1.788
giant	0.547	1.011	1.321	2.043
				
grugnas	0.267	0.494	0.645	0.998
mimo	0.267	0.468	0.582	0.778
aoe2	0.580	0.812	0.967	1.328

rescaled to the diameter:
grugnas	0.268	0.495	0.647	1.000
mimo	0.344	0.602	0.748	1.000
aoe2	0.437	0.612	0.728	1.000

For comparison, gather rates are around 0.4 for fields, 0.45 for mines, 0.65 for wood. With all upgrades the trade rate is 1.8x as big, fields 1.7x, mines and wood 2.0x, so it's okay to compare the unupgraded rates.

In D879#34481, @elexis wrote:

(Extending on my previous comment), if a player has an X percent longer trade route, he has to defend X percent more distance, so it seems reasonable to me that he would get X percent more resources per time, no?

My problem with this is that it forces players to make markets on the edge of the map which is very unnatural (and also easier to defend since one side is protected by blackness).

elexis added a comment.Sep 7 2017, 3:48 PM
In D879#34486, @temple wrote:

forces players to make markets on the edge of the map

s/forces"/incentivizes

which is very unnatural

I guess there is some graphical aesthetics to having markets close to the CC. From the gameplay/tactics POV it's different.

easier to defend since one side is protected by blackness

Not true, the tradeline becomes longer, so it has more distance where it can be attacked, thus harder to defend.
(Thus possibly requiring more resources to defend, especially in games with more enemies than allies).

temple added a comment.Sep 7 2017, 4:06 PM

We could argue for a long time, but I'll save it for when I post on the forum. :)

elexis added a comment.Sep 7 2017, 4:11 PM

Since there are many different opinions on how trade should work, it would be divide it into multiple aspects. I thought everyone would agree to factor in the mapsize.
If we need further nerfs or reshaping, that could be done afterwards, no?
Long topics won't help anyone, trade should be a simple but good concept that can be stated in few sentences, no?

mimo added a comment.EditedSep 7 2017, 7:08 PM
In D879#34501, @elexis wrote:

Since there are many different opinions on how trade should work, it would be divide it into multiple aspects. I thought everyone would agree to factor in the mapsize.
If we need further nerfs or reshaping, that could be done afterwards, no?
Long topics won't help anyone, trade should be a simple but good concept that can be stated in few sentences, no?

Why would everyone agree for the mapSize factor? because you agree with it? The argument against is the same as the one you quoted above (more distance, harder to defend, ...) so why would this argument works only against slowing the increase of gain at high distance, but not to justify higher gain on higher mapSize? That looks like a biased argument.

For me, the real justification of scaling the gain with mapSize is that we don't want trade to completely make gathering useless (at least not in phase 2), thus decreasing the gain on large mapSize is a reasonnable move. But the argument of longer distances harder to defend still hold, so my first move would have been to mitigate both effects and only scale by sqrt(mapSize) as I said above.

Then the slowering of the increase of gain with large distance (be it the d*tanh(d) or any other adequate function): the problem with our gain increase is that, as soon as you have a small territory advantage, it gives you a large boost of trade resource which gives you more armies, ... and the fate of a game is rather often determined by the first player which take an advantage. To mitigate this effect, the proposition is to slow down this increase for large distances while maintaining the function gain/distance strictly increasing to still reward larger distances.

Concerning the "trade should be a simple but good concept that can be stated in few sentences", the only important message can be summarized in one sentence! "gain/distance is strictly increasing to reward larger distances".

elexis added a comment.Sep 7 2017, 8:28 PM

Do we want to make trading on small mapsizes more profitable while not increasing the profit of the same traderoute length on larger maps?

In D879#34522, @mimo wrote:

Why would everyone agree for the mapSize factor? because you agree with it?

...
Because everyone in three discussions until today including temple and you agreed with the idea. As I stated my observation was falsified.

as soon as you have a small territory advantage, it gives you a large boost of trade resource which gives you more armies, ... and the fate of a game is rather often determined by the first player which take an advantage

AKA snowball effect
I shared that opinion on the conclusion to nerf trade per distance until seeing two players in alpha 19 assertively disallowing the enemy to trade with uninterrupted cavalry rushes, initiating an opposite snowball effect.
I won't stop anyone to nerf trade further, but don't blame me if players complain about trade being useless next alpha or players in some situations not having enough resources to break enemy defenses ending in deadlocks.

mimo added a comment.Sep 7 2017, 9:16 PM
In D879#34530, @elexis wrote:

Do we want to make trading on small mapsizes more profitable while not increasing the profit of the same traderoute length on larger maps?

In D879#34522, @mimo wrote:

Why would everyone agree for the mapSize factor? because you agree with it?

...
Because everyone in three discussions until today including temple and you agreed with the idea. As I stated my observation was falsified.

Well, we don't read this ticket the same way :) Fexor didn't agree with scaling, but find the rise at large distances a problem, Fatherbushido also stated that the rise at large distances was a more important problem than scaling and i said that, while i agree with scaling, i was not sure about the factor itself (mapSize or sqrt(mapSize)). But ok, i also said that i had no strong opinion about this factor.

as soon as you have a small territory advantage, it gives you a large boost of trade resource which gives you more armies, ... and the fate of a game is rather often determined by the first player which take an advantage

AKA snowball effect
I shared that opinion on the conclusion to nerf trade per distance until seeing two players in alpha 19 assertively disallowing the enemy to trade with uninterrupted cavalry rushes, initiating an opposite snowball effect.
I won't stop anyone to nerf trade further, but don't blame me if players complain about trade being useless next alpha or players in some situations not having enough resources to break enemy defenses ending in deadlocks.

Come on, the proposal was only to nerf the gain for d = mapSize by 25%. Compared to a d = mapSize/2 which is nearly not touched, the gain/d is still increased by 2 * (1-0.25) = 1.5 which is still large.

(25% is also a number I had in mind for normal mapsizes and beyond. Scaling the trade income to the current medium mapsize income would achieve that in said linear-profitrate-mapscale model (320/256 = 1.25).)

elexis added a comment.Sep 8 2017, 3:06 PM

As mentioned by others, since the time cost of carts actually gaining the profit has to be considered, we have to evaluate the profitrate, not the profit.
So when stating that square profit is too large, one states that linear profitrate is too large.

x => tanh(x):

logistic function with A=0, K=1, B=3, Q=ν=0.5, M=0, C=1, i.e.
x => 1/((1+0.5*e^(-3x))^2)

If we use something other than linear, like tanh or a logistic function to replace that linearity, then we need further constants.
I'd propose to keep it short and simple.
In order to avoid another patch hanging in the air like #3697, we need a decision.
The mapsize scaling must be rejected or accepted.
If A(tanh(B(x))) is necessary, we need to figure out A and B.
Would it hold back the mapsize scaling if we agree on the scaling but don't find numbers for that function yet?

temple added a comment.Sep 8 2017, 5:39 PM

It might be easier to decide what you want the rates to be at different distances and on different size maps (see the table in my earlier comment), and after that see if you can find a formula that produces them. (E.g., should trading be better than mining? How much should trading at the edges of the map be better than 1-4, and 1-4 versus 1-3?)

In D879#34690, @temple wrote:

It might be easier to decide what you want the rates to be at different distances and on different size maps (see the table in my earlier comment), and after that see if you can find a formula that produces them. (E.g., should trading be better than mining? How much should trading at the edges of the map be better than 1-4, and 1-4 versus 1-3?)

in my opinion trader shouldn't be better than mining because expanding and securing the spot from possible raiders require more effort.
thus i think that this would fit nicely:
rescaled to the diameter: grugnas 0.268 0.495 0.647 1.000 where the gain can be increased by techs of 1.8x is lower than 0.45 mining gain/sec where the gain can be increased by techs of 2x.

temple added a comment.Sep 8 2017, 7:03 PM
In D879#34703, @Grugnas wrote:
In D879#34690, @temple wrote:

It might be easier to decide what you want the rates to be at different distances and on different size maps (see the table in my earlier comment), and after that see if you can find a formula that produces them. (E.g., should trading be better than mining? How much should trading at the edges of the map be better than 1-4, and 1-4 versus 1-3?)

in my opinion trader shouldn't be better than mining because expanding and securing the spot from possible raiders require more effort.
thus i think that this would fit nicely:
rescaled to the diameter: grugnas 0.268 0.495 0.647 1.000 where the gain can be increased by techs of 1.8x is lower than 0.45 mining gain/sec where the gain can be increased by techs of 2x.

	1-2	1-3	1-4	diameter
grugnas	0.267	0.494	0.645	0.998
mimo	0.267	0.468	0.582	0.778

And what about the edges of the map versus 1-4? In the table the 1-4 rate is if you put the markets right next to your cc (from player 1 to player 4 in a 4v4), and diameter is if you put the markets on the edges of the map exactly opposite each other (both assuming a straight trading route). In the current formulation it's 0.998/0.645 = +55% better to put them on the edges of the map. Of course you can't put markets exactly on the edge of the map, and trading routes will bend and so on, but that's a huge increase in profit for putting markets just a little bit farther out, which is why I said "force" rather than "incentivize". In mimo's plan the difference is 0.778/0.582 = +34%.

elexis added a comment.Sep 8 2017, 7:22 PM

If I know that the enemy will appear there with 50 horses when my trade route just starts to have paid itself off, then there won't be +55% profit anymore, so I personally don't feel forced to do so.
(So I guess the number of trips until a trade cart has paid itself off should be considered too when deciding on a formula)
Agree that trade income should be similarly quick to gathering resources, so that it's a choice for the player which type of resource he wants and that trade can still replace the gather resource income.

Another pieze of the puzzle is the number of trade technologies, auras and team bonuses. Profit was buffed further and further with constant factors, but never nerfed on the other side.
(Originally I thought keeping it offtopic from the mapSize factor would make reviewing this patch simpler)
(So If we nerf trade a bit more but decide that players need more resources in lategame, perhaps we could add some fancy trade aura to wonders :P)

mimo added a comment.Sep 8 2017, 7:43 PM

I don't think it's complicated to choose some numbers to fit what we want.
let's take 3 distances (relative to mapSize) O.5, 1 and 1.41 which is the max possible (diagonal)

current game (and same in grugnas) gain/dist scale like dist

dist                0.50   1.00   1.41
-----------------------------------------
current gain/dist   0.50   1.00   1.41
tanh(d)             0.46   0.76   0.89
1.5*tanh(d/1.5)     0.48   0.87   1.10

My first choice would have been tanh(d/mapSize) to not give too much additionnal advantage to players who are already winning (bigger territory), but 1.5*tanh(d/1.5/mapSize) looks like a medium value if the previous one seems too drastic for some people.

temple added a comment.Sep 8 2017, 8:28 PM
In D879#34746, @elexis wrote:

If I know that the enemy will appear there with 50 horses when my trade route just starts to have paid itself off, then there won't be +55% profit anymore, so I personally don't feel forced to do so.

Well, I guess you aren't "forced" to get the first couple of wood and farm upgrades, but how often do you skip them? And they're only +15% each.
Trading routes are only as strong as their weakest point, so making them longer at the ends where it's easier to defend (in your territory, protected on one side by blackness) is a no-brainer. Plus trading carts are spread out more when they have longer to travel, so they might even be less vulnerable to raids.

I think the only reason why more players don't make markets at the edge of the map is that they don't realize how much of a difference it makes.

(I'll stop contributing to this discussion. It seems a bit dishonest when I really want to rethink trade not just tweak it at the edges. I looked through my notes and there's a few outstanding problems I haven't solved, so I don't think I'll post on the forum until I've figured them out (if I ever do).)

In D879#34750, @mimo wrote:

let's take 3 distances (relative to mapSize) O.5, 1 and 1.41 which is the max possible (diagonal)

Almost all maps are circular, so I think it's better to use max = diameter = map size.

at this point i feel splitted in half because as mimo stated, tangh would scale better between team placements but will penalize from side to side (diagonal length) trade thus there would perhaps be less gain difference thus a more homogeneus income.
On the othe hand, as temple stated, having a linear route on the diagonal would give a great advantage to a team which is in my opinion much harder to stabilish and to defend because the traders will pass near the territory border thus it may be rewarded ( a team who can mantain such advantage maybe deserves to win ) and a more safer route requires a circular route moving from base to base 1->2->3->4 requiring more time that perhaps may be compensated by that extra gain.

mimo added a comment.Sep 8 2017, 9:57 PM
In D879#34775, @temple wrote:
In D879#34750, @mimo wrote:

let's take 3 distances (relative to mapSize) O.5, 1 and 1.41 which is the max possible (diagonal)

Almost all maps are circular, so I think it's better to use max = diameter = map size.

True that the number of square maps is really small, and they are deprecated, so my "medium proposition" would rather be with 1.2 (instead of 1.5) which gives
gain/d = 0.47 for d=0.5 and gain/d=0.82 for d=1, instead of the current 0.5 and 1 respectively.

Grugnas updated this revision to Diff 3605.Sep 9 2017, 12:30 PM
Grugnas edited the summary of this revision. (Show Details)

( last update used @mimo tanh(d/mapsize) suggested formula ).

fatherbushido added inline comments.Sep 9 2017, 2:02 PM
binaries/data/mods/public/simulation/helpers/TraderGain.js
44
// We calculate gain as square of distance to encourage trading between remote markets
// and gainMultiplier corresponds to the gain percentage from the income of given distance
gain.traderGain = gainMultiplier * 1024 * distance * Math.tanh(distance / cmpTerrain.GetMapSize()) / 10000;

Try again

Grugnas updated this revision to Diff 3621.Sep 10 2017, 12:04 PM

reverted and updated comments.

Grugnas updated this revision to Diff 3622.Sep 10 2017, 12:06 PM
fatherbushido added inline comments.Sep 10 2017, 12:36 PM
binaries/data/mods/public/simulation/helpers/TraderGain.js
44
	// We calculate gain as distance between markets
	// and gainMultiplier corresponds to the gain for a 100m distance
	gain.traderGain = gainMultiplier * 1024 * distance * Math.tanh(distance / cmpTerrain.GetMapSize()) / 10000;

Try again

Because you've replaced the distanceSq with just the distance in line 40, the “/ 10000” in line 44 is now rather obsolete. (Besides, isn't *10 more efficient than *1024/10000?) If you want to keep the 100 m normalization, as suggested in line 43, change line 40 to:

let distanceN = firstMarketPosition.distanceTo(secondMarketPosition)/100;

and change line 44 accordingly.

mimo added a comment.EditedSep 10 2017, 2:03 PM

Functionality of the patch is good for me, if nobody complains on this gain, i would accept it.
Now on details:
the comment should state that the gain is normalized at 100m and for a 1024 map, and scales with map (the fact that the scaling mapSize is canceled with the one coming from tanh is not clear from the formula).
then, i don't know if we should keep the factor 1024/10000 or integrate it in the template value: the original factor 10000 (normalization on 100m) was only to avoid having numbers like 0.000075 in the template, but now with the 1024 factor, the value would only be 0.075. (Edit: Nescios commented also on that point while i was writing).

Finally, but maybe to be done in a second patch once the change of formula will be commited, move that computation in a globalscript function so that the ai can use it. Currently, the gain is computed in ai/petra/headquarters.js on line 1168 and ai/petra/tradeManager.js on line 447

Grugnas updated this revision to Diff 3623.Sep 10 2017, 2:46 PM

perhaps this is easier to read?
While on the code, aren't checks on gui components e.g. cmpTrader meaningless because they are always true?

fatherbushido added inline comments.Sep 10 2017, 3:26 PM
binaries/data/mods/public/simulation/helpers/TraderGain.js
46

"as a function of the distance" or something like that is general enough (and that function is the one mimo suggests to move in globalscripts).

(This is a big change on tiny a.k.a. pizza maps, so it's worth playing a game after the patch is committed to see if the change is good.)

Personally I still don't see why trade gain ought to depend on map size (actually I disagree with the principle), but if the concensus is this is necessary, I won't object. Besides, replacing the distance squared formula is certainly an improvement.

However, I'd like to see a comparison how this new formula would work out for different distances and map sizes (compared to the current unrestricted d^2 formula), preferably before this patch is committed.

In D879#35029, @Nescio wrote:

However, I'd like to see a comparison how this new formula would work out for different distances and map sizes (compared to the current unrestricted d^2 formula), preferably before this patch is committed.

Here's the rates on mainland 4v4 assuming straight lines from cc to cc.

	1-2	1-3	1-4	diameter
				
tiny	0.137	0.253	0.330	0.511
small	0.205	0.379	0.495	0.766
medium	0.274	0.506	0.661	1.021
normal	0.342	0.632	0.826	1.277
large	0.410	0.758	0.991	1.532
vlarge	0.479	0.885	1.156	1.788
giant	0.547	1.011	1.321	2.043
				
patch	0.267	0.468	0.582	0.778

However, I'd like to see a comparison how this new formula would work out for different distances and map sizes (compared to the current unrestricted d^2 formula), preferably before this patch is committed.

:X

mimo added a comment.Sep 10 2017, 6:55 PM
In D879#35029, @Nescio wrote:

Personally I still don't see why trade gain ought to depend on map size (actually I disagree with the principle), but if the concensus is this is necessary, I won't object. Besides, replacing the distance squared formula is certainly an improvement.

I think people should express their concerns/opinions: as i said previously, while i understand the need for scaling, i always thought that a scaling with mapSize is too much and i would have favoured something in between no-scaling and linear-scaling, so my sqrt(mapSize) proposition in previous comments. I didn't insisted on it because i thought i was the only one with such opinion, but if that's not the case, ...

In D879#35036, @mimo wrote:

I think people should express their concerns/opinions: as i said previously, while i understand the need for scaling, i always thought that a scaling with mapSize is too much and i would have favoured something in between no-scaling and linear-scaling, so my sqrt(mapSize) proposition in previous comments. I didn't insisted on it because i thought i was the only one with such opinion, but if that's not the case, ...

Honestly I am quite satisfied with the formula currently used in the uploaded diff, thank you for the interest.
Values can still be tweaked with the gain multiplier if too low or too high, which imho is not the case at moment.
for any doubts about scaling with mapSize, you can test trade income and resources generated in random maps in Tiny and in Giant sizes. For a fair comparison with metal gather rate, you use normal map size.
( sorry if i deleted the values table from the summary)

In D879#35030, @temple wrote:
In D879#35029, @Nescio wrote:

However, I'd like to see a comparison how this new formula would work out for different distances and map sizes (compared to the current unrestricted d^2 formula), preferably before this patch is committed.

Here's the rates on mainland 4v4 assuming straight lines from cc to cc.

	1-2	1-3	1-4	diameter
				
tiny	0.137	0.253	0.330	0.511
small	0.205	0.379	0.495	0.766
medium	0.274	0.506	0.661	1.021
normal	0.342	0.632	0.826	1.277
large	0.410	0.758	0.991	1.532
vlarge	0.479	0.885	1.156	1.788
giant	0.547	1.011	1.321	2.043
				
patch	0.267	0.468	0.582	0.778

Yeah, but I understood that these values are relative (27%, 49%, 65%, and 100% of map diameter). However, I'm more interested how the comparison would work out at actual distances (e.g. 100 m, 300 m, 1000 m, etc) on the different map sizes, because the trade income is the quotient of the trade gain and travel time (distance/speed), and walking speed is independent of map size.

PS Are those values up to date? It seems the code was changed a few times today.

In D879#34359, @FeXoR wrote:

@linear gain: Then I'd always chose the shortest possible trade routes since it's the same amount of resources per time and trader no matter the distance ... and nearly no risk involved.
@square is to much: What about an exponent about 1.5?

In general I don't understand why the map size should play a role here. Because it's less likely an enemy stumbles about a trade route on large maps?

Agree that capping (not done in the proposal) is more important than taking care of the size of the map.
Agree that tanh or any logistic function will do that job.
Agree with mimo.

In D879#35036, @mimo wrote:
In D879#35029, @Nescio wrote:

Personally I still don't see why trade gain ought to depend on map size (actually I disagree with the principle), but if the concensus is this is necessary, I won't object. Besides, replacing the distance squared formula is certainly an improvement.

I think people should express their concerns/opinions: as i said previously, while i understand the need for scaling, i always thought that a scaling with mapSize is too much and i would have favoured something in between no-scaling and linear-scaling, so my sqrt(mapSize) proposition in previous comments. I didn't insisted on it because i thought i was the only one with such opinion, but if that's not the case, ...

Well, at least I'm not the only one ...

In D879#35038, @Nescio wrote:

However, I'm more interested how the comparison would work out at actual distances (e.g. 100 m, 300 m, 1000 m, etc) on the different map sizes

Okey-doke (ignore where distance > map size or sqrt(2) * map size):

	a22	tiny	small	medium	normal	large	vlarge	giant
dist		512	768	1024	1280	1536	1792	2048
100	0.100	0.197	0.132	0.099	0.080	0.066	0.057	0.050
200	0.200	0.380	0.260	0.197	0.158	0.132	0.114	0.099
300	0.299	0.538	0.380	0.291	0.235	0.197	0.169	0.149
400	0.399	0.667	0.489	0.380	0.309	0.260	0.224	0.197
500	0.499	0.768	0.585	0.463	0.380	0.321	0.278	0.245
600	0.599	0.843	0.667	0.538	0.447	0.380	0.330	0.291
700	0.698	0.897	0.737	0.607	0.509	0.436	0.380	0.336
800	0.798	0.935	0.795	0.667	0.566	0.489	0.428	0.380
900	0.898	0.962	0.843	0.721	0.619	0.538	0.474	0.422
1000	0.998	0.981	0.881	0.768	0.667	0.585	0.517	0.463
1100	1.097	0.994	0.911	0.808	0.711	0.628	0.559	0.501
1200	1.197	1.003	0.935	0.843	0.750	0.667	0.597	0.538
1300	1.297	1.009	0.955	0.872	0.785	0.704	0.634	0.573
1400	1.397	1.013	0.969	0.897	0.815	0.737	0.667	0.607
1500	1.496	1.016	0.981	0.918	0.843	0.768	0.699	0.638
1600	1.596	1.018	0.990	0.935	0.866	0.795	0.728	0.667
1700	1.696	1.019	0.997	0.950	0.887	0.820	0.755	0.695
1800	1.796	1.020	1.003	0.962	0.906	0.843	0.780	0.721
1900	1.895	1.020	1.007	0.973	0.922	0.863	0.803	0.745
2000	1.995	1.021	1.010	0.981	0.935	0.881	0.823	0.768
2100	2.095	1.021	1.013	0.988	0.947	0.897	0.843	0.789
2200	2.195	1.021	1.015	0.994	0.958	0.911	0.860	0.808
2300	2.294	1.021	1.016	0.999	0.967	0.924	0.876	0.826
2400	2.394	1.021	1.018	1.003	0.974	0.935	0.890	0.843
2500	2.494	1.021	1.018	1.006	0.981	0.946	0.903	0.858
2600	2.594	1.021	1.019	1.009	0.987	0.955	0.915	0.872
2700	2.693	1.021	1.020	1.011	0.992	0.962	0.926	0.885
2800	2.793	1.021	1.020	1.013	0.996	0.969	0.935	0.897
2900	2.893	1.021	1.020	1.014	1.000	0.976	0.944	0.908
3000	2.993	1.021	1.021	1.016	1.003	0.981	0.952	0.918
In D879#35039, @Nescio wrote:
In D879#34359, @FeXoR wrote:

@linear gain: Then I'd always chose the shortest possible trade routes since it's the same amount of resources per time and trader no matter the distance ... and nearly no risk involved.
@square is to much: What about an exponent about 1.5?

In general I don't understand why the map size should play a role here. Because it's less likely an enemy stumbles about a trade route on large maps?

Agree that capping (not done in the proposal) is more important than taking care of the size of the map.
Agree that tanh or any logistic function will do that job.
Agree with mimo.

In D879#35036, @mimo wrote:
In D879#35029, @Nescio wrote:

Personally I still don't see why trade gain ought to depend on map size (actually I disagree with the principle), but if the concensus is this is necessary, I won't object. Besides, replacing the distance squared formula is certainly an improvement.

I think people should express their concerns/opinions: as i said previously, while i understand the need for scaling, i always thought that a scaling with mapSize is too much and i would have favoured something in between no-scaling and linear-scaling, so my sqrt(mapSize) proposition in previous comments. I didn't insisted on it because i thought i was the only one with such opinion, but if that's not the case, ...

Well, at least I'm not the only one ...

Tiny map (the smalles map) has a lower amount of resources generated than bigger sized maps, thus trade income acquire a more important role on lower sized maps thus it should yield (always in my opinion) a high income in order to prevent mass traders spam.
Using a linear method (the one used in current alpha 22), that amount linearly increases resulting in a huge income that basically remove the need to gather resources in bigger sized map thus unwanted ( always in my opinion).
Clear example: in normal sized map trade can give 150 metal per trip while in tiny it can give 6 metal per trip ( ~ diameter distance).
I thought that writing in the summary was enough to transmit the concern about the current trade system.
OFF TOPIC: ( if you want i can send a replay where traders income produced so much metal that training units to produce resources or even expanding would be meaningless ).

temple, thanks!

grugnas, I fully agree that the current (d^2) formula isn't good at all and that your proposal would be better. However, I'm not convinced it's perfect and just wondering how it could be improved.

Just a quick thought: how about (1 + Math.tanh(distance / cmpTerrain.GetMapSize()) / 2) ?

mimo added a comment.Oct 6 2017, 7:32 PM

Let's try to converge on that ticket:

  1. first point: saturation of the gain at high distances. The plot trade.png shows what is the current gain in red and the change i've proposed in blue. The top plot is the gain, and the bottom one the gain/dist which is the only relevant quantity to look at for comparison (as the time to travel should be taken into account). So instead of the current linear gain/dist, it is based on the tanh(dist/mapSize) function which gives the same behaviour at small distances, but saturates at high distances. Note that it is still an increasing function of the distance, so longer routes are still better, but with less benefit to build a new market a few meters away when the route is already long enough.

(As a side note, and because the important parameter is gain/dist, maybe it should be added in the tooltip)

  1. second point is the scaling of the gain with the mapSize (the original goal of this ticket). The more i think about it, the more i'm convinced that such a scaling is too strong.

To illustrate that, the plot tradePerDistVsSize.png shows the ratio gain/dist vs dist for 3 map sizes (tiny=512, medium=1024 and giant=2048). The top-left is without any scaling, and the top-right with the scaling with mapSize as originally proposed in that patch. None have satisfactory properties. So i come back to my initial proposition to scale by sqrt(mapSize) bottom-left which looks more adequate to me, or alternatively to only scale part of the gain as shown in bottom-right where half of the gain is not scaled and half of it scaled. This partial scaling (more or less equivalent to sqrt scaling when both parts are 50%) is maybe better for modding as it would allow to easily change to any setting between the two upper plots (left = 0% scaled and right = 100% scaled) by varying the proportion if we add it in some template.

  1. second point is the scaling of the gain with the mapSize (the original goal of this ticket). The more i think about it, the more i'm convinced that such a scaling is too strong.

To illustrate that, the plot tradePerDistVsSize.png shows the ratio gain/dist vs dist for 3 map sizes (tiny=512, medium=1024 and giant=2048). The top-left is without any scaling, and the top-right with the scaling with mapSize as originally proposed in that patch. None have satisfactory properties. So i come back to my initial proposition to scale by sqrt(mapSize) bottom-left which looks more adequate to me, or alternatively to only scale part of the gain as shown in bottom-right where half of the gain is not scaled and half of it scaled. This partial scaling (more or less equivalent to sqrt scaling when both parts are 50%) is maybe better for modding as it would allow to easily change to any setting between the two upper plots (left = 0% scaled and right = 100% scaled) by varying the proportion if we add it in some template.

Thank you for the plots, now the comparison between the different formulas is even easier.
The gain/dist growth of the bottom-right plot seems to fit most the intent to let the trade to have a bigger impact on the game over time (at least for small sized map) but the saturation for the 1024 size is too strong thereby may result in a really too low gain/dist, thus i totally agree on using the bottom-left plot.

Ok, after some testing using sqrt instead of tanh, I have to retake back my position in favor of the current uploaded formula as long as sqrt doesn't change at all the current gain/dist ratio in normal map which is unwanted. Someone may argue that the gain could be changed by tweaking the multiplier but having as tan(gain * affecting trade technologies) [i use this formula as explanation thus not intended to be implemented] the gain/sec * affecting metal gathering technologies of a citizen soldier worker is direction this patch wanted to have.
perhaps a sqrt growth goes against the initial design of linear gain where a tangent could have a more flexible impact depending on the map size, thus the impact degree the trade has in such a game.

mimo added a comment.Oct 7 2017, 12:21 PM
In D879#37098, @Grugnas wrote:

perhaps a sqrt growth goes against the initial design of linear gain where a tangent could have a more flexible impact depending on the map size, thus the impact degree the trade has in such a game.

I don't understand this comment: these are two different effects.
tanh drives the behaviour vs dist for a given map size.
sqrt scaling drives the normalisation of the trade multiplier for different map sizes

so both were supposed to be used         gain/dist = tradeMultiplier(at 1024)*sqrt(1024/size)      *      size*tanh(dist/size)

That's what was shown in the plots above.

What you propose in your last patch is the top-right which is definitevely not satisfactory

In D879#37099, @mimo wrote:
In D879#37098, @Grugnas wrote:

perhaps a sqrt growth goes against the initial design of linear gain where a tangent could have a more flexible impact depending on the map size, thus the impact degree the trade has in such a game.

I don't understand this comment: these are two different effects.
tanh drives the behaviour vs dist for a given map size.
sqrt scaling drives the normalisation of the trade multiplier for different map sizes

so both were supposed to be used         gain/dist = tradeMultiplier(at 1024)*sqrt(1024/size)      *      size*tanh(dist/size)

That's what was shown in the plots above.

What you propose in your last patch is the top-right which is definitevely not satisfactory

I am sorry, i replaced the tanh with sqrt and the result didn't satisfy me. That's why i raised a concern.

Grugnas updated this revision to Diff 3854.Oct 7 2017, 1:51 PM

uploaded the formula suggested by mimo.
I tried to update tooltips aswell, but they aren't very accurate though.

mimo added a comment.Oct 8 2017, 10:47 PM

So the patch was manifestly not tested!

binaries/data/mods/public/gui/session/selection_details.js
536 ↗(On Diff #3854)

why this factor 10?

binaries/data/mods/public/simulation/helpers/TraderGain.js
47

and ?

48

The normalisation of gainMultiplier on map sizes of 1024 is done by the sqrt(1024/size), so no need of the 1024 in line 28 which has no sense.
And there is a distance missing in the gain formula (what i gave in my previous comment was gain/distance).
And try to be consistent in the argument of your functions (see sqrt and tanh which have blanks in random places, what is done for tanh follows our coding conventions).

Grugnas added inline comments.Oct 9 2017, 8:13 AM
binaries/data/mods/public/gui/session/selection_details.js
536 ↗(On Diff #3854)

The values displayed in the market selection details are 10x the value carried by the trader. ( i recall simeone already mentioning this eventual issue)

binaries/data/mods/public/simulation/helpers/TraderGain.js
47

Little leftover :)

48

I'll recheck the code asap, as long as i am not very familiar with this, i used the formula used in thr correct plot. Since the result seemed promising, i uploaded the patch

Grugnas updated this revision to Diff 3895.Oct 16 2017, 11:29 AM
mimo added a comment.Oct 20 2017, 7:56 PM

Why do you have sqrt(distance) in line 45 ?
And did you ask yourself what happens when the function is called without trader? you don't normalize for the mapsize in that case! why?
But more importantly, you've not done any change for the ai while it was one of the previous comments (and requirements for this patch to be usable).

So i think it is a dead end, and i've changed the approach: first unify everything using globalscript functions, and only then, modify the way we compute the gain. See D964.

mimo commandeered this revision.Oct 21 2017, 10:33 PM
mimo edited reviewers, added: Grugnas; removed: mimo.

Now that D964 and D969 are commited, let's try to agree on that one.
I've previously shown plots showing the behaviour of the trade for several scaling of the gain with mapSize, and the one which looks best for me is the scaling with sqrt(mapSize) which is intermediate between the current state (no scaling, supported by some people) and the linear scaling proposed by others.
Then for a given scaling, i've argued in previous comments that it was important to have a saturation effect to avoid the huge quadratic increase of the gain at high distance. I've advocated something like size*dist*tanh(dist/size) which has the wanted behaviour. But in fact, that function is not really intuitive, and we can reproduce most of its effects by a simple one as dist*dist/(1+alpha*dist) which is easy to interpret if rewriting it dist*dist/(1+alfa*dist/mapsize) so beta is just the reduction we want on the gain for a route with dist=mapsize, and a value of 0.25.

This simple formula reproduces quite well the effect of the tanh as can be seen on the following plot: upper plot is gain and bottom one is gain/dist, red is our current gain, blue the one with tanh and green this new simpler one. The solid line correspond to dist<mapsize (so relevant for most maps, the circular one) and dotted is for dist<sqrt(2)*mapsize so may happen on the few square maps.

mimo updated this revision to Diff 3925.Oct 21 2017, 10:35 PM

new patch following D964 and D967

Vulcan added a subscriber: Vulcan.Oct 21 2017, 11:23 PM

Build is green

Updating workspaces...
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDAnimation]’:
FCollada/FCDocument/FCDLibrary.cpp:149:30:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
  const T* cptr = ((const FCDLibrary<T>*)l1)->GetEntity(0);
           ^
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDAnimationClip]’:
FCollada/FCDocument/FCDLibrary.cpp:150:34:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDCamera]’:
FCollada/FCDocument/FCDLibrary.cpp:151:27:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDController]’:
FCollada/FCDocument/FCDLibrary.cpp:152:31:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDEffect]’:
FCollada/FCDocument/FCDLibrary.cpp:153:27:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDEmitter]’:
FCollada/FCDocument/FCDLibrary.cpp:154:28:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDForceField]’:
FCollada/FCDocument/FCDLibrary.cpp:155:31:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDGeometry]’:
FCollada/FCDocument/FCDLibrary.cpp:156:29:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDImage]’:
FCollada/FCDocument/FCDLibrary.cpp:157:26:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDLight]’:
FCollada/FCDocument/FCDLibrary.cpp:158:26:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDMaterial]’:
FCollada/FCDocument/FCDLibrary.cpp:159:29:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDSceneNode]’:
FCollada/FCDocument/FCDLibrary.cpp:160:30:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDPhysicsModel]’:
FCollada/FCDocument/FCDLibrary.cpp:161:33:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDPhysicsMaterial]’:
FCollada/FCDocument/FCDLibrary.cpp:162:36:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDPhysicsScene]’:
FCollada/FCDocument/FCDLibrary.cpp:163:33:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
In file included from FCollada/FUtils/FUSemaphore.cpp:10:0:
FCollada/FUtils/FUSemaphore.h:36:2: warning: #warning "FUSemaphore: Semaphore not implemented for non Windows" [-Wcpp]
 #warning "FUSemaphore: Semaphore not implemented for non Windows"
  ^
FCollada/FUtils/FUStringConversion.cpp: In function ‘void TrickLinkerFUStringConversion()’:
FCollada/FUtils/FUStringConversion.cpp:281:8: warning: variable ‘f’ set but not used [-Wunused-but-set-variable]
  float f = FUStringConversion::ToFloat(&c);
        ^
FCollada/FUtils/FUStringConversion.cpp:283:7: warning: variable ‘b’ set but not used [-Wunused-but-set-variable]
  bool b = FUStringConversion::ToBoolean(c);
       ^
FCollada/FUtils/FUStringConversion.cpp:285:8: warning: variable ‘i32’ set but not used [-Wunused-but-set-variable]
  int32 i32 = FUStringConversion::ToInt32(&c);
        ^
FCollada/FUtils/FUStringConversion.cpp:287:9: warning: variable ‘u32’ set but not used [-Wunused-but-set-variable]
  uint32 u32 = FUStringConversion::ToUInt32(&c);
         ^
In file included from FCollada/FUtils/FUThread.cpp:10:0:
FCollada/FUtils/FUThread.h:30:2: warning: #warning "Threads not yet implemented for non Windows." [-Wcpp]
 #warning "Threads not yet implemented for non Windows."
  ^
FCollada/FCDocument/FCDAnimationCurve.cpp: In member function ‘float FCDAnimationCurve::Evaluate(float) const’:
FCollada/FCDocument/FCDAnimationCurve.cpp:396:13: warning: ‘inTangent.FMVector2::<anonymous>.FMVector2::<anonymous union>::x’ may be used uninitialized in this function [-Wmaybe-uninitialized]
   FMVector2 inTangent;
             ^
FCollada/FCDocument/FCDAnimationCurve.cpp:396:13: warning: ‘inTangent.FMVector2::<anonymous>.FMVector2::<anonymous union>::y’ may be used uninitialized in this function [-Wmaybe-uninitialized]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDAnimation]’:
FCollada/FCDocument/FCDLibrary.cpp:149:30:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
  const T* cptr = ((const FCDLibrary<T>*)l1)->GetEntity(0);
           ^
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDAnimationClip]’:
FCollada/FCDocument/FCDLibrary.cpp:150:34:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDCamera]’:
FCollada/FCDocument/FCDLibrary.cpp:151:27:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDController]’:
FCollada/FCDocument/FCDLibrary.cpp:152:31:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDEffect]’:
FCollada/FCDocument/FCDLibrary.cpp:153:27:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDEmitter]’:
FCollada/FCDocument/FCDLibrary.cpp:154:28:   required from here
FCollada/FCDocument/FCDLibrary.cpp:141:11: warning: variable ‘cptr’ set but not used [-Wunused-but-set-variable]
FCollada/FCDocument/FCDLibrary.cpp: In instantiation of ‘void LibraryExport() [with T = FCDForceField]’:
FCollada/FCDocument/FC

http://jenkins-master:8080/job/phabricator/2142/ for more details.

Executing section Default...
Executing section Source...
Executing section JS...
Executing section XML GUI...

http://jenkins-master:8080/job/phabricator_lint/613/ for more details.

Grugnas accepted this revision.Oct 25 2017, 4:23 PM
This revision is now accepted and ready to land.Oct 25 2017, 4:23 PM
This revision was automatically updated to reflect the committed changes.