Trading

[Spahbod]

Did you give up implementing it?

[fcxSanya]

Did you give up implementing it?

No, I was temporary very low active in the 0 A.D. development (busy with real life, tired by regular work etc.).

I fixed some minor issues with the UnitAI, but not this part:

What happens when someone selects an unreachable market, on a separate island or across a river?

I supposed that MoveToTarget (which is used to try to reach market) should return false in this case and unit should not move anywhere, but it looks like it moves as near as possible to target. I will test it more and fix. I think that if after ordering trade one of markets is not reachable there should be just notification, that trading with selected markets is not possible.

In discussion with Philip I find out that it is currently hard to check the reachability of the target market, so I decided to keep it as is for now (trader will try to move to the market and discard order if it can't reach it).

<fcxSanya> Philip`, as I understood I need for trading function like 'try to move exactly to entity or give up if can't reach the target', but in UnitMotion component there is only 'move as close as possible and give up only if can't move at all or if already reached target', this is right?

<fcxSanya> and I don't see anything like 'IsTargetReachable'

<Philip`> That's correct

<Philip`> It's not really possible for it to accurately tell whether a target is reachable, because the long-range pathfinder might say it is but the short-range pathfinder might discover that it's not

<fcxSanya> Philip`, can I use long-range pathfinding result as rough approximation to checking reachability? To deny trading with totally unreachable markets, like these which are on different islands for example

<Philip`> fcxSanya: One difficulty is that the location of the market will probably be actually unreachable, because it's blocked by a building (i.e. the market)

<Philip`> But I guess some kind of function that checks if the point is reachable to within a certain radius would be okay

<Philip`> (i.e. the pathfinder can stop when it gets within 4 tiles of the point, or whatever)

<fcxSanya> Philip`, if there is such complexities maybe it is better for now (in current patch) to do the same as e.g. gathering, i.e. reach nearest point, check if market is close enough and give up if it is not?

<Philip`> Even with a new reachability approximation function, it'll still need code to handle the case where the approximation is wrong and it gets to the nearest point then gives up

<fcxSanya> ok, then I will start from this

<fcxSanya> thanks for advice

<Philip`> so maybe it's sensible to do that now, then add the approximation function later to improve the common-case behaviour

I implemented this:

Destroying Trade Units

Raiding undefended international or domestic trade units can be lucrative, since destroying a Trader (on land or water) will transfer any resource points he was carrying into the player's Resource Pool.

Nice idea, but not implemented in my patch yet. I think we can just add carried goods to loot, sound simple, will do it later.

and added a coefficient to the trader component template, which allows to adjust gain for separate unit types (can be useful to make some civs better in trading or to change land/water trading gain proportions).

Also I implemented tooltips on hover:

they can display following states of a market:

* "First trade market";

* "Second trade market. Click to establish another route.";

* "Set as first trade market";

* "Set as second trade market. Gain: <number>.";

I don't know where to place the tooltip area. For now I placed it above minimap, but surely it looks very ugly because the minimap/formations/unit info panels have different height, so my tooltip area hangs in the air instead of sticking to a panel.

[historic_bruno]

Nice, so destroying an enemy trade unit gives some fraction of their carried goods as loot? What if a player destroys their own trader? I think they should get nothing but maybe that's how your patch works

I don't know where to place the tooltip area. For now I placed it above minimap, but surely it looks very ugly because the minimap/formations/unit info panels have different height, so my tooltip area hangs in the air instead of sticking to a panel.

Why not have the tooltip a bit to the right of the mouse cursor (and transparent)? In other words move it dynamically instead of being in a fixed position. I'm thinking we will do that for failed building placement as well, it won't seem so strange. You can make it multiple lines if it looks too long.

[feneur]

Why not have the tooltip a bit to the right of the mouse cursor (and transparent)? In other words move it dynamically instead of being in a fixed position. I'm thinking we will do that for failed building placement as well, it won't seem so strange. You can make it multiple lines if it looks too long.

As much as possible information should be near what it's related to imho

[Mythos_Ruler]

I probably won't have any further opinions on the subject until I can play with it in-game.

[fcxSanya]

Nice, so destroying an enemy trade unit gives some fraction of their carried goods as loot? What if a player destroys their own trader? I think they should get nothing but maybe that's how your patch works

It is more question how the looter component should work. Looter is called from the Attack component. If you kill your own unit using the gui command, it directly use the Health component, so looting is not performed. If you will kill your own unit by attacking it with other your unit, then looting probably will take place. But as far as I understood you can't order one your unit to attack another your unit.

Why not have the tooltip a bit to the right of the mouse cursor (and transparent)? In other words move it dynamically instead of being in a fixed position. I'm thinking we will do that for failed building placement as well, it won't seem so strange. You can make it multiple lines if it looks too long.

I suppose that this will overload the main screen area with details, but if we don't have other ideas I can do this and we will look how it works.

[gudo]

Well, I think it's time to take a closer look at the trading mechanic. The current system is set up so that whenever a trading cart makes a stop, the cart owner gets the resources regardless of who owns the market. This seems a bit odd, I wouldn't expect my traders to generate resources when they arrive at a foreign city, but I would expect them to generate resources when they get back. It also allows for some weird behavior. Cheifly, you can set up a trade route to go between two allied markets (and never stop at any of yours) and still gain resources. This seems counter intuitive.

I suggest the system be changed so that the market owner gains resources when a trading cart stops there. This will provide an incentive for allies to build markets even if they don't plan on trading. It will also put a stop to the counter-intuitive and strange behavior I outlined above.

This was brefily discussed in ticket 1546. Here's the relevent bits:

But trade is 2-way, and you can have several market "stops" queued. It seems like it would penalize "international" trade too much if the trader gives no advantage to his owner -- in that case it would be better to build two of your own markets and get 2-way trade vs. 1-way trade with another player. However I seem to remember wanting the market-owning player to get a cut of the profit (not all), but was overruled in favor of what we have now I do agree that would add an economic incentive to alliances.

The cart does give advantage to it's owner. The owner gets free resources when the cart returns, and a stronger ally to boot. The way we would make trading with an ally better than building a market next to his in this case would be to have international trade be worth double domestic trade. Then, you still get the same resources in the same time, it's just in one lump sum instead of two. (Also, the "break even distance" or the distance where trading is as fast as gathering is pretty darn long right now. This would help bring it down to a more reasonable length.)

As a tanget, in another thread, Mythos says that late game trading should be better than gathering so you can free up more population to do the fighting. I agree. There should be some city phase tech that improves the efficiency of traders.

[Mythos_Ruler]

I like the idea of the Market owner gaining the resources. Very nice idea. Adds another dimension to alliances/diplomacy.

And yep, the game needs trading techs if the default resource rate is going to remain so low.

[wraitii]

To be perfectly logical, shouldn't that actually be reversed? Make a lot of money selling to the foreign market, make little selling the ally's goods in yours?

I'm thinking a 80/20 mechanic would work better than a full 100/0 here.

[gudo]

Well, they way I look at it, when a trader arrives at a market, they offload stuff (market owner gets resources) and load up stuff (head back to your market.) You won't actually gain any resources till your trader returns with the stuff they got while away. So yes, they do make money selling in a foreign market, but it doesn't wind up in your war-chest till they bring it back home

[Sonarpulse]

On a related note, what if you have have multiple "bases" that are either a certain distance apart, or separated by water, they have separate stockpiles and you'll need to shuffle resources between them (with traders or something similar)? You could always build a string of cheep buildings in between to make the two bases one contiguous base ...but that would be much harder to defend.

I imagine this would probably entail overall big changes in the engine, but it would add a whole new dynamic to the game.

[alkazar-ipse]

between 2 markets there should be 2 different routes calculated: one for each direction, to counter those excited camels going straight on each other. (same for workers going to, or coming from a tc to a specific tree, or mine or idk. I know I'm being idealistic here, and that is easy to describe, but hard to implement correctly, but for the markets it's really not that hard, since camels really go form one precise point on the markets eadge to another one on the other market, so insted of going on one road back and forth they could do some kind of a rectangle with eadges 2 camellengths on markets)

wrote this in in an other thread, guess it belongs here

edit: talking about camels here, what I actually mean is any trader...

Edited October 11, 2012 by alkazar-ipse

[fcxSanya]

<...> but for the markets it's really not that hard, since camels really go form one precise point on the markets eadge to another one on the other market, so insted of going on one road back and forth they could do some kind of a rectangle with eadges 2 camellengths on markets

Gameplay logic (like trading) is written in the simulation part of the code. And there is stated literally 'MoveToTarget(targetMarket)', i.e. that code doesn't care what coordinates/dimensions the 'targetMarket' has, the same about the trader, this is just different level of abstraction. On the other hand, 'MoveToTarget' goes somewhere into the engine, where code know nothing about the trading and to what side the trader is moving. There is just one entity (the trader) and another (the market), their coordinates and all those pathfinding things. I don't know how exactly the pathfinder works, but I think (from what I vaguely remember/misremember) that it just calculates path to the centre point of the object (market) until it stumbles upon a tile blocked by the target. So what you propose requires significant changes in both engine and simulation sides.

[feneur]

On the other hand this is an issue for other units as well, so should probably have a more common solution rather than one specifically for traders or units going back and forth between a resource and a resource dropsite

[Mythos_Ruler]

What about a slider in the trader UI that adjusts that % of profit that goes to allies? Or....

A slider in your own Market's UI that determines the "tax" put on the profit of your ally's traders.

I like the 2nd idea because there's a little more interplay or tension between the allies.

[zoot]

I kinda like that too, if it can be put into the UI without feel overly out of place.

[Mythos_Ruler]

I kinda like that too, if it can be put into the UI without feel overly out of place.

Doesn't have to be done with sliders either-- could just be 3 toggle buttons: 25%, 50%, or 75%. (or 4 buttons to align better with the 4 barter buttons: 10%, 25%, 50%, 75%.)

[zoot]

Could it be a per-ally setting in the diplomacy window instead of a per-market setting in the building panel?

[Mythos_Ruler]

Could it be a per-ally setting in the diplomacy window instead of a per-market setting in the building panel?

Even better.

[alkazar-ipse]

GREATE IDEA !!! (but... put some boundries, to protect the player from doing stupidities)

Gameplay logic (like trading) is written in the simulation part of the code. And there is stated literally 'MoveToTarget(targetMarket)', i.e. that code doesn't care what coordinates/dimensions the 'targetMarket' has, the same about the trader, this is just different level of abstraction. On the other hand, 'MoveToTarget' goes somewhere into the engine, where code know nothing about the trading and to what side the trader is moving. There is just one entity (the trader) and another (the market), their coordinates and all those pathfinding things. I don't know how exactly the pathfinder works, but I think (from what I vaguely remember/misremember) that it just calculates path to the centre point of the object (market) until it stumbles upon a tile blocked by the target. So what you propose requires significant changes in both engine and simulation sides.

I can agree on a more common solution for all units, (just though maybe you can define the market as 2 objects, always built together, linked.

And then do something like:

-MoveToTarget(targetMarket_in)

-MoveToTarget(targetMarket_out)

I don't know exactly how, and if a more common solution will be found then everything is perfect.

As for now, I think the svn version deals with it pretty well, since i always get 2 routes, one for each direction.

Edited October 20, 2012 by alkazar-ipse

[quantumstate]

As for now, I think the svn version deals with it pretty well, since i always get 2 routes, one for each direction.

I think this happens because the pathfinder works in 8 directions, and has a bias in some directions, so you might get lucky and find that the two routes end up being different. i.e. with a diagonal bias it will make paths which look like this:

S-<--\
 \    \
  \    \
   \-->-E

Also the pathfinder in svn is no different to the previous alphas.

[alkazar-ipse]

ok