Print

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

[existent]

You misunderstand. What I'm saying is, cakes are delicious. If someone made me one (wink wink nudge nudge, G-Flex) I'd be very happy, and thank them for it. I'd eat my cake, and I'd enjoy it, and I would be pretty damn satisfied.

That said, most days I'm not delivered a freshly baked cake. I'm not angry at the entire planet for not making me a cake.

DF is a game I enjoy playing. When I said it was "done" I didn't mean it literally. I meant, if Toady were to abandon it today and go work on something else, I would still play it. Therefore, anything added past this point is like super-fun icing on said metaphorical cake.

[Deteramot]

Forewarning note: I didn't read the entire first post. I just kinda skimmed to get the gist of the concept. That being said, I suck at skimming things, so I might reiterate something said in the first post.

Disclaimer over, now to the meat of my post:

Personally, I'm a bit of a control freak. I also like to be able to react instantly to problems.

The problem with automation is that it breeds complacency. When something goes out of whack, everything comes crashing down. In order to be able to have an automation work in such a way that it can react to a problem by itself, you would have to set in every single contingency in the script. And that sounds like way too much work for something that's supposed to simplify the process.

Maybe something simple, like being able to set a design for your fortress to be mined out, which already has a periphery (I think. I don't use many peripheries) or a better manager (I personally don't use the manager because I think it's overly complex). At the most complex, something which automatically alerted your military if a dwarf is threatened, or automatically ordered dwarfs inside, but I think that takes away from the challenge (and I don't mean the cliff of difficulty, I mean the challenge of dealing with ambushes and sieges), which is detrimental to the worth of a game.

Just my three (due to inflation) cents.

[existent]

When something goes out of whack, everything comes crashing down.

Welcome to DF.

Maybe something simple, like being able to set a design for your fortress to be mined out, which already has a periphery (I think. I don't use many peripheries) or a better manager (I personally don't use the manager because I think it's overly complex). At the most complex, something which automatically alerted your military if a dwarf is threatened, or automatically ordered dwarfs inside, but I think that takes away from the challenge (and I don't mean the cliff of difficulty, I mean the challenge of dealing with ambushes and sieges), which is detrimental to the worth of a game.

1. There is, although I've never used it.
2. I find DF infuriating without dwarf therapist. I can't do anything on the fly, it takes me 10 minutes if I want to change the labours of every single dwarf, as opposed to 10 seconds with DT.
3. You can automatically send dwarves inside, with the burrow/alert system (I mean, you have to turn it on, but otherwise they just go). Other than that, the only things mentioned were scripting to give you MORE control over the military, not less.

haivng the ability to import and export uniform data or training schedules, so that the scripting can be less time-consuming), we might even be able to finally get some manner of control over military tactics.  Instead of charging enemies, we might have the ability to set up certain dwarves to be "wingmen" who stay in a certain formation (2 tiles to the left side of the squad leader's facing) until battle is met, who will not rush out to engage until fellow warriors are amassed

Finally, I don't blame you for skimming. That was a seriously LONG post.

[G-Flex]

That said, most days I'm not delivered a freshly baked cake. I'm not angry at the entire planet for not making me a cake.

DF is a game I enjoy playing. When I said it was "done" I didn't mean it literally. I meant, if Toady were to abandon it today and go work on something else, I would still play it. Therefore, anything added past this point is like super-fun icing on said metaphorical cake.

I get what you mean, but from the perspective of the game's long-term development, it's very much not the case, and it's sort of short-sighted to say something like that. After all, there were probably people saying/thinking things like that back in 40d, or even the 2D versions.





My main problem with "hey, let's implement scripting!" (as I've gone into in one of the recent FotF threads) is that it's touted as a solution to the game's poor fortress control and automation mechanics, but it's not a valid solution, as for any solution to a real gameplay need to be valid, some kind of effort needs to be made to make as intuitive and well-integrated as possible. A scripting language doesn't really do this.

[existent]

My main problem with "hey, let's implement scripting!" (as I've gone into in one of the recent FotF threads) is that it's touted as a solution to the game's poor fortress control and automation mechanics, but it's not a valid solution, as for any solution to a real gameplay need to be valid, some kind of effort needs to be made to make as intuitive and well-integrated as possible. A scripting language doesn't really do this.

My stance is this: IF scripting is implemented, it'd be stupid to do it now, as it would most likely just get tangled with stuff later.

[NW_Kohaku]

The problem with automation is that it breeds complacency. When something goes out of whack, everything comes crashing down. In order to be able to have an automation work in such a way that it can react to a problem by itself, you would have to set in every single contingency in the script. And that sounds like way too much work for something that's supposed to simplify the process.

Ah, this actually reminds me of something else I meant to have in the original post. 

It would be preferable to also have alerts that could come scripted, as well.

A general alerts script (what general actions trigger alerts) would be the quick way to dispel complaints of "job change" spam in general.  Giving the players the option to make alerts for themselves would also give them some ability to have a fail-safe in case of something going wrong in a script, or if scripting a solution to a problem is more work than a player wants to put in, so that they just make the script warn them when there is a problem, and focus attention in on it.  (For example, removing all the "cancelled job" spam that tends to clutter the alerts screen and go mostly unread, and giving players a warning when you run out of a particular resource, like wood, with options to do things like just make an alert at the bottom of the screen (and option on what color), make a pause and alert, and making a full pop-up alert with recentering.

When something goes out of whack, everything comes crashing down.

Welcome to DF.

Frankly, yes.  Things go wrong that require you to constantly hover over your workshops looking for job cancellations and to rove over your stockpiles or pull up stocks menus to try to manually guage wether you have problems or not.  This gives you some rope to hang yourself with if you aren't careful (which can be said for many things in DF), but also the ability to automate some of the most tedious aspects of the game, like hunting down supply problems.

Finally, I don't blame you for skimming. That was a seriously LONG post.

Not by my standards, nor the standards of some of the other people who give more thorough suggestions (Silverionmox certainly comes to mind).

I think it more a problem of people having too much of an Instant Messenger mentality that they have to get everything out as quickly as possible, and that anything more than a single paragraph is "tl;dr".  While brevity has its virtues, there comes a point where an idea simply can't be clearly expressed without detail.  Some problems in DF just take solutions more complex than "Add ___".

really?  People keep posting responses before I can finish mine...

My main problem with "hey, let's implement scripting!" (as I've gone into in one of the recent FotF threads) is that it's touted as a solution to the game's poor fortress control and automation mechanics, but it's not a valid solution, as for any solution to a real gameplay need to be valid, some kind of effort needs to be made to make as intuitive and well-integrated as possible. A scripting language doesn't really do this.

This smacks a little of the "Perfect Solution Fallacy".  This isn't meant to be a replacement for UI by any means, just a chance to automate some of the tedium, and while it is at it, give the player who is willing to spend the time to get more detailed control that detailed control, without "hurting" any other player for not using it. 

I also argue for UI improvements, but the problem with that is that it runs up against the twin problems of "Toady doesn't want to make the UI more accessable to modding" and "Toady hates doing UI work and doesn't particularly care if that drives away the noobs."  This basically boils down to how much players can pressure Toady into doing one of the two things he doesn't want to do... It is ultimately, however, a totally seperate problem from the one this suggestion is addressing, and it seems a little arbitrary if you say no to solutions to some problems of player control because it doesn't also solve other problems of player control and interface.

My stance is this: IF scripting is implemented, it'd be stupid to do it now, as it would most likely just get tangled with stuff later.

This is another of those things that tends to be said about just about any suggestion that people don't like.  You'd have to say what, exactly, would get "tangled".

[FreakyCheeseMan]

I like the idea- to an extent- but if you're going to go that far, I'd say just make the entire UI open source. Enough of the core game will still be closed that Toady won't have his job security threatened, and you could (I think) get everything you have here, and beyond.

[NW_Kohaku]

I like the idea- to an extent- but if you're going to go that far, I'd say just make the entire UI open source. Enough of the core game will still be closed that Toady won't have his job security threatened, and you could (I think) get everything you have here, and beyond.

Toady has specifically stated that he doesn't want to do that, though.  To generally paraphrase, he says it "would create pressure on him to work with third-party UI makers at updates that might break aspects of the third-party UIs".

Specifically, it seems to be in response to complaints about how people "couldn't play without the SDL" or "couldn't play without Dwarf Therapist" or any of the other third-party improvements.

Again, I'd like this, and I've argued for it, but it's also a completely different argument, and one that would take essentially just players pestering Toady until he some day feels like doing something.

[G-Flex]

This smacks a little of the "Perfect Solution Fallacy".  This isn't meant to be a replacement for UI by any means, just a chance to automate some of the tedium, and while it is at it, give the player who is willing to spend the time to get more detailed control that detailed control, without "hurting" any other player for not using it.

I also argue for UI improvements, but the problem with that is that it runs up against the twin problems of "Toady doesn't want to make the UI more accessable to modding" and "Toady hates doing UI work and doesn't particularly care if that drives away the noobs."

No, the "perfect solution fallacy" is when you claim a solution is bad because it isn't complete. I'm saying it's bad because it has implications that might not even be good.

Also, simply pointing out that a solution is incomplete is not fallacious.

I'm saying that whatever significant problems would be solved by user scripting still would need to be solved other ways at some point. No, this alone doesn't make scripting a bad idea, but I certainly don't think it's the best way to solve those problems, and think that if scripting were implemented before more intuitive methods, it would inspire some unknown amount of backlash and hurt the game's reputation (I go into the reasons why in the above linked thread; people already find the game impenetrable and the new version has already gotten flak in various places for things like the new military screen).


Also, I quite frankly have no idea why you think Toady is more likely to allow arbitrary user scripting than he is to implement a UI for a feature that we already pretty much know will be implemented at some point. "Standing production orders" in particular is even on the new dev page. He does UI work as new features demand it. For example, see, uh, any new feature introduced in .31.x.

This basically boils down to how much players can pressure Toady into doing one of the two things he doesn't want to do... It is ultimately, however, a totally seperate problem from the one this suggestion is addressing, and it seems a little arbitrary if you say no to solutions to some problems of player control because it doesn't also solve other problems of player control and interface.

DF does not exist in a vacuum and work spent on it is not free. If work spent on one solution to the problem could have been spent on a better solution, that's a problem, and if the work spent is judged to drive the game in a wrong direction, that's also a problem.

[NW_Kohaku]

No, the "perfect solution fallacy" is when you claim a solution is bad because it isn't complete.

 

Which was what you were saying. 

My main problem with "hey, let's implement scripting!" (as I've gone into in one of the recent FotF threads) is that it's touted as a solution to the game's poor fortress control and automation mechanics, but it's not a valid solution, as for any solution to a real gameplay need to be valid, some kind of effort needs to be made to make as intuitive and well-integrated as possible. A scripting language doesn't really do this.

Right here, you are arguing against it because it does not solve a problem that it was not intended to solve.  It is not meant to be a solution to UI problems.  It is meant to give players at least some control over what dwarven priorities are without necessarily taking the ham-fisted step of just disabling all other labors (such as when meeting with traders).

Also, simply pointing out that a solution is incomplete is not fallacious.

Pointing out? No.  Saying it was your "main reason" for being against it?  Yes.  That is, it perfectly fits the definition of the fallacy.

I'm saying it's bad because it has implications that might not even be good.

(You mean, you're saying now...) Regardless, the post Toady made in the page you linked to seems the most salient to the discussion (you don't even make any argument against it in that page, are you sure that's the page you wanted?), and he even effectively says "it ultimately doesn't matter, things like magic will require some scripting" and "I was thinking of including scripting in the raws for some of the randomly generated creatures". 

The main problem you seemed to have then (which I don't know why you wouldn't say directly now), is that this would give more player control than you want to give out if a full scripting language were implimented, which isn't exactly what I was suggesting here (although it was what Toady seemed to be thinking of), and that it wouldn't have imposed limitations. 

Honestly, there is nothing to oppose here, then, that can't be opposed in the Standing Orders... which is slated for going in, so this seems like you're using it as some sort of proxy fight over your dislike of Standing Orders, or the ideas tossed out by other people that go further than my own right now.

[G-Flex]

Right here, you are arguing against it because it does not solve a problem that it was not intended to solve.  It is not meant to be a solution to UI problems.  It is meant to give players at least some control over what dwarven priorities are without necessarily taking the ham-fisted step of just disabling all other labors (such as when meeting with traders).

Holy shit, are we having a communication breakdown or what here?

That kind of control is a legitimate need, and I'm saying that need should be addressed in other, more intuitive ways.

Pointing out? No.  Saying it was your "main reason" for being against it?  Yes.  That is, it perfectly fits the definition of the fallacy.

Goddamn, can you even read the rest of what I said, where I actually explain why I'm against it?

(You mean, you're saying now...) Regardless, the post Toady made in the page you linked to seems the most salient to the discussion (you don't even make any argument against it in that page, are you sure that's the page you wanted?), and he even effectively says "it ultimately doesn't matter, things like magic will require some scripting" and "I was thinking of including scripting in the raws for some of the randomly generated creatures".

I don't know if I linked to "the right page" because the discussion went on for at least a few. At any rate, in that quote, it's pretty obvious Toady's not talking about the same applications of scripting that I am.

The main problem you seemed to have then (which I don't know why you wouldn't say directly now), is that this would give more player control than you want to give out if a full scripting language were implimented, which isn't exactly what I was suggesting here (although it was what Toady seemed to be thinking of), and that it wouldn't have imposed limitations.

Not really. My main objection is that there are things the player should have control over as a general rule, and that if the player should have control over something as a general rule, it needs to be implemented in a better way than through custom scripting.

Honestly, there is nothing to oppose here, then, that can't be opposed in the Standing Orders... which is slated for going in, so this seems like you're using it as some sort of proxy fight over your dislike of Standing Orders, or the ideas tossed out by other people that go further than my own right now.

If you think I'm against standing orders, or anything like that, then you've apparently misjudged/misread my arguments so bad that pretty much anything you say is moot, as you're not actually arguing against a damn thing I've tried to argue.

[NW_Kohaku]

Holy shit, are we having a communication breakdown or what here?

That kind of control is a legitimate need, and I'm saying that need should be addressed in other, more intuitive ways.

As ever, yes, you lead to quite frequent total breakdowns in communication, and seem dead-set as ever to refuse to acknowledge any point you don't want to have to admit goes against your argument.

I'm not saying it isn't a legitimate need, I'm saying that this suggestion never was supposed to fix that need, so it's not a problem if it doesn't fix it.

Goddamn, can you even read the rest of what I said, where I actually explain why I'm against it?

Which is why I specifically noted that you were changing the reasoning for your argument entirely, and then switched to arguing against that.  (*harumph!* Did you read the rest of mine?! [/supersillious])

I don't know if I linked to "the right page" because the discussion went on for at least a few. At any rate, in that quote, it's pretty obvious Toady's not talking about the same applications of scripting that I am.

If it wasn't the points that Toady touched on, then it's the "it's too hard to learn to use a full programming language, and people will be FORCED to use it" argument... and, really, virtually everyone else in the thread was capable of making some very good points against that argument, especially Psieye.  This, again, just brings me back to "is this just a proxy argument?"

Not really. My main objection is that there are things the player should have control over as a general rule, and that if the player should have control over something as a general rule, it needs to be implemented in a better way than through custom scripting.

Now you're just making your argument so vague as to be meaningless.  What "things" do players need more control over, and what "better way" are we talking about?  Right now, you're basically just saying that this suggestion is flawed because it doesn't do some "things" that you want that should be done a "better way" than through what my suggestion asks for... which is hardly an argument of any sort.

If you think I'm against standing orders, or anything like that, then you've apparently misjudged/misread my arguments so bad that pretty much anything you say is moot, as you're not actually arguing against a damn thing I've tried to argue.

I'll just respond with this:

If a player has no programming skill whatsoever, standing orders are simple enough to understand that they can just copy/paste from a cookbook or from forum posts if the interface needs syntax care - simple IF ELSE statements are understood even by non-programmers as it's part of everyday logic in life.

This is already far too complex for the average user. A user should not have to look up things in a "cookbook" or on the forum in order to play the game, even for late-game/convenience-oriented things. What you're proposing is infeasible because of this case if for no other reason. If you implement a feature in a game that requires people to look at a script-programming cookbook in order to use it effectively, then you have failed.

Then you are saying that the current version of the game is unsuitable for the average user, due to worldgen params, machinery, the military, underground farming, moods, even the ASCII graphics and pretty much every other regular question that comes our way on the Gameplay subforum. A lot of users can play without looking anything up, simply by figuring things out on their own. But of course, that's not an average user.

Very well, we have laid out our views. Depending on how we interpret the scope of the word "scripting", multiple viewpoints are valid even if we had a common personality and outlook. Let's let this issue stew in the back of Toady's mind and come back to light when standing production orders gets implemented.

Also, don't YOU, of all people, dare to accuse me of not being able to listen to others.  Once again, arguing against something because of valid points that you don't want to acknowledge is not the same thing as just ignoring you.

[G-Flex]

Now you're just making your argument so vague as to be meaningless.  What "things" do players need more control over, and what "better way" are we talking about?

Workshop automation (standing production orders and things like that) is the obvious answer that I can think of off the top of my head. The better way would be, for instance, some sort of screen/interface in the game geared toward that purpose, such that people can set conditions for actions (and the actions themselves) in a friendlier manner without having to muck about with learning how to do any scripting.

[NW_Kohaku]

Workshop automation (standing production orders and things like that) is the obvious answer that I can think of off the top of my head. The better way would be, for instance, some sort of screen/interface in the game geared toward that purpose, such that people can set conditions for actions (and the actions themselves) in a friendlier manner without having to muck about with learning how to do any scripting.

Ummm... once again, that is scripting.

I'll say again what I said about the interface before:

I really just don't trust Toady to make an intuitive interface, no matter how ideal, so I think the best way to handle it is to have an import/export option to go along with whatever interface Toady gives us (which would be nice just to have a "save this script for the next fortress I play" utility, like with the "export/import uniforms" suggestion), so that we can have third-party utilities that would let us slap a GUI on top of a .txt file.

We could wind up with something simple and cartoonish and based on color-coded drag-and-drop interface where you build lines out of a library of fill-in-the-blanks plus some words to fill those blanks (again, color-coded) where rearranging priorities on jobs is as simple as loading the script up, dragging a priority up three slots, hitting save, and re-importing the script.

I'm not in any way saying "just give us a console so we can add Python to DF", which is where some of that in the other thread went.  I'm all for having limitations on what can be achieved, at least so far as not letting people do the macros for digging out whole sections of fort automatically (of course, that already exists...) I'm just saying that we could intigrate the Standing Orders with a jobs priority system so that we could have the ability to stop some of the "stupid" behaviors of dwarves that require micromanagement with a once-and-for-all solution through a script if the player so chose.

[NW_Kohaku]

Actually, G-Flex, on the off chance that this is the cause of your confusion...

You do realize that "scripting languages" come in more flavors than just things like Java or Python right?  The raws are a script, and are interpretted by the game at worldgen or whenever you load a save.  Military orders are scripts.  Heck, job queues are scripts.

Scripts can, and in the case of anything but those Java or Python languages, often do have specific limitations on the sorts of commands that can be put into them, as any other sort of command simply will not be interpretted.

This brings back the comparisons to mechanics and megaprojects - it's great to give players the power to make turing devices or fully functional calculators if they really want to through the use of nothing but the "script" that is built into a set of gears, pressure plates, pumps, and some water.  It does not, however, give them any control over anything more dire than what can be hooked to a mechanism.