Latest Posts

Topic: Transportation priorities

Forums » Player Forums » Game Suggestions » Transportation priorities
abtools

Joined: 2010-01-08, 15:31
Posts: 31
Ranking
Pry about Widelands
Location: Munich
Posted at: 2010-11-14, 15:46

Hello together,

yes, I talked about that problem already with SirVer and he also suggested such a system: https://bugs.launchpad.net/widelands/+bug/669918

So that should work fine.

Best regards Andreas

Top Quote
nsh

Joined: 2010-11-08, 19:30
Posts: 27
Ranking
Pry about Widelands
 Posted at: 2010-11-20, 16:56

I have made changes to flag.cc for transport optimization, so that corresponding functions look like following

`void Flag::add_item(Editor_Game_Base & egbase, WareInstance & item) {

assert(m_item_filled < m_item_capacity);

PendingItem & pi = m_items[m_item_filled++];
pi.item     = &item;
pi.pending  = false;
pi.nextstep = 0;
pi.priority = 0;

Request * req;
req = item.get_transfer()->get_request();
if (req) {
    pi.priority = req->get_priority(0);
}

item.set_location(egbase, this);

if (upcast(Game, game, &egbase))
    item.update(*game); //  will call call_carrier() if necessary

} `

and

` bool Flag::ack_pending_item(Game &, Flag & destflag) { int32_t highest_pri = 0; int32_t i_pri = -1; int32_t i_notoptimized=-1;

for (int32_t i = 0; i < m_item_filled; ++i) {
    if (!m_items[i].pending)
        continue;
    if (m_items[i].nextstep != &destflag)
        continue;

    if (m_items[i].priority>highest_pri) {
        highest_pri = m_items[i].priority;
        i_pri = i;
    }

    if (i_notoptimized<0) i_notoptimized = i;

}

if (i_pri>=0) {
    if (i_pri!=i_notoptimized) log("Ware transport optimization: %i with %i priority would be selected instead of %i with %i priority \n",
        i_notoptimized, m_items[i_notoptimized].priority,i_pri, m_items[i_pri].priority);
    m_items[i_pri].pending = false;
    return true;

}

return false;

} `

and add corresponding "int32_t priority" to the PendingItem structure.

This code looks for the economical priority of the wares when they are dropped at the flag and caches it. After that, carrier will pick up the ware with highest economical priority. All wares, being transferred due to the some request, are transported with corresponding priority. Wares, that are not requested (e.g. being delivered to the warehouse), have the lowest (default) priority. Unfortunately, the request->get_priority() gives low default priority for the construction wares for construction, therefore, it doesn't help build faster (unless get_priority correspondingly patched). Anyway, this approach looks promising for me. There is no need to change gui - make a priority of ware higher in any building and only wares for this building will move faster, not the whole kind of this ware everywhere.

The problem is that here is some bug, I could not identify. After such optimization game will go on, but eventually, soon or later, throw a "Carrier::find_pending_item: start flag is messed up" exception. I have played around with it and can not understand where is the problem. This exception is thrown when ack_pending_item returns false. But there is only a change in index of ware at flag, instead of one value another returned. How it may lead to the crash? And it is not well reproducible.

Please, anybody help me, I want to make my first contribution face-smile.png

Edited: 2010-11-20, 17:19
Top Quote
abtools

Joined: 2010-01-08, 15:31
Posts: 31
Ranking
Pry about Widelands
Location: Munich
Posted at: 2010-11-20, 18:29

Hello nsh,

could you push your code change to a Launchpad branch?

This would make it easier to test it.

I'm not an expert in C++ myself, but here are many very experienced developer around. face-wink.png

Best regards Andreas

P. S.: you could also ask directly in IRC if you didn't ask yet.

Edited: 2010-11-20, 18:31
Top Quote
nsh

Joined: 2010-11-08, 19:30
Posts: 27
Ranking
Pry about Widelands
 Posted at: 2010-11-20, 19:58

bzr diff

http://wl.pastebin.com/2MXXsSqi

Top Quote
nsh

Joined: 2010-11-08, 19:30
Posts: 27
Ranking
Pry about Widelands
 Posted at: 2010-11-21, 00:39

Finally, with the help of nha, abtools and gdb, I've got it.

The problem was in race, when the freshly produced ware s didn't have Transfer attached to it. Now it is Ok, I had run computer players for long period of times without segfaults. Also, I have found that request->get_priority() was intended to make construction wares more important, but due to the bug, actually made the opposite - they were given the lowest priority. The bug is reported to the launchpad. https://bugs.launchpad.net/widelands/+bug/677980 Hopefully, this bugfix alone increases also the priority of construction wares allocation, assigning them higher priority, as it was initially designed.

The full patch (including bugfix) is here:

http://wl.pastebin.com/nQZ9UrZk

How it works? Every time, when the ware is dropped at the flag, its economical priority is calculated. Ware with highest priority will be picked up by the carrier. To avoid ware stall due to its low priority, at every pickup priorities of remaining wares are increased. Current value of waiting bonus ensures that neither ware would wait more than 5-10 pickup attempts.

How to use ? If you need urgently an iron ore somewhere, just make in that building the delivery priority of iron ore higher. This will lead to the increase of economical priority of iron ores, which are being transfered to said building, and only for them! All other iron ore's moving somewhere else will not have a higher priority.

With the said bug patched, construction wares are given the highest priorities and they will be delivered faster automatically. Actually, the prioroty gived is as much higher as earlier the construction have been started. So, the trunk for building of lamberjack will move faster even if requested later, than the trunk for the wood hardener on the same road. Actually, this is the test I performed - made a long road, in the center of this road there were a place for lumberjack (do not built it now! just place a flag), and further a wood hardener is placed. After a wood hardener is built, headquarter will release a lot of trunks for delivery. Immediately after that build the lamberjack in between. The trunk for it will be released by headquarters later, and in FIFO principle, they would be correspondingly delivered later, only after trunks for wood hardener (didn't check, though). With my patch, they will be delivered much faster, probably 2 first trunks to lamberjack, then the trunk for wood hardener (well, it skipped 2 pickup attempts and increased its priority!), and then again for lumberjack, and then all remaining trunks went to the wood hardener.

Wares which are closer to their final destination also move faster. Probably, this adds up to the described test case (lumberjack is closer to the headquarters).

If in short - economical priority of ware is now also a transportation priority. Quite logical, without changing gui and hopefully quite intelligent face-smile.png

Edited: 2010-11-21, 08:02
Top Quote
nsh

Joined: 2010-11-08, 19:30
Posts: 27
Ranking
Pry about Widelands
 Posted at: 2010-11-21, 01:09

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

Look here for the replays. Watch how lamberjacks are being built. Wares for the second lamberjack were delivered with maximal speed achievable, from hands to hands, directly from headquarters to construction site, despite all the flags already contained concurrent wares face-smile.png

Edited: 2010-11-21, 01:34
Top Quote
abtools

Joined: 2010-01-08, 15:31
Posts: 31
Ranking
Pry about Widelands
Location: Munich
Posted at: 2010-11-21, 09:43

Hello nsh,

I've recompiled with your new patch now and also for me there are no segfaults anymore!

So it looks very promising - really good work. I'll do some more testing later on.

But I had problems applying your patch; I had to do it manually (not really fun). Maybe a problem from posting to this paste bin webpage? Anyway, I've created a new patch with exactly the same code change and uploaded it to my webspace. So if someone else want to try nsh patch and have the same problem as myself, just use this patch: http://www.ab-tools.com/temp/widelands-transport.patch

Best regards Andreas

Top Quote
Nasenbaer
Avatar
Joined: 2009-02-21, 17:17
Posts: 828
Ranking
One Elder of Players
Location: Germany
Posted at: 2010-11-21, 09:58

hey,

have not had the time to test, but one question: what about the priority buttons in constructionsites?

Top Quote
nsh

Joined: 2010-11-08, 19:30
Posts: 27
Ranking
Pry about Widelands
 Posted at: 2010-11-21, 10:11

Nasenbaer wrote: hey, have not had the time to test, but one question: what about the priority buttons in constructionsites?

It all depends on request.get_priority(). As far as I understand it:

1) bugfix already increases the resource allocation for construction sites, so one will need this feature rarely 2) priority buttons at construction site are respected exactly the same way as for consuming building

Priority is calculated as (priority set in building) * (time we had wait for this ware) / (delivery costs). Time for constructionsites is counted from the time when engineer gets to it.

So, yes - if you give construction a higher priority I assume its wares will be allocated and delivered also faster. Because priority depends on the how "old" the request for ware is, more constructionsites waits for ware, more priority to it will be given. That's why constructionsites wares priority I saw were much higher than for usual wares. If you make them higher priority at constructionsite I think they will get the highest priority possible, due to combination of both factors. Actually I fear, that priority calculated for long standing constructionsites (or a long awaited iron ore)may be so high, that it will overflow a signed int32 and became negative. I didn't make the corresponding check to keep the patch as small as possible to be reviewed and merged.

Edited: 2010-11-21, 10:50
Top Quote
SirVer

Joined: 2009-02-19, 14:18
Posts: 1445
Ranking
One Elder of Players
Location: Germany - Munich
Posted at: 2010-11-21, 11:17

I like this approach a lot; it seems logical to me that high priority wares get delivered as fast as possible. I also like that it does not need a manual GUI for tweaking and it does the right thing. I have not tested the patch yet and I'd like to have more testing with it before merging.

Can everyone live with this approach?

Top Quote