More balance settings and GT Ore integration#36
More balance settings and GT Ore integration#36Minepolz320 wants to merge 11 commits intoGTNewHorizons:masterfrom
Conversation
|
Make a config that we can add every gt ore not only this one you hard coded @Minepolz320 |
|
@Dream-Master yes, you can simply specify a different ore meta for a specific stalactite gt_oremapping { |
|
I would prefer if this was handled in GT and TF exposes an API that can be called |
|
@Caedis Yes, but on the other hand, you don’t need a dependency to build a mod for such a minor change I myself can’t decide whether it’s worth writing an api in the greg |
|
We really shouldn't be using reflection for new code unless we have to. |
|
@YannickMG unfortunately I can’t rewrite the code now, maybe later or I can cancel the request for now or just mark it as a draft |
|
It even seems to work with the non-GTNH version of gregtech |
|
Up? |
|
Will be reviewing this evening. |
YannickMG
left a comment
There was a problem hiding this comment.
Overall great and very welcome addition! I've made a few comments and suggestions.
Also, while this is in no way a blocker, I will mention that while we're adding the ability to replace TF ores I wonder why we're only looking at GT5U integration. For instance GT++ has Koboldite which it would be very nice to use here. If you want to make your solution more generic I suggest you simply expose an API that accepts a functional interface for the signature void setBlock(World world, int x, int y, int z, Block block) and let the caller decide exactly what ore block they want to place down. In that case integration with GT would be done in code in NewHorizonsCoreMod.
| @@ -378,6 +378,15 @@ public static TFFeature generateFeatureForOldMapGen(int chunkX, int chunkZ, Worl | |||
| } | |||
|
|
|||
| public static TFFeature generateFeatureFor1Point7(int chunkX, int chunkZ, World world) { | |||
There was a problem hiding this comment.
It appears this function isn't only used when generating a feature (as its name would suggest) but also when looking up which feature should exist in a given region.
Changing the configurated change post-worldgen affects functionality that check against existing features such as the magic map.
Is this intended? If so you might want to document the caveat that this config isn't meant to be modified on an existing world.

There was a problem hiding this comment.
yes, definitely need a warning, I was worried that this would happen
| if (ry < 75) { | ||
| TFGenerator rf = randomFeature(randomGenerator); | ||
| rf.generate(currentWorld, randomGenerator, rx, ry, rz); | ||
| // now with chance |
There was a problem hiding this comment.
The "now" part of "now with chance" isn't going to be very helpful to future readers of the code, for which that comment will always have been there.
If the intent of the comment is to indicate that there's a chance of the feature not happening then you might want to encode that knowledge about the code's intent into a well named function instead.
| // Greg? | ||
| public boolean doOreGen; | ||
|
|
There was a problem hiding this comment.
The // Greg? comment appears to be misleading since this can be used without GregTech. Also you should generally not expose fields publicly so this should be private.
| package twilightforest.gt_integration; | ||
|
|
||
| import net.minecraft.block.Block; | ||
| import net.minecraft.init.Blocks; | ||
| import net.minecraft.world.World; | ||
|
|
||
| import gregtech.common.blocks.GT_TileEntity_Ores; | ||
| import twilightforest.TwilightForestMod; | ||
|
|
||
| public class GT_OrePlacer { | ||
|
|
||
| public int getMappedGTMetaForOre(Block mOre) { |
There was a problem hiding this comment.
getMappedGTMetaForOre should be private, and if you remove GT_Integration_Utils::getOrePlacer then all of GT_OrePlacer can be package private instead of public to hide your implementation details.
| package twilightforest.gt_integration; | ||
|
|
||
| import net.minecraft.block.Block; | ||
| import net.minecraft.world.World; | ||
|
|
||
| public class GT_Integration_Utils { | ||
|
|
||
| static GT_OrePlacer orePlacer; | ||
|
|
||
| public static void init() { | ||
| // Create worker obj | ||
| orePlacer = new GT_OrePlacer(); | ||
|
|
||
| } | ||
|
|
||
| public static boolean isInit() { | ||
| return orePlacer != null; | ||
| } | ||
|
|
||
| public static boolean doPlaceGTOre(World aWorld, int aX, int aY, int aZ, Block mcOreBlock) { | ||
| if (!isInit()) { | ||
| return false; | ||
| } | ||
| return orePlacer.placeGTOre(aWorld, aX, aY, aZ, mcOreBlock); | ||
| } | ||
|
|
||
| public static GT_OrePlacer getOrePlacer() { | ||
| return orePlacer; | ||
| } | ||
|
|
||
| } |
There was a problem hiding this comment.
You should reduce the visibility of this class's members.
orePlacer and isInit can be private, getOrePlacer is not used and should be removed (or used).
| if (TFFeature.getRandom(randomGenerator, TwilightForestMod.minorFeatureGenChance)) { | ||
| if (randomGenerator.nextInt(6) == 0) { | ||
| int rx = chunk_X + randomGenerator.nextInt(16) + 8; | ||
| int rz = chunk_Z + randomGenerator.nextInt(16) + 8; | ||
| int ry = currentWorld.getHeightValue(rx, rz); | ||
| if (ry < 75) { | ||
| TFGenerator rf = randomFeature(randomGenerator); | ||
| rf.generate(currentWorld, randomGenerator, rx, ry, rz); | ||
| } |
There was a problem hiding this comment.
This new minorFeatureGenChance config option now compounds with an existing 1 in 7 chance of generating a minor feature. This makes the config option a bit misleading and limits our ability to do things such as making minor features more common.
Would it be possible to combine these random chances, such as by using 1/7 (~14.25%) as the default value of the config option?
There was a problem hiding this comment.
yes, I think it’s logical to combine and leave the default 14% in the config
|
@YannickMG Tanks for amazing review |
ok i try to do this and make it possible to switch the mode in the config сan i look some examples where is this done, for example in our project |
|
superseded by #50 |
-Ability to adjust the density of ore in stalactites
-Ability to disable certain ore in stalactites
-Ability to replace the type and ore in stalactites using ore metadata from GT
-Ability to customize the frequency of dungeon generation and landscape features
I immediately apologize for the low quality of the code
I can’t decide what to do:
it’s better to add the required method to the gregtech api or just use reflection
however, that’s why I opened it as a Draft
50%
