Print

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

[ggeezz]

I'm fairly new here, as in less than a year or so.  I kept asking a question for the talks about making the interface more pliable, but I didn't realize that was something that's been thoroughly discussed and settled.

I was thinking of a different angle though.  I know some people desperately want stellar graphics and dialog boxes and such, but I feel right at home in ascii.  Me. . . I long for a way to save a digging or furniture placement pattern, to write a script for trading, effectively manage skills and jobs and such.

So while I completely understand why Toady doesn't want the game becoming fragmented, nor to have to support third party developers, I think some things can be accomplished without risking those downsides.  But I thought I would bring up the issue here to see what you guys think.

Here's what I'm thinking.  Suppose the game supported some commands like:

designate code x1,y1,x2,y2

which would mark the rectangle for whatever the code means, ex. digging or channelling.  If Toady ever wanted to deprecate that for any reason, then the command wouldn't do anything.

It seems to me if the game supported things like this, the tools using the interface would be things that would help you play the game, rather than becoming the game you play.  In other words, you'd use this interface to help you do things that make sense in the game.  If the game changes in such a way that it no longer makes sense to dig a rectangle, then I would have no desire to use a tool that helps me dig rectangles.  I would want to use a new tool to do whatever new thing you do in the game.

Does this make any sense?

[Andir]

Are you talking about some sort of "dwarfscript?"
For instance, you hit some key combo, a command window opens and type DIG1,1,Z>64,64,Z and it would designate a Dig order from 1, 1 on the current Z level to 64, 64 on the current Z?  If you did this, then you'd want a way to chain load them to create other shapes, so you'd likely do something like:

DIG1,1,Z>10,10,Z
RAMP1,1,Z-1>10,10,Z-1
SAVE twostory10x10
EXEC twostory10x10
CLEAR

Dig - designate a dig order
Ramp - designate a dig ramp order
Save - save current command buffer (the orders since last clear) to file
Exec - execute current command buffer or optional file (auto clear command buffer after execute)
X, Y, Z - variables relative to the cursor, if numbers used, it's absolute to deploy area
Clear - resets the command buffer and ready for new buffer (wipe memory, clean slate... whatever you want to say...)  This would not cancel executed orders... Maybe an execute would return an order number that you can issue CANCEL 334 to cancel order 334?

Of course, the orders would be carried out from First to Last (FIFO) until complete than the next line would be queued up to alleviate the dreaded channel self into corner problems.

Though, I'm sure this has been brought up, bashed to pieces by a hundred people, and dropped into the bowels of the forum somewhere...

Disclaimer:  the above is just my quick brainstorm on the idea.

[dragon0421]

I'd like to see the interface become less complex and counter intuitive, not more. Adding some weird pseudo code does not appeal to me at all, and I can only see it intimidating new users more than what we already have.

[Sowelu]

I'd like to see the interface become less complex and counter intuitive, not more. Adding some weird pseudo code does not appeal to me at all, and I can only see it intimidating new users more than what we already have.

Players would never see this stuff.  It's a hypothetical interface for mod projects.

It still suffers from the same problems it always has:  An established protocol is a hindrance for developing DF the way Toady wants to.  If he makes big changes, and it takes a while for people to update the third-party programs, and players decide not to stick with the latest version of DF (and not donate) because of that...well, that's bad.

[Janus]

Correct me if I'm wrong, but I seem to recall something along these lines being included in the d16 test release and therefore being slated for inclusion in the upcoming major release.

EDIT: yeah:

* You can create keyboard macros

[ggeezz]

It still suffers from the same problems it always has:  An established protocol is a hindrance for developing DF the way Toady wants to.  If he makes big changes, and it takes a while for people to update the third-party programs, and players decide not to stick with the latest version of DF (and not donate) because of that...well, that's bad.

It depends on how it's done and what you allow.  Suppose you're just passing text back and forth with the commands.  That would never "break."  What would happen is that commands (or codes) would be deprecated because they don't make sense anymore.  And then when you sent those commands nothing would happen.  Suppose there was a set of commands for trading and in the future trading fundamentally changes in some way that all of the commands are deprecated.

Toady's concern, as I understand it, is that some interface will come along that people love and it will either fragment the game or Toady will have to support it.

But suppose there's some tool that helps with trading (and digging/building/whatever) and some part of it becomes deprecated because of changes in the game.  I wouldn't want the deprecated part of that tool to work because that's not part of the game anymore.  I would want to interact with the new trading system.  In the beginning I would have to use the in-game tool and maybe later there'd be a new tool for that.

The important thing would be that players have a mindset that they're using a tool to play Toady's game, rather than that they're playing a different kind of game.

Of course, some people may still want the old tool to work, but that would have nothing to do with the interface.  They would want the old trading system, which is an issue Toady faces every time he changes something anyway.

The way I see it, some things would have to be off limits.  Like you couldn't have an interface to change the way the game is displayed.

[Andir]

It still suffers from the same problems it always has:  An established protocol is a hindrance for developing DF the way Toady wants to.  If he makes big changes, and it takes a while for people to update the third-party programs, and players decide not to stick with the latest version of DF (and not donate) because of that...well, that's bad.

It depends on how it's done and what you allow.  Suppose you're just passing text back and forth with the commands.  That would never "break."  What would happen is that commands (or codes) would be deprecated because they don't make sense anymore.  And then when you sent those commands nothing would happen.  Suppose there was a set of commands for trading and in the future trading fundamentally changes in some way that all of the commands are deprecated.

Toady's concern, as I understand it, is that some interface will come along that people love and it will either fragment the game or Toady will have to support it.

But suppose there's some tool that helps with trading (and digging/building/whatever) and some part of it becomes deprecated because of changes in the game.  I wouldn't want the deprecated part of that tool to work because that's not part of the game anymore.  I would want to interact with the new trading system.  In the beginning I would have to use the in-game tool and maybe later there'd be a new tool for that.

The important thing would be that players have a mindset that they're using a tool to play Toady's game, rather than that they're playing a different kind of game.

Of course, some people may still want the old tool to work, but that would have nothing to do with the interface.  They would want the old trading system, which is an issue Toady faces every time he changes something anyway.

The way I see it, some things would have to be off limits.  Like you couldn't have an interface to change the way the game is displayed.

In all honesty, I've thought of that as well, and that's my fear/hope (yes, both) that something does get established.  Toady could concentrate on his world, those that know and do interfaces could make their own and with a "dwarfacto" standard setup, people could theoretically make their own "world servers" with their own rules that work with interfaces designed around Toady's game.  He can study the competition and decide what elements to compete on.  Of course, it could scare him off and DF would be halted (the fear aspect) but I'd hope he stepped up to the challenge and started concentrating on the stuff he does well (story, world) and brought more Dwarfiness to those that want it...and less debates on what tilesets, interface issues and other nonsense that pops up.

[Lav]

Correct me if I'm wrong, but I seem to recall something along these lines being included in the d16 test release and therefore being slated for inclusion in the upcoming major release.
EDIT: yeah:

* You can create keyboard macros

Unfortunately the functionality to create keyboard macros is extremely user-hostile. You spend a lot of time navigating enormous menus, then you try the macro and find out that you made a mistake in one of early designations so you have to delete everything and start from scratch.

I once suggested a much easier interface for macro creation but the idea didn't get acceptance.

[Asmodeous]

I long for a way to save a digging or furniture placement pattern, to write a script for trading, effectively manage skills and jobs and such.

Oh man what I wouldn't give to be able to designate a dig pattern to become a "stamp" for the mouse pointer, so that when making bedrooms I could run up a couple I want, and then just "Click-click-click-click-done".

[lucusLoC]

in my opinion we need dig templates, not macros. dig templets will be universally useful, no matter what direction the game goes, and since the file save would be difficult to depreciate (it is just a storage format, the parsing is separate and in game, and is free to change with the game without affecting the format) and the designation is handled by the default interface (also in game) just like all the other commands the community would be free to come up with a huge list of designs that could be designated and used. if you use the robust templet storage as fleshed out earlier you could even use it to help manage a fortress, as it includes a framework for designating stockpile defaults and such.

true this would not help you very much in a trade window (unless you count the helpfulness of having a "trade stockpile" designated in only a few key presses) but it would vastly simplify fort construction.

thread here: http://www.bay12games.com/forum/index.php?topic=39304.0

[ggeezz]

in my opinion we need dig templates, not macros. dig templets will be universally useful, no matter what direction the game goes, and since the file save would be difficult to depreciate (it is just a storage format, the parsing is separate and in game, and is free to change with the game without affecting the format) and the designation is handled by the default interface (also in game) just like all the other commands the community would be free to come up with a huge list of designs that could be designated and used. if you use the robust templet storage as fleshed out earlier you could even use it to help manage a fortress, as it includes a framework for designating stockpile defaults and such.

true this would not help you very much in a trade window (unless you count the helpfulness of having a "trade stockpile" designated in only a few key presses) but it would vastly simplify fort construction.

thread here: http://www.bay12games.com/forum/index.php?topic=39304.0

I agree that dig templates are on the best examples.  And I can't think of how that would lead to the sort of situations that Toady wants to avoid.  It's just a question of programming time which is a scarce resource.

And since Toady is a scarce resource I wanted to foster discussion on finding the "right" solution, i.e., the solution that protects Toady's interests and also gives us the most bang for our buck.

And this is just a wild guess really, but I'm thinking that supporting the commands I described above would give us more bang for the buck, while also protecting Toady's interests.

[sweitx]

In short, having any sort of API (which the topic poster is essentially suggesting) will place limit on how much the change a program can make before the API itself deprecate.  Imagine an API existed for the old 2D fortress, do you think we can get a 3D without essentially scrapping the entire API?

I think this is why Dwarf Fortress is still in Alpha.  There are a lot of changes that Toady One is planning and he's trying to limit additional, unneeded stumbling blocks as possible (for example, having an API).

I can already see a problem with the new version with utilities like Dwarf Companion unable to support for some time (looking at the changes, it looks like there a significant amount of changes that will require a major rework of Dwarf Companion).

[lucusLoC]

i reread your previous posts, and i still have to disagree. let me go over why, and please correct me if i misunderstand or misconstrue.


(also please don't take this in a harsh way, the comparisons are just a fast and simple way to do this.)
______
your idea:

1. some sort of CLI for the interface, that third party apps could interact with.

2. this interface would support commands for all (or most) windows in the game (e.g. trade, construction, military, job assignments etc.)

my idea is:

1. a save file for templates that would allow a player to save any possible designation the game is capable of (e.g. constructions, furniture, workshops, stockpiles, traffic zones, waypoints, etc.)

______
your way adds a second interface to the game

my way does not
______

your way allows for scripts to control almost every aspect of the game

my way only allows for you to "save" that awesome automatic bridge and trade depot entrance design so you can use it in your next fort
______
your way assumes 3rd party developers writing interfaces that would have to be updated by them when a revision came out

my way assumes that a player could update their own save files when a revision came out
______
you way could lead to a broken app when commands are depreciated

my way simply leads to an incomplete construction if a designation is depreciated
______
my way has precedent in that it is like a raw file for designations

your way has no precedent
______
my way is required anyway if we want a robust ai

your way would not benefit the ai (that i can see anyway)
______

in short, your way is more powerful, more complicated and possibly leads to some of the problems that Toady wants to avoid.

my way is less powerful, simpler, is required anyway and has precedent in the way raw files are currently handled.

And this is just a wild guess really, but I'm thinking that supporting the commands I described above would give us more bang for the buck, while also protecting Toady's interests.

for many of the reasons i described above i emphatically disagree with this statement, but the number one, most important reason i disagree is tat we need a template storage solution for the ai anyway, and once we have that it would be trivial to extend it to the player. and yes i understand that a "building script" could be exposed to the ai, but i think that would be a less robust solution than having a script engine simply access a building template file (assuming we get scripting in the future).

a building template solution should be kept separate from a scripting solution because they are different things, and we need a building template solution now, while a scripting solution is more of a luxury.

[ggeezz]

In short, having any sort of API (which the topic poster is essentially suggesting) will place limit on how much the change a program can make before the API itself deprecate.  Imagine an API existed for the old 2D fortress, do you think we can get a 3D without essentially scrapping the entire API?

I think this is why Dwarf Fortress is still in Alpha.  There are a lot of changes that Toady One is planning and he's trying to limit additional, unneeded stumbling blocks as possible (for example, having an API).

I can already see a problem with the new version with utilities like Dwarf Companion unable to support for some time (looking at the changes, it looks like there a significant amount of changes that will require a major rework of Dwarf Companion).

I've never played the 2D version so I don't know exactly how much changed.  But if you were designating rectangles, then yes the interface would remain exactly the same.  What would change is that some codes (or types of designations) would be deprecated and some would be added.  A utility for the 2D version would still work, it's just that commands with the old codes wouldn't do anything.

But more fundamentally, a designation utility designed for the 2D game probably wouldn't make sense for the 3D game.  It would be obsolete.  If you want to play a 3D game, you need a utility designed for the 3D game.

Skill designation is a good example too.  Dwarf companion is going to need a lot of work, precisely because there is no interface such as I have described.  If the interface is designed well, it could last for a very long time.  You could add/delete skills/professions, and add/delete skill levels, but the interface would remain the same.  You would just be adding and deleting codes.  The parts of your skill/profession manager that are still valid would just work and the obsolete parts would silently do nothing (or probably write the error to a log).  If you want to take advantage of the new stuff, it would need to be added, but it wouldn't be a big deal.

And what happens in the future if skills and professions are radically changed, as in you no longer assign professions and dwarfs don't have skills at various levels.  Then the api and anything built on it would become obsolete.  Why would you want to assign professions when that's not a part of the game anymore?

[ggeezz]

@lucasLoC

I'm not sure what the best way to implement this interface would be.  CLI is the first thing I came up with, but I just know that it needs to be loosely typed and not strongly typed functions.  The latter would create headaches, since things would break when an int becomes a double, etc.  And since the game is coded in C/C++, I can't think of a better way than a CLI, a la Autocad.

I do NOT think Toady should allow access to every part of the game.  Instead, he could determine which parts you can access, which are off limits and what exactly you can do.  If he wants to avoid fragmentation then he should limit the things we can access.

But consider this.  Many people think you need Dwarf Companion to make the game playable (for large forts).  By creating an interface to support DC, Toady reduces the demand for a better interface, making fragmentation less likely.

And while "my way" assumes 3rd party developers, I don't think that's a bad thing.  Even if we went "your way" I think it'd be nice to have a 3rd party tool to help you design patterns.  And what 3rd parties do, Toady doesn't have to.

If implemented as I described our ways would be the same as far as breakability.  If a designation/code is obsoleted then the command doesn't do anything.  If a command is in an improper format, it doesn't do anything.  If a designation is removed, we'd both get incomplete constructions.

To sum up, I like your way.  And we probably do need it anyway for more robust AI.  But it only solves part of the problem.  If you want something like Dwarf Companion you need to use my way.  And rather than making those "problems Toady wants to avoid" more likely, I think supporting DC would make them less likely because there's less incentive to make a complete, alternative UI or a clone of DF if more people are satisfied with the available tools.