Bay 12 Games Forum

Regarding placing rooms, there is a point where removing complexity actually removes control over the game. If you want to build your fortress in one key press... you are going to have no choice as toward what your fortress will look like, and that isn't any fun. The problem with auto-building rooms is that sizing the room is very important to be in the players hands. It is possible to have rooms with no walls that don't overlap, and overlap decreases the value of the rooms. Even creating a burrow then replacing it with the room is incredibly misleading. It tells the player "You've just built a bedroom" that they will then THINK does something, but in reality it does nothing, or worse. Burrows mess up workshop and stockpile use. Therefore, making a bedroom into a burrow changes how the stone in that burrow is used. Recording the building to be built then building it later shares the problem of having done nothing until a bedroom is placed.

YAY, THIS IS AWESOME!
I am a programmer, but not familiar with this code specifically.
However, from what I can see, (1), and (3) should be easily do-able. Just make the macro of key-presses bigger, it shouldn't be much more complicated than that. Well, that depends on whether Mouse Fortress lets you send key presses to Dwarf Fortress, or DFHack only. The problem with (2) is that I don't know if you can create a bedroom without a bed. You could have a weird set of macros that waits until the bed is built, then converts it into a bedroom, but what size should the bedroom be? Or, where should the bed be, in your bedroom? Both are decisions that might be best made by the player, but that's just my opinion. All of this is from my knowledge of macro programs similar to (but not) Mouse Fortress.

One big question I have, where is the code for Mouse Fortress(if it is open source)? (I don't know how to open a lot of stuff) Um never-mind... I think I found it. I'll have to take it for a little spin to be sure.
This is SO EXCITING! I'm going to try Jiri Petru 's 8th page GUI. All I need to do is find out how to display the buttons. I feel like either Space Core from Portal, in Space, or the spaceship guy from The Lego Movie building a space ship.

ROFL I've used AutoHotkey before.

"Trying to get Mathig to look."
I looked at it the first time and mentioned it directly in my post. Aside from my comment concerning it, it is irrelevant.

Quote from: Mathig on July 13, 2014, 07:37:38 pm

Paraphrasing someone else, why hasn't someone simplified this massive debate so that new players can find the current status on the issue? I mean most of the threads are morons flaming someone for bothering to ask the question. Sure, the last time someone asked the question a flame war happened, but starting a flame war to prevent a flame war is hardly logical.

Ok, You have a point there. There isn't a faq about it, just countless topics that the newbies are usually instructed to read when this comes up. And please understand that this and "why not multithread" comes up a lot, and the answer is always the same, and after the umpteenth time it's a bit annoying, that's one of the reasons for the flamewar...this week this is the 3rd time someone wants to beat the dead horse. damn, we really need a faq.

and wine:
No, virtualization is not the answer, especially not because the number one reason for fortress abandonment is fps death. virtualizing, starving the game of resources will make that worse. And no, there is no 100% efficient solution, that's a myth.
And if I understand right what you propose it has been already accomplished, it's called dfhack. there are lot's of UI tweaks that come with it, practically any memory structure can be manipulated/overwritten/whatever...IF you have the skill and the patience to figure out how to do it.You can think of it as an unsupported/unofficial API that tend to get broken with every new release.

Virtualization does have one flaw, and you named it. However it illustrates precisely the fix we need. The fix is to replace Dwarf Fortress's menu system, and map system, with a new map and menu system. The new one having better GUI, obviously. If Stonesense works as described, that proves the map can be overhauled. It literally is a map overhaul, and apparently it relies on DFHack which is even better. All that remains is the menu interface, and guess what? Dwarf Fortress runs entirely off keyboard inputs. That is where virtualization comes in. Or, more specifically, virtual key strokes. If building a masons workshop requires the input command b-w-m then so long as you can send Dwarf Fortress a virtual b-w-m independent of the actual keyboard, you can program an interfacing software that allows players to access the menu in a more fluid, natural, clean setting.

This, is where WINE comes in. WINE IS NOT an EMULATOR. Wine converts inputs(well rather it converts outputs directed at the Operating System, but it demonstrates my point) from a windows system to a linux system, and consequentially doesn't use a massive amount of overhead. http://en.wikipedia.org/wiki/Wine_(software) There is also the example of Botting and Macro software. These software types often convert single keystrokes into multiple keystrokes. For example, ISBoxer is a multi-boxing software that allows players to manage dozens of separate EvE programs simultaneously with the same effort as one program. The problem, is that I, personally, didn't develop WINE or ISBoxer, or any other virtual keyboard input software personally. So where-as I know it will work, I don't know what code is needed. Something like /send keystroke('b') dwarffortress.exe but the devil is in the syntax. It probably be best found by locating the developers of WINE etc. and asking them. Or I could open up WINE (which is open-source) and look around for it myself.

I guess I'm just hoping that I'm not the first person to think of this, and that someone is already way ahead of me and about to release the alpha version, so I don't have to do research. Or maybe that I might find enough support to have someone else solve it for me. Do I have any volunteers? Or am I not only the first person to think of this, but the first person to think of this who has any motivation to do it. -sigh- I'll add it on my list. Thanks all! Your motivational speeches really work... *grumble grumble*

I said READ through, not glance at the OP and come back and tell me why a gui api is different. because almost everything you can say about the topic has been discussed there. and you are wrong, it's NOT completly different.
and lol, yeah. if a gui revamp is not going to happen, but we are going to solve the problem with wine. sure. why not build a dorfputer and run the game on it? at least that has been demonstrated to work.

-sigh- Not really. Page six and I learned the following... The OP thinks realism and sandbox (art) are antithetic in spite of the real life being a counter example. He wants opensource and collaborative development in spite of The Toady One's desire to do otherwise. He wants frequent releases despite the increasing complexity. He wants Dwarf Fortress to be about bug fixing instead of feature development. And he wants less stone variety.
The next six pages consists of people complaining over whether stone variety is better than stone mechanics. To explain the remaining 6 pages, I'll quote a nice little post on page 6: "Well, ok then.  Read this entire thread, and kinda regretting it now.  I did skip over any post that ONLY "bashed" the op though, because it added nothing to the argument, and is typical internet BS you find on facebook or youtube from kids." Except I read all the bashing... and I can confirm it is pointless.

None of that relates to having a select group of people work closely with The Toady One's code, not The Toady One himself, to develop a mod that creates an API to use GUI for.

Returning to my suggestion about using virtual computing to overhaul the graphics... Since people here are so illiterate, I'll explain the gist behind Virtual Computing...

Virtual computing has been demonstrated, as I am describing it, to work for dozens of programs in the example of WINE(Wine Is Not an Emulator). WINE is a Linux software that converts commands given to it in a Windows Operating system to commands that work for a Linux operating system. The whole point is that games interact with operating systems, not actual hardware, and programs already exist that act as operating systems but aren't operating systems. Thus, the difficulty in redesigning GUI is merely the difficulty in manipulating those emulators to give fake signals that register as real signals to the actual programs. There are dozens of working programs out there that do exactly that. Auto-it is the only one that comes to mind, but any botting software seeks to do this, essentially, and there are hundreds(probably thousands, but that might be an exaggeration) of those. Software like Unity can be used to monitor the screen to be more effective, but I'm fairly certain any programming language can be utilized to reassemble the GUI. Finally, the example of StoneSense would remove any barriers for running the command interface and the mapping at the same time, which I previously thought to be a potential issue.

Anyway, I happen to have not read up on directly programming software like WINE so I can't do this right now to get it over with already, but I'm sure the Linux community has some answers out there already for this on some FAQ questions.

Side note, why does everyone think I am someone else returned with a new account. What, is it that I know too much to be someone who just stepped in? Whatever... Trolls be trolling

Sorry to Necro, but I am done reading threads. I've read this thread and the links there-of, and this one seems to be the best to reply to. I am really curious as to why these AMAZING suggestions are not in the game. Referring to some of Toady's posts, he seems to have several reasonable concerns. However, none of his concerns restrict one potential option. I'm going to "reply" to his post http://www.bay12forums.com/smf/index.php?topic=21806.msg237594#msg237594
as if it were an anti-GUI overhaul post, in order to conclude what we, as a community, should do.
1: ...And right now, I have no idea what would happen...
>Well sure. Life is uncertain. However, what danger does helping the community improve a game have? I mean, on the same token doing nothing carries an unknown risk.
2: If more than half the player base comes in off a third party interface
>Proof that helping GUI will double your player base
3: The pressure on me to work directly with them to get the interface out at the same time as the game itself would likely be immense and disruptive, given what little evidence we have from broken utilities.
>That assumes you are capable of speeding up the process. That merely means whatever method we use must be so fast that having The Toady One help won't speed it up one second.
4: First, I don't want to work with other people.
>Easy to implement.
5: If I didn't support it directly, but it was there, I'd still likely make more money, but I'd be unhappy.
>Why? Assuming no one says a word about GUI not being ready etc., where is your happiness lost? Does The Toady One really want to be the Sole Developer of Dwarf Fortress so badly, that'd he would accept making Dwarf Fortress worse than it could be, even if he gets all the credit and money anyways?
6: Given what I've seen here and there, it seems like a full third party interface might develop even without my involvement
>My goal

OK, so how do we come up with a way to improve the interface where The Toady One can't possibly help speed up, where The Toady One doesn't dedicate any time towards improving it, and where the players never complain about no interface updates???

Open Source. We find someone who The Toady One approves of as being respectable enough to safeguard his secrets open up the source code, and decipher everything. Probably multiple people, if they are to do this as a hobby. Those people first run through an old copy of Dwarf Fortress and locate all GUI elements. Then, they create an mod that edits Dwarf Fortress to have an API port to access the GUI. This is the hardest part. Next, The Toady One occasionally logs his changes, maybe on a weekly basis, and uploads them without commentary to the various respectable editors. Those editors, at this point, will be skilled enough at reading The Toady One's code, that even The Toady One couldn't help explain it to them. They merely locate changes to GUI and modify their mod that allows access to an API port. Finally, someone else creates ANOTHER mod using this API mod to overhaul the GUI. They can then work directly with the respectable people to proactively come up with new versions to match game updates.
The Toady One assumes one risk. The respectable people he lets look at his code for GUI elements aren't respectable.
The Toady One must work with the players on one thing. Occasionally backup his data to an external location, and select respectable people, probably from the forums, who he trusts. If he doesn't back up his work, he should. If he doesn't trust anyone, there is really nothing we can do... or is there?

Is Dwarf Fortress ALREADY open source(as in, open up the game file and edit away)? If so, ignore everything I said about The Toady one assuming any risks or doing anything, he already assumed said risks and did such actions, now we get to edit.
If not, does The Toady One already trust anyone enough to let them do this? Secondarily, would they be willing to do this?

Personally, I doubt The Toady One codes in the enigma, and so long as he codes in a language machines can understand, we community members can probably crack it. Once we have the code cracked, and available, finding the GUI elements could take about a month, maybe, and developing the API porting software maybe another month. Developing one of these options of GUI initially for the old variant of Dwarf Fortress might take a week... Following that, it may take some time to catch up to the latest version.

Yes its a stupid amount of work, but think of it this way. What if this 3rd party GUI overhaul makes Dwarf Fortress pull another Minecraft? Imagine The Toady One's delight at seeing his creation go viral... (Well, The Toady One ALREADY inspired Minecraft and tons of other games, so... he may be indifferent...)