Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 2 [3]

Author Topic: Sometimes losing isn't fun...  (Read 4168 times)

Man In Zero G

  • Bay Watcher
    • View Profile
Re: Sometimes losing isn't fun...
« Reply #30 on: May 08, 2010, 02:59:39 pm »

I think you guys (other then the OP) seem to think that its a GOOD thing that you cant actually do anything with a game because of trapped dwarfs trying to do tasks that they will never be able to reach.
Really, it can be a bug even IF theres some absurdly micromanage-y method to repair the problem.

But, see, you can do something with the game. All those interruptions and suspended construction alerts? Those are the game telling you, "Hey, there's some dwarves assigned to stuff they can't do, you should decide what to do about that." Then you can go turn off those dwarves labors, rescue them, or rage because the game isn't playing for you.

Quote
However, disabling every. last. labor.  on a large pool of intentionally trapped dwarfs, just to get the remaining group of dwarfs to get any work done, is inescapably boring. It feels unnecessary to any logical entity that they should have to disable a dwarfs wall making ability if he is stuffed into a small stone box so that wall-making isn't constantly and intermittently interrupted.

Why would you ever, ever, intentionally trap a large pool of dwarves and leave a bunch of labors on that they will be unable to do? What possible logic is there in making a dwarf incapable of completing a task, and yet leaving the instruction for the game engine to assign that task to the dwarf? So you stuff a dwarf in a stone box, but you keep telling the game "he's a mason", and are upset because it's assigning mason jobs to him that you've prevented him from doing? Again, this is a failing of the player, not the system.

Quote
It shouldn't be the players responsibility to baby every singe dwarf through every little situation, such as being trapped in a cave full of monsters, and in the process completely incapacitating the entire fortress.

The only control we have over the average dwarves at all is which labors they have activated. So, switching off the ones they shouldn't be attempting isn't really babying them, it's playing the game. Managing your dwarves is a core element of the gameplay. Just because a few get out of your sight and get themselves trapped and cause what is honestly a temporary inconvenience, is no reason to declare the entire system broken. Especially since, as I pointed out, there are more than enough ways to keep it from even happening accidentally. And if you're causing the situation on purpose, what logical reason could you possibly have for not preparing for it properly?
 
I think a lot of the problem here is, most of the people in this thread have been talking about the specific incident that happened to the OP, while a few are talking about the game in general. The OP made a massive blunder, as has been pointed out by others, in that he did not restrict his dwarves from the battlefield or forbid the dead soldier's corpses and stuff, so half his fort went after dead dwarf belongings. Then he walled them in. I'm sure this did cause massive job cancellation spam, I'm sure it was annoying, but again, the root cause was his own fault, and once he saw what happened, it was an easy enough fix, but instead he abandoned. Annoying, yes. Easily fixed, also yes. The OP even realized it after the fact, and said so in his post!
In retrospect, if that was indeed the problem, maybe I could have fixed it by turning all the tasks (including haulage) off for the stranded dwarves.  It's OK, I guess, the fort was too stable and boring and that point anyway - I got into trouble in the first place because I was constructing a magma pump stack from level 7 to level 120, and I dug into an unseen cavern on the way up.  That's the sort of project you undertake when there's nothing much else to do.
The only bug here was the unkillable beast the soldiers were fighting in the first place. A lot of the argument in this thread has really been with people disagreeing that the OP's tactical blunder put him in this position in the first place, and then bitching about the engine not fixing it for him.
But it isn't the fault of the engine here, at all. Because, see, if you don't tell your dwarves to do something impossible, they won't try to do it. The OP just had an exteme case of this situation, is all.
« Last Edit: May 08, 2010, 03:03:57 pm by Man In Zero G »
Logged
Quote from: Toady One
Their lack of eyes should stop them from crying.
Quote from: Toady One
Just watching dwarves make poor decisions repeatedly as I fix their little minds...
Quote from: Toady One
I haven't checked since I'm not doing bugs until after the release (well, I'm doing bugs, in the additive sense).

shadowform

  • Bay Watcher
    • View Profile
Re: Sometimes losing isn't fun...
« Reply #31 on: May 08, 2010, 03:14:20 pm »

The only bug here, I think, is in the game trying to force dwarves to perform jobs they cannot path to, then canceling the jobs when they can't path to them.  The pathfinding check should be performed during job assignment, not after.
Logged
Q: What do you get when you take 100 clear glass windows, 1000 silver bars, 6700 gold bars, and 18,000 marble blocks?

A: A very large wall.

"Alright, here's Helltooth... Harborfence... Urist, come get GenericBlade... and you. Welcome to the Danger Room. First timers get good ol' Ballswallowed. Have fun and try not to take off your own toe."

QuakeIV

  • Bay Watcher
  • Cant resist... must edit post.
    • View Profile
Re: Sometimes losing isn't fun...
« Reply #32 on: May 08, 2010, 03:17:51 pm »

Deathworks, i agree there should be consequences for trapping dwarves in holes, but random job cancellations as the engine loops over them and tries to give them jobs sure is a strange way to do it.



Oh, we don't consider it a good thing. But we do consider it an easily fixed problem, and bitching about it on the Internet instead of fixing it is a stupid and juvenile thing to do.

Yes, turning off everyone's labors would be boring. Sorry this game isn't non-stop fun-time action all the time. But that's how it is, so suck it up and wait for Toady to fix it when he feels like it.

Dude, thats a perfectly good point, if this werent supposed to be a game.  Games are supposed to be fun.

They arent about 'fixing the problem' like in real life, the whole point is to escape from that for a bit.

It makes sense to reflect real life, but this is obviously a bug, not some kind of metaphor for reality.
« Last Edit: May 08, 2010, 03:26:05 pm by QuakeIV »
Logged
GENERATION 9: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social experiment.
I wish my grass was emo, then it would cut itself.
Quote from: Jesus
Quote from: The Big Fat Carp
Jesus, you broke the site!
Sorry, Bro.
link to quote

Deathworks

  • Bay Watcher
  • There be no fortress without its feline rulers!
    • View Profile
Re: Sometimes losing isn't fun...
« Reply #33 on: May 08, 2010, 03:27:17 pm »

Hi!

Well, it is a strange way, I agree, but since the announcement gives you the name of the affected dwarf and even allows you to jump to his/her location (at the time the announcement was made, though) as far as taking care of the problem is concerned, it is sufficient, I believe. I mean, it tells you that there is something wrong with dwarf XYZ so that you can take care of that. And pathfinding cancellations virtually always mean that you as the player want to check on what is going on.

Anyhow, I just hope that all players enjoy playing the game in the end despite the occasional bugs and the quirks it has here and there. Hopefully, even our greatest defeats can eventually be looked at in retrospect with a nostalgic smile.

Deathworks
Logged

QuakeIV

  • Bay Watcher
  • Cant resist... must edit post.
    • View Profile
Re: Sometimes losing isn't fun...
« Reply #34 on: May 08, 2010, 03:37:20 pm »

The only bug here, I think, is in the game trying to force dwarves to perform jobs they cannot path to, then canceling the jobs when they can't path to them.  The pathfinding check should be performed during job assignment, not after.

At this point, ditto.
Logged
GENERATION 9: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social experiment.
I wish my grass was emo, then it would cut itself.
Quote from: Jesus
Quote from: The Big Fat Carp
Jesus, you broke the site!
Sorry, Bro.
link to quote
Pages: 1 2 [3]