Jump to content

Aecht_Rob

Members
  • Posts

    10
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Aecht_Rob's Achievements

Tree Puncher

Tree Puncher (2/8)

0

Reputation

  1. After two days of almost literally random trial-and-error I think I have it working. The bug was something to do with passing a ConfiguredFeature where a PlacedfFeature was wanted. I don't fully understand why what I have done works, but it works and that is good for me. My repository is linked above in case there is stuff in there to help anyone else.
  2. Here you go. These are from the IntelliJ dev launcher environment: (1) This is a log from starting a new world: https://pastebin.com/8j23PUEW (2) This is from entering a world which was created previously without the mod: https://pastebin.com/31G1ma49 (3) And this is from entering the same world as (2) but with the single line of code in ModWorldEvents:biomeLoadingEvent commented out: https://pastebin.com/qnCLqM5T It feels like something is not registered properly somehow?
  3. As I mentioned in the original post there is seems to be no error in the loot table and this seems to be a false diagnostic result. I think this because commenting out the worldgen everything runs perfectly, loot tables load fine and behave properly in-game; uncommenting the worldgen makes it error again with this error. (Also if I remove all loot tables entirely the game still falls over). (It is as if providing the reference to the tree in the worldgen forces it to go looking for things which are not yet registered at that moment in time?) I have re-synched the repository, to include all assets now (sorry).
  4. I am in 1.18.1 and trying to get a tree to generate at worldgen. I have a functioning ConfiguredFeature tree (saplings work properly) at "ModConfiguredFeatures.LEPIDODENDRON". When I add this to generation, on loading a world, the world crashes (the error is incorrect - the loot tables work perfectly without adding trees to worldgen). Is there a resource-loading issue here, with the tree placer trying to register something that does not exist to register yet? My placer definition in "ModPlacements": public static final PlacedFeature LEPIDODENDRON_TREE = PlacementUtils.register("lepidodendron_tree_placement", ModConfiguredFeatures.LEPIDODENDRON.placed(RarityFilter.onAverageOnceEvery(12), InSquarePlacement.spread(), PlacementUtils.HEIGHTMAP_WORLD_SURFACE, BiomeFilter.biome())); My worldgen: @SubscribeEvent public static void biomeLoadingEvent(final BiomeLoadingEvent event) { event.getGeneration().addFeature(GenerationStep.Decoration.VEGETAL_DECORATION, ModPlacements.LEPIDODENDRON_TREE); Error: https://pastebin.com/KUZ5gRYC Repository:https://github.com/AechtRob/Prehistoric_Nature
  5. Well, to follow up, these have been my activities with this: I moved the placement of all the tree blocks to the expected Trunk and FoliagePlacer classes: it just seems that I ought to do what the framework wants me to, in case there is a special reason I don't know about. My trees place more than just logs and leaves (other blocks too), so at first I tried out using the Trunk placer itself to add all the variety of blocks (and then pass a null list to the foliageplacer). This also had the effect that when tick speed was high the tree leaves decayed before/while it was placed. I then moved all the foliage placement to a real custom FoliagePlacer class via the List of foliage coordinates (and managed the various different kinds of leafblock in a different way). Setting all leaf blocks in the LeafPlacer results in a stable placement with no decay during generation at high tick speeds. Setting then in the TrunkPlacer does not. This is all very weird, and I am not sure if this is uncovering a bug or something actually wrong in my code. It's an open question about whether other methods placing a large amount of blocks including leaves might result in some decaying before the full lot have been set.
  6. I am working in 1.18.1 Forge (39.0.9). I have a set of code which runs to put a tree in the world from a sapling (I am placing blocks directly in an AbstractTreeGrower class, without using the ConfiguredFeature methods of vanilla trees). When generating the tree at regular randomTickSpeed = 3 and then setting the randomTickSpeed = 1000 afterwards, the tree is stable. Logs are correctly tagged etc. Nothing decays. However, if I set randomTickSpeed = 1000 and then generate the tree, the leaves decay as the tree is generated and it falls apart as it is built. How can this happen? It is as if the blocks are being ticked before the code has completed? My repository for this is here, and includes just about only this one set of trial tree code: https://github.com/AechtRob/PrehistoricNature/tree/master/src/main Many thanks to anyone who can help me here! Rob
  7. As no-one wanted to help me, I thought I'd update this in case anyone else wants to do something like this (which was to pseudo-embed a texturepack inside a mod to enable a user to toggle specific changed blocks textures on/off via a config). The answer I used is the extremely simple blockstate, via the getActualState method of the block to check the config setting and apply the blockstate and model as required.
  8. Apologies, no, I don't know at all. All I know is that the problem to solve is the same and I don't know how it's done, and assumed it would be code along the same lines. I don't have anything like the 1.12 code specifically referencing models inside the later version code. It just seems finds the right model as if by magic, and I don't know how it is doing it, unless its the text match between block and json names. My code is largely cut-and-paste from tutorials and examples, and then edited to what I need, and I'm looking for some basic help on how to make this next edit. For 1.13+, does that mean it's impossible to circumvent the "intelligent" handling? I know I can do things like use blockstates, but what I am looking for is to assign different textures (via two different models) for the same block and blockstate, depending on the value of a variable passed by a config file. Like an embedded texture resourcepack. I don't know if I am looking for a solution in the block definitions, or to pass the variable to the jsons for deal with there (and I don't know how I would do that unless I know where in the code the jsons are even referenced). Or maybe I can override the global models filepath and store the alternate models in a different folder, but have no idea how I would do that.
  9. Thanks - I think this the same issue presents itself with the same code in later versions - this is not specific to 1.12.2 (?) My mod is versioned over 1.12 through to 1.15 with the various code variants, and the same question applies. Thanks!
  10. Hello. I think I get how basic json block models work by default just matching on name essentially (?). How would I go about inserting a condition into my code to provide an alternative different model though? I have created two different json model files, each pointing to a different set of textures: bbb.json + 32bbb.json I tried this simple code here in the public block class for the block called bbb, but this does not result in the 32bbb model ever being used, and the bbb model is used in both cases: @SideOnly(Side.CLIENT) @Override public void registerModels(ModelRegistryEvent event) { if (somecondition) { ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation("aaa:bbb", "inventory")); } else { ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation("aaa:32bbb", "inventory")); } } Is this something to do with having to force a registration of the 32bbb model somehow to make it visible to the bbb block? If so, how and where do I do this so that the block class can see it? Or is it something else completely? (The condition itself is coming from a static config file, and is not dynamic so I reason can be applied at the point of creating the block like this). Thanks for any help - greatly appreciated.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.