I was just throwing in my two cents since someone brought it up. had no intention of arguing with anyone. I really am sorry if it seamed like I was.
my only point was that I guess some programs may be able to read the file, but that any editing would have to be manual, since no save editor would know what to do with the data.
Also, I meant to quote Videogamer555 XD
Fair enough
Just be careful about what you read on the internet I guess Anybody claiming to support Tall Worlds already is clearly out of their mind!
Quote from CosmicDanjump
I'd say somewhere between 5% and 95%.
Trying to slap a number on to how "complete" a piece of art is is more difficult than creating the art itself. And everytime someone asks for ETA's or related, the developer has to stop work and spend a few hours calculating the estimate
Yes, providing M3L has Forge compatibility from the beginning (very likely).
Are you saying that even the devs have absolutely zero idea how far the "art" has progressed? Every self-respected software developer has at least some sort of a roadmap and advance planning for their products. Yet for simple players who've been following the amazing promises of Tall Worlds since last April, it's actually incredibly hard to predict the status of the project from the outside. So it's not unreasonable to ask approximately, in the most roughest terms, how far the mod is away from being released as stable public beta. A month? Two to four months? No sooner than 2016? Should thousands of people who wish to get back to the game with Forge 1.8 patiently wait for Tall Worlds to release in a month or two, or should they just forget about it until the time of another major mod/version upgrade? I honestly don't think that people who have the capacity to rewrite an entire gaming engine from scratch would need to "spend a few hours calculating the estimate" for a fairly basic question like this.
Are you saying that even the devs have absolutely zero idea how far the "art" has progressed? Every self-respected software developer has at least some sort of a roadmap and advance planning for their products. Yet for simple players who've been following the amazing promises of Tall Worlds since last April, it's actually incredibly hard to predict the status of the project from the outside. So it's not unreasonable to ask approximately, in the most roughest terms, how far the mod is away from being released as stable public beta. A month? Two to four months? No sooner than 2016? Should thousands of people who wish to get back to the game with Forge 1.8 patiently wait for Tall Worlds to release in a month or two, or should they just forget about it until the time of another major mod/version upgrade? I honestly don't think that people who have the capacity to rewrite an entire gaming engine from scratch would need to "spend a few hours calculating the estimate" for a fairly basic question like this.
Estimation is much harder than you think it is. As a general rule, I don't do estimates for modding projects. Even if I did predict how much work it would take to complete a given feature, I have no possible way to estimate how much time I'll have to work on it. So any estimate for a release date would be completely imaginary. This isn't my job. I don't have to stick to release schedules.
You, as a user, have three options:
You can contribute directly to the development of the mods you enjoy by writing code. Since this requires advanced skills, I'm guessing not many people can contribute in this way.
Contribute financially so that developers who do have advanced skills have the free time to use those skills to give you something fun to play, instead of working at a job where that developer can actually be fairly compensated for his/her time and advanced skills. Many people expect software to be free, despite all the work that is required to create software, so many are reluctant to give up hard earned money for it. I'm guessing this is why participation in donation programs is astonishingly low.
Wait patiently for someone else to do all the work, and then be appreciative when they give you the result of that work especially since they ask for absolutely nothing in return.
Estimation is much harder than you think it is. As a general rule, I don't do estimates for modding projects. Even if I did predict how much work it would take to complete a given feature, I have no possible way to estimate how much time I'll have to work on it. So any estimate for a release date would be completely imaginary. This isn't my job. I don't have to stick to release schedules.
With all due respect to your modding abilities, that's splitting hairs. Even if you don't know how much time you'll have to work on something, you already have years of general modding and a year of continuous development to extrapolate from. There's also a major difference between saying "I will release this on Valentine's Day, February 14th" and saying "We finished working on feature X, and now we only have problems Y and Z to solve—something that will probably take at least 2 to 4 months at our current schedule". As a former software developer, I very well know how hard estimation can be, but I haven't worked on a single project in my life—software or not—without having at least the most general idea about how much time I expected it to take (as opposed to its real time frame, which could take much longer for a number of reasons, of course). Again, this is not a personal jab, but as general rule of thumb, if one can't honestly estimate if their project will take a month vs a year to reach beta, something is usually suspect.
With all due respect to your modding abilities, that's splitting hairs. Even if you don't know how much time you'll have to work on something, you already have years of general modding and a year of continuous development to extrapolate from. There's also a major difference between saying "I will release this on Valentine's Day, February 14th" and saying "We finished working on feature X, and now we only have problems Y and Z to solve—something that will probably take at least 2 to 4 months at our current schedule". As a former software developer, I very well know how hard estimation can be, but I haven't worked on a single project in my life—software or not—without having at least the most general idea about how much time I expected it to take (as opposed to its real time frame, which could take much longer for a number of reasons, of course). Again, this is not a personal jab, but as general rule of thumb, if one can't honestly estimate if their project will take a month vs a year to reach beta, something is usually suspect.
There are two parts to doing a time estimate. Part 1 is estimating how much work there is to do. With all due respect, most software projects are relatively mundane things. Most software projects are some instance of the problem X, where problem X has been solved by many different people in many different situations at many different times in the past. It's generally easy to estimate these things because there is a large body of literature behind you that says here's how other people solved this problem, and here's how long it took them.
In the case of Tall Worlds, I'd say this follows more of a research model of development. In research, you propose to do a thing that no one has ever done before. No one really knows how long it will take, because you only have the barest glimpse of how hard the problem actually is. No one has actually solved this problem before. It might be that no one even truly understands the problem yet. In this case, it's basically impossible to estimate how long it will take you to solve it. You literally have nothing to extrapolate from. I don't know of a single person in history that has released a functional mod that entirely replaced the chunk loader in Minecraft.
Part 2 is estimating how much time you'll have to work on the project. In my case, I do modding work in my free time. The demands of life are varied and unpredictable. I have to spend my time on those things first. Whatever's left over, I might spend on modding If I Feel Like It That Day. Since there's no one guaranteeing me a salary for doing modding, I don't have to carve out any constant chunk of my time to do this. I do it when I want to, and some days I'd rather just go watch TV instead. Your assumption of a "year of continuous development" is simply wrong. I have not worked on this project continuously.
Those two things means I'm just not going to do release estimates. I'm sorry if this makes you uncomfortable, but I really doubt you have an argument that's convincing enough for me to change my mind. "Other people do it" is not a convincing enough argument for me.
If Cuchaz doesn't want to give out a release date, for whatever reason, then you just gotta deal with it and live with the simple knowledge that it will be released when it is done (or at least, done enough to be released).
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
As a map maker, I say keep your mouth shut about when it 'supposed' to be released and just release when it's done. Just be sure to SCREAM TO THE WORLD when it is, so we can flock over and break your download page.
Rollback Post to RevisionRollBack
Truly he is my rock and my salvation; he is my fortress, I will not be shaken. ~Psalms 62:6
As a current software engineer, I can tell you that giving an ETA for a Linux kernel driver (or whatever you used to do) is far less complicated than giving a Minecraft mod ETA. When you're working with an API that has practically-zero documentation (Forge) or writing your own API from scratch because existing ones don't cut it (M3L), which is based on hacking-into a reverse-engineered and deobfuscated program (Minecraft), the best one could give is a wild speculation. Tall Worlds Mod is a unique, first of it's kind mod - and expecting research into an ETA just takes away the dev's time from actual development.
There's a reason why asking for ETA's are ban-able offenses in many open-source/non-profit communities. This isn't a corporation, there is no time constraint or deadline or market pressure; the ETA is "when it's ready" and/or "when the developer feels satisfied".
Hey Cuchaz I'm back you might remember me. I was thinking, would you be able to implement separate settings for vertical and lateral render distance, for performance/wanting to see the giant mountain you made.
To all those terrain wizards out there: how feasible would it be to generate a square area of tileable terrain?
If someone thinks they can do it, it might be worth investigating whether we can extend M3L (and ultimately TWM) to working with pseudo-planets (aka, infinitely tiled terrain, with some tricky tricks to make it seem like the looping terrain is actually a part of a proper planet).
Which reminds me @Cuchaz, while the code is probably still pretty young, how feasible do you think it will be (in TWM) to manipulate the skylight level of a chunk, at the chunk level (aka, one chunk/column might be provided light level 14, while an adjacent chunk/column is provided light level 15)?
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
It is possible to generate tileable terrain - using tileable perlin noise. But I'm not sure how would you use it to generate planets.
With Tricky tricks and magic.
Actually, you would just hack a heap of modulus into the chunk handler (or something similar), so that the same chunks tile endlessly in every direction.
The next step is a bit harder, but... well... The first part is tracking things like the sun and moon. Ultimately, we end up with a set of functions that take the world time, and some X/Z, and spit out direction vectors for the sun, moon, and star layers.
The second part is to apply this data to the world. On the client, this is easy. We just calculate the directions and draw the sun, moon, and stars. Quite simple.
On the server, we need to change a little more, mostly related to lighting. At the chunk level, when calculating skylight, rather than using a global skylight level, we would pass the X/Z of the chunk, and calculate the light level according to the position of the sun (and moon?) relative to that specific chunk.
EDIT: Note that for SSP, we actually can get away with changing ~just~ the global light level, relative to where the player is. On SMP, we have to change it on a chunk-by-chunk basis, so that every player sees the world in the correct state.
One part of the world is dark while the other is light, one part of the world can see the sun while another can see the moon. You can even travel around the entire planet and end up exactly where you originally started. Pseudo planet.
EDIT: Yes, the Quaternion conversation on the ships thread might have encouraged this line of thought.
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Actually, you would just hack a heap of modulus into the chunk handler (or something similar), so that the same chunks tile endlessly in every direction.
The next step is a bit harder, but... well... The first part is tracking things like the sun and moon. Ultimately, we end up with a set of functions that take the world time, and some X/Z, and spit out direction vectors for the sun, moon, and star layers.
The second part is to apply this data to the world. On the client, this is easy. We just calculate the directions and draw the sun, moon, and stars. Quite simple.
On the server, we need to change a little more, mostly related to lighting. At the chunk level, when calculating skylight, rather than using a global skylight level, we would pass the X/Z of the chunk, and calculate the light level according to the position of the sun (and moon?).
One part of the world is dark while the other is light, one part of the world can see the sun while another can see the moon. You can even travel around the entire planet and end up exactly where you originally started. Pseudo planet.
EDIT: Yes, the Quaternion conversation on the ships thread might have encouraged this line of thought.
There is a game that actually does something like this, I don't remember the name. It generates tileable terrain and even uses shaders to make it look like a sphere.
Generating tileable terrain isn't that hard - you can use 6D perlin noise to simulate tileable 3D noise (just like you can use 2D noise to simulate tileable 1D noise - instead of X coord you use angle in a circle). You can generate tileable caves/ravines/other things by looping chunk coordinates in the generators and changing noise they use to tileable noise.
And on the server I think you could calculate correct skylight value (using solar and lunar angle) in method that returns skylight value. World time would be a bit more problematic - I don't think it can be dependent on position. But you can do that clientside by taking player position and setting time depending on position. So instead of changing rendering code to change sun and moon position - you would modify world time. For stars you would probably need to do some changes.
Also, since it's in TWM thread - do you want to do it with TWM?
There is a game that actually does something like this, I don't remember the name. It generates tileable terrain and even uses shaders to make it look like a sphere.
Generating tileable terrain isn't that hard - you can use 6D perlin noise to simulate tileable 3D noise (just like you can use 2D noise to simulate tileable 1D noise - instead of X coord you use angle in a circle). You can generate tileable caves/ravines/other things by looping chunk coordinates in the generators and changing noise they use to tileable noise.
And on the server I think you could calculate correct skylight value (using solar and lunar angle) in method that returns skylight value. World time would be a bit more problematic - I don't think it can be dependent on position. But you can do that clientside by taking player position and setting time depending on position. So instead of changing rendering code to change sun and moon position - you would modify world time. For stars you would probably need to do some changes.
Also, since it's in TWM thread - do you want to do it with TWM?
I figured I should raise it here, because ultimately I would want it to compliment TWM if possible. It would also need a lot of ASM in a lot of important places, which makes M3L a wise choice of API. Plus, I know that most of the people on this thread atm are actually pretty skilled coders.
The world time is a fairly simple fix IMO. The world clock simply provides a reference telling us where the planet is - it's more like a "solar system clock". The time at a certain location would have to be derived when required. Of course, this means that many things would need to be patched manually, but that's small game compared to the rest of the changes.
As for rendering, it's actually surprisingly easy (I'm already working on tweaking the sky rendering system for a day lengthening mod). The way the current renderer works, you can literally just throw in your desired rotations, and the sun, moon, and stars, will find themselves in the correct positions. Currently, I'm just using a sin curve to change their 'orbits', but I've only scratched the surface atm.
EDIT: Imagine three spheres around the planet. One sphere has the sun drawn on it, one sphere has the moon drawn on it, one sphere has the stars drawn on it. That's how the renderer works - vanilla MC simply rotates all three at the same speed, in the same direction, on one axis only.
But these are all things I can manage (hopefully). The things I am concerned about are 1. Seamless Terrain (I'll look at this 6D Perlin stuff... definitely sounds like it's exactly what I need), and 2. The ability to manipulate sunlight at the chunk/column level in TWM.
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
The Meaning of Life, the Universe, and Everything.
Location:
127.0.0.1
Join Date:
8/22/2012
Posts:
217
Location:
127.0.0.1
Minecraft:
Barteks2x
Xbox:
null
PSN:
null
Member Details
After reading it I realized that I haven't thought about biomes. This part may be a bit harder. I'm not sure how to do that with vanilla biome generator (yet). In TWM there is some (currently not used) custom biome generation code that would make it easy to do, but rivers wouldn't work, and biome size would be simillar for all biomes.
Because it's been partly created and is open source. Also, Cuchaz has been kind enough to tell us what he is doing, and how the mod does/will work.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumFair enough
Just be careful about what you read on the internet I guess
Who are you talking to? I don't see anybody asking questions lol.
Are you saying that even the devs have absolutely zero idea how far the "art" has progressed? Every self-respected software developer has at least some sort of a roadmap and advance planning for their products. Yet for simple players who've been following the amazing promises of Tall Worlds since last April, it's actually incredibly hard to predict the status of the project from the outside. So it's not unreasonable to ask approximately, in the most roughest terms, how far the mod is away from being released as stable public beta. A month? Two to four months? No sooner than 2016? Should thousands of people who wish to get back to the game with Forge 1.8 patiently wait for Tall Worlds to release in a month or two, or should they just forget about it until the time of another major mod/version upgrade? I honestly don't think that people who have the capacity to rewrite an entire gaming engine from scratch would need to "spend a few hours calculating the estimate" for a fairly basic question like this.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEstimation is much harder than you think it is. As a general rule, I don't do estimates for modding projects. Even if I did predict how much work it would take to complete a given feature, I have no possible way to estimate how much time I'll have to work on it. So any estimate for a release date would be completely imaginary. This isn't my job. I don't have to stick to release schedules.
You, as a user, have three options:
- You can contribute directly to the development of the mods you enjoy by writing code. Since this requires advanced skills, I'm guessing not many people can contribute in this way.
- Contribute financially so that developers who do have advanced skills have the free time to use those skills to give you something fun to play, instead of working at a job where that developer can actually be fairly compensated for his/her time and advanced skills. Many people expect software to be free, despite all the work that is required to create software, so many are reluctant to give up hard earned money for it. I'm guessing this is why participation in donation programs is astonishingly low.
- Wait patiently for someone else to do all the work, and then be appreciative when they give you the result of that work especially since they ask for absolutely nothing in return.
Choose wisely.EDIT: should you want to pursue option 2, I would greatly appreciate your support:
http://www.cuchazinteractive.com/donate.php
With all due respect to your modding abilities, that's splitting hairs. Even if you don't know how much time you'll have to work on something, you already have years of general modding and a year of continuous development to extrapolate from. There's also a major difference between saying "I will release this on Valentine's Day, February 14th" and saying "We finished working on feature X, and now we only have problems Y and Z to solve—something that will probably take at least 2 to 4 months at our current schedule". As a former software developer, I very well know how hard estimation can be, but I haven't worked on a single project in my life—software or not—without having at least the most general idea about how much time I expected it to take (as opposed to its real time frame, which could take much longer for a number of reasons, of course). Again, this is not a personal jab, but as general rule of thumb, if one can't honestly estimate if their project will take a month vs a year to reach beta, something is usually suspect.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThere are two parts to doing a time estimate. Part 1 is estimating how much work there is to do. With all due respect, most software projects are relatively mundane things. Most software projects are some instance of the problem X, where problem X has been solved by many different people in many different situations at many different times in the past. It's generally easy to estimate these things because there is a large body of literature behind you that says here's how other people solved this problem, and here's how long it took them.
In the case of Tall Worlds, I'd say this follows more of a research model of development. In research, you propose to do a thing that no one has ever done before. No one really knows how long it will take, because you only have the barest glimpse of how hard the problem actually is. No one has actually solved this problem before. It might be that no one even truly understands the problem yet. In this case, it's basically impossible to estimate how long it will take you to solve it. You literally have nothing to extrapolate from. I don't know of a single person in history that has released a functional mod that entirely replaced the chunk loader in Minecraft.
Part 2 is estimating how much time you'll have to work on the project. In my case, I do modding work in my free time. The demands of life are varied and unpredictable. I have to spend my time on those things first. Whatever's left over, I might spend on modding If I Feel Like It That Day. Since there's no one guaranteeing me a salary for doing modding, I don't have to carve out any constant chunk of my time to do this. I do it when I want to, and some days I'd rather just go watch TV instead. Your assumption of a "year of continuous development" is simply wrong. I have not worked on this project continuously.
Those two things means I'm just not going to do release estimates. I'm sorry if this makes you uncomfortable, but I really doubt you have an argument that's convincing enough for me to change my mind. "Other people do it" is not a convincing enough argument for me.
If Cuchaz doesn't want to give out a release date, for whatever reason, then you just gotta deal with it and live with the simple knowledge that it will be released when it is done (or at least, done enough to be released).
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffPerhaps this is why you are a former software developer.
As a current software engineer, I can tell you that giving an ETA for a Linux kernel driver (or whatever you used to do) is far less complicated than giving a Minecraft mod ETA. When you're working with an API that has practically-zero documentation (Forge) or writing your own API from scratch because existing ones don't cut it (M3L), which is based on hacking-into a reverse-engineered and deobfuscated program (Minecraft), the best one could give is a wild speculation. Tall Worlds Mod is a unique, first of it's kind mod - and expecting research into an ETA just takes away the dev's time from actual development.
There's a reason why asking for ETA's are ban-able offenses in many open-source/non-profit communities. This isn't a corporation, there is no time constraint or deadline or market pressure; the ETA is "when it's ready" and/or "when the developer feels satisfied".
"I used to be a software developer like you, but then I took an arrow to the knee"
I'm sorry, I couldn't resist. It's the only thing I can think of when I see that part of your post.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
If someone thinks they can do it, it might be worth investigating whether we can extend M3L (and ultimately TWM) to working with pseudo-planets (aka, infinitely tiled terrain, with some tricky tricks to make it seem like the looping terrain is actually a part of a proper planet).
Which reminds me @Cuchaz, while the code is probably still pretty young, how feasible do you think it will be (in TWM) to manipulate the skylight level of a chunk, at the chunk level (aka, one chunk/column might be provided light level 14, while an adjacent chunk/column is provided light level 15)?
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCubic chunks discord server
With Tricky tricks and magic.
Actually, you would just hack a heap of modulus into the chunk handler (or something similar), so that the same chunks tile endlessly in every direction.
The next step is a bit harder, but... well... The first part is tracking things like the sun and moon. Ultimately, we end up with a set of functions that take the world time, and some X/Z, and spit out direction vectors for the sun, moon, and star layers.
The second part is to apply this data to the world. On the client, this is easy. We just calculate the directions and draw the sun, moon, and stars. Quite simple.
On the server, we need to change a little more, mostly related to lighting. At the chunk level, when calculating skylight, rather than using a global skylight level, we would pass the X/Z of the chunk, and calculate the light level according to the position of the sun (and moon?) relative to that specific chunk.
EDIT: Note that for SSP, we actually can get away with changing ~just~ the global light level, relative to where the player is. On SMP, we have to change it on a chunk-by-chunk basis, so that every player sees the world in the correct state.
One part of the world is dark while the other is light, one part of the world can see the sun while another can see the moon. You can even travel around the entire planet and end up exactly where you originally started. Pseudo planet.
EDIT: Yes, the Quaternion conversation on the ships thread might have encouraged this line of thought.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThere is a game that actually does something like this, I don't remember the name. It generates tileable terrain and even uses shaders to make it look like a sphere.
Generating tileable terrain isn't that hard - you can use 6D perlin noise to simulate tileable 3D noise (just like you can use 2D noise to simulate tileable 1D noise - instead of X coord you use angle in a circle). You can generate tileable caves/ravines/other things by looping chunk coordinates in the generators and changing noise they use to tileable noise.
And on the server I think you could calculate correct skylight value (using solar and lunar angle) in method that returns skylight value. World time would be a bit more problematic - I don't think it can be dependent on position. But you can do that clientside by taking player position and setting time depending on position. So instead of changing rendering code to change sun and moon position - you would modify world time. For stars you would probably need to do some changes.
Also, since it's in TWM thread - do you want to do it with TWM?
Cubic chunks discord server
I figured I should raise it here, because ultimately I would want it to compliment TWM if possible. It would also need a lot of ASM in a lot of important places, which makes M3L a wise choice of API. Plus, I know that most of the people on this thread atm are actually pretty skilled coders.
The world time is a fairly simple fix IMO. The world clock simply provides a reference telling us where the planet is - it's more like a "solar system clock". The time at a certain location would have to be derived when required. Of course, this means that many things would need to be patched manually, but that's small game compared to the rest of the changes.
As for rendering, it's actually surprisingly easy (I'm already working on tweaking the sky rendering system for a day lengthening mod). The way the current renderer works, you can literally just throw in your desired rotations, and the sun, moon, and stars, will find themselves in the correct positions. Currently, I'm just using a sin curve to change their 'orbits', but I've only scratched the surface atm.
EDIT: Imagine three spheres around the planet. One sphere has the sun drawn on it, one sphere has the moon drawn on it, one sphere has the stars drawn on it. That's how the renderer works - vanilla MC simply rotates all three at the same speed, in the same direction, on one axis only.
But these are all things I can manage (hopefully). The things I am concerned about are 1. Seamless Terrain (I'll look at this 6D Perlin stuff... definitely sounds like it's exactly what I need), and 2. The ability to manipulate sunlight at the chunk/column level in TWM.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCubic chunks discord server