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.

Topics - anallyst

Pages: [1]

DF Suggestions / BUG of the week

« on: November 20, 2010, 03:36:52 pm »

there are some f***ing annoying bugs in DF. some of them since ages.
unfortunately, Toady One seems to care mostly about Adventure mode and fixing typos.

to finally get bugs like

* the incredible FPS drop from blood splatters, until the game becomes unplayable (there's a switch in init.txt to avoid this, but it doesn't change anything)
* huge "cancels clean self: cannot find path" spam (when soap is available)
* backup files created by editors (*.bak) in raw folder leads to unplayable embarks (WTF toady, that's a one line fix: if (fileext(configfile) == "txt") { parseconfig(configfile); } )
* [insert your favorite bug here]

solved, it seems some pressure from the community is required.

I therefore suggest adding a weekly vote for the "bug of the week", which ToadyOne has to solve.

DF Suggestions / enemy filter for units menu

« on: October 31, 2010, 10:55:48 pm »

e: view enemies

would only show hostiles, invaders, uninvited guests.

i look it up very often, and have to scroll down dozens of pages (130 dorfs, 260 pets, ...)

DF Suggestions / BURN tag for wood items (burns to coal)

« on: October 06, 2010, 09:13:51 am »

i have tons of useless wood stuff around... i'd be glad if i could use them for my furnace industry.
(even better would be to make logs from wooden stuff, but i guess toadyone doesnt like that idea)

DF Suggestions / one executable per cpu arch (i.e. core2, corei7) to take advantage of SSE etc

« on: September 19, 2010, 07:19:34 am »

the standard binary is most likely compiled for i486 compatibility and could in theory even run on a 486.
that's nice, though modern processors have many features that can be automatically used via compiler optimization.
to take advantage of this, one only has to recompile with a switch like this: "gcc -O3 -march=core2".
that allows the compiler to use MMX, SSE1-4 and friends for things like memcmp and memcpy (could i.e. fetch one 128bit junk of mem in one cpu cycle) and in many other cases.

DF could be distributed like this

Code: [Select]

downloads
  windows
    df_31_13_win_main.zip (includes everything as usual)
    df_31_13_win_corei7-bin.zip (includes only Dwarf Fortress.exe with corei7 specific optimization)
    df_31_13_win_core2-bin.zip (includes only Dwarf Fortress.exe with core2 specific optimization)
    df_31_13_win_pentium4-bin.zip (includes only Dwarf Fortress.exe with p4 specific optimization)

...etc.
that would cost nearly no effort, and speed up things for most of us (i'm pretty sure nobody uses a cpu below pentium4 for DF anyway, so MMX and SSE could speed up things already)

DF Suggestions / make the game playable through consistent menu behaviour

« on: September 18, 2010, 06:04:11 pm »

every time i start another try with df, i get soon frustrated by the weird menu design, so i stop playing after a while.

in some menus with 2 columns, you can move left and right with left and right keys.
in others, you have to use two sets of cursor keys for every column. (stock vs trading menu)

make menus use columns, which can be switched via tab and then
navigated via cursor keys, in ALL of them.
there could be a convention that the first column can be directly accessed via F1, the second via F2, etc.
in the embark window, where TAB has another meaning, just select another key for that purpose like "Home"
the embark window consists of 4 tabs, in each one of them cursor keys should work.

whenever an area can be designated, use the same system: select start and end sector.
i'm speaking about the weird ukhm/UKHM style navigation i.e. used for selecting the embark region or building walls.

once that is fixed i'll make a generous donation, because then i can actually enjoy the game.