From a "universe of modders" view it would make far more sense for somebody to mod the 1.10 content into 1.9 while mods and modded players stay in 1.9 than to have every modder create and maintain separate 1.9 and 1.10 versions.
This concept makes sense to me. But the 1.8 and 1.9 content has mostly been ported back to 1.7.10 by Et Futurum and others, yet developers are still running like lemmings towards the 1.8/1.9/1.14+ cliff.
So you get half the mod developers sticking with the stable 1.7.10 platform.
And the other half abandoning their 1.7.10 versions and porting to 1.8+.
You've seen the result in this thread… users who have to upgrade for some of their favourite mods yet cannot upgrade because they lose others.
The whole scenario makes me very sad for everyone, users, developers and even Mojang.
5 months since his last post though, i also deeply wish there was some 'competition'. other mods with similar functionality would only bring more to the table.
Competition can be good. But it can also be a waste of resources if two teams implement almost the same thing.
Like FastCraft and CoFHTweaks for example. So many duplicated hours of tracing, coding and debugging. Ouch!
The solution to that problem is open source. So if someone sees an opportunity for improvement they can implement it in a fork. The original team then has the option of merging the fork or not.
Also, if open sourced, there is no way a popular project can be abandoned. If there is demand, someone will pick up maintenance.
The only problem with open source is building and maintaining a revenue stream. But I hardly think anyone is making Minecraft mods for profit… and if they are making a profit then presumably they will offer good maintenance and support.
there seems to be no git or open source at all though. shame.
and the 1.0 version (MC 1.7.10) is utterly broken. i'd prefer an update to the 0.8 version.
Woah, that's one awesome-looking mod
The copyright statement specifically denies forks and Click-me seems to still be active and says he is intending to update the mod, just a few months ago.
Having said that, RTG does re-decorate a lot of biomes. ... Other times, it's out of a desire to make the biome look more realistic, unique, awesome, breathtaking, etc. Obviously, these are all subjective terms... what some consider breathtaking and awesome, others might consider monstrous and horrible. Fortunately, there's a way that everyone can be happy, and that is with the biome-specific config options that are planned for a future release. This will include the option to have RTG decorate the biome, or have the biome decorate itself (where technically possible).
... Of course, if we decide to get rid of the old RTG layouts altogether (and again, I'm very much in favour of this), it wouldn't necessarily mean that they would disappear forever. For example, someone else could create that mod called "Biome Regions" or "Legacy RTG Layouts" or whatever, and it would work great with RTG. And there's always version 0.4.0, which will always be available on GitHub and Curse for people who want to use the old layouts.
...
So I guess I'm just throwing this out there to see what others think.
Sorry for the late reply on this post… I have been thinking deeply about this over the weekend.
There are two issues raised:
- decoration
- RTG layouts
On RTG layouts… I agree that RTG should concentrate solely on terrain improvement and decoration. Zeno's new system of working within the vanilla biome placements is totally awesome. Climate Control does a great job of giving the user control over biome layout, there is no point maintaining an inferior system within the RTG mod. Backwards compatibility is the only reason to retain "RTG Biome Layout" at all, and even then all users of this mod have known it to be alpha/beta and potentially world-destroying. Splitting off the RTG Biome Layout into a "Legacy RTG Layout" mod would be a bonus.
Decoration is a much trickier issue. And I will preface this discussion by saying that I usually don't use any extra-biome mods at all. And for my current project, I want to use RTG solely to improve the structure and character of Vanilla and perhaps Thaumcraft biomes.
I really love some of the things RTG does when it varies vanilla generation. And other things I really dislike. I would like to have control over these features without hacking the source.
The large trees really add a lot of character to Forest biomes. I see a call for help to improve the tree designs, and I think that's a wise call. Adding some diversity to the trees, increasing girth at the base etc would really improve this feature. But the patches of tall forest are just amazing!
I still REALLY dislike the insertion of mixBlocks into biomes whether stone, podzol or whatever.
I don't like cactus generating in jungles.
There are too many cobble boulders scattered around.
There is too much vegetation generated in deserts.
I think that, in general, RTG goes a little crazy adding custom features and foliage and that moderating decoration would be an improvement.
I would like to see the current hard coded mechanism replaced with config options to control on a per-biome basis:
- whether RTG overrides decoration of the biome (or whether it generates with vanilla decoration)
- if overridden, which RTG features are added
- and how strongly RTG features are added.
The "which RTG features" options would allow users to, for example, disable cactus generation in jungles (what were you thinking?) or disabling boulders in plains (where the smooth green rolling hills are beautiful).
The "how strongly" config would give the user control over how strongly and how densely RTG decorates a biome. It would control both the density of vegetation/foliage/features as well as the size of trees, the size of boulders and so on.
It would also be great to have a secondary noise generator varying the strength of decoration across the world, creating smooth transitions between patches of light decoration and patches which are really dense. So user might select strength 128 (from a range of 0-255). But RTG might apply decoration to the biome on a range 64-192. Or user selects 128 but RTG applies decoration from 0-256 heavily weighted towards 128. Or perhaps config could be a min_strength and max_strength so user could select 32-192 to precisely control their world. Don't want to get too complex though!
Generation of specific features could be varied by Y-value, so that forests generate more birch in lowlands, spruce in highlands and oak in between.
I would love to have a go at coding some of this up, but my Minecraft modding skills are pretty basic and I am really time poor at present. I could really use 48 hours in every day!
I hacked on the source and took the stone out… and to my eyes the world is much prettier with grass. But I see what you mean about opening up the biomes. Forests are more trees than air without the stone!
I think a better way to open up the biomes would be to make fewer attempts to spawn trees in these biomes. Rather than making unspawnable locations by placing stone.
But I guess there's a good reason for the way it's done and you're the expert so I'll leave it to you
I have converted all my coal to blocks of coal to save space in my chests.
Now I need lots of coal for a project and I find that the vanilla crafting recipe to convert a block of coal back to coal has been over-ridden by Galacticraft and I can only obtain Fragmented Carbon.
I guess I can work around this by adding a user Sag Mill recipe or something, but this is pretty inconvenient.
I have found pepper(corn), pistachio, vanilla, and breadfruit(? I think that's what it was) in a savannah mountainy biome. High up on a ridge. Jungle trees. There was a coconut tree in the mix too if that helps.
Only vanilla biomes in the pack I use. It was a weird biome. Coastal, mountains, and savannah all at the same time. Couldn't say which was actually responsible for the spawn and it was a few restarts ago so I couldn't check for you.
I found small patch of Savanna M biome and you're right… it is a veritable tropical garden of HarvestCraft trees!
Starfruit, cashew, pistachio, pecan, papaya, banana and dragonfruit.
All these were growing on jungle trees.
I think that if I had a larger patch of this biome I might have found even more!
So I think there is definitely a problem which needs to be addressed here… these fruits/nuts should spawn in jungle biomes, but nothing does. I found no HarvestCraft trees at all in the Jungle.
I think that when the spawning was changed to rely on biome classifications, that a lot of the Vanilla biomes missed out on receiving any HarvestCraft trees.
There are quite a few tree types available in the marsh biome, not to be confused with the swamp biome. Try there if you haven't already. You can also find cinnamon in the rainforest and tropical rainforest biomes. I forget if they're also available in the jungle. Edit to clarify: these are Biomes o' Plenty biomes I'm mentioning, to be clear.
I don't have any biome mods installed.
Am I unable to obtain a full set of HarvestCraft trees from Vanilla biomes?
That would seem a little unusual!
I spawned in Plains, there are no Ground Gardens here.
It might be one of my other mods interfering. I'll set up a test world...
Edit: Plains spawned Grass, Gourd, Leafy, Berry and Stalk gardens. No Ground Gardens.
But… in an adjoining Extreme Hills, guess what? I spotted a strange thing I'd never seen before… Lo and Behold, a Ground Garden. So now I'll go back over the few Extreme Hills in my mod pack world and see whether I can find one there.
0
This concept makes sense to me. But the 1.8 and 1.9 content has mostly been ported back to 1.7.10 by Et Futurum and others, yet developers are still running like lemmings towards the 1.8/1.9/1.14+ cliff.
So you get half the mod developers sticking with the stable 1.7.10 platform.
And the other half abandoning their 1.7.10 versions and porting to 1.8+.
You've seen the result in this thread… users who have to upgrade for some of their favourite mods yet cannot upgrade because they lose others.
The whole scenario makes me very sad for everyone, users, developers and even Mojang.
KeepOnDigging.
0
I'm not seeing any Pam's tree fruits with RTG snapshot 5.
Is this a known problem or something unique to my config?
Thanks, and
KeepOnDigging!
1
That is just so completely awesome I am speechless
There has been such an amazing pace of development on this mod.
So many new features, so much community interaction.
Well done
0
It seems that this mod requires Java 8. I haven't had any problems since updating.
1
Competition can be good. But it can also be a waste of resources if two teams implement almost the same thing.
Like FastCraft and CoFHTweaks for example. So many duplicated hours of tracing, coding and debugging. Ouch!
The solution to that problem is open source. So if someone sees an opportunity for improvement they can implement it in a fork. The original team then has the option of merging the fork or not.
Also, if open sourced, there is no way a popular project can be abandoned. If there is demand, someone will pick up maintenance.
The only problem with open source is building and maintaining a revenue stream. But I hardly think anyone is making Minecraft mods for profit… and if they are making a profit then presumably they will offer good maintenance and support.
Sorry to derail the thread
KoD.
0
Woah, that's one awesome-looking mod
The copyright statement specifically denies forks and Click-me seems to still be active and says he is intending to update the mod, just a few months ago.
KoD.
0
Which mods in particular do you need?
If a 1.7.2 mod has been abandoned and is popular, I might be interested in forking it and maintaining it.
KoD.
0
I have seen this question a couple of times… and it always gets me wondering…
Why?
What does 1.7.2 do that 1.7.10 doesn't do better?
Thanks, and
KeepOnDigging!
0
Sorry for the late reply on this post… I have been thinking deeply about this over the weekend.
There are two issues raised:
- decoration
- RTG layouts
On RTG layouts… I agree that RTG should concentrate solely on terrain improvement and decoration. Zeno's new system of working within the vanilla biome placements is totally awesome. Climate Control does a great job of giving the user control over biome layout, there is no point maintaining an inferior system within the RTG mod. Backwards compatibility is the only reason to retain "RTG Biome Layout" at all, and even then all users of this mod have known it to be alpha/beta and potentially world-destroying. Splitting off the RTG Biome Layout into a "Legacy RTG Layout" mod would be a bonus.
Decoration is a much trickier issue. And I will preface this discussion by saying that I usually don't use any extra-biome mods at all. And for my current project, I want to use RTG solely to improve the structure and character of Vanilla and perhaps Thaumcraft biomes.
I really love some of the things RTG does when it varies vanilla generation. And other things I really dislike. I would like to have control over these features without hacking the source.
The large trees really add a lot of character to Forest biomes. I see a call for help to improve the tree designs, and I think that's a wise call. Adding some diversity to the trees, increasing girth at the base etc would really improve this feature. But the patches of tall forest are just amazing!
I still REALLY dislike the insertion of mixBlocks into biomes whether stone, podzol or whatever.
I don't like cactus generating in jungles.
There are too many cobble boulders scattered around.
There is too much vegetation generated in deserts.
I think that, in general, RTG goes a little crazy adding custom features and foliage and that moderating decoration would be an improvement.
I would like to see the current hard coded mechanism replaced with config options to control on a per-biome basis:
- whether RTG overrides decoration of the biome (or whether it generates with vanilla decoration)
- if overridden, which RTG features are added
- and how strongly RTG features are added.
The "which RTG features" options would allow users to, for example, disable cactus generation in jungles (what were you thinking?) or disabling boulders in plains (where the smooth green rolling hills are beautiful).
The "how strongly" config would give the user control over how strongly and how densely RTG decorates a biome. It would control both the density of vegetation/foliage/features as well as the size of trees, the size of boulders and so on.
It would also be great to have a secondary noise generator varying the strength of decoration across the world, creating smooth transitions between patches of light decoration and patches which are really dense. So user might select strength 128 (from a range of 0-255). But RTG might apply decoration to the biome on a range 64-192. Or user selects 128 but RTG applies decoration from 0-256 heavily weighted towards 128. Or perhaps config could be a min_strength and max_strength so user could select 32-192 to precisely control their world. Don't want to get too complex though!
Generation of specific features could be varied by Y-value, so that forests generate more birch in lowlands, spruce in highlands and oak in between.
I would love to have a go at coding some of this up, but my Minecraft modding skills are pretty basic and I am really time poor at present. I could really use 48 hours in every day!
Anyway, I hope some of my ramblings are useful.
Thanks for the amazing mod, and
KeepOnDigging!
0
Hi WhichOnesPink,
Thank you for your comprehensive reply.
I hacked on the source and took the stone out… and to my eyes the world is much prettier with grass. But I see what you mean about opening up the biomes. Forests are more trees than air without the stone!
I think a better way to open up the biomes would be to make fewer attempts to spawn trees in these biomes. Rather than making unspawnable locations by placing stone.
But I guess there's a good reason for the way it's done and you're the expert so I'll leave it to you
KeepOnDigging!
1
This mod looks really nice. I love those screen shots in the first post.
So I installed it and the first thing I see are these forests:
The left half of the image is a Roofed Forest and the right is Forest.
Both of them have exposed stone on the ground instead of the 2-3 blocks of covering dirt. This makes the forests look pretty barren.
And the Roofed Forest is way more open than vanilla… it's not even really roofed any more.
Are these changes intentional? Or just artefacts of the beta?
Thanks for the interesting mod, and
KeepOnDigging!
0
Now I need lots of coal for a project and I find that the vanilla crafting recipe to convert a block of coal back to coal has been over-ridden by Galacticraft and I can only obtain Fragmented Carbon.
I guess I can work around this by adding a user Sag Mill recipe or something, but this is pretty inconvenient.
KeepOnDigging!
0
I found small patch of Savanna M biome and you're right… it is a veritable tropical garden of HarvestCraft trees!
Starfruit, cashew, pistachio, pecan, papaya, banana and dragonfruit.
All these were growing on jungle trees.
I think that if I had a larger patch of this biome I might have found even more!
So I think there is definitely a problem which needs to be addressed here… these fruits/nuts should spawn in jungle biomes, but nothing does. I found no HarvestCraft trees at all in the Jungle.
I think that when the spawning was changed to rely on biome classifications, that a lot of the Vanilla biomes missed out on receiving any HarvestCraft trees.
Thanks for the advice, and
KeepOnDigging!
0
I don't have any biome mods installed.
Am I unable to obtain a full set of HarvestCraft trees from Vanilla biomes?
That would seem a little unusual!
KeepOnDigging!
0
It might be one of my other mods interfering. I'll set up a test world...
Edit: Plains spawned Grass, Gourd, Leafy, Berry and Stalk gardens. No Ground Gardens.
But… in an adjoining Extreme Hills, guess what? I spotted a strange thing I'd never seen before… Lo and Behold, a Ground Garden. So now I'll go back over the few Extreme Hills in my mod pack world and see whether I can find one there.
I'm still concerned about tree spawning though!
Thanks for the advice,
KeepOnDigging!