Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - expwnent

Pages: 1 ... 18 19 [20] 21 22 ... 113
286
Utilities and 3rd Party Applications / Re: DFHack 0.40.24-r3
« on: June 27, 2015, 07:31:48 pm »
I have no idea. I think at this point you and Urist_Davinci know the most about it.

287
Utilities and 3rd Party Applications / Re: DFHack 0.40.24-r3
« on: June 27, 2015, 11:37:29 am »
Awesome! Scriptable attacks are a great tool. I'm slightly concerned what would happen if the game saves during the one tick where things are weird but as long as that doesn't happen it should work fine.

288
DF Suggestions / Re: Where is the Polygamy / Polyandry?
« on: June 25, 2015, 05:29:57 pm »
Ah, ok. It could be neat just for cultural variety.

289
DF Suggestions / Re: Where is the Polygamy / Polyandry?
« on: June 25, 2015, 04:29:51 pm »
I think dwarves shouldn't be polygamous but it should be raw-moddable. I agree serial polygamy (that means one spouse at a time, right?) makes sense for elves given their lifespan, no marriage makes sense for goblins, etc. Maybe human civs could be set up to vary. I don't see it as a high priority but it would be neat and it probably wouldn't be too much work to implement.

290
DF Suggestions / Re: Abstracted Interface: Redux
« on: June 25, 2015, 04:08:18 pm »
PS: I think it's more an issue of priorities than not thinking it through. He's more interested in the game itself and its mechanics than the user interface, so that's what he spends most of his time on.

291
DF Suggestions / Re: Abstracted Interface: Redux
« on: June 25, 2015, 04:04:01 pm »
Even if he didn't mind working with other programmers I doubt he'd include the custom job management screen you mention.
Generally, we'd prefer to stay away from spreadsheets or a numbers-oriented priotization for specific labors on the labor list. We'd rather see the labor list removed entirely in many circumstances, depending on fortress citizen status, but that'll have to wait until starting scenarios are completed.

Isn't that like saying "I'd prefer to stay away from an Interface that works"?  Because it's not something about presentation, it's about how the game was built in the first place that requires specific types of data to be in the game in the first place. 

Toady built a game where you need to be able to compare dwarves to see which one is best suited for a task, or where, when a job isn't being done, you need to see how many dwarves are assigned to that task, who is available to be shifted over to that task, and what consequences there would be for assigning those labors to them. 

He built a spreadsheet-based labor screen by building a game that requires a spreadsheet-based labor screen to actually manage.  And if he doesn't like that, well, HE'S BUILT THE WRONG GAME, THEN.  This is a simple failure to think the consequences of his design through, and it shows through every fracture in this broken and failed interface of his. 

I also have no problem with spreadsheets. They accurately display a large amount of useful information and it's easy to navigate to what you need.

He built a system for, say, bee hives, where you need to be able to set half the hives to be split and the other half to be gathered.  There's no reason to do otherwise.  There's a button to control that, and you just have to manually make sure it's half.  It's not ideal, but it's fairly functional, and all the buttons are explained on the menu, itself, which is fairly good, and probably one of the better uses of interface Toady has performed. 

Nest boxes, on the other hand, require that players somehow manually forbid dwarves from collecting fertilized eggs, which is a massive chore, and a failure to foresee how these nest boxes will be used, especially when you have something like bee hives with a perfectly good system for designating whether a nest box's eggs should be forbidden AUTOMATICALLY or not. You can't see whether turkeys are gay or not because he didn't bother to think through the need for that interface.  You can't see which turkeys are fat or muscular on the screen where you butcher them after explicitly making a system which rewards selecting for fatter, more muscular livestock because he didn't bother to think that one through.  You have the game that requires keeping track of when a turkey was born for maximum butchery, but no means of actually tracking that information, because he didn't bother thinking it through.  We only needed those features when he built the game so that we'd have to use those features.  He BUILT the problem to which those interface features are the only, obvious solutions.

I think I can fix most of those examples with DFHack.

That's where all this comes from: He didn't bother to think it through.  And it turns what would be a game that could curb-stomp Minecraft into some tiny indie thing only programmers play because only programmers can figure out how anything works and can manually change it to properly run. 

I wouldn't go that far, but it could absolutely be more user-friendly and it could improve in the ways you've said.

I like keyboard shortcuts. They take longer to learn but once you learn them you can navigate MUCH faster than you can with a mouse.

292
DF Suggestions / Re: Abstracted Interface: Redux
« on: June 25, 2015, 03:50:23 pm »
Which brings up another thing: Cursor Memory.  Can't we have a way to remember where we were in the units screen or stocks screen?  I have to hesitate to wonder if it's really worth it to zoom in on where a given item in the stocks screen is, because I know I have to search for that type of item again if I'm looking for where every single wheelbarrow has gone off to...

That is completely possible with DFHack and would be quite nice. I'll add that to my list. There's already "tweak stable-cursor" for the map cursor. It won't always be possible for menu items, especially if new units/items are created or old ones are destroyed, but something is better than nothing.

But anyway, if we're talking about links between different modes of information-gathering and decision-making, obvious culprits are the military screen and anything having to do with animals.  Animals, in particular, require that you just memorize the order of the animals' appearance on the list, because there is no other distinguishing feature you can find when you want to train or pasture some, and butcher others.  You just have a list of 30 turkey hens all listed as "turkey hen", and no idea which one is in a pasture on a nest box, and which one is just running around free.  To see the specific stats of a given turkey on the detail view, you need to exit (and lose your place in) the units screen, and even then, you don't get enough information without just using DFHack, anyway.

I agree, and this is also possible to fix graphically with DFHack. I have no problem just showing the exact weight, or at least a few significant digits based on the skill of your most-skilled dwarf. I had always thought that you could go directly to the unit viewer from the animals menu but I just tried it and that doesn't work. That would help at least a little.

For that matter, just plain having a capacity to nickname animals would be a huge help.  "Egglayer turkey 04" is fine enough to label a turkey, while, due to the difference in adulthood and max size, you might say something like "butcher timber 1062" on another turkey.

That would be handy. Nicknaming them isn't hard but I don't know whether it would show up in useful places in the UI without extra tweaking.

Also, one thing that's just the bane of my existence in this version is inexplicable job cancellation messages.  Jobs about stockpiling keep being canceled because of the job item being lost or moved, and I have NO IDEA what's creating the problem, because the announcements screen only zooms in on the area where the DWARF was when they canceled the job.  There is no indication what item they were going for, so I have no way of solving the problem.  Worse, I keep having job cancelations with my clothesweavers saying they're out of cloth when I have 70 cloth in the stockpile, apparently because someone just keeps moving all the bins or something...

Difficult to fix, but maybe possible. It would involve searching through the entire list of jobs every time there's a job cancellation announcement, but on a frame-by-frame basis this is pretty rare so it shouldn't be too bad for performance.

One of the things I really loved in Gnomoria was the fact that, if you ordered a new steel spear, and you were out of steel, rather than just spitting out one more cancellation message among 500 others that get spammed a second, it just plain orders a new bar of steel be forged to complete that order, and the steel spear order is suspended until the steel bar is ready for being made into a spearhead.

Possible, but not 100% clear how to generalize. What if the components also have prerequisites? What if there are multiple ways of producing the ingredient item and they have different trade-offs (prefer magma forges over fuel-powered forges probably)? Would players want the game to completely automate going through an elaborate long tech tree in some mod in order to produce a top-tier blueprint, or would they want to do it themselves? What if they don't have any of the right kind of ore? One of angavrilov's old ideas was to combine one of the automining plugins with workflow and mine out ore as you need it. That might help.

While we're on topic, if you could actually add in sound effects, that would be great.  In Gnomoria, things like shield blocks, dodges, hits to armor, and hits that pierce flesh are all different sound effects, and it helps give a sense of how a battle is going without having to read combat reports every 0.2 seconds.  Sound effects for different events could also take some of the load off of visual representation, such as an "ahhh!" sound for getting a happy thought looking at
something.

Soundsense did this for a while but it may or may not work anymore. It would require finding free sound effects or making them, which is nontrivial.

However, I think the most critical issue of interface (one I've harped on to some length in some of the previous rants I've linked to within this thread,) is the fact that critical data is invisible to the player.

Players keep running into problems where their dwarves go into tantrum spirals because of problems they don't understand.  Thoughts exist, but most players don't camp in the thoughts screens of dwarves, especially as you start to get over a hundred dwarves.  (Again, a reason why dwarven migration should be far, far slower...) When they finally do look it up, it's mostly just talk about being horrified by one thing or another, and a bajillion messages about how friggin' INTERESTING every random door is.  Not a specific door, just "a door".  No zoom-in here.

The big problem is that everything in this game needs to be visually identifiable for players to really understand it.  Players understand minecarts and fluids and even to some extent combat (although they have to read the reports to get the blow-by-blow, they understand where they are standing, and what is dead).  Players do not understand conversations, social relations, thoughts and mood until it has hit critical stages, and general problems dwarves have with why they are picking one job over another.

I generally agree. There is the question of how much information should be available to the player. The player should certainly never be punished for something they couldn't reasonably have known about.

I agree migration should be slower. If you have fewer dwarves the game runs faster and each dwarf matters more and there's less micromanagement. I always keep my forts small.

That last one is especially critical when Toady wants to move away from enabled and disabled labors to dwarves-choose-jobs.  Why does a dwarf choose one job over another?  WHO KNOWS! What can we do about it? APPARENTLY NOTHING!  Sure, there's going to be an elite few that get how to make this work, and build elaborate systems to exploit the subtle quirks of the system for maximum efficiency, the way that we used to control which side of a wall dwarves stood on by ordering suspended wall construction where we didn't want them to stand, but most players wind up walling a few dwarves into a closed-off space, and have no idea why.

Dwarves don't look for jobs, jobs look for dwarves. There are a few exceptions with mining but that's basically how it works. It's more or less random and hard to control, as you say. This would be difficult to fix. Manual control is possible but a bad idea to rely on because that's a LOT of micromanagement. DFHack's autolabor does very advanced things to maximize efficiency that I'm reading about. It's an improvement but not a perfect solution.

Adding in this tavern stuff, with musicians whose actions we can't see, visitors whose thoughts we can't see, but whose happiness we need to ensure so that we get more paying customers, and all sorts of other invisible data problems all add up to a major problem going on. 

In The Sims, we can see what a character is thinking - not through some details view that requires dropping all else from the screen to focus on just that one character - but just because a bubble pops out of their head saying "I wanna go to the bathroom".  And frankly, OF COURSE they do that, because understanding what your sim is doing, AND WHY, is critical to playing the game.

DF needs to have this capacity to show when a dwarf is playing or listening to music if this is going to be some sort of important aspect of gameplay.  We need to know why a dwarf is doing one thing, and not another thing when both choices are available to them, and what we can do to influence that decision in the future, and do so natively in the game, not only if you search and read up some obscure forum post where SCIENCE was done. 

We need to be able to see when a dwarf gets unhappy because they saw some swarm of flies because there's a rotting untreated leather in the stockpile so we can remedy that, rather than just see problems occuring, but having no idea WHY.  We need to be able to see the relationships, and what they do, or they're just some invisible bar filling up to a marriage that you can't even distinguish from being single except for when straight dwarves randomly spawn more babies.  If we have these taverns, we need to see what parts of the tavern are working well at satisfying customers or what parts of dining halls dwarves love, and which ones are annoying dwarves.  Armok forbid we start getting advanced social structures or factions within a fortress or thieves that pose as fortress members, and we have no means of telling what's happening or why.

I agree completely. I'm not completely certain what the best way to present that information is but I agree it should be available. Toady's plan is probably to expand the nobles and have a "public relations" or "morale officer" who can tell you about who's upset and why, like the bookkeeper manages item counts. I personally kind of like spreadsheets. Just replacing the wall of text of recent thoughts with a table describing lots of useful information at a glance would be a step in the right direction.

Interface, and showing what's actually happening as it happens, not just when a player randomly chases a cause down after the disaster has already occurred is critical to letting dwarves become more than just the smiley faced automatons that blithely do whatever they are ordered without questioning orders, because we have no means of seeing when it is they are questioning orders.

Sounds would help, as you said. DFHack could monitor thoughts and let the player know when a lot of one type of unhappy thought are happening or when a dwarf is getting too stressed out. Not clear what the best answer is though.

(reading next post)

293
DF Suggestions / Re: Abstracted Interface: Redux
« on: June 25, 2015, 02:02:28 pm »
Worse, I've seen some fights on the wiki about people saying that such-and-such is how you do something, and not mentioning it's only available via DFHack plugin because they didn't know it was a plugin.  When you have people who never use vanilla DF, they have trouble telling where DFHack ends, and vanilla begins...

That's certainly a problem but I see no way around it. There will always be a large section of the userbase who refuses to read any documentation.

I'm more interested in less ambitious user interface overhauls. Just using the existing in-game stuff with different menu design, adding more search buttons, categorizing things better, etc.

I particularly like the idea of showing the current job of a dwarf visually somehow. I'll think about whether there's a way to do something like that with DFHack in a somewhat user-friendly way.

Upgrading workshops are already possible. Ask Roses about it. We'd just need to replace the existing workshops with a sort of tech tree and it would work like Gnomoria. I think Meph has an extensive tech tree for Masterwork (at least before he started it over). Regular old raw modding can accomplish that: you need a certain building to make a blueprint for another, etc. Lua scripting can let you upgrade a building in-place. Sandbox paralysis is certainly an issue.

294
Utilities and 3rd Party Applications / Re: DFHack 0.40.24-r3
« on: June 25, 2015, 01:45:07 pm »
Announcement: if possible, please submit structure/memory research in the issues tracker for df-structures. Direct Link

295
DF Suggestions / Re: Abstracted Interface: Redux
« on: June 25, 2015, 12:26:17 pm »
DFHack can cause bugs but it's fairly stable. Stable enough for most users. It's true that it's sometimes unclear whether it's a DFHack bug or a DF bug. That's a drawback and there isn't much we can do about it.

I have literally never seen Quietust be wrong about anything, which scares me a little. He's probably a robot from the future. In any case, it's a pre-existing issue that few people can help Toady debug, but without memory hacking, zero people can help except for Threetoe if he's a programmer.

I agree more transparency would help so that we can increase the number of people who can help.

Graphical stuff is an insignificant performance drain. Most of it happens when the game is paused anyway.

Quote
I get that DFHack makes great features available, but when someone can make a third-party interface that replicates the functions of Dwarf Therapist ENTIRELY IN-GAME USING IN-GAME ASSETS, then it's basically as close to a slap in the face as a programmer can get.  Since it's literally already coded out for him, it just begs the question why Toady can't just sheepishly accept it and copy that code?

Hehe I guess I never thought of it that way. In the same category, I implemented digging invaders but I'm not aware of anyone who uses it, despite how high it is on the eternal suggestions voting.

Here's how I see it: as players we have relatively little influence on what Toady works on. He does great stuff but he's going to focus on whatever he wants to do. As DFHackers we can add certain features, and cannot add other features. The best thing for the players is for Toady to work on the stuff he can do that we can't and for us to do the stuff that he doesn't want to, and for raw modders to take advantage of DFHack stuff to enhance their mods.

I think I have the necessary skill to redo most of the interface but I don't know where to start with the actual interface design. I've seen several suggestions posts talking about interface improvements, but I haven't seen any concrete suggestions of what should replace it, at least not enough for me to take it and run with it. I've gotten used to DF's interface to the point where I don't remember what was counter-intuitive so it's sort of "too late" for me.

296
DF Suggestions / Re: Abstracted Interface: Redux
« on: June 25, 2015, 11:11:33 am »
Making it open source does not solve the problem, and telling people to fix it themselves is not a solution because only a small subset of players have the necessary skill to both program and know the game and user interface design well enough to design a good interface. It's never going to happen anyway. Toady has said many times that he's not going to make it open source.

I think people would be surprised how much is currently possible with DFHack. One ambitious person with a lot of free time could probably redo most of the whole interface. We know how to directly paint tiles to the screen, create new viewscreens, listen for keyboard input, etc. People have added search buttons to existing viewscreens before. Quietust even made a simplified version of Dwarf Therapist in-game.

297
Utilities and 3rd Party Applications / Re: DFHack 0.40.24-r3
« on: June 22, 2015, 08:52:16 am »
does the df::global::world.buildings.all vector contain every building ever made, including removed ones?

I'm trying to decide how I will send over constructed buildings to Armok vision. I don't want to send more than I need to, but besides searching through all buildings and picking the ones that are inside a specific map block, I'm not sure how that could be done.

I'm 90% sure that it does not.

298
Utilities and 3rd Party Applications / Re: DFHack 0.40.24-r3
« on: June 21, 2015, 11:44:23 pm »
There's definitely a way but I forget what it is. Try looking at the tileprobe plugin. Or maybe it's just called probe? I forget.

299
Utilities and 3rd Party Applications / Re: DFHack 0.40.24-r3
« on: June 21, 2015, 04:14:35 pm »
If you look at the JOB_COMPLETED event then you can probably get rid of the boil-away stone and just count dig completed jobs and check the tile for the appropriate type of rock and then trigger the thing that spawns them or increases their population somehow.

300
I thought I had already posted to watch but it looks like that's not the case.

Looks awesome!

Pages: 1 ... 18 19 [20] 21 22 ... 113