Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Matryoshika

Forge Modder
  • Posts

    523
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by Matryoshika

  1. 16 hours ago, Draco18s said:

    Got a picture? That sounds neat.

    Sadly I do not, at least of the later stage when I switched from 2d flat-faced textures to an actual 3d block with actual holes
    I do however have the first rendition of my menger-sponges still.
    Lapis block -> Lapis Menger Sponge T1 ->...->T5
    spacer.png

    I eventually as said switched to actual 3d-models instead of using the void hole in the middle. The commented out part below the highlighted code in the link is what's shown above.
    Feel free to setup a local repo though and build your own jar of Σcho. Tried to but haven't used eclipse since that project (3 years ago now >.>) and I forgot how much I hate setting up projects in it.
    Requires botania & jei cause I had some integrations with them

     

  2. Don't try to emulate the texture itself.
    Instead use IForgeBakedModel::getQuads which has a side argument.

    I used this back in 1.12 to make menger sponges out of any solid block.
    It's a bit outdated, so copy/paste probably won't work, but should point you in the right direction.
    BakedMengerOneModel.java#L47-77

     

    Also please cache the models that your blocks have copied. It's much easier on the client to reuse the List<BakedQuad> that you've already gotten once, than to continuously ask for it.

    Cache
    However nowadays you should use ISelectiveResourceReloadListener instead

    The bytes sprinkled throughout the code is the tiers of the menger iterations. They can be safely ignored.

    • Thanks 1
  3. Preface: I will not name the mod I'm trying to identify on client-connection, bar possibly in PM to someone from the Forum Team. It shouldn't be known about

    I'm part of a server-network that has started to see several players using a "hacking mod" that allows them to manipulate packets.
    The mod in question goes cross-language between java and C++.

    Usually, for things like this, we just add the offending mod's modid to a blacklist plugin and that'll disallow the client from connecting to any of our servers.
    However, this mod in question, stupidly enough, allows the user to edit it's own modid, modname and version-id through a gui in the menu, to anything they user can think of.
    This is quite disconcerting.

    I know there's very little information given here, but is there anything bar modid/modname/version given out in any packet/handshake/event that can be used to identify a mod?
     

  4. Whilst I cannot help out with the proper way to disable the blocks from rendering inside this area, and substituting your own animation, I can quite confidently state that it will not be as performance intensive as you think, if you keep OpenGL calls to a minimum.
    I've made some menger-sponge inspired compressed blocks (20^1, 20^2.... 20^6 block compression) and whilst I was dealing with pre-calculated models and bakedQuad-caching, T3 compression(20^3) or 8,000 miniature blocks rendered inside a single blockspace did cause some stutter, but not game-breaking. (Though it wasn't animated)
    Though 11^3 isn't a small number, that still only equates to 1,331 blocks. Yes, scaling all of this will have a higher performance drain than just basic rendering, but it shouldn't be impossible if you focus on performance.

    • Like 1
  5. He just linked you the source-code for the class that specifically holds all registries... perhaps you should use that class?

    ForgeRegistries.BLOCKS.getValue(key) to get a specific block, where key is the block's RegistryName,
    If you want to get all your mod's blocks at once, you would need to iterate over the registry first. (personally I'd use a lambda stream with a filter matching each blocks's RegistryName's getResourceDomain (mod-id), then save that in a collection somewhere)

     

     

    7 minutes ago, Big_Bad_E said:

    Don't use ID, you can just have a static instance of the Block in your registry class.

    Whilst not using raw ID's is correct (they can be different on different servers!) NEVER use static instances. The whole RegistryEvent was made to remove this practice.
    Use the ObjectHolder annotation instead if you must have an associated field.
     

    1. Wrong sub-forum to create this thread in. Modder support is for people actively coding with Forge.
      1. Support & Bug reports would be the correct location for this issue
      2. You've already made a thread there. No need to spam threads
    2. 10 minutes ago, Keoks said:

      States: 'U' = Unloaded 'L' = Loaded 'C' = Constructed 'H' = Pre-initialized 'I' = Initialized 'J' = Post-initialized 'A' = Available 'D' = Disabled 'E' = Errored
      ...
       | UE    | tartheus            | 0.1.6             | Tartheus-+(v0.1.6)+1.12.2-14.23.5.2772.jar    | None                                     |

       

    3. Tartheus is the mod trying to access client-side only code(particles in this case) whilst being server-side.
      Find their issue-tracker and report it there

  6. Your if-statement is faulty.
     

    43 minutes ago, Cris16228 said:

    BlockPos surface = world.getTopSolidOrLiquidBlock(new BlockPos(X,Y, Z));

     

    43 minutes ago, Cris16228 said:

    world.isAirBlock(surface)

    surface here will always be a non-air-block. You have to check if surface.up() is an air-block, not the one that is guaranteed not to be.

    Further-more, if you simplify your entire if-statement to if(A && B && C || D) then the logic is easier to see. if A, B and C are true, OR if D is true, then continue. Dirt-blocks will always pass this check, even if the air-block or surfaceWorld are false. You need to wrap C and D inside a parenthesis. if(A && B && (C || D)), to continue if either of those two are true, whilst still relying on the A and B checks.

     

    43 minutes ago, Cris16228 said:

    Edit 2: It attempts to spawn farmland and crop in water

    3 hours ago, Matryoshika said:

    As for y-coordinates, you can use World::getTopSolidOrLiquidBlock to get the top-most solid y-value. Be sure to check if it is not a fluid though!

  7. This is how I usually create my worldgen features

    1. Implement IWorldGenerator in your worldgen class(es). This will give you access to a generate method which will be called during worldgen.
    2. Be sure to check what Dimension(id) and/or what WorldType is being used by the current world. Don't think you want to generate stuff in the Nether/End etc.
    3. The mentioned generate method will give you a chunkX & chunkZ parameters. Do not multiply by 16 to get blockcoords, but rather use bit-shifting (blockpos = chunkpos << 4).
      1. Whilst multiplication from chunkpos to blockpos will result in correct numbers, division (block->chunk) will result in incorrect values for negative coordinates, due to how integers are rounded. It is for the best to consistently use one method to calculate rather than mix-and-match based on the situation.
    4. Always try to generate your features inside of the currently generating chunk. Do not generate along the border. This can cause cascading chunk-generations, and cause lag.
      Add 8 to both your x & z block-coordinates to get the (almost) centre of the current chunk, then use a random value between -7 to 7 (min-max values) to truly get a random position within the chunk. As for y-coordinates, you can use World::getTopSolidOrLiquidBlock to get the top-most solid y-value. Be sure to check if it is not a fluid though!
    5. For your normal crops, you only need to check for Dirt or Grass blocks, switch them out for Farmland (be sure to place some water next to it) and then place the crop ontop of that
    6. Sugarcane is a bit trickier. You can have a look through the WorldGenReed class in your IDE to see how Vanilla spawns Sugarcane
    7. Lastly, you need to register your IWorldGenerator implementing class during  init (FMLInitializationEvent) using GameRegistry.registerWorldGenerator(WorldGenerator, weight) where weight is an integer determining when they are run. Higher weights tend to run after generators with less weight.
  8. You can not create any item after pre-initialization has finished. The code is built specifically to that effect.

     

    If you must, you can allow the end-user to create new items through JSON or any other means, but those items will not exist until Minecraft launches once more, and detects the new items during the registry-events.
    This however has it's drawbacks, especially with constant addition and possibly subtractions from the registries.

    It would be for the best if you created a base-alloy item, register that once, and then edit it's stat with NBT, similarily to how Tinkers' Construct creates it's tools.
    You can edit many, many different client-side stats of the alloys, such as name, icon/model etc, to distinguish them. They will still all use the same [modid]:[name] but again, as with Tinker tools, you can spawn them in with specific NBT data.
    If you sort out all your different possible stats (or just some of them) the different alloys can be added to your CreativeTab (and thus also automatically into JEI if installed) to make it simpler to spawn in.

  9. On 7/16/2018 at 7:17 PM, LexManos said:

    However, the re-write of the loading system is to support running on J8+, that includes 9, and 10.

    On 7/16/2018 at 7:17 PM, LexManos said:

    But again, as Minecraft still targets J8 we have to support it, which means no hard deps on J9/10 features. Hence why developing with JDK8 is recommended.

     

  10. Quote

    RedstoneFlux has detected that the following OLD API classes from CoFHLib are being repacked!

    RedstoneFlux is crashing because another mod has packed old API classes from CoFHLib into itself. This seems to be intended behaviour.

     

    Further more, please read the crashlogs.
     

    Quote

    To prevent this crash, add "-Dcofh.rf.crashOnOldAPI=false" to your command line arguments.

     

  11. Biomes are not chunk-based. They are block-based, ignoring the y (meaning a single chunk can have 256 different biomes inside of it, each on a different x&z coord)
    You need to use the biome-check on each block-position when placing the actual block, not just check it once per chunk.

  12. The generators are given the chunkx & chunkz coordinates.
    From there, you need to manually iterate over 0-16 for both x & z. From there, calculate (chunkx << 4) + x to get the actual blockX coordinate. Do the same for z.
    There should be a method in the World object to get the top block (blockY coordinate) (World::getHeight or World::getTopSolidBlock; Not at my IDE so can't provide the exact name).
    Now you got all three positions, which means you should be able to spawn the snow at blockX, blockY + 1, blockZ.

    (the "<< 4" is a bit-shift operator. It's equivalent to doing "n * 16". Bit shifting should be done instead of multiplying/dividing by 16 because dividing negative chunk coordinates will result in wrong coordinates as integers get rounded down)

  13. Have you tried running a server-instance in Eclipse?

    By default, annotated event-handlers are registered on both the Server & Client side, but this code deals with Client-Side only code.
    You need to add value=Side.CLIENT to the annotation to make sure that this EventHandler is only run on the client.

    Oh, and you shouldn't acronym your modid. What if someone else makes a mod called "magic lore" etc and decide to shorten their modid as well... It won't look pretty, is all I'll say.

    • Like 1
  14. Ah, I knew I was forgetting something.
    However, even with a flag:0 in World::setBlockState, It seems I was still loading new chunks.

    I ended up merging this with my IChunkGenerator, as the ChunkPrimer::setBlockState does not notify neighbours; It was going to end up in the IChunkGenerator eventually, just wanted to use an IWorldGenerator to keep things a bit more modular whilst I work on updating the whole project.

×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.