EmperorPingu Posted December 29, 2025 Report Posted December 29, 2025 (edited) Mod Title: Celestial Navigation (and clockwork) Mod Version: Current (with polite request to update periodically to latest version as necessary) Commission: Yes but... you should consider the following: I can only put $100 towards the project. I have a big move coming up so it might be a couple months until I can pay you (sorry but rent gotta come first). The amount of hours needed to pull this mod off I imagine would be quite a bit and might honestly not be worth your while if doing just for the money, so if you take this on it should probably be for the love of the game, the mod, or for modding in general. Because of part 3^ I invite any non-modder out there reading this who likes the sound of the mod I'm requesting to use the comments below to pledge towards this mod getting made, but I want to make clear to the modder who takes on this project that I am in no way responsible in any form for the pledges made by others, only for the $100 I've already mentioned. Feel free to have a go at making this mod or any component of it on your own if you like, but know that I will only be choosing 1 modder (or mod team) to commission in order to not mess people about. I will likely choose this modder based on experience, enthusiasm, and reputation. Price Range: $100 + Celestial Navigation (and clockwork) Celestial Navigation is a complete overhaul of the mapping, coordinate, astronomy, and time-counting mechanics of Vintage Story. There are a few pretty decent mods out there already that have some of the elements I describe, but none of them have quite everything I am looking for. The basic premise of this mod is that the player cannot know or record their time or location without physically engaging with the world around them in a navigationally realistic way - because of this, a lot of caveats and features need to be considered in order to make this mod work as intended. If you are reading this to get an understanding of what the mod is, you may prefer to read the suggestion page I made to compliment this post which summarises the mod and explains the main points without getting into too much technical jargon. This page is primarily for those interested in how the mod itself would work, or those who are considering actually producing it. Feature 1: Realistic Cosmic behaviour There are many features to this mod - undoubtedly the most difficult with regards to implementation will be that of realistic cosmic behaviour. I ran actual dozens of hours of investigations and tests and the bottom line is: The cosmos in Vintage Story is not reflective of realistic behaviour. This isn't just a case of the nightsky having different constellations for lore reasons either - this includes things like the rotation of the cosmos being mathematically inconsistent even to the construct of it's own universe (devs - if you're reading this, send me a message and I'll show you what's up). It means that we can't make our Navigation mod with what Vintage Story already has, so we're literally going to have to rewrite the game logic from the ground up in order to get what we want. I can give you the mathematics you'll need to make it work, but you're going to have to do the modding and coding (I cannot mod or code for fertiliser). First things first - destroy the Sun, destroy the Moon, and obliterate the Universe. The Cosmos we're going to make is going to exist "around" the player (using their eye-level as the centre of origin), in this way each player will have there own unique sky textures that revolve around them - this way we can use their position as a reference for what the sky is supposed to look like. Naturally we're not going to make it massive but the celestial textures need to be behind everything else that is generated in the game so we don't just end up seeing the heavens through the ground etc. We're going to need to create 3 spheres that exist around the player: - The Star-sphere - The Sun-sphere - The Moon-sphere For the Star-sphere we're going to want a texture of the real cosmos - this can be photographic or artistic - either way, it should be accurate and visually aesthetic (don't ask me why we're not using the in game constellations, I spent more than 6 hours trying to answer that question). With the Sun-sphere and Moon-sphere textures, it's more going to be a case that you have a texture for those objects and that the rest of the sphere is transparent with the sky and star-sphere opacities being changed depending on the Sun's position in the Sky relative to player (as will be discussed later). Polar coordinates Now, to make this work we need to work in (psuedo) polar coordinates because the in game x, y, z coordinates won't tell us directly where our celestial bodies should be relative to our player. We basically need to work out where the player is relative to the actual (simulated) equator of the map, and the poles. The "North pole" has to be 90° north of the equator in our "polar" coordinates in such a way that when the player goes to where the North pole is meant to be then 90° is the reading of their position on the "z axis", and at the equator they are 0° (north or south of the equator). Here's how we work it out: Let: q = equator to pole distance (as defined by the world config or initial settings) x[p] = the actual x coordinate of the player y[p] = the actual y coordinate of the player z[p] = the actual z coordinate of the player c = starting climate number where: Hot climate: c = 0 Warm climate: c = 0.25 Temperate climate: c = 0.5 Cool climate: c = 0.75 Icy climate c = 1 φ[p] = the "pseudo-polar" latitude number to replace "z" (in degrees) λ[p] = the "pseudo-azimuth" longitude number to replace "x" (in degrees) ζ[p] = elevation of the player above sea level (in metres) --- The three numbers, φ[p], λ[p], and ζ[p], represent the players coodinates and can be used for many other areas of the mod that we wouldn't be able to do with the xyz coordinates, such as enabling us to callobrate the cosmos to act realistically respective to where the player is on the world map. φ[p] represents where the player or location is on the north-south line, λ[p] represents the east-west line, and ζ[p] represents elevation respective to sea level. They are calculated as follows: φ[p] = 90 * ((-z[p] + (c * q)) / q) λ[p] = 90 * (x[p] / q) ζ[p] = y[p] - 110 Star-sphere axial tilt So you know how in real life the Earth spins on it's axis and when we look up the stars they always look like they're revolving around one point? That's what we're going to simulate. In real life, if you were to go to the North pole and look straight up you would see all the stars revolving around Polaris (the North star). At the South pole looking straight up (or down?) you would see the Southern Cross. On our in game Star-sphere, we need to run an axis going between Polaris and the Southern cross so that when it "spins" at night, it spins about those 2 points like a ball on an axel. That Star-sphere axis will be tilted itself along the φ (north-south) axis depending on where the player is on the map - visually this will simulate seeing Polaris or the Southern Cross at different points in the night sky depending where one is standing. If the player is on the equator (φ[p] = 0°), then we want the player to see Polaris on the horizon in the northern direction. If the player is at the North pole (φ[p] = 90°), then we want the player to see Polaris straight above them. Imagine the player walks from the equator to the North pole, as they do so the axial tilt of the star sphere should slowly rotate towards them about the x-axis. At φ[p] = 0°, the Star-sphere axial tilt should sit cleanly on the φ-axis. As φ[p] increases, the angle between the star-sphere axial tilt and the φ-axis increases by φ[p]° (clockwise about the φ-axis). At φ[p] = 90° the star-sphere's axis will sit cleanly on the ζ-axis. Star-sphere axial tilt = φ[p]° Star-sphere axis So the star-sphere texture is going to rotate about the star-sphere axis every night right? We want this texture to spin at a rate of about 1 more revolution than the number of days in our in game year - this is because as the Earth orbits around the Sun, it has to spin about it's axis a little more each time in order to bring the Sun back up (in Solar days) relative to it's rotation with respect to the distant stars in the background. Basically if the year was exactly 365 days (it's not but that's not the point here and the difference is nominal), you would see the cosmic background revolve about you 366 times. Devs: when you did this in Vintage Story you did 1 fewer rotation than the number of in game days when it should have been 1 more - it just wouldn't happen like that with the Sun rising in the East unless the world at some point reversed it's direction of orbit for lore reasons... m[sun] = days per in game month rev[year] = number of revolutions the star-sphere should do about it's axis per in game year (from the player's perspective) rev[day] = number of revolutions the star-sphere should do about it's axis per in game day (24 hours) Crunching the numbers gives us: rev[year] = m[sun]*12 + 1 rev[day] = (m[sun]*12 + 1) / (m[sun]*12) Converting that into an angle gives us: Star-sphere axial rotation per in game day (degrees) = (((m[sun]*12 + 1) / (m[sun]*12)) * 360)° Star-sphere axial rotation per in game hour (degrees) = (((m[sun]*12 + 1) / (m[sun]*12)) * 15)° Star-sphere axial rotation per in game minute (degrees) = (((m[sun]*12 + 1) / (m[sun]*12)) * 0.25)° Star-sphere axial rotation per in game minute (radians) = ((m[sun]*12 + 1) / (m[sun]*12)) * 𝛑 / 720 Since the game starts in early May we should have our starting position reflect that. At polar coordinates (0, 0) (φ, λ), at Sunset (18:00) the constellation Orion should be lying very low in the West and Scorpio should be prominent in the East. Since the day starts at 8:00, we will want to reflect that on the start of a new world. So, since the stars appear to move westward in a usual sense we'll want to rotate the stars eastward (from their position at 18:00) about the star-sphere axis by 150° - this will be the starting position of of the star-sphere on a new world that then will line up the constellations as they should for that time of year. --- Now... for reasons that will take too long to explain right now (wait until later) we don't want the rotation angle of the stars to be the same wherever anyone stands on the East-West axis. In order to make things like the chronometre work, we'll need the sun to rise and set at different times depending where someone is on the map. Consider that an entire revolution of Earth is represented by 24 hours. Consider also that the polar-equator distance is 1/4 of the worlds circumferance (assuming the Earth is spherical, it's not but just go with it). This means, if someone were to travel the polar-equator distance around the Earth westward, their sunrise, middays, and sunsets would be 6 hours behind than if they were to stay put. We will of course be reflecting this in the Suns observation, but it needs to occur for the Star-sphere as well because basically everyone sees Orion in the West at their sunset in the start of May on the equator - but if we program the sun to set at different times depending on λ coordinate, then thats because within the space of 1 irl day where the Sun and stars are relative to the person on Earth is relatively static and unchanged regardless where they are. Basically, we need to factor in that local time on the map should affect the rotation of the star-sphere to the player because as the Sunset catches up to those who are more westward, the background stars should look more or less the same at the point of sunset (even if being on different positions of the planet they would see different constellations at the exact point in time but then as the planet rotates the simulated sunsets with background stars are the same). It's really more about relativistic position but the math adds up. I don't think I've explained that very well, but just make sure that once you've determined where the star sphere starts at (0, 0) you apply the following equations: t[p] = the local time of the player (in in game "minutes") t[g] = the actual in game "global" time that has elapsed since the start of the game (in in game "minutes") - this will always be the time at λ = 0. t[p] = t[g] + (λ[p] * 4) Double checking our numbers we can see that if it was 20:00 on May 1, first year, at λ = 0... then 600 minutes would have elapsed of in game time. If the player had a position of λ = -90 (representing 90° west), then their local time would be: 600 + (-90 * 4) = 240, or -360 minutes (- 6 hours) than at the equator, making their local time 12:00 which is what we expected. For each degree east or west of the prime meridian (λ = 0) that the player travels, the star-sphere must also rotate by that amount in order for everything to work properly - it doesn't happen like this in real life, but in order to simulate everything properly it does have to be a case that the more the player walks west on the map, the further "back in time" they travel. Because the star-sphere's axial rotation can be determined by east-west position, we don't actually need to use the player's local time in order to derive it. So long as you have set the star-sphere texture in the correct starting position, you can determine how much it should have rotated about it's axis using the amount of true in game time that has elapsed and the east-west (λ) coordinate of the player. Star-sphere angle of rotation (degrees) = ((t[g] * (((m[sun]*12 + 1) / (m[sun]*12)) * 0.25)) + λ[p])° Star-sphere angle of rotation (radians) = (t[g] * (((m[sun]*12 + 1) / (m[sun]*12)) * 𝛑 / 720)) + λ[p] Sun-sphere Note: I got waaay stuck on the mathematics in this section so I used chatgpt to work it out and explain this part. As such they might get it wrong but in any case we're trying to make accurate Sun position based on the players location, and we're trying to replicate seasons too. It looks like it makes sense, but proceed carefully and double check. Our next task is to implement the Sun-sphere. In real life, the Sun doesn't line up to it's zenith at 12:00 every day, but we're going to do 3 things that don't happen irl: We're going to make it so that the Sun is at it's highest at 12:00 everyday. We're going to make it so there is an exact number of days every year (irl, each year is closer to something like 365.24 days per year). We're going to line up the sostices and equinoxes so that they happen at the turn of each month (irl the winter solstace is the 21 December). In our construction, the Winter solstice will be on January 1 at 00:00. The Summer solstice will be July 1 at 00:00. So the Sun has to have two angles relative to the player: Altitude → how high it is in the sky (0° at horizon, 90° straight up) Azimuth → compass direction (0° North, 90° East, 180° South, 270° West) The position of the Sun depends on two things: The time of day (local solar time) The season (which controls how far north or south the Sun is) Step One: Determine date position (Season progress) Let: m[sun] = days per month Y = 12 * m = days per in game year m[i] = current month index (january = 0, May = 4 etc.) d = day of the month 0 to m[sun]-1 t[g] = global time elapsed since world creation (in minutes) Because the game starts on May 1 at the Prime Meridian (λ = 0) we define a starting offset as: T[0] = 480 (minutes) Defining a "global" time of day: t[day] = (t[g] + T[0]) mod 1440 Longitude correction so each player has a local time: t[local] = (t[day] + 4 * λ[p]) mod 1440 This way, each degree of longitude = 4 minutes, with East being later and West being earlier. This helps us ensure two players in different areas experience different solar times. Now we determine where we are in the year: D = m[i] * m[sun] + d + (t[day] /1440) Step Two: Seasonal Movement (North - South Sun Shift) The Sun moves north and south during the year by an angle called declination, simulating seasons. Let: δ[max] = maximum solar latitude (default: 23.5°) Then: δ[sun] = −δ[max] * cos(2π * D / Y) From this we'll have a negative in January giving a Southern hemisphere Summer, positive in July giving a Northern hemisphere Summer, and 0 at the equinoxes. It'll make days longer in summer and shorter in winter (apparently). Step Three: Sun's daily rotation (East-West movement) We base how far the Sun is from local noon based purely on time of day. Sun rotates 360° every 1440 minutes which is 0.25° per in game minute. We define the Solar Rotation Angle as: H[sun] = 0.25° * (t[local] - 720) Because: 12:00 (local) = 720 minutes → H[sun] = 0° 06:00 (local) = 360 minutes → H[sun] = -90° (rising in the east) 18:00 (local) = 1080 minutes → H[sun] = 90° (setting in the west) Midnight (local) = 0 or 1440 minutes → |H[sun]| = 180° At game start / world creation moment: t[g] = 0 λ[p] = 0 t[day] = 480 t[local] = 480 So: H[sun-start] = 0.25° * (480 - 720) = -60° The Sun begins 60° before it's noon position which is correct for 8:00. Step Four: Sun's position in the Sky Using the players pseudo-latitude: φ[p] = 90° * (-z[p] + (c * q)) / q We compute the altitude (height above the horizon): sin(a[sun]) = (sin(φ) * sin(δ[sun])) + (cos(φ) * cos(δ[sun]) * cos(H[sun])) a[sun] = arcsin(sin(a[sun])) a[sun] = angle above the horizon (0° to 90°) So when: a > 0 → daytime a = 0 → sunrise/sunset a < 0 → night Then we compute the Azimuth (compass direction, clockwise from north): sin(A[sun]) = - (cos(δ[sun]) * sin(H[sun])) / cos(a[sun]) cos(A[sun]) = ((sin(δ[sun]) * cos(φ)) - (cos(δ[sun]) * sin(φ) * cos(H[sun]))) / cos(a[sun]) Finally we convert it all to a direction vector in game coordinates: S[x] = cos(a[sun]) * sin(A[sun]) S[y] = sin(a[sun]) S[z] = cos(a[sun]) * cos(A[sun]) This^ is the point on the Sun-sphere where the Sun texture should be drawn. Summary for Developers: Time system t[day] = (t[g] + 480 mod 1440) t[local] = (t[day] + 4 * λ[p]) mod 1440 Sun Angle H[sun] = 0.25° * (t[local] - 720) Season δ[sun] = −δ[max] * cos(2π * D / (12 * m)) Sky Position sin(a[sun]) = (sin(φ) * sin(δ[sun])) + (cos(φ) * cos(δ[sun]) * cos(H[sun])) Moon-sphere Had to use chatgpt for moon stuff too but like before I'll go through it to make sure it all works out. Moon time. We want to build the Moon-sphere so that it: Has proper phases Moves differently from the Sun (rises later each day) Allows partial and total eclipses depending on player position Can give a percentage of Sun coverage for light dimming Is not too predictable (eclipse paths drift over the years) m[sun] = days per in game month Y = 12 * m t[g] = global elapsed time in minutes since world start T[0] = 480 minutes (starting offset (world starts at 8:00 at λ = 0)) t[day] = (t[g] + T[0]) mod 1440 t[local] = (t[day] + 4 * λ[p]) mod 1440 δ[sun] = −δ[max] * cos(2π * D / (12 * m)) H[sun] = 0.25° * (t[local] - 720) φ[p] = player latitude Moon specific parametres: L = Lunar month to solar month ratio (default: 0.97) m[moon] = Length of the Lunar cycle in days i = orbital inclination of Moon relative to the Sun's path (e.g. i = 5°) P[node] = nodal precession period in days (e.g. many years, like P[node] = 18Y) [seed] = world seed → used to pick an initial nodal angle Apparent sizes (in degrees, as seen in the sky): R[sun] = angular radius of the Sun (e.g. 0.27°) R[moon] = angular radius of the Moon (usually set as equal to Sun) These Radii drive how "big" they look and how strong eclipses are. Lunar cycle and phase ω = Lunar cycle fraction ϕ[0] = a phase offset chosen from the world seed so different worlds don't start with the same Moon phase m[moon] = L * m[sun] ω = ((D / m[moon]) + ϕ[0]) mod 1 Define Lunar phase angle: Φ = 2π * ω Φ ≈ 0 → New Moon Φ ≈ π → Full Moon Illumination fraction of the Moon's Disc: f[moonillum] = (1 - cos(Φ)) / 2 0 = completely dark (New Moon) 1 = fully lit (Full Moon) Moon's Orbital Geometry: declination and "hour angle" We want the Moon to: Drift eastward against the stars → rises later each day Wander a bit north and south around the Sun's path → allows rare eclipses Have eclipse seasons that slowly drift over many years → not trivially predictable Define the Moon's mean orbital angle (like it's ecliptic longitude): θ[orbit] = 2π * (D / m[moon]) This completes one full turn every m[moon] days. Define a line of nodes (where the moon's orbit crosses the Sun's path). This line slowly rotates (precesses) over many years: Θ[0] → chosen from world seed P[node] → large (e.g 18 years → 18Y days) Θ[node](D) = Θ[0] + (2π * (D / P[node])) This constant slow drift is what makes eclipse seasons move, so total eclipses happen at different longitudes and latitudes in different years instead of forminga perfectly repeating patterm. Latitude offset of the Moon relative to Sun's path Define a latitude offset β (how much above/below the Sun's path the Moon is): β = i * sin(θ[orbit] - Θ[node](D]) So: When θ[orbit] ≈ Θ[node], β ≈ 0 → Moon near Sun's path (eclipse season) Otherwise: Moon passes north or south of the Sun so no eclipses Define the Moon's declination: δ[moon] = δ[sun](D) + β This means the Moon oscillates around the Sun's path with amplitude i. Moon's daily rotation angle H[moon] We want the Moon to move across the sky like the Sun, but with a daily lag so it rises later each day. The Moon completes one cycle relative to the Sun in m[moon] days, so each day it gets ahead/behind by: ΔH[perday] = 360° / m[moon] Over D days that gives a relative offset: ΔH(D) = 360° * D / m[moon] Then we define: H[moon] = H[sun] + ΔH(D) Everything is understood modulo 360°. This ensures: Within one day, the Moon and Sun rotate together (both see 360° of diurnal motion From one day to the next, the Moon's position at a givenclock time is shifted eastwards by 360° / m[moon] Moon altitude and azimuth, and direction vector Same as Sun pretty much but with moon variables. Altitude: sin(a[moon]) = (sin(φ) * sin(δ[moon])) + (cos(φ) * cos(δ[moon]) * cos(H[moon])) a[moon] = arcsin(sin(a[moon])) a[moon] = angle above the horizon (0° to 90°) Azimuth: sin(A[moon]) = - (cos(δ[moon]) * sin(H[moon])) / cos(a[moon]) cos(A[moon]) = ((sin(δ[moon]) * cos(φ)) - (cos(δ[moon]) * sin(φ) * cos(H[moon]))) / cos(a[moon]) Finally we convert it all to a direction vector in game coordinates: M[x] = cos(a[moon]) * sin(A[moon]) M[y] = sin(a[moon]) M[z] = cos(a[moon]) * cos(A[moon]) Eclipses Sun Direction vector → S = (S[x], S[y], S[z]) Moon Direction vector → M = (M[x], M[y], M[z]) Compute the angle between the two vectors (ψ): cos(ψ) = S * M = (S[x] * M[x]) + (S[y] * M[y]) + (S[z] * M[z]) ψ = arccos(cos(ψ)) Eclipse geometry using apparent radii R[sun] = angular radius of the Sun (how much of the sky it takes up, e.g. a radius of 1° means the Sun will be 2° across proportional to the sky's total 360°) R[moon] = angular radius of the Moon A given player sees some kind of Solar eclipse if: The Sun is above the horizon → a[sun] > 0 The Moon is roughly in front of the Sun (near New Moon, automatically handled by the geometry here) The discs overlap → ψ < R[sun] + R[moon] Then: If ψ ≥ R[sun] + R[moon] → no eclipse If ψ ≤ |R[sun] - R[moon]Z| → central eclipse (total or annular) Otherwise: Partial eclipse Fraction of the Sun's disc covered: Treat Sun and Moon as circles of Radius R[sun] and R[moon] in a plane, separated by distance d = ψ. The area of overlap between two circles is the formula: If d ≥ R[sun] + R[moon] → A[overlap] = 0 If d ≤ |R[sun] - R[moon]Z| → A[overlap] = π * (min(R[sun], R[moon])^2) Else: The fraction of the Sun's disc covered is: f[cover] = A[overlap] / (π * (R[sun]^2)) Then the engine can do: lightscale = 1 - (f[cover] * S[eclipse]) where S[eclipse] ∈ [0, 1] is a tuning parametre (how dark a total eclipse gets) So... f[cover] ≈ 0 → No change f[cover] ≈ 1 → almost total blackout (limited by S[eclipse]) Because ψ is computed per-player from their position, every player can see a different coverage. Near the central path: ψ is tiny → total eclipse Offset: ψ is moderate → partial eclipse Far away: ψ is greater than the sum of the Moon and Sun's radii → No eclipse All at the same global game time. Controlling rarity and unpredictability Eclipses need 3 things: Right phase (Moon near Sun in it's cycle) Right latitude (Moon near Sun's path) Right local position (Player close to central alignment line) The model gives: i (inclination): smaller i → more frequent eclipse seasons larger i → rarer eclipses m[moon] → different values shift how often New Moon aligns with node crossings P[node]: Larger value means slower nodal drift → eclipse paths change slowly over many years Θ[0] → wach world has a different nodal alignment, so patterns won't repeat across seeds. So we get: Local eclipses that are different for different players Total vs partial handled automatically by geometry Light dimming exactly proportional to overlap Long-term drift in which regions get totality --- --- Okay... So I've gone through it, and whilst doing so I was making concerted efforts to understand the maths of it, but it was quite heavy even for me (took me literal days even with chatgpts help). It looks like it makes sense, but I have no true way of knowing unless I was to actually simulate it itself which I can't because I can't code. It looks like it adds up but you may want to check the maths and the numbers yourself because I can't guarantee with certainty that these numbers will necessarily add up the way we hope. There's also the fact that there may be more efficient methods for calculating much of this. If you do end up implimenting this system you may want to make your own notational conventions that make more sense in coding - these are just the ones I came up with and I'm sure they look terrible - I've tried to keep consistent but you do you on this front. So long as the code can handle all the numbers without being too much of a drain on the game engine's internal resources, it should be okay. From here, you will also need to determine the vectors for Polaris and the Southern Cross points as they will come up later when using various Navigational instrument designs (In a nutshell, if the viewing vector whilst using a specific instrument lines up close to one of those vectors or the Sun/Moon vector (depending on instrument used), this should bring about the right kind of check needed in order for those instruments to work. You may also want to double check the coding related to seasons, temperature, and light levels, to make sure they are all working properly and as expected with the new mechanics. At this point it's up to you if you would like to do anything else with the actual "Celestial" part of this mod, but you can just leave it here. I mean, if you've already made a model simulation of the Universe as seen from Earth - what's a few shooting stars and orbitting planets amiright??? Using similar math as we've discussed you could probably simulate Lunar eclipses as well. Use a gif as the star-sphere texture and you could probably have some twinkling stars as well perhaps? Maybe a drop in temperature during total eclipses would be a neat feature? These things together could add collectively to a more immersive astronomy aspect to the game (like telescopes etc) - something which would totally go well with this mod considering that other aspects of the game require glass/lens making anyway. From here the rest of the features will be nowhere near as complicated, but some could be a little tricky to impliment. $100 is $100, but like I said, to make this mod you're really gonna have to do it for the love of it. You can also be rest assured that this will be the absolute best navigational mod out there without any competition or comparison. Feature 2: Time and date inaccessible by default We're making an entire mod around the idea that position and time cannot be determined without a realistic mechanism. Go ahead and scrub that from the player GUI. A part of me wants to add a scrubbing of the temperature variables as well, but we'll save that for the Immersive Temperature mod (yeah we ain't doing that today)... Feature 3: Placed objects are player orientated As will be described later, the player will have the ability to make a compass that they can use to determine their cardinal direction. A common trick many players already use to determine cardinality is to place an unknapped flint or stone on the ground which can give the player this information - for example, when going to knap a flint knife or spearhead, the outline object to be knapped points west on the ground. We want to remove this capability so the player cannot determine cardinality unless they: A. Make a compass. B. Look at the Sun or Moon. C. Look at Sunflowers. This means we'll want to make it so that when an object is placed it is based on the direction that the player is facing and not on the global axes. I suspect that it might be easier to configure this somehow globally for all placeable items - this could then be used automatically on modded placable items without issue (I guess?). For this feature, we'd probably want to consider how flint and stones are placed, how they are placed when in "knapping" mode, how items being clayformed are placed, how regular items placed on the ground are oriented, how ingots are placed on the furnace, how heated ingots are placed on the anvil etc. Sounds silly and I'm probably being a bit too anal about it but I think it best if we can remove as many of these "unnatural" indicators as possible. This might also include things like the way planks and other blocks are placed cardinally as well, or how dirt is tilled. The only other unnatural indicator I figured could be an issue with this feature is the 2x2 square used during clay forming which in theory could be used to indicate cardinal direction - realistically though, most players won't be this pedantic. Unless this 2x2 grid can also be trivially configured to also be player oriented, my suggestion would be to have an option in the modconfig that enables or disables 2x2 clayforming. Feature 4: Dynamic Sunflowers Our next feature is a retexturing of Sunflowers. Sunflower drops and growth rates are completely unchanged and should be handled by other areas of the game or other mods. What we want is for Sunflowers to react to the position of the Sun. So... there are 12 stages of growth for the Sunflower... for each of those stages (except maybe the seedling and sprout ...) we're going to want the Sunflower to be in 1 of 11 different positions depending on where the Sun is relative to the Sunflower.... The easiest way to do this will probably be from using our Sun vector from earlier. Each Sunflower from growth stage 4 should have it's own head that points towards the Sun according to that vector if the Sun is above the horizon. We can also use the Sunflower's own position to indicate where it should be pointing, but it may be easier on the engine if the players own already computed vectors are used. If the Sun is below the horizon, then we want a slow return for each Sunflower to return back facing east over the course of the night. The growth stages of the Sunflower: Feature 5: Primitive compass Take either an iron, meteoric iron, or steel nails and strips - take 1 of these items and put it in your crafting grid to get 4 * iron / meteoric iron / steel nails respectively. Place 1 nail on the ground or hard surface like a table. Now, with a magnetite nugget, shift and hold right click over the the nail - do this for a couple seconds until the nail pops into your inventory as a "Magentised" iron / meteoric iron / steel nail. Now, take a parchment and cut it into parchment strips - you get 8 parchment strips if you cut the parchment with a knife. Now place a ceramic bowl with water onto the ground or hard surface and place a parchment strip into the ceramic bowl... an internal timer will start and you will have 3 in game hours until the parchment strip disintegrates. Within that time, place the magnetised nail onto the ceramic bowl with parchment strip. It will take a few seconds, but eventually the nail will point north. After the internal timer for the parchment strip has run out, you will be left with a ceramic bowl with water and a magnetised nail inside it (because the parchment strip has dissolved...) which you can pick up to return the bowl and the magnetised nail with a little less durability than before. The parchment will also disintegrate if you pick up the bowl / primitive compass before the timer has run out returning the bowl of water and the magnetised nail with less durability. If you would like to repeat the process you will have to produce the setup again. After the magnetised nail has run out of durability, it will turn into a rusty nail (which doesn't do anything - maybe 8 of them can be turned into metal scraps?). The steel magnetised nail has more durability than the meteoric iron which has more than the iron. Ceramic Bowls: Dark Brown Fireclay Black Brown Cream Gray Orange Red Tan Unfortunately there wasn't a "leaf" in the vanilla base game, otherwise I would have suggested incorperating this somehow as well. I did think about the potential for utilising dry grass instead of parchment strips, but the model of dry grass as it stands is massive compared to the bowl and I don't think would be of a decent aesthetic as is unless something changes with vanilla grass harvesting (not asking for it). With that said, being forced to make parchment could utilise the paper making aspect of the game more so in terms of ridiculously long grindy progression, I'm not completely against parchment strips being the only "floaty" thing for primitive compasses for now. Feature 6: Compass The compass is the next step up from the primitive compass and represents a permanent and more effective means at determining cardinality. It can be viewed in the hand when scrolled over in the hotbar or placed on the ground. It determines north much quicker compared to the primitive compass and it does not lose durability. The compass is made up of 4 parts: - The compass casing - The compass face - The compass needle - The glass cover The compass casing can be forged via blacksmithing costing an ingot and can be made out of: - Copper - Brass - Tin bronze - Bismuth bronze - Black bronze - Bismuth - Silver - Gold Other materials could also possibly be considered for the compass casing, but under no circumstances should any of those materials be magnetic. Absolutely no iron, no meteoric iron and no steel (no nickel either but if you did include nickel then the compass should work terribly). We also probably don't want to make the casing out of arguably realistic ancient materials that were used (such as wood, or bone) because we to preserve an element of progression. The compass face is made by cutting up parchment with shears. The initial face will be blank but will work fine as a valid compass face. Take the blank compass face and place in the centre of the crafting grid. Next, place the ink and quill into the grid... now, depending where the ink and quill is relative to the blank compass face (in the centre of the grid), a different paper face design will appear. There are 8 different faces in total which each represents a different kind of face that can be used. The compass needle must be blacksmithed out of steel. It must then be magnetised with a magnetite nugget just like the nails were for the primitive compass (same process). Unlike the nails from the primitive compass however, magnetising the compass needle takes a little bit longer because we're making a more refined product. We now have a magnetised compass needle. From this point we will probably want to paint our needle. Hold the needle, hold the sprint button over a bucket of dye and the magnetised compass needle will be mixed and swirled in the bucket for a few seconds - after which the northern part of the needle will be dyed that colour, and 2 litres of the dye will be expended. Do it again (with a different dye) and the southern half of the needle will be painted with the new colour. Do this on a bucket of water and you will wash off the colour from the needle - starting with the north part, then the south. To make the glass cover, first take a clear glass slab along with some shears in the crafting grid - this will create a rough glass square. Next, take some coarse sandpaper (has a durability - is made from parchment, resin and 1 sand) and use the coarse sandpaper with the rough glass square to get an unfinished glass cover. Now use some fine sandpaper (parchment, resin, 1 fine sand - made from putting regular sand through a quern) with the unfinished glass cover to get a glass cover. Take the compass casing, the compass face, the compass needle and the glass cover and craft together in the crafting grid to get your very own customised compass. Notes: Both the compass and the primitive compass work normally as described above except in regions with high magnetite. Depending on the strength of the magnetite, the compass will work more or less effectively - the more magnetite, the more haywire the compass acts out. Perhaps in regions of decent - high magnetite the compass flickers, but spins uncontrollably in regions of ultra high magnetite? Feature 7: Plumb line quadrant Craft a log together with a knife and a piece of charcoal. A wooden quadrant will be returned to you along with the knife minus 1 durability. Now craft the wooden quadrant with any stone and 2 pieces of twine... this will give you a plumb line quadrant - a basic tool for latitude and elevation ascertainment. The Plumb line quadrant has 2 modes: Latitude mode Elevation mode In Latitude mode, the player can use the plumb line quadrant to determine roughly how far north or south they are of the equator. This can only be done either at night time when the stars are out, or at midday when the Sun is at it's highest within a 30 minute bracket either side of midday. If the player does not have a watch or clock in which to determine the time, they can also infer when the Sun is at it's zenith using a gnomon or sundial. If operated at night time, the player must find either the Northern star Polaris, or the Southern cross whilst holding the plumb line quadrant. Once they have done so, they must hold right click for a few seconds and a reading will be taken which will then be printed in the game log (similar to how prospecting prints readings). If the reading is taken at midday, then the player must point the plumb line quadrant at the sun. The read out will depend on whether the modconfig has been assigned to use polar coordinates, classical coordinates, (or both - default: polar only). If polar coordinates are selected, the readout will give out an angle between 0-90° North or 0-90° South, depending on the measurement. This will be an approximation based upon where the player is relative to the equator and will read to the nearest 1°. If done in classical coordinates, the readout will say that z ≈ [number], where [number] is the player's actual z coordinate to the nearest 1000. In Elevation mode, the player takes a reading by looking at the horizon (in any direction). Once a reading has been taken, the game log will tell the player how high they are to the nearest 10 blocks in the game log. If the modconfig variable for elevation measurements is set to "realistic" (default), the value will be given as "[number] metres above sea level" (where metres just means "blocks to the nearest 10"). If the modconfig variable is set to "classic", the reading will be " y ≈ [number]". Elevation readings cannot be taken below sea level. The plumb line quadrant cannot be used on a raft or on a boat. In all cases (including future ones with similar instruments), some form of feedback should be given to the player when they are taking a reading so they know they are doing it right. Feature 8: The Mariner's quadrant The Mariner's quadrant works exactly in the same way as the plumb line quadrant does, but it is a little bit more expensive to make, it is a bit more accurate, and it can be used on boats and rafts. The Mariner's quadrant is made by blacksmithing a quadrant plate out of any of the main metals or pouring into a mould: - Copper - Brass - Tin bronze - Bismuth bronze - Black bronze - Bismuth - Iron - Meteoric Iron - Steel - Silver - Gold The player then needs to blacksmith a lead plumb out of lead, 1 ingot makes 4. Using the quadrant plate, 1 lead plumb, and 4 twine in the crafting grid, the player will craft the mariner's quadrant. In Latitude mode, the Mariner's quadrant has an accuracy to the nearest 0.1° (or nearest 100 z coordinate). In Elevation mode, the Mariner's quadrant gives accurate elevation (sea level or y-level...) readings. Feature 9: The Primitive Gnomon Carve a wooden pan with a knife in the crafting grid to get a "wooden base". Craft the wooden base, along with a stick and some resin to make the primitive gnomon. It's basically a primitive sundial. Place the primitive gnomon on the ground. With a piece of charcoal in your hand, right click on the primitive gnomon within an hour after sunrise, within an hour either side of midday, and within an hour before sunset. The gnomon will now act as a "scored primitive gnomon" and bear 3 markings (representing sunrise, sunset, and midday). If you right click the scored priminitive gnomon whilst on the ground, the game log will tell you what month you are in and whether it is dawn, morning, midday, evening, or dusk. No reading is given at night (shocker, I know...). If you break the scored primitive gnomon on the ground, it will return as a primitive gnomon item and placing it anywhere again you will have to repeat the process of taking measurements in order to get it to work again. Right clicking on an uncallobrated gnomon outside of the allowed times or without a charcoal will return a message to the player saying something to the effect of "The gnomon needs to be callobrated". Feature 10: The Sundial The Sundial is a more accurate version of the gnomon. It is made of two parts, both of which are made with blacksmithing - the Dial plate can also be made by first making a clay mould: The Dial plate The Triangular Gnomon Both components of the Sundial must be the same, but they can be made out of most metals: - Copper - Brass - Tin bronze - Bismuth bronze - Black bronze - Bismuth - Iron - Meteoric Iron - Steel - Silver - Gold Once crafted, the Sundial must be placed on the ground and callobrated. It must be right clicked at sunrise, midday, and sunset, and then finally once more at any time at night. If in the Northern hemisphere, the Sundial will point northwards, if in the southern hemisphere, the dial will point southwards (after measurements have been taken). If the sundial is broken from it's position, it must be recallobrated. Right clicking on the callobrated sundial will reveal: the time (accurate to the minute), the correct calender day (day and month). Right clicking whilst holding the run button will reveal the player's latitude to the nearest 0.1° (or nearest 100 z coordinate). Both the Sundial and primitive gnomon must be placed outside to work. Feature 11: The Calender It can be placed on the wall and tells you the date. Mix 6 parchments with an ink and quill in the crafting grid to get an empty calender. Whilst holding an empty calender, right click on a callobrated sundial to get a calender. The calender will be useless after 1 in game year. Feature 12: The Watch The watch is made in a similar way to the compass. To craft it you will need: - The watch casing - The watch face - The watch gears - The small watch hand - The large watch hand - The spring mechanism - The glass cover The watch casing is forged via blacksmithing costing an ingot and can be made out of: - Copper - Brass - Tin bronze - Bismuth bronze - Black bronze - Bismuth - Silver - Gold - Iron - Meteoric Iron - Steel The watch face is made by taking a blank compass face (shears + parchment) and crafting it in the grid to return a blank watch face - you can also put the blank watch face in the crafting grid on it's own to return a blank compass face. Put the blank watch face into the crafting grid with a pen and quill for a watch face - there are 8 total designs. The watch gears and spring mechanism are made through blacksmithing (costing an ingot each) and can be made out of: - Copper - Tin bronze - Bismuth bronze - Black bronze - Iron - Meteoric Iron - Steel The Spring mechanism material is important, as the material used to make the spring mechanism will impact how often the watch needs to be rewound to keep it working. The watch hands are made from any metal (1 ingot produces both hands) and they can be dyed in much the same way as the compass needle was. The glass cover is made the same way as it was for the compass by polishing a clear glass slab with coarse sandpaper and then fine sandpaper. Combining all the ingredients together will give the player their own customised watch. The watch has three modes: Regular Chronometre Set To use the watch, it must first be wound up (by holding right click and run whilst holding it in "regular" mode). The charge of the watch will depend upon the spring mechanism (this will act a little like durability). If a copper spring mechanism was used, then the watch will run out of charge after 1 in game month. If any bronze is used, the charge will last 3 months. If Iron is used the charge will last 9 months. If Meteoric Iron is used, the charge will last 1 year. If steel is used, the charge will last 18 months. The watch can be recharged at any time, but if it runs out of charge then the time will stop (and it will need to be recallobrated). To callobrate a watch, hold run and right click with the watch on a sundial during daytime (in "set" mode), or on another watch, grandfather clock, or clock - this will bring the watch to match the local time of the sundial/watch/clock. In chronometre mode, you need to right click with the chronometre over a callobrated sundial or primitive gnomon. If used over a primitive gnomon, the watch will tell you in the game log how far east or west you are in degrees of the original sundial you set the watch to. Using the watch in chronometre mode on a primitive gnomon will be accurate to 1° (or 1000 x). Using the watch in chronometre mode on a sundial will be accurate to the 0.1° (or 100 x). A pocket chain can be blacksmithed using most metal materials. You can craft the watch with the pocket chain to make a pocket watch which can be worn around the neck like a necklace - as an item, it will still hold all the same functionality as a regular watch. You can blacksmith a watch buckle and craft this with some leather to make a watch strap - craft the watch strap with the watch and you'll have yourself a nifty wristwatch which can be worn on th wrist and will work the same as the watch when used as a regular item. When wearing a wristwatch, the player can use the tab button to open up the GUI to show the time (from their wristwatch) like how classical time use to work. It does not show them the date however. You can rename your watch to anything you like. Feature 13: The Clock Made from: - Clock casing - Clock face - Clock gears - Small clock hand - Large clock hand - Large spring mechanism - Glass cover The clock casing can be blacksmithed using 2 ingots, or carved with a knife and of any kind of log. The clock face is made much like the watch face but you would first craft 4 blank watch faces together - you can then either use the blank face or produce custom marking by placing the blank clock face in the crafting grid with an ink and quill (8 designs). The clock gears are made by smithing 2 ingots of any of the following: - Copper - Tin bronze - Bismuth bronze - Black bronze - Iron - Meteoric Iron - Steel The clock hands are made in the same way as the watch hands and can be dyed like they can too - they cost 2 ingots (or 1 each) however. The large spring mechanism is also made with 2 ingots and works in the same way as the regular spring mechanism (but lasts twice as long with respect to material used). The glass cover is the same as before. The clock can be used in the same way as a watch and has the same 3 modes (including chronometre). The clock is set in the same way. The clock cannot be turned into a wearable item. Right clicking on the clock will return the time that it is callobrated to. Feature 14: Grandfather Clock Made from: - Grandfather Clock casing - Clock face - Clock gears - Large clock hand - Small clock hand - Pendulum - Glass cover - Glass casing The clock face, clock gears, clock hands, and glass cover has already been discussed. The Grandfather clock case is made from 4 ingots or 2 logs carved with a knife and an axe (must be same kind). The pendulum is blacksmithed using 2 ingots of: - Copper - Brass - Tin bronze - Bismuth bronze - Black bronze - Bismuth - Silver - Gold - Iron - Meteoric Iron - Steel The Glass casing is made of 3 glass slabs in the crafting grid. To build the Grandfather clock - place the Grandfather clock casing down wherever you want it to go. Place in the grandfather clock casing, the clock gears and the pendulum, next place the clock face and the clock hands. Then place the glass cover and the glass casing. Congratulations you have a grandfather clock. The grandfather clock is 2 blocks high. It must be set by holding a watch or clock (in regular mode) in the left hand and holding run and right click on the grandfather clock (to set the grandfather clock to the time on the clock or watch you are holding). The grandfather clock does not run out of charge - it lasts forever. Right clicking on it will tell you the time. If you break the clock as to pick it up, you will break the whole clock and recieve all the constituent parts. Feature 15: Giant clock hands The small Giant clock hand is made by blacksmithing two ingots. The larger is made using 3. They can be made of any of the following: - Copper - Brass - Tin bronze - Bismuth bronze - Black bronze - Bismuth - Silver - Gold - Iron - Meteoric Iron - Steel The Giant hands can be dyed to any colour. Giant clock gears are blacksmithed using 2 ingots. The giant clock gears are then placed inside a gearbox to make a Giant clock gearbox. This gearbox can then be painted any colour and is 1 block in size. The gearbox is made of 4 wooden slabs. The Giant clock gearbox can be connected to an axel (which is further connected to rotating power - presumably from windmill or other source) on one side of the gearbox. On the other side is where you place the clock hands. Looking at the block where the hands meet the gearbox (in front of the gearbox), you can tune the clock hands to the right time in the same way as was done with the grandfather clock. Provided there is rotation energy feeding into the clock hands they will rotate at the correct rate of in game time. The hands need enough space around them to do their rotations, so naturally nothing must be in their way when placed (similar to windmill system). The blocks around the gearbox (left, right, up, and down - but not front and back) are empty and the player can fill those with any blocks they like and if they so choose, they can chisel their own clockfaces. One of the unique things about the giant clock (presumably used for towers and such) is that the player can synch up time devises (like the watch, clock etc), just by looking at the giant clock face from a distance. Feature 16: Sextant The Sextant is used primarily to find latitude. It works by using it to first find the horizon and then finding either Polaris, the Southern Cross or the Sun at midday. The Sextant has 3 modes: Regular Set Relative In regular mode, the Sextant finds your local latitude accurate to 0.1°. In set mode, the sextant is callobrated to a sundial, or even just a position - all this does is records a latitude. In relative mode, the sextant tells you how far or north or south you are from the point in which you set the sextant in set mode. Here's the fun part: If the player uses the sextant (in regular mode) whilst holding a watch in their off hand, they can use the sextant any time of day or night and achieve an accuracy of 0.001° If they use the sextant in relative mode whilst holding a watch in their off hand, they will be told how far north or south they are from the point they set their sextant AND how far east or west they are from the place they set their watch - Meaning, if the sextant and watch were set in the same location, they can be used to find that location again whever they end up on the map (kind of like a lodestone in minecraft but way way way more realistic). When used in this way, the coordinates have an accuracy of 0.001° (or 1 x and z block if selected by modconfig). Make a sextant using: - Sextant frame (2 ingots of main metals including aesthetic ones) - Sextant parts (1 ingot, main metals) - 2 small mirror parts - 2 glass lenses Saw a clear glass slab to make a rough thin glass slab. Sand the rough thin glass slab with coarse sandpaper to get unfinished glass sheet, sand that with fine sandpaper to get glass sheet. Glass sheet can be used for greenhouse roofs. Place the glass sheet in a 1x1 hole. Next, melt an ingots worth of silver and pour it over the glass sheet. After it's cooled down, you'll have a large mirror pane (don't actually make a functioning mirror). Cut the mirror pane with shears to get 4 small mirror parts. To make the lenses, take a clear glass slab along with some shears in the crafting grid to make a rough glass square. Take the shears to the rough glass square to make a rough glass circle. Now use coarse sandpaper on it to get unfinished glass lens. Use fine paper on the unfinished lens to get a glass lens. Mix it altogether to get the Sextant. Feature 17: The map There are 4 resolutions of map: Very large scale map → A very localised/detailed map showing a small area Large scale map → A localised map showing a slightly larger area than the very large scale map but with less detail small scale map → A broad map with not a lot of detail Very small scale map → A very broad map showing a very large area but with very little detail To make the map, the player must take 8 parchments surrounding a compass in the crafting grid - the compass is returned with no loss of durability and the parchment transforms into a Blank very large scale map. Placing the blank very large scale map into the crafting grid will return the blank large scale map, which itself would return the blank small scale map, which would return the blank very small scale map, which itself when placed in the crafting grid will return back the blank very large scale map. These scalings determine the "resolution" of the map. Once a map has been drawn on - it can no longer be crafted to any of the other sizes/scales/resolutions. To draw on the map, the player must be holding a pen and quill in their off hand - then holding the blank map in their main hand, the player holds "run" and right click... then after a couple of seconds a rough area the size of a few chunks (but circular) is drawn on the map, that corresponds to a circular area around the player on the map. If the player wants to complete the map (perhaps because there are blank regions the player has not completed), the player must go to those blank regions on the map and repeat the process in order to fill in those areas. The player cannot see themselves on the map. If the player presses right click (on it's own, no "run" button), they will "open" the map to get a better look at it in game. If the player is holding a pen and quill in their off hand when they do this, they can make markings on this map (draw freely or use preset symbols - but for now, only in black). The map colour looks like the default map colouring (not true world colouring). When placed on a wall, the map is by default configured to be facing with the top part of the map being the cardinal direction that the player is facing (example: if the player places the map on a wall that is west of the player, then the top part of the map is the western part of the map. To place the map on a wall, the block before the wall must be empty and the player must expend 1 resin in or to do so (perhaps by placing the resin on the wall first to act like glue). The map is 1 x 1 block in size and can be placed adjacent to other maps. If the player is holding the map in their off hand and then uses the sextant or mariner's quadrant to take a latitude measurement, then the map will be assigned approximate latitude coordinates (that can be read in it's text description area like when you hover over it), if the player takes a chronometre reading with their watch over a sundial whilst holding the map in their offhand, they will be given a longitudinal reading for the map aswell - The measurements must be taken in the region occupied by the map! Map's can be renamed. Map's do not update automatically, they must be drawn over. Maps can be copied over to other maps using a cartographer's table, but the resolutions of both map and blank map must be the same. You can craft the cartographer's table with a compass, 2 logs, a saw, and a pair of compasses. The "pair of compasses" is crafted from a pencil and an "empty pair of compasses". The empty pair of compasses is blacksmithed for 1 ingot. The pencil is crafted using a knife, a log and a lead nugget. Feature 18: Clockmaker class upgrades So it's up to you how you want to do this - you can either edit the existing clockmaker class, or you can create a new class called the "Navigational Clockmaker" so that the changes don't affect other mods (although personally I think we should totally overide them by this point ). It's pretty simple stuff, the Clockmaker (or navigational clockmaker) can make stuff that the other classes cannot - they are exclusive recipes unless the worldconfig says otherwise. We have discussed a lot of intricate navigational tool and clock making in the design of this mod - as such, we should now reflect that some of these items can only be made by one of a particular trained skill. The following items are exclusive to the clockmaker: The metal plumb A quadrant plate The Mariner's quadrant The Dial plate Triangular gnomon Sundial The watch casing The watch face The watch gears The small watch hand The large watch hand The spring mechanism Clock casing Clock face Clock gears Small clock hand Large clock hand Large spring mechanism Grandfather Clock casing Large clock hand Small clock hand Pendulum Glass casing Giant clock hand (small) Giant clock hand (large) The gearbox Giant clock gears Giant clock gearbox Sextant frame Sextant parts Sextant Naturally, since so many items are exclusive to the clockmaker (essentially: mariner's quadrant, sundial, watches, clocks, sextants), we're going to want to nerf some of the clockmakers abilities. Get rid of Precise, Technical, Tinkerer. Keep Frail, Nervous, Fleetfooted. Call the new traits for the exclusive recipes something like "True clockmaker" or "Celestial Navigator" (or whatever you like). Final thoughts So yeah, that pretty much covers it. There is plenty that can be added and worked on with this mod, but as it is on it's own I think it's pretty comprehensive and covers virtually everything that's really needed for a totally immersive navigation and cartography system for Vintage Story. There were other things that came to mind that could make potentially decent additions to the mod, but i'll leave it up to you if you wish to include those at a future date. Things I didn't work into the mod included items like the Astrolabe, cross-staff, backstaff. I did want to create a facility for coloured maps but that appeared to be dependent on the creation of a kind of inkset with many colours and would honestly be it's own mod all unto itself. I honestly have my doubts if anyone would seriously consider making this mod, or the entire thing just due to it's size and the amount of time needed to impliment al the features - but I have done my best to try and ensure that all parts both work together to create the immersive navigational feel to a mod as well as fits thematically to the Vintage story gameplay style. In any case, I hope you've enjoyed reading my mod design, with any luck someone will pick it up or use ideas from it for their own mod creations, and if we're really lucky, maybe one of the game devs will see this and use it as inspiration for future versions of the game. Thank you for reading. Pingu. Edited December 29, 2025 by EmperorPingu Added link to complimentary suggestions post 2
Gr33nB00t5 Posted December 29, 2025 Report Posted December 29, 2025 Hey @EmperorPingu, just wanted to say this is such an imaginative and thoughtful idea! I really think you put alot of care into outlining this mod concept — it’s clear you’ve given a lot of thought to how celestial navigation and clockwork could enrich the exploration experience in Vintage Story. The way you’re trying to bring more realism and depth to navigation and time mechanics is genuinely inspiring, and I think it taps into the best part of the game and one that so many people would love to see expanded. Even if this project doesn't end up being a mod, I think there’s already a lot here for the creators to think about. The mechanics, the more realistic star behavior, clockwork elements, new navigation tools, this could be an amazing way to teach CelNav in the real world — it’s the kind of idea that could evolve in so many fun directions. Thanks for sharing it, and for being so respectful and encouraging in your approach! You're so awesome! Sincerely, Green 1
IronOre Posted January 6 Report Posted January 6 Wow! You've really done your homework here. Lots of great ideas! I really like the idea of having the east/west position shift the sun according to local time. It would be amazing to use time keeping like you've outlined to determine longitude by the time offset just as they did in the real world once timekeeping technology was sufficiently advanced. Before that all they really had to work with was latitude. If I understood correctly, are you envisioning an option to keep the word generation to just one set of latitudes without repeating as you go north and south? I try to do that in my worlds currently but you have to start in a hot climate and the location is still randomized so there will be some overlap. I've always wanted a world generation game that wrapped the map so that it made some sense as a self-contained world at whatever scale. I've seen some test code for doing it for a voxel game that works in all directions, but I'd even be happy if the world just ended at the north and south pole edges and wrapped from east to west only. I searched a long time for a voxel game or a mod of Minecraft that had actual north/south climate effects and seasons, and one of the main reasons I started Vintage Story was after I heard that the sun actually changed position on the horizon according to the seasons. When I first saw that I was thrilled with the possibilities of using realistic skies to actual effect in the world (including navigation), but I was soon very confused by the stars and especially the moon. Still, I currently set my windows up so that then I open the menus the date and time are covered and I keep track of the year with sun rise/set horizon markers and counting stones. I also tell the approximate time of day with a mid-day shadow post with some measurement indicators on the ground for shadow length throughout the year. I love being able to look at the sun and orient myself just as I do in the real world. Here is a post I made on some of the basics we still need to see in the sky: If even that much can get started in a mod such as you are proposing, that alone would be an amazing start! I really do hope in the meantime that the devs get the stars working they way they'd planned. It seems like they had the right idea and that it would be an easy fix. With that I'd already be able to estimate my latitude even with no in-game tools. I don't know when the devs will move these things forward again. It seems they had some issue that required setting the moon back to a square but I think the phase is at least working more realistically. I really wish I had the skills to mod myself, there would be so many possibilities! 1
EmperorPingu Posted January 6 Author Report Posted January 6 For anyone else who is as interested in immersive astrophysics as I am, you should check out some of @IronOre's other posts. They're the real deal and even more nerdy about it than I am xd 11 hours ago, IronOre said: You've really done your homework here. You damn right I did 11 hours ago, IronOre said: If I understood correctly, are you envisioning an option to keep the word generation to just one set of latitudes without repeating as you go north and south? I try to do that in my worlds currently but you have to start in a hot climate and the location is still randomized so there will be some overlap. So yeah, hense why I've called them pseudo-polar coordinates - for quite a number of reasons... For example, let's say we start with a Hot climate world and (x, z) = (0, 0) is both at the equator and the prime meridian, then the polar coordinates (φ, λ) would also be (0, 0). But if we were to travel lets say 360 deg straight north then our (x, z) coordinates would be (0, -4q) (where q is the polar-equator distance), but our polar coordinates (if simulated to act realistically) should be (φ, λ) = (0, 0), making it the same location - as you can probably tell though, these would absolutely not be the same location and we would run into the problem that coordinates within the system would be used to reference multiple actual locations on the map. This would be the result of us being on a flat 2D terrain rather than on a 3D geodesic - in the real world we would return to the same spot, but on our 2D map, this is impossible. Another issue would arise if we even tried to make "where the north pole should be" be at a particular location... as soon as we traversed that northen point (north ward), we would still be in the "northern hemisphere" but the axis would start pointing southwards overall for us which (hard to explain) also means that east and west would kind of have to swap directions (creating the same problem as before and just making it unnecessarily confusing with crossed regions sharing same coordinates. We'd really just have to go for the simplest solution which would be to treat the entire map as having only 4 directions that transcend the entire map itself: North, South, East, West, and these directions do not change (and there is no "focal point" of any of them regardless of where we are on our 2D plain"). So the compromise (in my mind) for us being on a 2D world would be to keep one set of coordinates for each location and no matter how north you go you remain "North" and the world map only really has 1 "true" equator. Back to our example from earlier, if we went 360 deg north we wouldn't end up at "(φ, λ) = (0, 0)" again, we'd instead just list that as (360, 0). 11 hours ago, IronOre said: I've always wanted a world generation game that wrapped the map so that it made some sense as a self-contained world at whatever scale. I love this idea, and I think it's totally possible given that a 2D (square) map absolutely tesselates. Back in the day I use to make my own chess variant games - one of them was this very concept where you'd have a square board but you could go left, right, up and, down to "wrap round" again to make more of an open concept kind of game (imagine the king and pieces in the centre of a position with the pawns surrounding them). But back to the idea itself, it could probably work but you might bump into the problem of stitching the map because you I don't think (off the top of my head) you'd be able to stitch north and south together at the same time as stitching north and west. There might be a way to do it but it would either be really tricky or you'd have to make comprimises somewhere. Currently the best kind of immersive setup would really be to set up the map so that it's size (length or height) was exactly twice that of the pole-equator distance, and starting in a hot climate to centre equator and have the poles in their respective places. Personally, I also like the idea of having a pole-equator size of 400k - at a metre per block, that works out to be 400km per equator-pole distance which reminds me of the 4000km real life equator-pole distance. And yeah, I'm rooting for the devs here on this one as they're the ones most likely to have the resources and potential willpower to pull off something like this of this scale. For all the dunking I do on the lore side of the game, I don't dislike it by any means (just the forced temporal storms wind me up as it negates my ability to play to my preferred playstyle). Having a different sky and stars, or even a retrograde orbit to what we actually have on earth is totally fine as long as the math is consistent unto the rules of it's own world (which could totally feed into lore!). I realised that the component of the game I'm most into is really less about hyper-realistic immersiveness (which don't get me wrong, I freaking love anyway), but more about an immersive and satisfying progression system that I both feel like I earned and allows me to escape to the idea like I really could have done this - hense the absolute autistic special interest obsession I've had with contemplating highly in depth navigational and celestial mechanics for the game. With any luck, a dev will probably stumble across the posts we make and use them as inspiration for their own future developments - they are already making a whole bunch of progress already! Naturally, nerds like us are gonna nitpick (I know I certainly do lol), but I have no doubt even the devs would know that whether it's us hyper-evaluating our observations, or them actually developing the game, it's all coming from a place of total love and appreciation for this wonderful project of theirs. Maybe they'll see themselves having fun interacting with an implimented version of our own contributions, just as we have fun interacting with theirs? A penguin can dream 1
Recommended Posts