Topic: Dwarf Foreman 0.7.2 - Tool to automatically dispatch jobs to your workers (Read 113057 times)

devek · « **Reply #240 on:** April 07, 2011, 05:01:56 pm »

Ya, its actually a good thing in my opinion. It seems kind of silly to simply queue one job when you're low on something when you might as well make a few more while you are at it. If you use a good workshop design, its more efficient than distracting the worker from whatever else he was working on every time an item is consumed.

LoSboccacc · « **Reply #241 on:** April 07, 2011, 05:25:23 pm »

Probably the safest way in the long run may be to queue 5 to 30 items per Job kind and leave them alone.

Like if (desired>current & not exist job xxx), queue min(max((desired-current),30),5)

That would reduce efficiency a bit but wont require to force large numbers upon jobs and allow to live without cancellations of previous orders (player can do that and overshoot is keept at reasonable values anyway)

OzoneGrif · « **Reply #242 on:** April 07, 2011, 05:26:23 pm »

Quote

There is a race condition where DF tries to remove at the exact same moment that Foreman does.

I program multi-threading applications, and trust me, that kind of conflicts happen all the time in multi-thread environments.

DFhack provides a tool to pause DF, then restart it. It happens so quickly the user won't notice. It may be a solution for your problem, no?

devek · « **Reply #243 on:** April 07, 2011, 05:35:09 pm »

Quote from: OzoneGrif on April 07, 2011, 05:26:23 pm

Quote
There is a race condition where DF tries to remove at the exact same moment that Foreman does.
I program multi-threading applications, and trust me, that kind of conflicts happen all the time in multi-thread environments.

DFhack provides a tool to pause DF, then restart it. It happens so quickly the user won't notice. It may be a solution for your problem, no?

Well, you can try pausing the game or suspending the process.

Suspending DF doesn't help because it is just as likely that it will suspend it in the middle of changing something that I plan to change. Depending on your design, suspending can help (a little) but it won't fix the problem and in my case makes no difference. The only fix is to hook into DF's main loop and have it suspend itself, which is something that has actually be done and creates nice defined behavior for all operations. Discussion has taken place with the dfhackers about some sort of protocol for a mutex that gets used by DF and utilities and everyone can play nice. thewonderidiot even noticed that df calls the sdl joy stick function every frame and since df doesn't use a joystick, it provides an incredibly easy way for us to hook in that isn't df version dependent

Now for pausing the actual game, it was kind of my idea hehe http://www.bay12forums.com/smf/index.php?topic=58809.msg1537346#msg1537346

Too bad it is a horrible hack and if I was trying to pause the game on a regular basis the user would notice and be annoyed... You don't notice so much when using dftools because they don't run automatically while you are playing the game. The main problem is summed up by peter in the dfreveal source.

Code: [Select]

cout << "Pausing..." << endl;

    // horrible hack to make sure the pause is really set
    // preblem here is that we could be 'arriving' at the wrong time and DF could be in the middle of a frame.
    // that could mean that revealing, even with suspending DF's thread, would mean unleashing hell *in the same frame*
    // this here hack sets the pause state, resumes DF, waits a second for it to enter the pause (I know, BS value.) and suspends.
    World->SetPauseState(true);
    DF->Resume();
    waitmsec(1000);
    DF->Suspend();

thewonderidiot · « **Reply #244 on:** April 07, 2011, 06:27:46 pm »

Quote from: devek on April 07, 2011, 05:35:09 pm

thewonderidiot even noticed that df calls the sdl joy stick function every frame and since df doesn't use a joystick, it provides an incredibly easy way for us to hook in that isn't df version dependent

That was peterix, not me.

That's how he had the old SDL.dll hack working.

devek · « **Reply #245 on:** April 07, 2011, 06:49:56 pm »

Quote from: thewonderidiot on April 07, 2011, 06:27:46 pm

Quote from: devek on April 07, 2011, 05:35:09 pm
thewonderidiot even noticed that df calls the sdl joy stick function every frame and since df doesn't use a joystick, it provides an incredibly easy way for us to hook in that isn't df version dependent

That was peterix, not me. That's how he had the old SDL.dll hack working.

Bah, my mind thinks too abstract to get important details like that right.

I'm so horrible with social skills.. since I have already embarrassed myself multiple times on this issue. Were you the one who was playing around with procedural generated 3d models?

While enjoying my time as being unemployed, it has been one of my interests when I am not doing pointless things like http://www.youtube.com/watch?v=BqyKqOWFrgc

thewonderidiot · « **Reply #246 on:** April 07, 2011, 06:55:49 pm »

Quote from: devek on April 07, 2011, 06:49:56 pm

Bah, my mind thinks too abstract to get important details like that right.

I'm so horrible with social skills.. since I have already embarrassed myself multiple times on this issue. Were you the one who was playing around with procedural generated 3d models?

While enjoying my time as being unemployed, it has been one of my interests when I am not doing pointless things like http://www.youtube.com/watch?v=BqyKqOWFrgc

Haha, when you were still hanging around in #dfhack I was doing a lot of code injection stuff, so you have that right. I was just basing my stuff off of peterix's old dll hack

And yeah, I was probably the one working on procedural geometry for Overseer.

devek · « **Reply #247 on:** April 07, 2011, 10:08:26 pm »

Ok

0.6.8 - Better supported for modded DF(tested with genesis). Default item buffer is 5 to prevent a rare race condition.

If you don't like the default item buffer feature, you can switch it back to 0 and 9999999/10000000 of the time it won't be a problem for you. I personally use the item buffer anyway because it ends up being more efficient for my fort and I imagine it is for most people too.

I also made the vector scan more robust, so mods like Genesis "just work". That being said, they are modded so some types of job won't work. For example, genesis mod does not have a simple make steel reaction, so obvious that job will fail to do anything. In the future I imagine mods will someday have their own dfjobs.xml that come with them to describe and support the various reactions they add/change/remove.

There might be some mods that fail to work, especially total conversion ones... I will figure out what to do about those on a case by case basis as they are reported to me.

devek · « **Reply #248 on:** April 08, 2011, 07:45:12 pm »

Small update.

0.6.9 - Added support for jobs that create multiple items.

Essentially, instead of queuing 100 jobs when you need 100 arrows.. it will just queue 4. It goes both ways though, it also won't queue a single job until you are 25-item buffer short of arrows(that is intended).

forsaken1111 · « **Reply #249 on:** April 08, 2011, 09:05:18 pm »

I have to say it is fantastic to have this utility again, thanks Devek!

Aalto · « **Reply #250 on:** April 09, 2011, 07:44:22 am »

I don't suppose it'd be possible to have it automatically reattach itself when you load a game after saving? I tend to save (and savescum 'cos I'm a dirty cheater) often and keep forgetting to restart foreman. Loading a specific profile on start and/or the ability to associate it with profile files along with some autohotkey magic could also work in a pinch.

And thanks for this awesome tool, ofc.

devek · « **Reply #251 on:** April 09, 2011, 11:50:35 am »

The logic is there for connect/auto connect already actually, and I do plan on adding such a thing. Expect it somewhere after 0.8 hehe.

Aalto · « **Reply #252 on:** April 09, 2011, 01:36:30 pm »

devek · « **Reply #253 on:** April 09, 2011, 04:51:28 pm »

Anyone interesting in working on dfjobs.xml? If you have a google code account, that is a good thing, but not necessary.

It needs some love. Specifically relating to having more entries and organizing it.

It is pretty self explanatory. The name and category of a job doesn't do anything but change how it is displayed in the interface. If you're dealing with a custom reaction, you just use the name that is in the raws and that is all you have to do. Otherwise the type is a table of hard/coded values.

Spoiler (click to show/hide)

Some jobs require a material, you can specify wood, bone, other, on inorganic. If you specify other or inorganic you also need to specify which other or inorganic material. Other is a hard coded list.

Spoiler (click to show/hide)

Inorganic materials are also specified by their raw names, you can see a list of them by using test.exe's dump materials function.

Stack is used for items that produce more than one item, such as arrows where each job makes 25 arrows.

Once you specify a job, you need to specify which items are produced when the job is done. You can specify 1 or more things here. If you're curious how Foreman views items, you can use the dump items feature of test.exe to see for sure. Furthermore, they are additional categories. Material of all matches all materials, other matches all "other" materials, etc for organic, inorganic, and creature. Creature means it is made from a creature and is useful for bones and such.

There are like a thousand jobs, and they all need to be tested hehe. It isn't that bad though, because we really don't need to support finished goods. The purpose of foreman is to prevent you from running out of stuff, not run your fort for you. You're either making crafts in your fort or you're not, no one ever needs 200 crafts on hand "just in case" lol.

I also haven't implemented subtypes for items yet. Items with subtypes are instruments, toys, weapons, armor, shoes, shields, helms, gloves, ammo, pants, siege ammo, traps, and food. As you see, most of those we don't care about but I already implemented a temporary hack for bolts and I might make one for siege ammo later...

Finally, gems are kind of weird and not really supported but it is irrelevant because I haven't implemented the "make all" feature yet. It would be like a reverse job, it would queue a job for each item that existed so you could automatically cut every gem you have hehe.

If someone worked on this, I could skip to working on new features.

Either way, I can't get much done in weekends so meh.

LoSboccacc · « **Reply #254 on:** April 10, 2011, 12:26:02 am »

Quote

so you could automatically cut every gem you have hehe.

great scott!

News:

Author Topic: Dwarf Foreman 0.7.2 - Tool to automatically dispatch jobs to your workers (Read 113057 times)

devek

Re: Dwarf Foreman 0.6.7 - Tool to automatically dispatch jobs to your workers

LoSboccacc

Re: Dwarf Foreman 0.6.7 - Tool to automatically dispatch jobs to your workers

OzoneGrif

Re: Dwarf Foreman 0.6.7 - Tool to automatically dispatch jobs to your workers

devek

Re: Dwarf Foreman 0.6.7 - Tool to automatically dispatch jobs to your workers

thewonderidiot

Re: Dwarf Foreman 0.6.7 - Tool to automatically dispatch jobs to your workers

devek

Re: Dwarf Foreman 0.6.7 - Tool to automatically dispatch jobs to your workers

thewonderidiot

Re: Dwarf Foreman 0.6.7 - Tool to automatically dispatch jobs to your workers

devek

Re: Dwarf Foreman 0.6.8 - Tool to automatically dispatch jobs to your workers

devek

Re: Dwarf Foreman 0.6.9 - Tool to automatically dispatch jobs to your workers

forsaken1111

Re: Dwarf Foreman 0.6.9 - Tool to automatically dispatch jobs to your workers

Aalto

Re: Dwarf Foreman 0.6.9 - Tool to automatically dispatch jobs to your workers

devek

Re: Dwarf Foreman 0.6.9 - Tool to automatically dispatch jobs to your workers

Aalto

Re: Dwarf Foreman 0.6.9 - Tool to automatically dispatch jobs to your workers

devek

Re: Dwarf Foreman 0.6.9 - Tool to automatically dispatch jobs to your workers

LoSboccacc

Re: Dwarf Foreman 0.6.9 - Tool to automatically dispatch jobs to your workers