You are right the code is not the most elegant as it can be...
but sets are not fine, because we need something that takes pairs duetime:job,
and ideally that would re-order itself after each entry, so the the job with
oldest duetime is on the bottom or top
As for identical duetime - it
When using simple std::pairScheduleTasks, DueTime, I would completely
eliminate the scheduler_review() function. It would made the code shorter and a
bunch of variables would disappear.
--
https://code.launchpad.net/~widelands-dev/widelands/ai-scheduler/+merge/251327
Your team Widelands
daAlx1 has proposed merging lp:~amdat/widelands/HunterBug1407418 into
lp:widelands.
Requested reviews:
Widelands Developers (widelands-dev)
For more details, see:
https://code.launchpad.net/~amdat/widelands/HunterBug1407418/+merge/251689
solves Bug 1407418 Multiple Hunters hunt for same
I would like to keep this stuff separated.
You understand this is not a queue in a FIFO meaning. When actual job is
running it is not obvious which one will be run afterwards. Might be the same
job again. And it is not important to know order of subsequent jobs.
It is merely to provide equal
Set elements are pairs of key, value. Just use the duetime as the key and the
job type as the value, and your entries will automatically be sorted by
duetime. Pop the next job off the front and insert a new check of the same job
type into the set with the new duetime and you will have
I am going to investigate priority_queue :)
--
https://code.launchpad.net/~widelands-dev/widelands/ai-scheduler/+merge/251327
Your team Widelands Developers is requested to review the proposed merge of
lp:~widelands-dev/widelands/ai-scheduler into lp:widelands.
Well it is not so simple.
I thought priority_queue + pairs would do the trick, but I realized that I dont
need to remove and add items into queue, instead, all items would be stable,
only second member of pair would be changing. And this is not possible with
priority_queue.
But I could create
7 matches
Mail list logo
