Print

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

[Squirrelloid]

The point is that we shouldn't have to rely on third-party utilities for such an important purpose. I'm sure we all agree that managing a large fortress without Foreman is a complete nightmare. While the separate-window utilities do work, we have to worry about them possibly corrupting memory or saves, and of course they need to be updated for every new version. And I personally far prefer to play DF full-screen on a widescreen monitor than in a window, so am forced to either play it in a window or constantly switch out. It also breaks immersion since the Foreman windows look so completely different from the DF UI.

Given Foreman already exists, it shouldn't be too hard for Toady to create hooks in DF that would let it access the information it needs (and then Foreman could be recoded to use those instead of memory hacking).  This would be a positive change.

Foreman could always be coded to look like DF.  It could even be coded to be platform independent.  And once you slave DF and Foreman to a parent program or script that calls them both, they're basically the same program in any real sense, they just work in 2 windows.

The only thing this requires from Toady is he implements a way for another set of code to access the relevant data while DF is running, and to be able to make changes to that data while its running.  This is far more likely than Toady incorporating Foreman into his code and updating it every version release (just another thing that can go wrong)

Basically, working as a mostly distinct set of code would seem to be an advantage.  And being controlled by a separate developer would also seem to be an advantage because that developer can do his own bug fixing so foreman becomes functional faster in a new version.  The only thing that prevents the real illusion that it is two programs right now are appearance and the memory hacking - only one of which requires Toady's assistance to fix.

I'm not sure what this mythical 'part of the program' thing means - a program is just a collection of code.  If you write a script that starts DF and Foreman together, then you are essentially treating them as the same program.  (Maybe this is a difference of perspective, but plenty of programs have multiple distinct components that are only unified as code by being called by the same parent script.)

[The Glock]

  This thread needs more attention!

So Valdemar, do you have an actual prototype DF v.31 with this implemented in the game? If yes, can you post a download link of it?

[immibis]

Of course he doesn't. I'd be really surprised if anyone but Toady, ThreeToe and Baughn had access to the relevant source code.

[Rafal99]

So Valdemar, do you have an actual prototype DF v.31 with this implemented in the game? If yes, can you post a download link of it?

Read the first post again.
What he did is a program in Javascript that immitates how that screen would look like in DF. There is nothing else except what you can see on that screen, you can use keys and see how stuff changes, but there is no actual dwarves, or any actual game logic there.

[KFK]

Given Foreman already exists, it shouldn't be too hard for Toady to create hooks in DF that would let it access the information it needs (and then Foreman could be recoded to use those instead of memory hacking).  This would be a positive change.

Maybe I'm thinking of something else, but hasn't Toady often expressed apprehension about accommodating 3rd party interface tools? I seem to remember him saying that too much can change, and too much has to change from release to release that thinking about this now isn't practical. But I could be way off here.

[Atanamis]

Maybe I'm thinking of something else, but hasn't Toady often expressed apprehension about accommodating 3rd party interface tools? I seem to remember him saying that too much can change, and too much has to change from release to release that thinking about this now isn't practical. But I could be way off here.

Yes, he's expressed almost exactly that sentiment several times. Something like this suggestion that pulls the essential controls back inside the game would be great. Most people might still use the third party utilities, but they wouldn't be as necessary as they are at present. This is a gorgeous mockup, and it would be cool it it were added.

[Draco18s]

Excellent mock up.

Added this thread to the Eternal Voting item.

[Footkerchief]

I don't find the two-letter abbreviation for the labor name at all readable -- the DF interface already has too many cryptic elements that require memorization.  Otherwise, I'm all in favor.  Toady has resisted concepts like this on the grounds that they're spreadsheet-like, but a) the healthcare screen is already a spreadsheet, b) it's a completely natural way to manage something like this, and c) the alternatives all suck.

Running the utility in a separate window would be gross, however -- it's aesthetically unappealing and doesn't work for people who like to play games in fullscreen.

[Draco18s]

I don't find the two-letter abbreviation for the labor name at all readable -- the DF interface already has too many cryptic elements that require memorization.

Agreed, but once I realized what I was looking at, it wasn't too bad.

Then again, this is the default 80x25 grid view, adding more grid height reduces the problem (once we can get non-map screens to resize usefully).

[Squirrelloid]

Running the utility in a separate window would be gross, however -- it's aesthetically unappealing and doesn't work for people who like to play games in fullscreen.

I'm not sure i follow, plenty of applications have multi-window displays, and this is generally a positive.

Further, the game's full-screen resolution is what, 800x600?  My monitor hasn't been that small since 1993.  If nothing else, people with two monitors can full screen and use a second window with no problem.

Some thinking about how multi-windowing the full screen could work as a full screen display.  The main play area would be a 'window' or section of the screen in the upper left corner extending to somewhere near or beyond the center of the screen.  Foreman could be on the right side from top to bottom, and some other useful utility could fill the lower left area that is still open.  Possibly the current command layer could display there instead of on top of your map area, and you could issue commands without pausing the game.  (so if you go to mine the mining designations menu pops up in the bottom 'window'.

This isn't too unlike how a game like Civ IV divides up its screen space - there is a main play area surrounded by other windows with useful information, game controls, and so on.  And since DF's best resolution is far smaller than modern screens, it would seem the issue for 'full screen' users would be maintaining the illusion that the game is occupying the full screen.  Or really, if DF + Foreman did occupy the full screen, of convincing the user that it really was all the game.  (Foreman really is a part of the game if you're using it - pretending otherwise is like drawing lines in the sand).

Edit: Regarding Toady's willingness to create hooks for applications like Foreman: if he's unwilling to take a simple measure like making hooks, what makes you think he'll make the effort to fully incorporate it into the game?  Making hooks is vastly easier, and will involve less tweaking on his part as the code develops.  If he won't allow programs like foreman to hook into DF, he's certainly not going to try to implement Foreman himself.

[Valdemar]

Running the utility in a separate window would be gross, however -- it's aesthetically unappealing and doesn't work for people who like to play games in fullscreen.

I'm not sure i follow, plenty of applications have multi-window displays, and this is generally a positive.

Further, the game's full-screen resolution is what, 800x600?  My monitor hasn't been that small since 1993.  If nothing else, people with two monitors can full screen and use a second window with no problem.

Some thinking about how multi-windowing the full screen could work as a full screen display.  The main play area would be a 'window' or section of the screen in the upper left corner extending to somewhere near or beyond the center of the screen.  Foreman could be on the right side from top to bottom, and some other useful utility could fill the lower left area that is still open.  Possibly the current command layer could display there instead of on top of your map area, and you could issue commands without pausing the game.  (so if you go to mine the mining designations menu pops up in the bottom 'window'.

This isn't too unlike how a game like Civ IV divides up its screen space - there is a main play area surrounded by other windows with useful information, game controls, and so on.  And since DF's best resolution is far smaller than modern screens, it would seem the issue for 'full screen' users would be maintaining the illusion that the game is occupying the full screen.  Or really, if DF + Foreman did occupy the full screen, of convincing the user that it really was all the game.  (Foreman really is a part of the game if you're using it - pretending otherwise is like drawing lines in the sand).

Edit: Regarding Toady's willingness to create hooks for applications like Foreman: if he's unwilling to take a simple measure like making hooks, what makes you think he'll make the effort to fully incorporate it into the game?  Making hooks is vastly easier, and will involve less tweaking on his part as the code develops.  If he won't allow programs like foreman to hook into DF, he's certainly not going to try to implement Foreman himself.

What you're proposing sounds like a complete interface overhaul with all the sub-windows. While it could work, it's something that would take a lot of coding.

My monitor is 1280x1024, and I have DF set to expand the grid to fill all of it. With 16x16 custom tiles, it's quite beautiful. As I've said before, if I want to use Foreman, I either need to set it to the far uglier windowed mode or constantly switch back and forth. Either ruins the immersion. Additionally, Foreman has  the aforementioned problems of having to be constantly updated and possibly corrupting memory.

Toady has rejected the idea of hooks for custom interfaces because he feels that it takes the game out of his hands, a reasonable decision. But that's almost exactly what is happening right now without the hooks, with a huge number of people relying on Foreman.  Toady adopting ideas from utilities into the core game is not unprecedented. Remember Regional Prospector, the utility that revealed magma/rivers/HFS on the region map? It was a practically essential tool for a while, until Toady rolled it (and more) into the core game with the Site Finder.

I don't find the two-letter abbreviation for the labor name at all readable -- the DF interface already has too many cryptic elements that require memorization.

Agreed, but once I realized what I was looking at, it wasn't too bad.

Then again, this is the default 80x25 grid view, adding more grid height reduces the problem (once we can get non-map screens to resize usefully).

Have you tried expanding the abbreviations with Tab? The four-letter abbreviations are more understandable, though it remain a bit difficult to read due to the vertical aspect. It shouldn't be too much of a problem though, since the full name of the professions are always shown in the the blue detail region. Along with the colors, one should be able to get used to them fairly quickly.

Some of the abbreviations could probably be better, though. I can't really judge what's easy to understand since I came up with them, so does anyone have any in particular they think should be changed?

[Steely Glint]

Toady wants to maintain control over his project. I understand that desire, and fully support it.

I agree with most of the people here that I would not like it in a separate window, and I want it to be part of the same executable and written by the same programmer.

I've played a lot of Angband, and have never once used multiple windows. I prefer to play games like DF/Angband with one very large window, so I can see the maximum possible amount of the game world.

[Squirrelloid]

Toady wants to maintain control over his project. I understand that desire, and fully support it.

I agree with most of the people here that I would not like it in a separate window, and I want it to be part of the same executable and written by the same programmer.

I've played a lot of Angband, and have never once used multiple windows. I prefer to play games like DF/Angband with one very large window, so I can see the maximum possible amount of the game world.

How do you play Angband with only one window?  Its painful.  Having inventory and monster information in other windows is so much nicer.

I also don't recall being able to change the amount of 'world' you can see - but its been quite awhile since i've played Vanilla and they might have changed that aspect of display.

[Valdemar]

I also don't recall being able to change the amount of 'world' you can see - but its been quite awhile since i've played Vanilla and they might have changed that aspect of display.

In DF (don't know anything about Angband), you've been able to change the amount of world displayed using the [GRID] setting in init.txt for a long time now. It was definitely present in 40d, which was released over a year ago. It doesn't affect the menus, though.

[Alloy]

I was about to suggest this myself, based on the health interface, but I see I was beaten to the punch by a superior example. Definitely in favour of something like this so I can manage my dwarfs more easily. I share the disdain for spreadsheets but in this case it is a necessary evil. (Mouse control to enable/disable labours would also be really, really nice.)

The only modification I would make to the original suggestion is to put it on the Status Menu next to Health, so: Z -> Labours, since that's a more logical place for 'overview' interfaces like this.