Important Dates

Latest Posts

Topic: main roads becoming normal again

ypopezios
Avatar
Joined: 2018-04-20, 00:22
Posts: 220
Ranking
Widelands-Forum-Junkie
Posted at: 2018-04-20, 01:03

Calculating busyness is not the best model, not to mention it's hard for simple users to understand. I believe that the following algorithm is superior:

  • Every human carrier starts with a hypothetical wallet empty of coins (zero value of a single simple integer variable, very friendly both to calculations and to savegame).
  • Every time a carrier loads a ware, his wallet gets increased by an amount of coins equal to the number of wares awaiting in the respective queue of the flag (no wallet is permitted to go above the maximum amount of coins gainable in a specific length of time). If we also want to help long roads, the said amount could be increased by the length of the road.
  • Periodically (only a single system-wide timer) the system removes a fair amount of coins (say maintenance costs) from the wallet of every carrier (no wallet is permitted to go below zero), except of those in congested roads (since they cannot increase their coins). Removes double that amount from the wallets of those who have animals. If one of those has not enough coins for the payment (thus wallet goes to zero), his road gets demoted and his animal becomes available for reassignment.
  • Same period second step (applicable only when there are animals available), the system checks the amount of coins of every carrier in unpromoted roads. If any of those carriers has accumulated enough coins (say to buy an animal), his road gets promoted and the proper amount of coins is removed from his wallet, while an animal is assigned to his road. If there are not enough animals available, they get preferably assigned to the carriers with the most coins.

Having said that, I would also like to mention something irrelevant to this thread, but too minor for its own thread. That if the following text from the campaigns is true (and I believe it is):

"The ox is as swift as a human being while being much stronger"

...then the animals should carry two wares per time. But since this would make the road too effective (three wares carried per time in total), the human carrier could stop carrying things himself and instead pull the strong animal around (back to two wares carried per time in total), which is again more realistic and only slightly less efficient than the current model.

Edited: 2018-04-20, 12:04

Top Quote
Tibor
Joined: 2009-03-23, 23:24
Posts: 1317
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2018-04-20, 08:51

Hi,

What current system does not have is system-wide time/job that would iterate over each road/carrier periodically, but this might be right idea and could provide some opportunities for improvement..But would be quite a big change to the current code.


Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3159
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2018-04-20, 12:02

I don't remember exactly what the current code does, but in principle it's just "road business" rather than "coins in wallet"... on the surface, this sounds to me like the exact same thing that we already have, only with a different metaphor.

Linking the carrier to the animal would definitely be nice eye candy if we can find somebody to create the animations. It will probably make the roads less efficient though, because we remove the independence of the 2 units. Maybe link them together and carry up to 3 units? This would need some coding changes too though.


Busy indexing nil values

Top Quote
ypopezios
Avatar
Joined: 2018-04-20, 00:22
Posts: 220
Ranking
Widelands-Forum-Junkie
Posted at: 2018-04-20, 12:09

Tibor wrote:

What current system does not have is system-wide time/job that would iterate over each road/carrier periodically, but this might be right idea and could provide some opportunities for improvement..But would be quite a big change to the current code.

I thought that a global timer would be less work based on this:

GunChleoc wrote:

Maybe we could have a global timer that goes through all the donkeys once in a while? This would be less work than checking all the roads.

The system-wide timer makes better decisions for the empire, as it compares the performance of all roads in a length of time (which doesn't have to be short). But if the current code isn't friendly to such a timer, then the algorithm could change like this (first two bullets remain the same):

  • Every human carrier starts with a hypothetical wallet empty of coins (zero value of a single simple integer variable, very friendly both to calculations and to savegame).
  • Every time a carrier loads a ware, his wallet gets increased by an amount of coins equal to the number of wares awaiting in the respective queue of the flag (the wallet is not permitted to go above the maximum amount of coins gainable in a specific length of time). If we also want to help long roads, the said amount could be increased by the length of the road.
  • Same time second step, the system removes a fair (proportional to the time passed since last check) amount of coins (say maintenance costs) from the wallet of that carrier (the wallet is not permitted to go below zero). Removes double that amount if that carrier has an animal. If he has not enough coins for the payment (thus wallet goes to zero), his road gets demoted and his animal becomes available for reassignment.
  • Same time third step (applicable only if the road was unpromoted), if the carrier has accumulated enough coins (say to buy an animal), his road gets promoted and the proper amount of coins is removed from his wallet, while an animal is assigned to his road, if there is one available.
Edited: 2018-04-20, 12:35

Top Quote
ypopezios
Avatar
Joined: 2018-04-20, 00:22
Posts: 220
Ranking
Widelands-Forum-Junkie
Posted at: 2018-04-20, 12:22

GunChleoc wrote:

I don't remember exactly what the current code does, but in principle it's just "road business" rather than "coins in wallet"... on the surface, this sounds to me like the exact same thing that we already have, only with a different metaphor.

Of course on the surface all algorithms have the same goal, to effectively model a given situation. But the different models make different calculations under the surface and produce different results. The wallet metaphor is used only to help us come with a better model, certainly not what we already have.

Edited: 2018-04-20, 12:45

Top Quote
Tibor
Joined: 2009-03-23, 23:24
Posts: 1317
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2018-04-20, 12:48

Are you able to (at least) understand C++ code (small portion, not entire codebase)? It would help if you could suggest changes to actual state instead of suggesting something completely new from scratch... But if you want to learn some C++ coding this sounds like great opportunity.....


Top Quote
ypopezios
Avatar
Joined: 2018-04-20, 00:22
Posts: 220
Ranking
Widelands-Forum-Junkie
Posted at: 2018-04-20, 13:23

Tibor wrote:

Are you able to (at least) understand C++ code (small portion, not entire codebase)? It would help if you could suggest changes to actual state instead of suggesting something completely new from scratch... But if you want to learn some C++ coding this sounds like great opportunity.....

It is funny how I'm "accused" (no hard feelings) for suggesting both the "exact same thing" and "something completely new from scratch" at the same time... If you guys find the time to go again through current thread, I believe that you would realize that things are not that extreme. I have already read the following code per your suggestion:

http://bazaar.launchpad.net/~widelands-dev/widelands/trunk/view/head:/src/economy/road.cc#L601

Although the wallet metaphor is a new contribution to this thread, I don't suggest something from scratch code-wise, I simply suggest to avoid going to this direction:

https://bugs.launchpad.net/widelands/+bug/1451973

...and instead improve current code by using the wallet instead of the busyness. Given some help, I could suggest specific code changes, but only if we firstly agree on the principle. And this is why I wrote in this old thread instead of launchpad, to have people discuss the theory before any implementation.


Top Quote
Tibor
Joined: 2009-03-23, 23:24
Posts: 1317
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2018-04-20, 13:54

My personal opinion is that the change should not be very expensive CPU-wise, and should work (when testing/observing) better than current implmentation.

Your description sounds fine, but unless it is changed into code it is hard to say whether the idea is good.


Top Quote
ypopezios
Avatar
Joined: 2018-04-20, 00:22
Posts: 220
Ranking
Widelands-Forum-Junkie
Posted at: 2018-04-20, 14:19

Of course no idea is good enough before passing the test of reality. If this is the only concern, I could proceed with suggesting specific code changes (maybe open a new bug in launchpad or you tell me what could work better for a first-time indirect contribution). But since this thread engaged more people, maybe we should wait for some further approval or other input. I don't really know how decisions are taken in this community. What I know is that it would not be nice to mess with code only to have some administrator say something like: "This works fine, but I don't agree with it in principle, so let's dump it."


Top Quote
Tibor
Joined: 2009-03-23, 23:24
Posts: 1317
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2018-04-20, 14:27

OK, let wait a bit, no need to hurry.

But what matter is implementation. Actual code that improves the situation is much better than great idea never to be implemented...


Top Quote