A while back, someone posted a thread asking what to do with a captured werebeast. I suggested using using the werebeast to trigger a mechanism, such as a calendar, every month. I don't know if the guy asking the question did anything with the idea, but I decided I liked it. As it turned out, the project led to questions about what a dwarven calendar should be, and it necessitated a bit of astronomical research, which I hope to add to the wiki soon (I'd appreciate independent confirmation if anyone is willing). Before I get to the dwarven astronomy, though, let me tell you a bit (much of which you probably already know) about real-life astronomy.
As you're no doubt aware, nearly every real-world culture, past and present, keeps track of the year in terms of the cycles of the moon. As far as I am aware, the most commonly used cycle is the synodic month, the period of the moon's phases. This is also the one that's relevant to werebeasts, so it's the one I'll focus on.
In real life, we have:
- about 365 1/4 days in a year
- about 29 1/2 days in a synodic month
- 12.36 synodic months in a year
Much to the chagrin of ancient astronomers, there is no easy way to fit a syndodic month (or a month based on any other lunar cycle) into a year. The ancients sure as hell tried. Take, for example, the 19-year, 235-month Metonic cycle (http://en.wikipedia.org/wiki/Metonic_cycle), which is the basis of the Babylonian, Chinese, and Hebrew calendars. Some calendars, like the Hebrew calendar, feature 29-30 day months, in keeping with the natural synodic month, and add leap months every few years to keep in sync with the solar year. Others, like the Gregorian Calendar, add days to each month, abandoning the idea of syncing the calendar month with a lunar cycle. Why do I bring all this up? To contrast it with the dwarven approach to the calendar.
In a Dwarf Fortress universe, we have:
- exactly 336 days in a year
- 25.85 days in a synodic month
- exactly 13 synodic months in a year
That's right. The dwarves have a year with exactly 13 synodic months, the kind of lunar cycle ancient man would have killed for, the kind of cycle that would have been cited as proof of a benevolent god for thousands of years, and the dwarves took that and came up with a calendar with... 12 months. I suppose I should have expected nothing less. However, I'm not a dwarf, so I decided to make a logical calendar, one with 13 months. I named the 13th month Slade.
For reference, here are the dates (they're the same every year) of the full moons in the "official" dwarven calendar:
25th granite
23rd slate
21st felsite
19th hematite
17th malachite
15th galena
13th limestone
10th sandstone
8th timber
6th moonstone
4th opal
2nd obsidian
28th obsidian
I'd like to add this to the wiki, pending independent confirmation.
The display
(http://i.imgur.com/IbvEATy.png)
(http://i.imgur.com/HCkl0rU.png)
(http://i.imgur.com/4DX70rG.png)
(http://i.imgur.com/huLM1Ij.png)
The display consists of 315 green glass bridges, or 9 5x7 characters. There are 92 characters in the names of the 13 months. With an estimated average of 13 pixels per character, and two mechanisms required per pixel, that's 2392 mechanisms. Add 630 mechanisms for the reset mechanism and a few hundred to account for all the pressure plates, hatches, and mistakes I made, and we're up to around 3,200 mechanisms used in the project. And let me say, the mechanical linking interface SUCKS. It took me about 30 seconds to create every bridge linking job thanks to all the scrolling I had to do, and I had to do all the work blind, since there's no easy way to see what is linked to what. It was only sheer stubbornness that kept me from abandoning the project, to be honest.
The font I used is Minecraftia (http://www.dafont.com/minecraftia.font), mainly because it was the first 5x7 pixel font I found. I altered the i's and l's to try to make them look better in a fixed-width setting.
The mechanism
(http://i.imgur.com/TTt8rTR.png)
(http://i.imgur.com/kNtwnB4.png)
The mechanism is not nearly as complex as it looks. It's actually 13 copies of the same monthly mechanism daisy-chained together, and all the loops and stops are just there to delay the minecart a bit. To see how it works, let's look at the parts in detail:
Cerol, the werelizard
(http://i.imgur.com/BvWHoG6.png)
Level Z, detail
(http://i.imgur.com/ITrmJzx.png)
Level Z-1, detail
(http://i.imgur.com/9UfbRas.png)
Cerol, the werelizard: This guy (not a member of the fort, incidentally) is sitting on a pressure plate linked to thirteen hatches, each of which will support the blue minecart for one of the thirteen months. When he turns into a werelizard, he gains [TRAPAVOID], deactivating the plate and causing nothing of importance to happen. When he turns back, however, he retriggers the plate, opening the hatches and sending the minecart into motion.
Green arrow: When the mechanism is activated, the minecart drops through the hatch it is sitting on, runs over the pressure plate on Z-1, then takes an impulse ramp back to level Z. This pressure plate closes a hatch located in the red box. The minecart follows the loops, waiting for that hatch to close, then it hits the...
Blue box: This is another impulse ramp which ensures the minecart hits the upcoming pressure plate at high speed. Hitting the plate at high speed ensures that it either an on signal (if the bridge is off) OR an off signal (if the bridge is on), but never both. The plate is linked to the bridges spelling out the name of the month, in this case Obsidian.
Red box: The hatch in this square (which will be closed by the time the minecart gets here) is the starting point for next month. The werebeast will trigger its opening and send the cart down a functionally identical track.
If you've followed my description carefully, you've probably noticed something is missing. If the cart prints the name of the current month, then next month it prints the name of the next month, and so on. But what happened to the text that was already there? Originally, I had planned for the minecart to trigger a fairly complex reset loop, but then I realized that there was a a solution which required no extra machinery: add another minecart. If you look at the large screenshot of level Z, you'll see two minecarts, one blue and one brown. The brown cart follows the blue one, always one month behind. That means that whatever bridges the blue cart turned off (and thus made visible), the brown cart will turn them on ("erasing" them) next month.
Needless to say, this calendar is totally useless, but the werebeast-triggering mechanism could be applied in useful ways. For example, perhaps you could pasture livestock around a bridge which is tied into the werebeast system. You could set it to retract automatically every few months, dropping several of the animals down a deep shaft, exploding them for maximum yield. It should make for an efficient and fully automatic meat and leather industry. I'd love to hear some of your ideas for what to do with the system.
Mapping the region onto the resulting sphere shows what I though I would see. The world map shows approximately 1/8 of the total global surface for this worldgen.
As expected the map gets smooshed what good when mapped onto the sphere's surface.
It however looks pretty sexy otherwise.
(http://i186.photobucket.com/albums/x248/wierdw/dfGlobe_zps5d0a8b20.png)
I need to find the best way to project this map
The 45 degree measure is from the centerline of the map, to the two extrema, as mapped from the equatorial line. The faint red line is the measured 30 degree light angle line, where solar energy delivered to the surface is 50% of what is delivered directly to the equator. The white elipse, is the equator projected around the whole sphere.
A possibly better projection would be a cubic projection, but that wouldn't have the 30 degree inclination line in the correct location.
Ok, I am quite confident in my calculations now.
I have genned many many many more worlds that are large islands for cross comparison. Some have been southern hemisphere regions. Not a single one has had the equator in the middle. When stitched together, these worlds all have the same banding patterns for biomes, with a conserved equator.
(http://i186.photobucket.com/albums/x248/wierdw/DFPlanetRender_zps01c7f6ad.png)
The planets produced really are just that small.
I am in the process of stitching 8 such regions together (4 northern, 4 southern) to map onto my sphere to get a sample planet.
I've started doing hour-by-hour temperature measurements in a new large world. Here's how I'm conducting the measurements.
(http://i.imgur.com/witLjjC.png)
This is Catig Strangleforded, the flying bronze colossus climatologist. I'll be sending him to interesting locations around the world to measure the temperature. The plan is to wait until dawn, read the temperature with dfhack's probe command, wait one hour, probe, etc.
To start, I chose to measure the temperature at the southern edge of the map, which is 100% ocean in this world. There were some frustrating technical issues. When crossing the ocean, there was a 5-10 second lag spike every 3-5 seconds, so in the end I had to tape down the DOWN key and walked away for a while. To use the wait command, I had to use tiletypes to make a solid platform to stand on. After waiting, the platform would disappear, and I would find myself half a screen from the map's edge. To move back to the edge, I had to endure another 10 seconds of lag each time, then I had to remake my waiting platform. Due to these inconveniences, I only tooks two days worth of readings. Here's a plot of the data:
(http://i.imgur.com/5tXKLUz.png)
Day 1
1: 38
2: 47
3: 56
4: 60
5: 63
6: 67
7: 71
8: 72
9: 72
10: 72
11: 72
12: 72
13: 67
14: 58
15: 47
16: 38
17: 36
18: 36
19: 36
20: 36
21: 36
22: 36
23: 36
24: 36
Day 2
1: 39
2: 47
3: 56
4: 60
5: 63
6: 69
7: 71
8: 72
9: 72
10: 72
11: 72
12: 72
13: 66
14: 56
15: 47
16: 36
17: 36
18: 36
19: 36
20: 36
21: 36
22: 36
23: 36
24: 36
Hour 1 is dawn. Values on the graph are actually temperatures in Urists minus 10,000 U. For example, a temperature of 10,038 U will be displayed as 38.
As you can see, the data was pretty much the same on both days. The graph is surprisingly asymmetrical. The temperature rises relatively slowly and non-linearly in the morning, but falls quickly and linearly in the evening. The temperature plateaus in the afternoon and night, but the night-time plateau is almost twice as long. It will be interesting to see if this pattern hold in other regions, as well, and even more interesting to investigate why the temperature should behave this way.
wierd: A Joule (J) is 1 kg * m2 * s-2. You're thinking of calories: 1 cal is about 4.2 J, 1 Cal or kcal about 4.2 kJ.
Also, I'm kinda skeptic about some of your claims about the plateaus making sense. Ocean water is pretty stratified, with only limited mixing between layers. For a very simple model, heat is transferred between layers and between the surface&atmosphere by heat transfer rate being relative to the temperature difference (for pure blackbody radiation/absorption, it would actually be the Stefan-Boltzmann law i.e. the difference between the 4th powers of the temperatures), so that cooling/heating is always fast at first and then slows down.
Well ok, the plateau makes sense, since the later slow cooling/heating could indeed look like a plateau, but it should be symmetric, not asymmetric as with the data. The plots look more like heating is just turned off at dusk, and the temperature drops linearly, as itg said. Also, whereever the measurements were made, it was (or should have been) summer at the time, since dusk occurred 16 hours from dawn. Also, on Earth, a daylight duration of 16 hours at summer solstice corresponds to roughly 48 degrees North/South. Which is a bit south of Paris, about the same as Munich, Vienna, Ulanbaatar, or a tad North of Seattle. Or about 150km South of New Zealand's South Island (pretty much open ocean all around the Earth, with the exception of southern Argentina/Chile).
Since insolation follows a sinusoidal curve over the day, I'd claim that average daily temperatures (so excluding weather effects, which DF doesn't have AFAIK) are also nearly sinusoidal, e.g. with this plot of water temperature over a year (the yearly plot is analogous to a daily one, which I had trouble finding just now).
(http://maracoos.org/blogs/main/wp-content/uploads/2012/04/baytemps.jpg)
What the large heat capacity or specific heat capacity (2 different things) does is delay the increases/decreases in water temperature compared to the insolation maxima/minima: solar heating is at it's smallest at the end of December, and at it's greatest at the end of June, and yet in the above "warm" coastal area water temperature plot, the sea water reaches it's temperature minimum in late January/early February, and it's maximum some time in August. The greater the specific heat capacity of the material, the bigger the delay. And if we include mixing/conduction of heat deeper into the material, the heat capacity and thus the delay grow. A sand desert (which also transmit heat downwards into the earth really badly, IIRC) would react quickly to changes in solar heating, both over the day and over the year, whereas oceans are pretty much the slowest thing to do so found on earth (possibly beaten at times by moist forests, both tropical and temperate).
So, from the data we know that:
- There are set "target" maximum (daytime) and minimum (nighttime) temperatures.
- Heating is either sinusoidal or logarithmic, but cooling is linear.
- Daylight hours are a bit whack; if the hot edge of the map gets 16 hours of daylight, even if it's only at the summer solstice, that would mean the equator is actually still quite a ways off, and probably quite !!FUN!! (what's called a scorching desert in DF would probably feel refreshing after a walk at the equator).
Since sand deserts came up in the discussion, I decided do the next set of measurements in the nearest desert region. I found a nice one not far from the southern tip of the nearest land mass, probably about 10% of the way to the north pole. Later, I'll try to put together a map with the measurement locations marked on it. I did three days worth of measurements this time. It appears the temperature curve ought to be identical from day to day. The small day-to-day differences were caused by bandit attacks, which threw off the timing of subsequent measurements.
(http://i.imgur.com/A1Osxrk.png)
16th Ma 17th Ma 18th Ma Avg
1 30 30 30 30
2 40 40 40 40
3 51 51 51 51
4 55 55 55 55
5 59 59 59 59
6 63 63 63 63
7 68 68 68 68
8 69 69 69 69
9 69 69 69 69
10 69 69 69 69
11 69 69 69 69
12 69 69 69 69
13 69 68 69 68.6666666667
14 63 57 61 60.3333333333
15 53 55 51 53
16 42 45 40 42.3333333333
17 32 34 30 32
18 27 27 27 27
19 27 27 27 27
20 27 27 27 27
21 27 27 27 27
22 27 27 27 27
23 27 27 27 27
24 27 27 27 27
Readings were taken starting on the 16th of Malachite (official calendar). Bandit attacks occurred on hour 9 of the 16th, hour 15 of the 17th, and hour 9 of the 18th. The temperature data looks similar to the ocean biome data, but the temperature plateaus are closer in length. Both regions reached maximum temperature 8 hours after dawn, but the desert stayed at max temperature one hour longer than the ocean did. The cooling period took the same number of hours in both regions, so the ocean biome had to spend longer at the low temperature plateau. Is the difference between the temperature curves due to biome or to latitude? More measurements will tell.
By the way, the ocean measurements were taken on the 11th and 12th of Malachite (official calendar).
Pictures look great. I'll have to think about this later. In the meantime, here's temperature data from a second desert, a day's rampage north of the first one:
(http://i.imgur.com/DzQ2eEN.png)
1 29
2 40
3 51
4 55
5 60
6 64
7 69
8 70
9 70
10 70
11 70
12 70
13 69
14 57
15 47
16 36
17 27
18 27
19 27
20 27
21 27
22 27
23 27
24 27
This is data for the 20th of Malachite. As there was no interference with the measurements, for a change, I only had to do one day's worth. No surprises here, but, in addition to the plateaus, this is the third location out of three with a "hump" in the curve at hour three. At this point, I'm comfortable saying that hump is clearly a feature of DF's temperature model, not an artifact of my measurements.