Bay 12 Games Forum

No, I mean one game of DF vs another game of DF.

Ptw!

An important thing to remember is that computer specs, while a good contribuiter to FPS, doesn't necessairily translate well into comparing system results - you won't be able to give a multiplier on which to adjust FPS counts given hardware. Additionally, software (especially system services) plays in very strongly. As a result, it isn't very plausable to share absolute FPS counts, even when sharing system specs.

Really?  So are you saying that it might be possible for my computer to run one game faster than yours, while yours ran a different game faster than mine?

That got my thinking, that FM2 APU is only slightly faster in single core performance

I'm not familiar with those processors, but are you basing that just on clock speed (ghz)?  Processor performance is about a lot more than just clock speed these days.

Toggling bridges with a lever-flip

I think it's worth commenting a little bit on this problem and your solution from a more general perspective.

DF (wiki and forum) has adopted the jargon of electronics for talking about machinery like this, but this is a place where different terms would clarify things.

We use the term memory (or flip-flop, or latch), but another word that describes what it does is signal division.  Memory takes an on-off signal and returns either an on or an off.

Edge detection, on the other hand, can also be seen as signal multiplication.  It receives an on or an off and returns an on-off signal pair.

What you have here is a memory cell and edge detection built into a single device.  The tightness of the signal means that only a single half of the signal is getting through.  However, a more general purpose solution to this problem, and one that can be built using any discipline, any set of modular components, is to build input->edge detection->flip flop (toggle memory).

Also, I'm not sure this works as advertised.  Consider lever->bridge.  There are two times it doesn't act as you'd like.  First, when input follows input too rapidly.  Second, when the bridge is controlled by multiple inputs.  The first is never going to be solved by machinery, which can only exacerbate this problem.

But the second isn't actually solved by your circuit either.  When multiple levers control your inputs (hatches), it's easy to reach a situation where changing the state of one lever doesn't change the state of your circuit or trigger edge detection.  This problem cannot be solved without dedicated edge detection of each lever.

Where edge detection of a lever pull is necessary, this is the device I've settled on:
####
 ^ó#
####

The lever is totally superfluous, and exists only to drive a dwarf over a pressure plate.

(Edit: removed a bunch of stuff, a new thread is more appropriate place for what i was talking about)

Quote from: Nil Eyeglazed on March 20, 2014, 04:31:34 pm

Signal detection theory?  Service description table?  Sexually deprived teenagers?  Scottish dance theater?

Stupid Dwarf Trick.

Aha!  I should've known...

Not sure if you're planning on Dupree's goblin-on-a-pillar-and-dwarven-door-runner technique-- I did something similar once, but with timed bridges instead of door-runners, think it was probably a lot simpler to set up (and pause, etc).  Although I'd need to make a few modifications for the current version, used a falling dwarf to create the timing offset, and dwarves probably fall at a different rate now....

Important Note: When making aqueducts/drains (especially if they're only 1 tile wide), make sure to pave the bottom with constructed floors or roads. If the aqueduct is always filled with water it's not an issue, but if it ever dries, the water will leave mud, and mud can grow trees, which block all movement, including water. You don't want to have to dig a second drain just to drain your drain, and/or sacrifice the life of a miner/woodcutter, so just pave the thing before you flood it.

Alternately, create your channel out of ramps, on which no trees can grow.

Hmm.

1) I haven't seen any problems with this myself, although, granted, I don't do it a lot.  Some things to be aware of: you can't designate tiles near the edge (like 5 or fewer tiles away, I think); when outdoors, it defaults to designate trees, rather than designate mine, which obviously won't do anything inside a mountain, and with hilly environs, "outdoors" can involve a lot of rock; when moving the mouse quickly, designation spots can be missed (the mouse is quicker than the brain!  erm cpu).

2) I didn't realize that was ever a single way to scroll up and down like that!  There are three ways to scroll, depending on the menu: up/down arrows; pgup/pgdn keys; numpad +/- keys.  None of these take modifiers like alt or ctrl, and maybe numlock needs to be in some particular state.  The precise key you need depends on the menu, which I think we all agree sucks, so if one set of keys doesn't work to scroll the menu, try the next.  Not sure about how laptop peeps play DF.

I hope that helps.  Good luck with your game!  If you have more problems, or if this doesn't help, let us know.  Hopefully with the precise menu/situation/whatever you're having trouble with, because there are bound to be special situations that won't immediately spring to mind.

Glacier drop used to give a source of (exhaustible) water; haven't had to use since caverns were implemented, but I imagine it would still work.  Stupid freezing tricks can be used to dupe water once you have any magma access.

Don't need to spend much time on the surface to take advantage of wildlife.  I once ran a fort based on the capture, breeding, and drop-slaughter of wild camels.  Wild animals still don't need pasture, right?  And can still breed?  And some animals can be extra handy to have around.  Even without magma, I know of at least one way to sustainably melt ice...