Jump to content

Duplicants and their retarded sense of consequence,


Recommended Posts

Duplicants have no sense of consequence and effect and often get resources out of reach or get themselves killed because they has awful sense of awerness. First of all, let's talk about digging.

Ideally, when you select a square block to dig straight down into, it should look like this.

←←←←←←←←

→→→→→→→→

←←←←←←←←

→→→→→→→→

But instead of taking the obvious choice of digging one layer at a time, they dig in all sorts of weird places, making it harder than it need to be. And that's just an example. There's no rhyme or reason to their randomization. We need an option to make is so that they only go for the ones that are closest to them. And another thing. Just give us the option to click to select all of one kind on screen. Having to click my planter pots one by one to seed ain't fun. It'd also be so awesome if you could click on a certain type of resource two times and it selects all of that resource on screen. 

Second, if you try to remove the bottom layer of a floor and you're above say a deep water mass and then add on a new layer of floor as you go, then the duplicants are almost guaranteed to fall down and get themselves killed. They should not be automated to do things that kills them. They should not remove any kind of tile or block that somebody who can't move away from it is standing on. If I have a stranded dupe then I don't want them dead because somebody though "lemme just remove that block with a stranded person on it, great idea". This needs to be fixed.

 

Quote

There's no rhyme or reason to their randomization. 

Erm, I'm pretty sure they just choose the closest one.

Anyway, your alternative suggestion is often just as bad or worse, depending. Like, for example there's a cave underneath the first layer in the middle of the zone you designated. Dudes digging the top layer first would start digging, the next guy would walk forward while he's working to go at the next part of that layer, then get stranded on the other side of the newly formed gap. If not falling to his doom, even (as you pointed out later in your post. Could disallow, but stranding would still occur, and flooding would still occur and blah blah blah)

There is no simple pattern like that that would ever work reasonably in all situations. If you want them to never get themselves in trouble, they would have to do a lot of complicated global pathfinding and logical crap every single tile. Which may likely slow the game down, and would also make it less zany.

1 hour ago, Crimeo said:

Erm, I'm pretty sure they just choose the closest one.

Anyway, your alternative suggestion is often just as bad or worse, depending. Like, for example there's a cave underneath the first layer in the middle of the zone you designated. Dudes digging the top layer first would start digging, the next guy would walk forward while he's working to go at the next part of that layer, then get stranded on the other side of the newly formed gap. If not falling to his doom, even (as you pointed out later in your post. Could disallow, but stranding would still occur, and flooding would still occur and blah blah blah)

There is no simple pattern like that that would ever work reasonably in all situations. If you want them to never get themselves in trouble, they would have to do a lot of complicated global pathfinding and logical crap every single tile. Which may likely slow the game down, and would also make it less zany.

Nah, I wish they did. They could be digging at something that was 2 tiles ahead instead of something that was one tile above them. There's also nothing bad about streamlining simple tasks. Sure, I could prioritize layers so that they will dig in a logical sense. It isn't bad wanting them to have a little logic on their own. I said it'd be an optional things anyways, options are a good thing. As for the pattern, here's one: always dig in such a way that every tile is accessible. Say that I wanna remove a 8x6 block of resources. Ensuring that they never remove so much so that the cannot climb up to the top until it's done is programmable and should be. It's be as if you pit a bunch of staircases on top of each other then remove them one by one starting up. Allow me to illustrate.

It starts like this.

▉▉▉▉▉▉▉▉
▉▉▉▉▉▉▉▉
▉▉▉▉▉▉▉▉
▉▉▉▉▉▉▉▉
▉▉▉▉▉▉▉▉
▉▉▉▉▉▉▉▉

it now looks like this.

▉▉▉▉▉▉
▉▉▉▉▉▉
▉▉▉▉▉▉▉
▉▉▉▉▉▉▉
▉▉▉▉▉▉▉▉
▉▉▉▉▉▉▉▉

Then like this 

▉▉▉▉▉
▉▉▉▉▉
▉▉▉▉▉▉
▉▉▉▉▉▉
▉▉▉▉▉▉▉
▉▉▉▉▉▉▉

And so on, until it eventually looks like this.



▉▉
▉▉
▉▉▉
▉▉▉

At this point, you climb to the top and remove this part


Then this part

▉▉
▉▉

And finally this part

▉▉▉
▉▉▉

The entire block is now gone.This process can and should be programmed in, We live in 2017. These kinda things is what I'm asking for.

Sure, I could make them do this but it'd require a lot of micromanagement just to remove some blocks. The important pattern is, top to bottom, always maintain a way down. It's just have to respect the 2 tile climb rule.  

 

Also, having duplicants not killing each other and themselves through sheer stupidity is not a blah blah matter. it's a pressing concern.

 

 

 

 

 

Quote

Sure, I could prioritize layers so that they will dig in a logical sense. 

My whole poitn was that this method ISN'T "more logical" than the rule they use now of "pick the closest one." 

There will be some cases where one is better. There will be other cases where the other is better.

Example where close is better: If there's a lot of noxious gas in the area, then digging the closest thing is often better, because they get more done without wasting time walking back and forth holding their breath, which they'd do more of in your typewriter method in the first post. And because the source area they come from is more likely to be oxygen rich than the part of the dig furthest from it.

Example where typewriter is better: You've given some already, when somebody might get stuck on top in an uneven dig order shape.

Example where your newly mentioned sideways typewriter is hot trash terrible: When there's no solid floor under the block of stuff you specified, then using your most recent algorithm would make the whole left half completely inaccessible almost immediately. Womp womp, try again! (In this case, top down typewriter would have worked, but too bad since you already abandoned it since earlier!)

There exists no one simple pattern that is "best"

It has nothing to do with the year 2017. It has to do with the fact that this game does not exist in a clean, unobstructed, infinite solid grid of hazard-free, uniform material as you are oversimplifying it to be.

1 hour ago, Crimeo said:

My whole poitn was that this method ISN'T "more logical" than the rule they use now of "pick the closest one." 

There will be some cases where one is better. There will be other cases where the other is better.

Example where close is better: If there's a lot of noxious gas in the area, then digging the closest thing is often better, because they get more done without wasting time walking back and forth holding their breath, which they'd do more of in your typewriter method in the first post. And because the source area they come from is more likely to be oxygen rich than the part of the dig furthest from it.

Example where typewriter is better: You've given some already, when somebody might get stuck on top in an uneven dig order shape.

Example where your newly mentioned sideways typewriter is hot trash terrible: When there's no solid floor under the block of stuff you specified, then using your most recent algorithm would make the whole left half completely inaccessible almost immediately. Womp womp, try again! (In this case, top down typewriter would have worked, but too bad since you already abandoned it since earlier!)

There exists no one simple pattern that is "best"

It has nothing to do with the year 2017. It has to do with the fact that this game does not exist in a clean, unobstructed, infinite solid grid of hazard-free, uniform material as you are oversimplifying it to be.

Optional OPTIONAL! is that word not in your vocabulary? The point is to make digging out chunks that are more than 4 tiles high easier. Yes, it's situational, yes it can backfire, duh. You're basically saying "making a task easier to do in the exact same fashion is bad" - just... WHAT?

And again, what's so impossible about making dupes NOT get themselves stuck on things, or making each other fall to their deaths?

As for the gas thing, so you're saying it's better to dig the bottom out first and miss out on resources above you. Got it. Uh, btw, you do know that oxygen rises, right? Assuming that it's a solid chunk with no holes around it, which, again, is the scenario suggested, oxygen would rise with you as dig it out in a stairwell fashion leading UP. So no, dupes wouldn't need to run back all the time. Even if they open a gas pocket on the way up, the massive amounts of oxygen following you is gonna keep it breathable long enough for your dupes to finish up without having to run back all the time.

And no, nobody is gonna get stuck on the top. As long as you dig in a stairwell fashion whith each "step" being no more than two tiles high, there's always a way down. And again optional. Could be bound to a hotkey. Specific function for a specific purpose. We got a ton of those as is, how can one more be a bad thing?

the only thing i want from this is so they dont dig blocks if they cant get out of the area(if there is no breathable oxygen).

edit: other than that dont change any of the current digging mechanics because i like them how they are.

12 minutes ago, DrBrobotnik said:

what's so impossible about making dupes NOT get themselves stuck on things, or making each other fall to their deaths?

Not impossible, but very time consuming for programmers, because you basically have to make like 10 algorithms and 40 special exceptions and check all of them in some slow, complicated flowchart, but without slowing the game down somehow depite doing thousands of checks per tile for all possibilities, etc.

Quote

Optional OPTIONAL!

This doesn't help much. If you take those same 10 algorithms and 40 exception rules and give an options menu for them instead of complex flowcharts and brute force, 99% of players will have no damn idea what it is or is for, or even if they do, aren't realistically going to go reset the options every dig they do for the one optimal algorithm each time. So dupes will still kill themselves when the options inevitably go unused. And programmer just wasted a ton of time if so.
 

Quote

 you do know that oxygen rises, right?

Nope, depends on the gas. Oxygen falls when you strike hydrogen. It rises when you strike chlorine. Again, two different algorithms needed, one size does not fit all. And 99% won't ever choose the options to optimize for situation. So again, oversimplifying and you killed dupes as a result.

Not that the current way is much better, but it has a huge advantage: it already exists...

1 minute ago, Crimeo said:

Not impossible, but very time consuming for programmers, because you basically have to make like 10 algorithms and 40 special exceptions and check all of them in some slow, complicated flowchart, but without slowing the game down somehow depite doing thousands of checks per tile for all possibilities, etc.

This doesn't help much. If you take those same 10 algorithms and 40 exception rules and give an options menu for them instead of complex flowcharts and brute force, 99% of players will have no damn idea what it is or is for, or even if they do, aren't realistically going to go reset the options every dig they do for the one optimal algorithm each time. So dupes will still kill themselves when the options inevitably go unused. And programmer just wasted a ton of time if so.
 

Nope, depends on the gas. Oxygen falls when you strike hydrogen. It rises when you strike chlorine. Again, two different algorithms needed, one size does not fit all. And 99% won't ever choose the options to optimize for situation. And again, oversimplifying and thus killing dupes still if done your way only...
 

Okay, guess I need to say this in clear text. The optional part is for the digging pattern only. It'd be the same drag and click as with priorities.

Guess why it's optional? Because it isn't always the best, obviously, never said it is either. It's just streamlined digging to maximize resource gain. If you want to dig precise paths with respect to hazards that you'd rather keep containted then god yes, bad idea. Obviously.

No single thing in this game is the best in 10/10 situation. Everything is situaional. I don't see why you'd think anyone would suggest something that isn't. 

And you can say what you want, but I'm pretty sure a lot of people are tired of dupes digging the floor out beneath each other and getting themselves trapped in carbon pits and in stupid places. Klei should do SOMETHING about it. 

3 minutes ago, mr_anderson said:

last time my dupe got stuck i tried to get him out but messed up again and ended up killing 6 dupes in that one hole

Also gotta love when you tell them to make a ladder and dig out resources in a 4x2 pattern and one of them somehow got himself stuck on top.I wish they'd focus down tiles together, because what happens is that one guy digs out a rock then climbs to the next one that another guy is digging out and then climbs higher to save himself from a fall and promptly gets stuck. 

Quote

The optional part is for the digging pattern only. It'd be the same drag and click as with priorities.

And you'd need to have like 10-20 different optional patterns to cover all situations usefully (otherwise one or two only would barely ever matter since each is best only like 5% of the time). And 99% of people again would be utterly confused and have no idea why or when to use them and probably feel frustrated with the learning curve.

That's a huge programmer investment in exchange for very little gain for few players and possibly even a negative impact on most players if unduly confused and frustrated.

Automating all 10-15 algorithms would neither confuse nor frustrate but would take astronomically more programmer time too. Tough call.

10 minutes ago, Crimeo said:

And you'd need to have like 10-20 different optional patterns to cover all situations usefully (otherwise one or two only would barely ever matter since each is best only like 5% of the time). And 99% of people again would be utterly confused and have no idea why or when to use them and probably feel frustrated with the learning curve.

That's a huge programmer investment in exchange for very little gain for few players and possibly even a negative impact on most players if unduly confused and frustrated.

Automating all 10-15 algorithms would neither confuse nor frustrate but would take astronomically more programmer time too. Tough call.

Well the real problem is probably the fact that the dupes digs out the ground that other dupes is standing on to dig other blocks. My idea would work just great if everybody focused down one block at a time, but since whoever gets there first starts on his own block, that nobody else mines with him it's really freaking random. Makes me wish they could focus dig and build, or maybe only dig onoccupied blocks. Hey, there's an idea!

And Klei is silly loaded because Don't Starve was a mega success and is still hella popular so they got the resources to do it. I think they want streamlines, non-frustrating gameplay as much as I do. Also, I think I get what you're saying. Because the dupes doesn't care if somebody is standing on the block they're working on, you'd need a lot of programming just to make digging a square out streamlined in all situations, or indeed making simultaneous removing and building of two layers of floor work smooth.

Hmmm yes, that does seem pretty weird. Still tho, you were being a bit of an ass about it at first, guess I got a bit mad. Sorry for the hassle tho. 

Quote

Makes me wish they could focus dig and build.

Sure, I can't think of many ways this could be bad. But it also fails to solve any of the problems you mentioned in your OP. It's sort of just an entirely separate problem.

 

Quote

Because the dupes doesn't care if somebody is standing on the block they're working on, you'd need a lot of programming

That's one of a dozen or two dozen things that cause you to need a lot of programming. A short list of other examples of things that make it require a lot of programming:

  • Holes breaking up the space and complicated pathfinding around it to avoid stranding.
  • Breathability expected and thus whether to prioritize short hauls.
  • Whether air is expected to fill in partway through or not. Very difficult to program this prediction, but it makes the above example useless or not,depending.
  • Is the encountered gas heavier or lighter than oxygen, which flips all your algorithms around, but not in a simple way. Oh no, we aren't that lucky, because gravity DIDN'T flip. So the algorithms change in very non-linear ways.
  • Expected reachability of every tile. This is NOT as simple as just "go in rows of 2." Because up to 4 can be reached on the top row, for example, And any non-square dig area pattern dramatically changes the ways you'd have to do it to always be able to climb as well. If your dig area slants upward, that would require a totally different algorithm than yours to do that.
  • Whether or not the dig order includes replacement with ladders or tiles or just plain digging. This obviously very much affects the algorithm for subsequent dig order, and usually all three types are ordered simultaneously in complicated patterns.
  • Will dupes end up standing on tiles being dug? Even if dupes cancel digging when a dupe stands on a tile, you now need to also implement logic to avoid infinite loops -- what if there are two tiles and two diggers, and they each start digging, then each stand on that, cancel each others' digging, then try again to start digging, stand on each other, cancel again, forever and ever (or even just some absurdly inefficient 60 seconds or something = VERY bad)
  • What if you have red alert turned on? How should all of these algorithms change since red alert is defined as "do your jobs without regard to safety?" This effectively doubles the entire programming job.
  • What happens if a narcoleptic falls asleep on the one tile you need to dig to stop your base flooding with magma RIGHT NOW?
  • Is there water above the tiles being dug? How do we deal with that? Do we ignore it? DO we have an entirely different algorithm from any of the above (read: SET of algorithms, actually) to implement complex logic to try and breach those tiles last?
  • What if you have the top tiles hitting water AND also 5 tiles high dig area? Now you have a conflict between the goal of "don't dig in a way that makes you unable to reach the top" vs "don't dig the tiles that flood until last" Logic = ERROR, need a brand new algorithm (or SET of algorithms). Yayyyy.... *bang head on desk*
  • What if the player WANTS to flood with the first tile dug? The program cannot read minds. How does the algorithm know whether the player intends this area to become a "water basin" vs. "future living room" -- a hole looks like a hole to the computer algorithm. Is it supposed to predict player psychology too? 

 

...Having written out just some of these, I take it back: I'm updating my estimate to 100+ algorithms needed.

20 minutes ago, Crimeo said:

Sure, I can't think of many ways this could be bad. But it also fails to solve any of the problems you mentioned in your OP. It's sort of just an entirely separate problem.

 

That's one of a dozen or two dozen things that cause you to need a lot of programming. A short list of other examples of things that make it require a lot of programming:

  • Holes breaking up the space and complicated pathfinding around it to avoid stranding.
  • Breathability expected and thus whether to prioritize short hauls.
  • Whether air is expected to fill in partway through or not. Very difficult to program this prediction, but it makes the above example useless or not,depending.
  • Is the encountered gas heavier or lighter than oxygen, which flips all your algorithms around, but not in a simple way. Oh no, we aren't that lucky, because gravity DIDN'T flip. So the algorithms change in very non-linear ways.
  • Expected reachability of every tile. This is NOT as simple as just "go in rows of 2." Because up to 4 can be reached on the top row, for example, And any non-square dig area pattern dramatically changes the ways you'd have to do it to always be able to climb as well. If your dig area slants upward, that would require a totally different algorithm than yours to do that.
  • Whether or not the dig order includes replacement with ladders or tiles or just plain digging. This obviously very much affects the algorithm for subsequent dig order, and usually all three types are ordered simultaneously in complicated patterns.
  • Will dupes end up standing on tiles being dug? Even if dupes cancel digging when a dupe stands on a tile, you now need to also implement logic to avoid infinite loops -- what if there are two tiles and two diggers, and they each start digging, then each stand on that, cancel each others' digging, then try again to start digging, stand on each other, cancel again, forever and ever (or even just some absurdly inefficient 60 seconds or something = VERY bad)
  • What if you have red alert turned on? How should all of these algorithms change since red alert is defined as "do your jobs without regard to safety?" This effectively doubles the entire programming job.
  • What happens if a narcoleptic falls asleep on the one tile you need to dig to stop your base flooding with magma RIGHT NOW?
  • Is there water above the tiles being dug? How do we deal with that? Do we ignore it? DO we have an entirely different algorithm from any of the above (read: SET of algorithms, actually) to implement complex logic to try and breach those tiles last?
  • What if you have the top tiles hitting water AND also 5 tiles high dig area? Now you have a conflict between the goal of "don't dig in a way that makes you unable to reach the top" vs "don't dig the tiles that flood until last" Logic = ERROR, need a brand new algorithm (or SET of algorithms). Yayyyy.... *bang head on desk*
  • What if the player WANTS to flood with the first tile dug? The program cannot read minds. How does the algorithm know whether the player intends this area to become a "water basin" vs. "future living room" -- a hole looks like a hole to the computer algorithm. Is it supposed to predict player psychology too? 

 

...Having written out just some of these, I take it back: I'm updating my estimate to 100+ algorithms needed.

Okay. I admit that it'd be a ***** to do. But I hope for at least improvements. 

2 hours ago, BreadProduct said:

Guys. Guys. Just set the dig arrangements by priority. It takes like 3 seconds.

This, seriously the like rare situations where it actually matters what order blocks are dug out, it is really simple to use the priority system to make sure it is done right.

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...