Print

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

[Othob Rithol]

hats off to zagibu for seeing this through.

Underground Diversity <-- I want to live in a big cavern
Better/Harder Agriculture <-- 2 Farmers feeding 150 dwarves is ridiculous
Reduced Owned Item Clutter <-- I gave you a @#$%#% chest and a @#$%&! cabinet!

[Fedor]

quote:Originally posted by martinuzz:
<STRONG>(query about multi-threaded and FPS improvements overlapping)

Not fully, no.
Multithreading would give some FPS gain.
But optimizing pathfinding for instance would also mean a gain in FPS. I don't think multithreading DF would give the biggest FPS gain. Although it would help.</STRONG>

The problem here is that one suggestion is a Objective "I want the game to run faster", and the second is a Method "I want the code to use multi-threading".  The reason they need to be combined is that the Method is being requested to accomplish the Objective - it's not independent.

[Tuv]

im gonna have to say:

improved sieges
framerate improvements
and
multi-threaded program code

[Calenth]

1) the main thing I'd like to see would be auto-searching of starting locations. For example, I'd like to be able to enter "limestone, level 4 cliffs, sand" and have it search the generated world until it found a block with those elements for me. As it is I have to search for starting sites by hand and it's time consuming and cumbersome -- searches for anything on a computer should be automated, or at least automatable.

On a similar note, a set of sliders for "volcanic activity" "climate" "terror" etc. might be very nice additions.

2) I'd like to be able to alter the default embark loadout, permanently. i.e., after i do my first loadout, there should be a "save as default?" option (and a "restore default loadout" option also). I realize there are some variations in starting loadout etc. but I think this is an area where standardization would help gameplay replayability.

3) edit: change: dwarves who are set to "off duty" for sparring seek out the *worst* weapons of the type they're set to. i.e., they'll use silver and wood weapons preferentially over steel ones while sparring.

[ May 19, 2008: Message edited by: Calenth ]

[kamikazemoose]

more underground diversity: Because there could be more challenges waiting underground. currently I find all my troubles comming from the outside world.

more raw files: Because there are many things that would be awesome to have modable.

practice weapons / make dwarfs use them for sparring: because recruits getting their dirty hands on my *steel spears* are not a pretty sight.

[ShunterAlhena]

I hereby cast my votes at (in order of implementation difficulty, ascending):

show lever connections / name levers / blink connected: as in "name levers". Currently I have to keep a sheet marked "Tar Thran - Tholarel - Lever assigments:" and a matrix showing which lever does what.

multithreaded code: of which I was a big advocate of in another thread. Pathfinding would be an eminently multithreadable problem, for example. Or weather in another thread. Etc.

improved sieges: this I think is a large thing to ask for. But given that Toady One is working on the Army Arc, this might be the best time to ask for such a thing.

[ May 19, 2008: Message edited by: ShunterAlhena ]

[Lokysan]

My votes for this round go for:

- improved sieges (tunnels, siege ladders, better AI, etc.).
- framerate improvements.
- transport vehicles/animals, better hauling.

[Caz]

resizeable viewport and a better GUI. It's too much trouble to play any more when similar games are so much more simple to use...

[RoboCicero]

1. Framerate improvements.
2. More underground diversity
3. Improved seiges.

[zagibu]

@ Fedor: I don't agree. While they certainly go into the same direction, multithreading is a very specific suggestion, and only benefits those users with multiple cpus/cores. It's probably possible to achieve framerate improvements without having to rewrite a lot of the codebase (which will be required to make it multi-threaded). But it's not certain how much framerate can be improved this way. Some think multi-threading is the best way to do it.
You can try to win over voters from either "camp", of course.

[Narceh]

My three cents' worth of endorsement, then...

- Give dwarves the ability to carry multiple items
- Resizeable viewport
- Allow engravings on constructed walls

[Fedor]

quote:Originally posted by zagibu:
<STRONG>@ Fedor: I don't agree. While they certainly go into the same direction, multithreading is a very specific suggestion, and only benefits those users with multiple cpus/cores. It's probably possible to achieve framerate improvements without having to rewrite a lot of the codebase (which will be required to make it multi-threaded). But it's not certain how much framerate can be improved this way. Some think multi-threading is the best way to do it.
You can try to win over voters from either "camp", of course.</STRONG>

You have actually agreed with my essential point:  That the "multithreading" request is a sub-set of the "framerate improvement" response.  Whether it is an effective way to increase framerate is immaterial - there's no need to debate that - because its essential purpose, effective or not, is to contribute to another vote option.

When making a poll, each request should be logically separate and distinct, so that no request can be confused for another.  Methods and Objective options aiming for the same goals must never be combined.  Failure to do this is a logical fallacy.  Please stop making this mistake!!

Another point:  This series of polls is "winners take all".  Having overlapping menu options splits the vote for a given objective among several items; this often results in none making the cut-off, when the combination would.  There is no good reason to do this.

[zagibu]

I agree that it is a subset, but I don't agree that votes for the subset should go to the superset. I can see valid situations where people would want framerate improvements, but not multi-threading (because they have old single-core cpus) and where people would want framerate-improvements, and foremost by means of multi-threading (because they think multithreading will benefit them the most).

It is indeed a problem that people aiming for the same general goal get separated this way, and you are right that none of them might win at the end, but that's not the problem of the vote. Lobbying is most important in politics, and in this vote especially, because you can see what everyone voted and you thus have the chance to win the stray sheep over.

[Fedor]

quote:Originally posted by zagibu:
<STRONG>I agree that it is a subset, but I don't agree that votes for the subset should go to the superset. I can see valid situations where people would want framerate improvements, but not multi-threading (because they have old single-core cpus) and where people would want framerate-improvements, and foremost by means of multi-threading (because they think multithreading will benefit them the most).</STRONG>

That was ... a stretch.  If you're not interested in hearing ideas about how to make the poll better, just let me know and I'll shut up.  Seriously.  I shan't peep another word.

quote:<STRONG>It is indeed a problem that people aiming for the same general goal get separated this way, and you are right that none of them might win at the end, but that's not the problem of the vote. Lobbying is most important in politics, and in this vote especially, because you can see what everyone voted and you thus have the chance to win the stray sheep over.</STRONG>

It should not be necessary for me or any other poster to lobby you or each other to get more votes for something.  This isn't politics; it is - or should be - a straightforward requests poll designed to give Toady useful feedback.  It is YOUR responsibility, as the poll-writer, to ensure that the options do not conflict with or trip over each other.

[zagibu]

It's futile, we will never agree. I am open to suggestions on how to make the poll better, I have already combined many of the suggestions, but in this case, I am against a combination, because I think that a large part of the "better framerate" voters wouldn't be okay with Toady spending large parts of his development time on multi-threading and thus neglecting other problems.