A pawn start its way from base to a construction site on the other side of the map at 9 pm half starving. By the time he gets there not only it's "bed time" and he's tired, but also hungry. It builds something (one piece), then eats without a table, then goes back to the base to get rest. You see how it's frustrating to watch? And it's pisses off the pawns.
So, can the game calculate a couple of steps ahead, like if by the time a pawn gets to the object of its mission they will be hungry, maybe go eat first? And if it will be time to go to sleep, then find another work to do, closer to the base?
Needless to say this should not apply to manual commands.
Of course there are many other problems, like why send 20 colonists to build 20 pieces of a wall, when (and if there's time for that) one pawn can handle it?
This is more a problem with AI in general than it is with the game -- the computation time required for your proposed algorithm is much, much higher than for what's being used now.
Quote from: vzoxz0 on September 26, 2018, 06:01:03 PM
This is more a problem with AI in general than it is with the game -- the computation time required for your proposed algorithm is much, much higher than for what's being used now.
Really? seems rather straight forward..
if(calculate_time_required(distance ( current_location, waypoint_location )) +time > time_for_sleeping )
initiate_sleeping_routine;
if(calculate_time_required(distance ( current_location, waypoint_location )) +time > time_for_next_meal )
initiate_mealtime_routine;
------------
I also suggested a small tweak to logic that seems as straight forward as water, but got no response.
if(pawn_is_delivering_item && (pawn_destination(check_zone_ID) == pawn_location(check_zone_ID) ))
if(current_pawn_location_has_no_items)
{
drop_inventory;
start_next_task;
}
(Pawns have always choose to walk over empty spots in a delivery zone, often heading to the back of a zone area to drop something while passing empty spots that just make no sense that they don't choose to leave the item at, some function checks.. that must exist already.. if called would solve this problem..)
I recommend you look at the decompiled code, specifically Verse.AI -- Classes of interest might be .PawnPath, .PathFinder, .PathGrid, .PawnPathUtility
If you still think this would be easy and cheap after looking at that code, I suggest you mail the (real) changes to Tynan and wait for your credit in the game. :P
Quote from: vzoxz0
This is more a problem with AI in general than it is with the game.
..
"Look at the real game code"
Well, it seems that you saying this is actually a problem with the game because the AI (logic) is straight up simple.
I look forward to you explaining how multiple pawns doing multiple job-checks all of which calculate a distance that used to be done once ends up not costing computing time.
I look forward to you explaining why Santa Claus isn't a byproduct of the Easter bunny.
Because that's about as close as one thing is to the other. You said the AI (not the game) made it difficult to do, later you said the code is spaghetti. I'm willing to accept and believe the code is spaghetti but the functions I'm talking about, like computing the time needed to go from A to Z, shouldn't require a super computer, nor is an impossible logic task.
I never said anything about spaghetti code, but what can I expect from someone who isn't educated/a professional in CS/SE besides straw-men and nonsense.
Which of these statements do you fundamentally disagree with? You can choose any combination including none.
Pathfinding is computationally expensive.
Doing pathfinding much more often is much more computationally expensive
The algorithm you propose requires doing pathfinding much more often than the one that is currently in use
If you can concretely answer that question maybe we'll get somewhere.
Quote from: vzoxz0 on September 27, 2018, 05:30:32 AM
I look forward to you explaining how multiple pawns doing multiple job-checks all of which calculate a distance that used to be done once ends up not costing computing time.
For someone claiming to be an edumakated coder, you are quite foolish to suggest or assume that any suggested change/improvement should cost
nothing and go on to ridicule someone because because it will cost some time to process an additional instruction at which point you seem to assume such a change is impossible. An edumakated coder doesn't consider if an instruction is going to cost something, they EVALUATE it for worth, demanding that a change cost nothing or expecting someone to argue that it doesn't is "nonsense".
Yes, I'm not familiar with Rimworld (code), but if there is nothing like a function to start_next_task_because_this_old_shit_is_finished_now that is a pity because that is the only time that a pawn should logically decide if heading out across the map is a good idea or not, that isn't going to burn your cpu core into dust, so yes, I think it's worth the cost.
Quote from: vzoxz0 on September 26, 2018, 06:01:03 PM
This is more a problem with AI in general than it is with the game -- the computation time required for your proposed algorithm is much, much higher than for what's being used now.
What I hear you saying is the code can't handle it.
The only thing you need to take forward is this. Pawns do some really really stupid shit, and the code should be improved to the point where such obviously stupid shit doesn't exist in the final game. People who say "it can't be done" or "it will cost something" shouldn't be on a high horse or make excuses for it, especially a gifted coder such as yourself.
Guys, chillax, for god's sake. :)
Let Tynan do his work if he decides, that it's needed or not. ;)
Quote from: dragonalumni on September 28, 2018, 10:47:37 AM
Quote from: vzoxz0 on September 27, 2018, 05:30:32 AM
I look forward to you explaining how multiple pawns doing multiple job-checks all of which calculate a distance that used to be done once ends up not costing computing time.
For someone claiming to be an edumakated coder, you are quite foolish to suggest or assume that any suggested change/improvement should cost nothing and go on to ridicule someone because because it will cost some time to process an additional instruction at which point you seem to assume such a change is impossible. An edumakated coder doesn't consider if an instruction is going to cost something, they EVALUATE it for worth, demanding that a change cost nothing or expecting someone to argue that it doesn't is "nonsense".
Yes, I'm not familiar with Rimworld, but if there is nothing like a function to start_next_task_because_this_old_shit_is_finished_now that is a pity because that is the only time that a pawn should logically decide if heading out across the map is a good idea or not, that isn't going to burn your cpu core into dust, so yes, I think it's worth the cost.
Quote from: vzoxz0 on September 26, 2018, 06:01:03 PM
This is more a problem with AI in general than it is with the game -- the computation time required for your proposed algorithm is much, much higher than for what's being used now.
What I hear you saying is the code can't handle it.
The only thing you need to take forward is this. Pawns do some really really stupid shit, and the code should be improved to the point where such obviously stupid shit doesn't exist in the final game. People who say "it can't be done" or "it will cost something" shouldn't be on a high horse or make excuses for it, especially a gifted coder such as yourself.
I never said the code couldn't do this. It can. It just isn't, because pathfinding is expensive.
The limitation to software is almost never "code", it is logic.
You couldn't even answer the
one question I asked you, so I'm done talking to you. Some people's opinions can't be swayed by facts or logic and you are one of those people.
Quote from: vzoxz0 on September 28, 2018, 09:47:47 PM
The limitation to software is almost never "code", it is logic.
I believe when you are trying to code this is the case.
Quote from: dragonalumni on September 29, 2018, 11:13:03 AM
Quote from: vzoxz0 on September 28, 2018, 09:47:47 PM
The limitation to software is almost never "code", it is logic.
I believe when you are trying to code this is the case.
There's a certain amount of irony in that you think that's an insult. Not even good at trolling.
Quote from: vzoxz0 on September 29, 2018, 11:48:36 AM
I'm done talking to you
..
"oh wait no I'm not"
I'll assume you code just like you communicate.
The fighting is going to stop here folks or I'm going to be forced to settle it in a way that none of us really want it to be settled... in an administrative meeting regarding how we can further settle this like gentlefolks....
No but seriously, chill.
Think they're always trying to improve it when there's an obvious solution. It's just not an easy task.
Here's an old video from tynan himself going over that kind of stuff. I assume there has been many changes since then but still interesting to watch. https://www.youtube.com/watch?v=RMBQn_sg7DA (https://www.youtube.com/watch?v=RMBQn_sg7DA)
I thought pawns packed a single meal in their personal inventory, so that they could eat it if they were far away from the kitchen / freezer. Did this behaviour get removed? I've been playing with my modded food, which might be incompatible, but I know in the past my pawns would take a simple or fine meal with them, to eat when they were out mining across the map from my kitchen.
Quote from: AileTheAlien on September 30, 2018, 11:29:23 AM
I thought pawns packed a single meal in their personal inventory, so that they could eat it if they were far away from the kitchen / freezer. Did this behaviour get removed? I've been playing with my modded food, which might be incompatible, but I know in the past my pawns would take a simple or fine meal with them, to eat when they were out mining across the map from my kitchen.
AFAIK, they still do. Though there are situations that can end up using that packed meal for something else. Like if a Doctor or Warden needs to feed a Patient or Prisoner. After feeding the patient/prisoner they won't always go back and resupply before doing other tasks. Training animals is another task that might have them use their packed meal if there isn't a preferable animal meal nearby.
It might be beneficial if the current unstable functionality of "food policy" could also specify how many you take to inventory.
It'd be nice to tell animal trainers to take kibble to inventory while still telling them they can't eat it. I mean, doctors should naturally keep some food on them if they're feeding patients -- though I still feel like "Wardening" should also pitch in there.
Getting back to the original complaint, a partial fix could be that pawns with a work target outside the home zone will eat first if they're below, say, 35% of their food bar. I don't know how the code is set up, but it seems like an if statement checking a map that has already been drawn shouldn't be too expensive. That wouldn't do anything for farmers or with a couple constructor scenarios I can think of, but it would help with miners, hunters, and handlers.
That would be a reasonably efficient fix, since zoning is already integrated in how the logic works.