Bay 12 Games Forum

For your seed stockpiles, barrels allowed == 0.

Doing that - you'll have to have some huge stockpiles or you'll have seeds laying around everywhere.

Maybe do a central stockpile for all seeds with barrels, then a second stockpile for just plump helmet spawn with zero barrels set to pull from the central stockpile.  That second stockpile can be small and located right next to the farm.

What *should* happen is for pickup up seeds all over the fort, is a dwarf goes to stockpile one, gets a barrel, hauls it to the seed, puts the seed in, hauls it back to stockpile 1, and then picks up the seed from barrel and takes it to stockpile 2 (if there is space there).

Then I could just put my main dining room with a glass ceiling to the outside - and it would ignite those bloodsuckers.   

Are there any way to filter these guys out of your fortress?

I'm outside mowing the yard while my wife+kids are inside watching Cake Boss...
In my head I'm thinking:

                 Idlers:  3

The long range/short range idea I've used before is kinda similar to what you suggested above.  Each frame the short range one is really just quick logic to keep you on a path layed out by A* from the long range pather.  If it cannot get you where it needs to, it tries to get you close, if it can't do that it figures out if the original long range path it has is still viable - if not it requests a new one next frame.   In that next frame the long range pather has a list of requests which is can prioritize and gate based on how much time it has to opperate.

On the logs - the problem I frequently have is that each thread writes into its own log file (otherwise you have the issue of write contention on the log file which creates bottlenecks that you are trying to avoid in the first place).  So you end up with 3 different files that you are trying to interlace together on the same timeline so you can figure out what happened.

"I do not really get your point here. All the input for the path finder would be read-only for it, since the outcome is some new data: the current path"

Even though it is read-only, it has to be thread safe. So you are going to have to either use reader/writer locks - or you are going to have to make a read-only full copy of ALL the data the pather needs at the start of the frame.

On the other - if you have any sim event whose resolution is going to depend on WHEN the thread it is in is executed - then you are introducing randomness.  Trying to debug a crash with a crash-dump is going to be impossible.

Quote from: Hateweaver on February 21, 2011, 11:38:19 am

Quote from: Nekudotayim on February 21, 2011, 11:30:00 am

Single threaded application... boo.   

Getting a game sim of any complexity to run across multiple cores is almost impossible.  Folks can generally dream up some fake game world situation where it would work - but for most games, no.  Something like DF where he is going to have an order of event applies and resolutions is impossible.

You could spend time going through the sim and looking for iterative loops where previous results don't affect others and split that operation up.  But its going to take a lot of time for probably not much reward.

Nah. For example: The path finding algorithm could be done by another thread implementing message queues for request and response. That way, everything stays synchronized but is still able to get calculated by multiple cpus, increasing the speed in total if you got 2 cores for this example. It's a general concept of server applications just to name it.

That would work except that your sim update is going to change your path-ablity.  So a path request updating at the begining of the sim update is going to have different data than one at the end of the sim update.  I'm used to working on sims which are determanistic so that they are more debug-able.  Adding randomness to the pathing resolution would drive me nuts.

Also you are going to have to make all data that the pather needs thread safe - that trade-off of locks is going to slow down the sim update which is the primary pinch point for the processing.

Yes! That is greatness!