Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[eclipsetail]

Mounts!

Yes!

[sweitx]

There's actually a case where it very much matters whether the sieger or the mount is doing the thinking.

LOL!
Damn, I'm going to sig that.

[Lord Herman]

Glad to see DF Talk is back! 

[nenjin]

Martial Arts and Targeted Strikes

HEART PUNCH!

Seriously, that would be hilarious for martial artists to be able to target organs instead of just body parts. Although that might cause issues when all players want to do is run into Kobold warrens and kick them in the genitals to prevent breeding.

Guarding

Is this a framework we might eventually see applied to Shield Use as well? 

It sounds like it's already a little complicated already. Any thoughts as to abstracting it or simplifying it? Such as everyone just having a "guard value" that tries to select the most optimal blocks, and deducts from the guard value per turn when blocks are used? So like, GV 50, left arm blocks head attack, GV -25, right arm shield blocks body attack, GV -25, no GV remaining to block subsequent attacks. Something like that. And then the player could go in and define what their optimal blocks look like. So their best block would be left hand, zone 1, 2nd would be right hand zone 2, and zone three with either hand is their least favorable block. And they could make changes if they get wounded or the situation changes.

So the game would tend to ignore attacks to the legs and leave it up to dodge and/or mitigation. Speaking of, all this blocking procedurally follows after a failed dodge, I assume?

Advanced Skill Sets

I find this idea really cool, but problematic because in Dwarf Mode at least, I already feel a little overwhelmed by the skill list. I agree too that questions about "What does this mean?" make implementation tricky.

Just a couple things: Is it possible to do replacements within the skill list? Say, a character reaches 10 sword skill and it gets replaced with "Fencing?" Assuming that could be done, it might even be like an RPG mechanic. Assuming all the right resources are available, it could go "You have reached Sword Skill level 10. Would you like to choose a specialization? Your currently available options are:......

Secondly, and this just occurred to me listening to the Talk on skills, would it be possible to either a) subordinate some skills to others as they appear on the skill list, b) add headers much like we see in labor assignment to the skill list when we build dwarves for Fort Mode?

So we could see something during Embark that looks like....

LABOR SKILLS:
Carpentry 0
Wood Cutting 0
Farming 0

ect....

COMBAT SKILLS:
Swords 10
    Fencing 3
Axes 0

Something like that.

[nophilip]

Am I the only one who found the "bonus hour" way more entertaining/interesting than the official podcast?

[Jiri Petru]

Amazing! Great this is back, I've been growing impatient and restless. Thanks everyone for the amazing job.

Am I the only one who found the "bonus hour" way more entertaining/interesting than the official podcast?

Yeah, me too. I guess it's because there wasn't much "content" in the official podcast. There were one or two mega-questions that had eaten most of the time, and then there was the art discussion which wasn't very DF related.

Not that I'm complaining. Along with the bonus part we got 2 hours of entertaining and enlightening talk. Thanks again!

[Mephansteras]

I've always enjoyed the talks. Glad to have another one to listen to!

[billw]

On threading:
I guess a hundred other programmers have pointed this out already, but spreading inner loops over multiple threads is a very simple operation. Even the most naive implementation can see decent gains. You have a an operator and a set of data, e.g. operator is "find_next_task", and the set of data is a vector of dwarves and a vector of availableTasks. Instead of just:

Spoiler (click to show/hide)

void find_next_tasks(Dwarf* dwarves, size_t dwarfCount, const std::vector<Task>& availableTasks)
{
  for(size_t i = 0; i < dwarfCount; ++i)
  {
    find_next_task(dwarves[ i ], availableTasks);
  }
}

you have:

Spoiler (click to show/hide)

void find_next_tasks_mt(std::vector<Dwarf>& dwarves, const std::vector<Task>& availableTasks)
{
  std::vector<Thread> threads(MAX_THREADS-1);
  size_t itemsPerThread = dwarves.size() / threads.size();
  size_t remainder = dwarves.size() % threads.size();
  for(size_t i = 0; i < threads.size(); ++i)
  {
    // find_next_tasks must have no modification of global state (including availableTasks), it can only modify dwarves it has been passed.
    // Modifications to availableTasks could be done in a couple of ways, either by generating a list of modifications for each instance of find_next_tasks that is running, or by locking it before modification
    threads[ i ].start_thread(bind(find_next_tasks, &dwarves[i*itemsPerThread], itemsPerThread, availableTasks));
  }
  if(remainder > 0)
  {
    find_next_tasks(&dwarves[threads.size() * itemsPerThread], remainder, availableTasks);
  }

  // waiting for all the threads to finish before we leave the function
  for(size_t i = 0; i < threads.size(); ++i)
  {
    threads[ i ].join();
  }
}

Obviously it takes a few more lines of code, but simple threading can be done safely just following a couple of simple rules: copy all shared data for each thread, and don't access global state from the threaded function.

I wouldn't mention this except that I used to have threading apprehension, but after a bit of messing with it I realised it can be used safely and simply. Also I would like to be able to take off the 100 dwarf / no child / no temperature limits out of my init_d.txt file

[devek]

It isn't that simple lol.

There is overhead to start the thread(or notify the pool). There is overhead when your thread needs to write its result or share any data with anything else. There is even overhead OS scheduler overhead to have the thread run at all.  Sure, it is easy to thread anything... not so easy to actually get gains while very easy to end up with a slower program.... I've taken many a multithreaded program and turned it back into a single thread multiplexed operation just so it would run faster... lol. Furthermore, new processors like the i7 actually reduce the benefit of threading programs like DF that have low thermal loads.

[billw]

I knew someone would pipe up with "its not that simple ". Actually it is simple: if the gains out-weigh the overhead then its a win. You try the naive method, and if you get gains then its good, if not then you need to worry about the more complicated issues or you go do something else. You don't need to start by thinking "this is way to complicated I'm just not going to even try it".
The mistake people make when learning multi-threading is trying to perform complicated asynchronous operations that modify global state when they don't understand the issues involved. Hence I say pick the low-hanging fruit of costly inner loops operating on large data-sets. Hopefully the code is structured to limit global state modification, or can be easily re-factored to this end. In these cases its pretty easy to get a win even if you have the overhead of large data set copies, and quite often EVEN with the overhead of starting fresh threads every time. It doesn't matter that it is non-optimal practice from a multi-threading stand point, only that it takes less time over all. And when you want to squeeze more out of it later, you still have room for optimization and you have already begun the process of re-factoring.

[Capntastic]

This is for DF feedback, not coding talk please.   Multithreading has been discussed in a million other places.

[mnjiman]

This is for DF feedback, not coding talk please.   Multithreading has been discussed in a million other places.

but multithreading is mentioned in the DF talk, so expect people to give feedback on it.

[Capntastic]

Feedback is fine, but arguing about how complex or simple it is to implement isn't really needed.  Toady's aware, I'm sure.

[devek]

Toady is aware, he isn't dumb. Some of the people who keep bring it up, I'm not so sure about

[Capntastic]

There's really no need for calling people dumb, either.