New question.
Will the somewhat absurd tactic of making furniture out of ores be nerfed somehow, or will it still be a way to make high-value furniture?
It won't be nerfed at all. You'll be able to nerf it the same way you can in the current version (by modding the material values).
I think he meant how making furniture from ore isn't worth less than making it from bars so you can get lots more native aluminum statues by making the raw economic stone available for the task.
You'd see yourself going FTL long before you approached lightspeed. Your perception combined with your actual speed will make it seem the universe flies past you faster than lightspeed. Also, I thought light has a static finite speed? You won't see light shooting ahead of you if you're already at lightspeed, because that would mean light travels faster than light for an outside observer.
Moving at the speed of light time you should stop having any advance in time anyway.
I was referring to how very near the speed of light you do still see light shooting ahead of you at the speed of light thanks to your perception of space being quite distorted. At the speed of light doesn't really mean anything for particles with ma- OH GOD MAKE IT STOP.
Edit: Could we switch to a topic other than theories on relativity and FTL travel? Not that I don't like to read it, it's just not going anywhere.
And its definitely not related to the game or upcoming updates.
Someone design a flingcelerator where a dwarf pulls a lever, an object is flung by a bridge on the floor, then as it moves across a nearby space another bridge flings it again before it stops, and thuslike over and over again in waves of triggered bridges until the object breaks the speed of light.
Bridges just throw things in random directions rather than in the direction they were raising so no.
For example:
1) if you channel into the floor and it has access to a larger body of water above it, nothing happens. So a toilet-like U-bend (S-bend?) isn't possible.
Hydrostatic pressure SHOULD work, it's in the game. But it won't perfectly equalise. Try putting your S-bend 1 z lower.
2) if you channel a one tile access to a river, split access into 4 sub-channels, let those channels dump into a tube which has a one tile exit for the water at the bottom, and your tube overflows. I guess because the 4-splits serves to suck more water from the river? Pretty sure that's not right.
having had funnels overflow from faucet input, I feel safe in saying this is reasonable (not that it WILL happen in all cases, but at least some)
3) again, you can have a 7-tile of water back-logged up a 1-tile channel accross the map and have it dump into a huge reservoir. Water will actually seep into the ground and dry up before the reservoir fills, if it ever fills. The water should flow faster in the channel and slow down once it gets into to the reservoir. Pretty sure this is also not the case.
Water won't seep into the ground inthe current version. Evaporation, however, does. (as for thechannel, it might be misbehavior, it might not. A river outlet does not drain a lake necessarily.)
I personally am really looking forward to the next five pages of "I'm not a theoretical physicist but..."
I am not a theoretical physicist, but my father was. unfortunately I cannot have him come and blow all these theories out of the water...
So if you threw a dwarf at light speed
I will merely say that that's where your argument falls apart, since accelerating anything with mass to c requires infinite energy. Apparently you caught this: Eventually right up near the speed of light you'd need all the energy in the universe just to get half of the remaining difference between your speed and the speed of light.
You'd see yourself going FTL long before you approached lightspeed. Your perception combined with your actual speed
You're using the wrong speed-addition.
Also, in DF, presently light and sound are both infinitely fast instantaneously-propagating effects, therefore it is impossible to break either speed.
Toady, how often do you back up your work?
Programatically you could by having the effect happen the turn before what caused it, though if you want to be |absolute| about it that would actually just be slower.
That space-folding notion(http://en.wikipedia.org/wiki/Alcubierre_drive), too, requires infinite energy to FTL, unfortunately (probably. it was shown for two dimensions...)citation
I've always had a hard time dealing with those energy requirements when I want to explain it to other people. Is it just hidden away in such nasty math that I have to take it for granted?
@shoku re: water
Basically, the game needs to be aware of the difference between a static body of water and a dynamic one. As it is, it makes no distinction. Once this sort of thing happens, then FPS would only get hurt when water starts to flow. Furthermore, I don't see any other way around modelling beyond the tiles immediately adjacent to a tile of water. Somehow the game needs to realize: "Hey, I'm a 7/7 deep thingy of water next to a completely vacant thingy of space. I better change that fast! So let's see, where should I move to..." and kill the FPS if need be, at least it will only be killed for moment if the flow isn't into a chasm or some other endless extreme.
It does that just fine. You can expect a large body of water to very quickly fill up a room you've accidentally carved into it and piercing an aquifer floods your fort at a suitable rate.
The slow water issue only shows up when you've got 7/7 next to a long stretch of 6/7 next to a long stretch of 5/7 and so on.
But even then, can't the game realize this and treat even water flow as a static property of a body of water? I mean, what's the difference between a static finite amount of water and some moving body of water that has limitless input and limitles output? The current is the only thing I can think of. Sure, if the input and output are not equal then it might be a problem. But for most ingame rivers, it should work smoothly.
Right now flow is determined by the actual units sliding around (I think. If you pump some water into an aquifer you apparently give it flow forever,) so you'd need a whole different system for defining flow separately from the actual units of water.
The u bend was one of the first things checked to see if water pressure worked. I guess maybe if you've got water that isn't moving and channel into it it might not notice right away but-
One of the performance safety mechanisms in place is that water will only teleport to lower levels. Otherwise you might get a single 1/7 pathing back and forth over the whole map endlessly. One tile is obviously not that scary but you know it's obviously not going to be just one tile often and a whole ocean of these would be awful.
Last time I checked U-bends didn't work perfectly, they only fill to one level under the source level.
To ilustrate this situation:
Source
|
V
OOOOOO OOOOOOOO
77777O O....... <-Safe area
OOOO7O O7OOOOOO
O7O O7O
O7OOOO7O
O777777O
OOOOOOOO
The part you quoted explained why. Imagine if on the lowest level you had a winding maze that covered the whole map and that your 7's got split into some 4s and 3s up at the highest level. All of the fours would say "there's a lower number somewhere" and then try to path through the entire freaking thing to get to the other side but one they got there they'd say "there's a lower number somewhere" and path back. It would be pretty bad for fps.
However, if you stick a pump at the front of that the safe area will get wet just fine.