Topic: main roads becoming normal again
ypopezios |
Posted at: 2018-04-20, 00: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:
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, 11:04
Top Quote |
Tibor |
Posted at: 2018-04-20, 07: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 |
Posted at: 2018-04-20, 11: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 |
Posted at: 2018-04-20, 11:09
I thought that a global timer would be less work based on this:
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):
Edited: 2018-04-20, 11:35
Top Quote |
ypopezios |
Posted at: 2018-04-20, 11:22
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, 11:45
Top Quote |
Tibor |
Posted at: 2018-04-20, 11: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 |
Posted at: 2018-04-20, 12:23
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 |
Posted at: 2018-04-20, 12: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 |
Posted at: 2018-04-20, 13: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 |
Posted at: 2018-04-20, 13: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 |