Freeserf bug? - mine not receiving food despite being the highest food priority

[tlongstretch]

I have a savegame demonstrating this. Player1 has two iron mines. Iron mines have the highest food priority. The next-highest food priority gets all the food. Even after rebuilding various roads, changing food priorities, etc. nothing causes iron mines to receive food. HOWEVER, destroying one of the iron mines then rebuilding it in the same place triggers food to be delivered to that rebuilt iron mine.

I suspect there is an issue where the "request resource" setting is being lost and is never revisited

[tlongstretch]

after doing some testing with save games, it looks like the difference between the "before" iron mine and the rebuilt one is that the rebuilt one has stock[0].requested = 7 while the broken one has stock[0].requested = 8. If I modify the save game and change the 8 to a 7, it fixes the problem - food starts being delivered to the iron mine.

Need to figure out how this .requested variable is used

[tlongstretch]

maybe it stops trying once it hits max requested?

  case TypeIronMine:
    if (holder) {
      int total_food = stock[0].requested + stock[0].available;
      if (total_food < stock[0].maximum) {
        Player *player = game->get_player(get_owner());
        stock[0].prio = player->get_food_ironmine() >> (8 + total_food);
      } else {
        stock[0].prio = 0;
      }
    }
    break;

[tlongstretch]

ah, I see prio is also set to 1 in the rebuilt/fixed save.

I think the issue is: if the building requesting resources reaches requested = 8 (it looks like it increases by one every so often?) then it sets priority back to zero. However, if no resources were actually dispatched (because they were available then? Or inventory queue was full??) the building will set the priority back to zero and will never get the resources when they are next available!

[tlongstretch]

see further comments here: https://github.com/freeserf/freeserf/issues/490

If I assume the game is working perfectly, then the issue is that letting roads/flags become clogged with resources is MUCH WORSE than it seems, because not only will those resources not be stored, they are occupying slots in buildings that requested them. And once requested count reaches max count, those buildings will never request resources again even if a much closer source becomes available!

So it is possible to modify the AI logic to take drastic action if roads become clogged, but it seems more realistic to allow them to become clogged and have some fallback plan to re-request resources that haven't arrived in a reasonable amount of time, and let resources become lost on roads.

[tlongstretch]

I think the best answer to this, assuming the game tracks all resources perfectly, is to have a building re-request resources that have not arrived in a reasonable amount of time, AND to cancel the original request so that the en-route resource (that is probably stuck in a congested flag somewhere) can be re-routed to either a nearby inventory or a new direct destination.

OR, have serfs prioritize transport of materials destined for a non-stock (warehouse/castle) building over any resource destined for storage. Check to see if there is already some game feature do to do this that maybe I am not understanding.

[p1plp1]

heh, i dont use your AI build to test this, so im looking on TWO MAJOR PROBLEMS: -fisherman catch fishes, lot of fishes, but serfs transports them between nearest flags, or just takes fish and they didnt drop it to another flag but return back to flag where transport started ! -mines are bugged priority, confirmed, looking for any solution

[p1plp1]

hey, fix is simple, what about adding stock[0].prio fix in my code? in food type fix, file building.cc in Building::requested_resource_delivered, recalculate stock priority, and i need to find where is resource consumed and fix it there too.

[p1plp1]

testing now: / Add to building stock / for (int i = 0; i < kMaxStock; i++) { if ((stock[i].type == Resource::GroupFood) && (resource == Resource::TypeFish || resource == Resource::TypeMeat || resource == Resource::TypeBread)) { stock[i].available += 1; stock[i].requested -= 1;
if (stock[i].requested < 0) { stock[i].requested = 0;
Log::Info["Building::requested_resource_delivered"] << "Fixing req res delivered FOOD type requested below zero."; } stock[i].prio= stock[i].maximum - stock[i].available;

    Log::Info["Building::requested_resource_delivered"] << "Fixing req res delivered FOOD type.";
    return;
  }     
  if (stock[i].type == resource) {
    if (stock[i].requested > 0) {
      stock[i].available += 1;
      stock[i].requested -= 1;

      stock[i].prio= stock[i].maximum - stock[i].available;       

.....

[p1plp1]

fixing this functions too:

bool Building::use_resource_in_stock(int stock_num) { if (stock[stock_num].available > 0) { stock[stock_num].available -= 1; stock[stock_num].prio= stock[stock_num].maximum - stock[stock_num].available; return true; } return false; }

bool Building::use_resources_in_stocks() { if (stock[0].available > 0 && stock[1].available > 0) { stock[0].available -= 1; stock[1].available -= 1;

stock[0].prio= stock[0].maximum - stock[0].available;
stock[1].prio= stock[1].maximum - stock[1].available;
return true;

} return false; }

[p1plp1]

looks like this fixes miners food deprivation bug :) i cant still confirm this definitely, because there is another bug crashing game with big settlement after x-12hours ...

[tlongstretch]

Thanks for contributing this, I am opening an issue in Forkserf as I have moved this project there. I will take a look into this soon

https://github.com/forkserf/forkserf/issues/119