Print

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

The new channeling is covered in awesome sauce, the old channeling smelled real bad.

113 (19.3%)

The old channeling was the best, we don't need two ways to make ramps it is just silly.

245 (41.8%)

Old channeling was the best, new channeling is also the best.  Can't we all just get along?

132 (22.5%)

You people need to get on with your lives, it's not a big deal either way.

96 (16.4%)

Total Members Voted: 583

[Pickled Tink]

Then make it require braces. Just doing it with a pick is quite silly; breaks my suspension of disbelief. Breaching a body of liquid is not trivial, so it shouldn't be trivialized just like digging any old trench. The issue will be addressed again with "realistic mining" in any case.

So you can't possibly imagine that as part of mining/channeling, your dwarves use braces, because you didn't tell them to?  How do you deal with the fact that 1 tree gives you a log that can be used to build a 10 foot section of wall?  That digging through soil leaves no dirt/clutter?  The fact that your dawrves eat, drink, and sleep what, once or twice a season?  That there's no damp/warm stone designation for water/magma flows that you cause?  Not requiring 3 extra designations (dig partial, brace, complete dig, remove brace) to breach a liquid seems like a strange place to draw the line of "this needs to be realistic!".  Not to mention, as has been stated, you would need to brace the wall while using the current version of channeling to breach a liquid.  Does it break your suspension of disbelief that you can do that?  Since there's no bracing of walls, do you sacrifice a dwarf any time you want to breach magma, since you don't have the proper commands to tell him how to realistic do it without incinerating himself?

And since it's going to be addressed in the "realistic mining", why are we stuck with "partial realism" that doesn't allow us to reach realistic end results?  Are you going to not breach liquids until the realistic mining is added so it doesn't break your suspension of disbelief?

I'm actually not opposed at all to the practical measure (putting in the old channeling as well, for the time being). It's mostly about the principle: when something new doesn't work out as an improvement on all fronts, you don't immediately clamor for the old one. Additionally, you don't shoot down something new for something trivial like a flashing ramp that's aesthetically uncomfortable.

An impressive strawman there. Placing that last there as if to imply that is all that those opposed to ramped channels have against it. My hat is off to you. or it would be were I wearing a hat, which would be strange indoors and at 4am like it is now. But I ramble.

The objections to the new channels have been made clear a great many times. On every page of every thread on the matter.

1: Cannot channel into freezing aquifers without losing dwarves
2: Dwarves pathfind through channels containing or about to contain hazardous materials and flows, resulting in dwarf loss at the least and fort loss in the most extreme cases.
3: Dwarves have no trouble channeling a floor out from under themselves now, which has resulted in many of mine falling to their deaths.
4: Ramps look bad.
(There may be more I have missed because I am growing tired of the dead horse beating that is this topic of discussion)

Seriously. All the "we want to keep the current channels" crowd has done is fixate on #4 at every opportunity, and only ever pay attention to #1-3 when their noses are rubbed in them. Stop pretending they don't exist when it doesn't suit you.

I know you probably don't deserve the rant, but it needs saying.

[Sean Mirrsen]

And we're trying to rub your nose on the facts that your #1-#3 items are bugs, and can be fixed in due course as the bugfix releases are made, as opposed to the reversal you want, which may be undesired at this point as it may break more things than it fixes. Ergo, actually making the new channels workable may be faster and safer than restoring old channels, not to mention more prudent in the long run.

(I'm not qualified to say whether or not it's actually faster though, I'm merely guessing. So, have it this way - If old channels can be restored while keeping new ones and without breaking anything, let them be. If they cannot be safely restored, or if doing so would remove the new channels, the new channels should rather be fixed instead. Deal?)

[Squirrelloid]

And we're trying to rub your nose on the facts that your #1-#3 items are bugs, and can be fixed in due course as the bugfix releases are made, as opposed to the reversal you want, which may be undesired at this point as it may break more things than it fixes. Ergo, actually making the new channels workable may be faster and safer than restoring old channels, not to mention more prudent in the long run.

(I'm not qualified to say whether or not it's actually faster though, I'm merely guessing. So, have it this way - If old channels can be restored while keeping new ones and without breaking anything, let them be. If they cannot be safely restored, or if doing so would remove the new channels, the new channels should rather be fixed instead. Deal?)

Emphasis added.

So stop arguing it then.  You're wrong.  Its not faster to fix the bugs.  I can guarantee it.  Anyone with 2 weeks of programming experience could guarantee it.

[Sean Mirrsen]

I have more than 2 weeks of programming experience. From this experience, I can tell that altering functions is liable to introduce bugs. Especially since in this case simply "reverting" will not do - one or the other designation will have to become a separate command. I am "not qualified" only in the most direct sense - I have no idea how deeply the channel designation is rooted into DF code. For all we know it could be a jury-rigged mess of a subroutine with callbacks to AI and pathfinding classes made from its own designation function. If it's just a parameter set for a "catch-all" function like DFort.UI.Designate(int[] paramArray), then swapping it out or adding a new designation wouldn't be a problem at all.

[Lord Darkstar]

And we're trying to rub your nose on the facts that your #1-#3 items are bugs, and can be fixed in due course as the bugfix releases are made, as opposed to the reversal you want, which may be undesired at this point as it may break more things than it fixes. Ergo, actually making the new channels workable may be faster and safer than restoring old channels, not to mention more prudent in the long run.

(I'm not qualified to say whether or not it's actually faster though, I'm merely guessing. So, have it this way - If old channels can be restored while keeping new ones and without breaking anything, let them be. If they cannot be safely restored, or if doing so would remove the new channels, the new channels should rather be fixed instead. Deal?)

Restoring the old channels will be trivial, and won't cause any new bugs. It was a change of code from using the channel behavior to calling into the "dig upramp +1 level down from current z level". Reverting that ONE LINE OF CODE back to calling the old code won't be over 5 minutes of work at most (that's with Toady going back to the previous stored version to pull back that code from his source control archives), restores functionality, and improves the gameplay for DF players. Adding a "designate->down ramp" to keep the same functionality available (for those strip miners and other excellent uses) will take a bit longer.  That might eat up between another 5 minutes to a day of Toady's time, depending on how DF is set up, and how involved Toady gets moving things around on his menus.

We are ALREADY waiting on the "bug fix" concerning defenses. The fix being: Siege arc.

Drilling into liquids (including aquifiers) is awaiting the "bug fix": more detailed/realistic Mechanism arc.

AI pathing is going to be a long, long, long lasting problem.  It is ALREADY awaiting Toady to fix it. It has been awaiting that fix since the earliest version of DF.

Dwarves not digging realistically is ALREADY awaiting the bug fix: more detailed mining.

By your own logic, this change of channelling should be reverted. Indeed, by your own logic, you have demonstrated that we shouldn't even get "Designate down ramp" until we get to the final couple of arcs (presentation arc, and general polish and improvement). Because that is where it fits into the roadmap and the "bug fix" plan.

Honestly Sean, I don't get why you keep digging yourself in. Your own logic says you should be on the side for reverting the change (and adding in designate down ramp to make strip mining easier) OR demanding that the rest of mining "gets more realistic" and have the miner move into every square he works when done at a MINIMUM. Are you Toady in disguise/sock puppeting so you can directly interact with your fans without having them go super fanboy and just drool and coo at you? Is that why you just keep digging in deeper and deeper on this? You cannot otherwise be that married to ONLY have new channelling.

[CaptApollo12]

I have more than 2 weeks of programming experience. From this experience, I can tell that altering functions is liable to introduce bugs. Especially since in this case simply "reverting" will not do - one or the other designation will have to become a separate command. I am "not qualified" only in the most direct sense - I have no idea how deeply the channel designation is rooted into DF code. For all we know it could be a jury-rigged mess of a subroutine with callbacks to AI and pathfinding classes made from its own designation function. If it's just a parameter set for a "catch-all" function like DFort.UI.Designate(int[] paramArray), then swapping it out or adding a new designation wouldn't be a problem at all.

Knowing toady it is a subroutine or function that does exactly that. Today would have changed it or added a new one or even copied most of the code from up ramps. Also toady would have backups with the code from 40d. It would be safe to assume copy pasta of code with 5 minutes of changes. (even search and replace!)
Logically

[Sean Mirrsen]

Me? Digging? Hell no.

You must be misreading my logic somewhere. I'm saying the actual bugs could be fixed instead of plain reverting to the old channelling so they can again be circumvented. I'm also not pro-realism, unless it's in favor of the game. What I've been saying for the last couple of pages is essentially this: "Keep the new channelling, but make it work like the old channelling." That is, make it stop causing random deaths from normal operation, and allow the OCD people have their clean channels easier. That's all. My arguments against even bringing the old thing back were just one - "The reason for the change made sense, so no sense just changing it back."

Except, in this later post, I've proposed a compromiss solution - if Toady thinks it's worthy of his attention, let him decide:

If bringing back old channels can be done while keeping the new channels and the game unbroken, let them be brought back - I'll back down from my position on the anti-siege fix. After all, I'm only one player. (and so far, the only one bothering to actively defend the new way) Otherwise, if it'll mean removal of the ramped channelling or if it's going to require excessive effort, then my opinion remains the same - it would be better to improve the present system than trying to revert.

Then there's also the problem of choosing what to revert as what. One side will want d-h to make pits, the other will want it to make ramps. Just to push the discussion away from the pointless topic we can't get a consensus on: which would you prefer? Or tolerate? I'd find it more fitting if the old channels were moved to d-p, for 'P'its, since that's what they are.

Oh, and you should definetly pitch the "alter-ego" idea to Toady. Seeing how effective I was at creating the impression, he'll likely do a much better job.

[Squirrelloid]

Do you know how hard bugfixing AI is?  Do you have any idea whatsoever?

I expect to see improved siege behavior (buggy as hell, but present) before i expect to see these AI pathfinding bugs fixed. 

Regarding designation names: old channeling actually, you know, makes channels, and should retain 'h'.  Call the new one strip mining or dig down ramp or whatever.

[Sean Mirrsen]

No, I don't. It so happens AI is my weakest programming point. On par with databases.

However, I don't believe a simple counter to these very specific issues with magma and freezing aquifers is going to be so hard. After all, it's a matter of a one-tick delay after the job has been done. If the dwarf pauses for 1 tick after digging the ramp, this will not have a tangible effect on his average digging speed. But in that tick, the magma will occupy the ramp and the aquifer will freeze, putting the dwarf out of harm's way.

[Lord Darkstar]

Sean Mirrsen, we have reached a concensus. Revert to old channelling system. Concensus is when the MAJORITY of a group support the same idea. In this case, the majority of players (that answered the poll) support bringing back the old system.

I think the new channeling behavior should be set to designate-down ramps. The only real problem is that you designate down ramps from same level, up ramps from the LOWER level. THAT difference will be confusing to newer players.
 
And that one tick wait before moving into channeled square? Your dwarf is STANDING on the ramp when he gets caught. Remember, he's "in the ramp square" because he's been working in the square to finish the work of digging. And that's death for many conditions. If the dwarf ISN'T in the target square at the end of the dig, then he should NOT be auto-charging/auto-walking into it after the work is done. See the problem with your solution? It calls for channelling to work like before, only leaving a ramp behind on the first pass instead of possibly a stone and empty tile, rather than how up ramp digging actually works. If we have that, then we just have ANNOYING blinking triangles when breaching (although most pathfinding issues remain, thanks to a new ramp being just one tile away). And if the miner isn't in the tile while "digging down" because it is "more realistic", then why would he ever need to enter it at all?

[DarthCloakedDwarf]

Channelling is ideal now, since we no longer need to micromanage it. You don't want ramps? [d]-[z].

Under the old system, miners trapping themselves and then causing themselves grievous bodily harm was just something you had to live with. Now? No longer need to worry.

[Andir]

Channelling is ideal now, since we no longer need to micromanage it. You don't want ramps? [d]-[z].

Alright, I've cleared all the ramps from my newly dug watering hole... now my dwarf is trapped and can't get back out.  How do you clear the ramps, and keep the dwarf accessible?

[Tarran]

Channelling is ideal now, since we no longer need to micromanage it. You don't want ramps? [d]-[z].

Alright, I've cleared all the ramps from my newly dug watering hole... now my dwarf is trapped and can't get back out.  How do you clear the ramps, and keep the dwarf accessible?

... And it's not like it takes a whole year just to dig a tunnel to the channel, remove the ramps, and wall up the tunnel! ...

Amazing, I made the answer to that question before it was even asked.

[Andir]

Channelling is ideal now, since we no longer need to micromanage it. You don't want ramps? [d]-[z].

Alright, I've cleared all the ramps from my newly dug watering hole... now my dwarf is trapped and can't get back out.  How do you clear the ramps, and keep the dwarf accessible?

... And it's not like it takes a whole year just to dig a tunnel to the channel, remove the ramps, and wall up the tunnel! ...

Amazing, I made the answer to that question before it was even asked.

Now I have a bunch of manufactured walls that don't match the surrounding rock.  It looks out of place and not natural.  Previously, I could just channel it out... now this complicated process... seems like adding more work.

[Tarran]

Well, that's why we have mega-projects, since there's usually to little work!