These two things (pathfinding and temperature) theoretically should not be affected - unless some data is shared. Like, you know, dwarves avoiding too hot places. At end is larger explanation of potential problems with that.
No it
doesn't matter that dwarves want to avoid hot places. Go ahead and pathfind and just don't give a crap whether there is some slim chance that the square will catch on fire that same turn you pathfind. If it does, it's no big deal. Your only penalty is a dwarf walking a little bit further on rare occasions. NOT game crashes. NOT fiery death. As long as the dwarf checks for fire in front of him before he actually TAKES his next step, he can still cancel the now-dangerous path before he actually enters the danger.
Hence my emphasis on movement being the primary thing that needs to be non-parallel, not pathfinding. Planning wher eyou might go in the future does not actually move you anywhere impossible or dangerous. Moving moves you there...
Also, imagine a path that will take, say, roughly 500 ticks to complete. And let's assume that at some point it ends up obstructed. There is only a
1/500 chance that the thing that ends up obstructing that path will begin obstructing it in the exact same tick that the path was planned. Whereas there is a
499/500 chance that it will happen during some other tick, and that even if you calculated them in sequence, you'd still have to rely on MOVEMENT, not pathfinding, to see the dwarf to safety. So you're already obligated to check in front of you each step.
This obsession with thinking for some reason that pathfinding needs super up to date info all the time every time is the source of disagreement here. It doesn't. It can do perfectly fine with 1 or 2 or even 5 tick old information if it has to, almost every time. And the other times, it's just inefficient, not game crashing.
If you do not wait for flow or temperature calculations to end of tick
I apologize if I was unclear. Yes, every type of calculation needs to finish before every tick ends.
What I meant was that, for example, temperature does not NEED to have up to date information as of this exact same tick from liquid flow. Even though liquid flow is a major source of temperature change, you could just use the previous tick's state and be totally fine. Maybe one random guys' crazy dwarven computer won't work anymore, or something. But the other 99.9% of everybody else who doesn't absolutely need ice to melt THIS tick instead of NEXT tick gets a faster game, and that's worth it.
The only reason why, say, flow and temp would need to be done in sequence within a tick would be if temperature MUST be accurate based on fluid flow in that same tick. I see no reason why this is the case. So yes, you still wait for each thing to finish before ending the tick, but you don't need to wait for flow to finish within the tick before doing temp. You can just work off a cache of the last tick's state.
My impression is you wanted that on beginning (except actual movement for some reason), but later changed goalposts, of course without admitting that maybe making everything in main loop threaded simultaneously isn't best idea in universe.
Nope, goalposts still the same. I didn't say everything. I said:
* Pathing
* Temp
* Liquid flow
* Combat
I may be wrong about some of that, but I stand by it for the moment.
Combat is the only one I think is a bit iffy, but I am still pretty sure it would work, as long as it has its own thread to itself, not split up into several. You go based on last tick's positions, and combat resolves before you move this tick (since movement happens at the end), which should be fine.
Author
Topic: Securing DF in case of unfortunate event? (Read 22721 times)