Jump to content

TheMasterGabriel

Forge Modder
  • Posts

    178
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by TheMasterGabriel

  1. 57 minutes ago, Riyoze said:

    (receiveCanceled=true)

     
     

    You are a rare occurrence, as lots of people just try once, can't figure it out, and come back here in frustration. Thanks. As for that phrase, you don't need it. The Decorate event is not a cancelable event, so checking for receivedCanceled doesn't do anything.

  2. That would probably hog resources, as you might unload/reload chunks several times. If they didn't unload, that would probably be worse, as your computer would be keeping multiple chunks loaded for 1 block in a completely different area. A solution might be to, if a world operation cascades into another chunk, stop and queue it for when that chunk loads. That way you wouldn't run into cascading chunk gen/loading, but rather have operations waiting to take place. I'm not sure about the feasibility of that, as I can already think of some instances where that wouldn't be ideal (like if you TE needs to check blockstates rather than set them), but I'm just throwing ideas out there for what could be a really useful PR.

  3. When you set your item/block's registry names, make sure to add the modid as well. Not doing so will default the block to vanilla's json location (minecraft:block_banana), which you do not want. In your case, it would be 'examplemod:block_banana'. Forge usually flags mis-registered names as containing a dangerous prefix, so not sure why it didn't in your case.

  4. The easiest thing, in my opinion, to do is save the block state in a reasonable way, which would be serialized NBT data. Save the blockstates via NBTUtil#writeBlockState and write the NBT data to a file (I haven't looked into this whatsoever, but I can't image it would too difficult). Then when you want to compare them, for whatever reason you are doing, read the NBT data from file, deserialize it via NBTUtil.readBlockState, and compare them.

     

    Why are you doing this, anyway? Are you sure there isn't a better way achieving the functionality you desire?

  5. 4 hours ago, King_of_Mines1 said:

    int x = chunk_X * 16 + rand.nextInt(16);

    int y = minHeight + rand.nextInt(heightDiff);

    int z = chunk_Z * 16 + rand.nextInt(16);

     
     

    It's also a good idea to, whenever generating stuff in the world, offset the gen position by 8 on the X/Z axes. If you don't, you could run into cascading chunk gen problems.

  6. Even if you could, however, it would probably cause chaos in the model system, as you could theoretically add a block property to a block after the model loads, which MC would not know what do with when it tries to render said block. So, I think you're restricted in terms of options:

    - Make the IProperty accessible via an API and have other mods use and implement it themselves, which you would need to check for whenever you wanted to do something with the block. (This doesn't help in editing vanilla blocks)

    - Abandon dynamic properties in place of something else

    - Manually add substitutions for all the vanilla blocks you want to change, via the GameRegistry#addSubstitutionAlias

  7. If you were to implement something like that, you would need to ensure that the TE's world access is restricted to the chunk it is in. If you were to allow it to access block positions arbitrarily, then a modder could really easily overflow into an unloaded chunk, which would undoubtedly cause tons of problems.

     

    Edit: Also, did you try looking at ChunkEvent.Load? I didn't look into the load order that extensively, so you might run into the same problem. If not, however, you can probably use it, along with a list of TEs to be ticked, to get something that would work similar to your TE#onLoaded.

  8. You can probably use an IItemPropertyGetter, which can be used to change item models based on certain criteria. They are used by bows to change the texture depending on how long you have been holding down right click, for example. You can see how to use them in ItemBow and its associated json files.

     

    Edit: Also this post if you want another example.

  9. 26 minutes ago, DragonFerocity said:

    Does this mean that I don't need an ItemBlock for a door? Just a block and an item?

     

    Yes. If you registered an itemblock with your door, that would mean you could place the top/bottom parts independently, which wouldn't make any sense.

    26 minutes ago, DragonFerocity said:

    Is there a way to register items and blocks independently with the same name?

     

    As you state, you can already do this. An ItemBlock is just an Item that places a block when right clicked. It is not a block. You are crashing because you are setting the registry name of your ItemBlock to the same registry name as your Door placer.

  10. Hi,

    So I'm trying to figure out how to make my item do something unique whenever it is swapped from offhand to mainhand. Specifically, I want it to turn into another item. I tried looking, and it doesn't seem that there is a way to detect when a keybind is initially pressed? MC does it (or is at least supposed to do it) internally, but I can't seem to find a way of accessing that information. Does anyone know a method of doing so?

     

    Also, unless I'm reading the code wrong, it doesn't look like MC keybind functions are working correctly. Within the game loop (Minecraft#processKeyBinds), its made to seem like you should only be able to swap item hands when the key is initially pressed (and in fact, the comment on the method being used states that it is supposed to return true for initial key presses only). However, I can just hold down the key and the item I'm on will just rapidly switch between the left and right hands.

     

    Edit: It looks like there is an empty event called KeyInputEvent that gets fired whenever the keyboard it used. I presume I can do the initial check manually, but from the code it looks like KeyBinding#isPressed is already supposed to perform that logic?

     

    Another Edit: So I've realized it's kind of pointless to detect when the key is pressed, as it results in a packet being sent server-side to perform the logic. As I don't want my item to actually switch hands, I need to effectively cancel the hand swap. Any idea on how this would be done? Perhaps something to do with intercepting the packet between client and server and replacing it with my own packet?

  11. 9 minutes ago, TheMasterGabriel said:

    EntityTracker

     
     

    As I said, I haven't dug that deep into it. It looks like increasing the tracking frequency fixes it somewhat, but that might just be a side effect of some other problem. (Also, it doesn't seem to make sense to me why the update frequency would have different effects on your entity in comparison to the vanilla ones, which makes me believe its the latter of above).

  12. You can access all of Forge's registries via ForgeRegistries. Note, however, that when you iterate over the registry, you will only be iterating over the things that have already been registered. If a mod loads after yours, it will not be in the list.

     

    Edit: This is assuming you are doing the iterating in preInit, as Draco said below. If not, ignore that second part.

  13. 4 hours ago, aw_wolfe said:

    minecraft data only stores things that the players have changed.

     
     
     
     
     
     

    Minecraft has no concept of what you've changed unless you explicitly code it to. When a chunk generates, it looks at what biome it is supposed to be, generates the height map (placing the biome-specific surface blocks as well), and then decorates it with ores, trees, structures, etc. Then that's it; it will not be generated/populated again. Once a chunk has been generated, it stays in that state forever (unless a mod regens the chunk manually, like Rejuvenation Missiles from ICBM). In your case, if a chunk generates before your ore is set to spawn, it will not spawn in that chunk. Any new world decorating you do (like fixing the spawn rate of your ore ) will only occur in freshly generated chunks.

     

    Edit:

    4 hours ago, aw_wolfe said:

    8,000,000

     

     The fact that you were iterating over such a huge number of blocks also probably led you to think nothing was happening, when in fact it either crashed internally, was just taking a ridiculously long time, both, or something in between.

×
×
  • Create New...

Important Information

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