Topic: main roads becoming normal again

We are not getting any AppVeyor builds at the moment, because somebody had initiated a merge request for an empty branch, which totally screwed up our build bot.

Launchpad doesn't offer any continuous integration options, so SirVer has hacked together a bot that is running on his Raspberry Pi. There is no really clean way of doing this, so it is pretty fragile. I notified him yesterday, and we have to wait for him to find the time to get it running again.

The first order of business after Build 20 will be to move to GitHub so that we can integrate Travis and AppVeyor directly and retire our little hard-working bunnybot.

Busy indexing nil values

Top

Quote

I conducted my tests. What works:

• The algorithm performs exactly as expected, fully predictably and like a precise clock (although its precision has been purposefully limited to coins, seconds and wares, not trying to be smooth in between them).

• It successfully catches the targets of the proposed finetuning (alternative finetunings are possible, if people agree on them).

• The extra road-segment of buildings is successfully included in the calculations (although I suspect that the system isn't reliable in reporting a carrier there).

• In all my tests the new algorithm outperformed the old one, without stressing the system, and it could be merged even at this stage, no matter the remaining issues right below. Still people are encouraged to test it for their own. Mind that this fix is only about the stated goals, not about everything mentioned in this thread.

What doesn't work:

• Fully idle roads are not checked, so they don't get demoted before a ware finally comes to them (they get demoted when the carrier takes that ware). That problem exists in the old algorithm too.

• Congested roads don't escape maintenance charges, so a prolonged congestion can demote them prematurely (still the system is fast to promote them again after the congestion is over). On the other hand, while a promoted road remains congested, its animal becomes inefficient and could be more useful somewhere else.

For both the things that don't work, the reason is that I limited my work to specific files (having already moved beyond the initial method). I tried to do the most out of those files, but it turned out that the involved code is more spread than necessary, which needs a good understanding of the codebase, and in particular of the scheduling/signaling system (which probably needs to be reworked, but I wouldn't go there without serious help). The lines for those two things (100, 411 and 412 in file tribes/carrier.cc) can get commented out (although their effect is minimal).

Top

Quote

Description looks good to me, I have not tested it though...

Top

Quote

Hi,

I can't stick to all the discussion (I don't have a time to read all 19 pages). But I have a question about old improvement to the roads:

is there any idea how to solve manual upgrade/downgrade of the road?

I know that this could solve many problems for some players.

einstein13
calculations & maps packages: http://wuatek.no-ip.org/~rak/widelands/
backup website files: http://kartezjusz.ddns.net/upload/widelands/

Top

Quote

As I understood previous system, a player could add some points to any road and instantly upgrade it. That idea didn't change the logic because further behaviour was as before. So if there is some type of points that counts how the road should look like, it is always possible to do that.

Newbies don't have to change anything, their roads will upgrade anyway (but after some time), but advanced players can predict bottlenecks faster and know how to solve any traffic jams faster. Downgrading would behave like always. Micromanagement here don't have to be done, but can be (other opinion needed here).

einstein13
calculations & maps packages: http://wuatek.no-ip.org/~rak/widelands/
backup website files: http://kartezjusz.ddns.net/upload/widelands/

Top

Quote