Edit existing blocks

[Quack Man]

Greetings people from... somewhere.

 

I am currently facing an issue that I have given up on how to address it and I am unable to find the information I really want, so I ended up here.

 

For simplicity and to better allow understanding on the issue, I will break it up on parts; however, it is all regarding the edition of blocks that are already on the game, like dirt.

 

  1. Make blocks fall

 

I remember trying this long ago. Back then I could simply change the line for the block and make it say extend BlockFalling instead of Block. However, in this new version I am not allowed to touch the vanilla code. The question would be, how can I do such thing?

I could create a custom event to make them fall on update I suppose, but for something of this scale (every measly block) I don't think this would be the best approach, so I haven't really tried this approach. If it is, then I guess this is problem solved...

 

  2. Changing the drops

 

I have added custom blocks and I am able to make them drop what I want, yet again, I can't figure out how to edit those that are already on the game. I have yet to exhaust all my options here yet, but I am asking in case none of them works. Also because a different approach could help me see things in a different way.

 

  3. Adding a custom function and extra variable

 

This one is a bit unusual, yes. It is tied with the first point in regards that I want to use a function to make the block fall under certain circumstances using a new variable.

Here is the big issue. Using metadata would not work apparently. I have been looking around and it seems this only have 16 bits of information, making it only able to store an integer of up to 16. I want to store an integer that could go to up 30, not to mention that existing block are probably making use of some of this already very limited space. Also, I have read somewhere (can't remember where) that using an NBT tag is not recommendable at all for common blocks since it could make a world's save file to just shoot to astronomical sizes.

 

  Request

 

Although information directly about any of the three point above would be appreciated and very helpful, general information on how to edit, twinkle, mess with, touch,  , or modify with existing blocks would work as well. I think I could work my way around with it.

 

 

 

In case it is of any help on how to help me or point me in a direction, I do have some programming experience; although not much in Java, I can hold my own. However, dealing with code that not only I have not written, but I can't edit is giving me problems. I learn a lot more by trial and error, so breaking things up is my way to go... my specialty? ... my dream?... I really would need to think in a way to properly put that. HAIL ENGLISH!

I have also done this on an earlier version (1.6) and it did work, all of these issues were not issues (I had to deal with storing the extra info though), but since I can't touch the vanilla code anymore, I am at a loss and I can't find a good source of information, tutorial or guide for this.

[Draco18s]

1) http://www.minecraftforge.net/forum/index.php/topic,29341.0.html

 

2) Subscript to the LivingDropsEvent or the BlockHarvestEvent

 

3) Yeah, no.  You're not going to manage that in anything less than a mess.

[Draco18s]

My guess is that he wants that data to track his collapse physics, that is, how far away a given block is from downward support.  Which is functionally equivalent to turning the whole world into redstone.

 

It's not the space-efficiency that's the issue, its the management.

[Quack Man]

1) http://www.minecraftforge.net/forum/index.php/topic,29341.0.html

 

2) Subscript to the LivingDropsEvent or the BlockHarvestEvent

 

3) Yeah, no.  You're not going to manage that in anything less than a mess.

 

 

Thanks a lot for the info. I will see those 2 events you mentioned. I saw that post earlier. I will have to read it in more detail. It was awfully similar to what I want to accomplish.

 

 

3) Yeah, no.  You're not going to manage that in anything less than a mess.

Not all that true, really. You can do pretty space-efficient things using a ChunkDataEvent.

 

 

So, saving extra data in blocks can be done with that event? I will have to check that one as well. Thanks for the info.

 

 

My guess is that he wants that data to track his collapse physics, that is, how far away a given block is from downward support.  Which is functionally equivalent to turning the whole world into redstone.

 

It's not the space-efficiency that's the issue, its the management.

 

 

Half true. The extra variable I want to add is to actually avoid keeping track of the supports.

[Draco18s]

So, saving extra data in blocks can be done with that event? I will have to check that one as well. Thanks for the info.

 

A few things I've learned having to deal with these events:

• There's four events you need to be concerned with.
  

1. 
   
2. Chunk generation.  There's a thousand different events here, you'll need to figure out which one you need, if any
   
3. ChunkSave.  Save the data, duh
   
4. ChunkLoad.  Read the data
   
5. ChunkUnload.  Cleaning up your data so you don't have a memory leak.
   

[*]#4 there is not strait forward.  ChunkSave will run after ChunkUnload, so you should either a) keep a Weak reference to the chunk object itself for mapping your data in a HashMap<Chunk, MySpecialData> or b) use the event to note which chunk has been unloaded, and then when ChunkSave happens, also remove the data from memory.

[*]Chunk NBT is just like any other NBT, you can read and write to it very easily, you just have to translate your data structure into primitive types.

 

Half true. The extra variable I want to add is to actually avoid keeping track of the supports.

 

You can actually cheat and just look at the world when the block updates.  Examining the world doesn't take that much CPU time (I've clocked it: examining an entire chunk takes about 0.6 milliseconds^† even when using world.getBlock instead of directly accessing the chunk block arrays).  You'll lose a small portion of realism by taking shortcuts, but it'll be easier to code.  e.g. searching NSEW in straight lines will be easier to write (but less accurate) than trying to A* to bedrock.

 

^†This is based on my own code and using Time.getNano().

[jabelar]

Whenever you want to change vanilla stuff, I recommend looking for solutions in this order:

 

1) Check if the vanilla classes have public fields or methods you can access directly. It is very inconsistent, but there are lots of public stuff -- for example, entity AI is contained in a public task list that you can fully edit.

 

2) Look for events. Forge and FML have provided a lot of events that intercept vanilla functionality that is interesting to modders. Furthermore, many events are cancelable, meaning that you can fully replace the vanilla behavior.

 

3) Use Java reflection to access private/protected fields and methods. You can't change the code itself with reflection, but can often affect it's execution or monitor for a field to hit a certain value.

 

4) Consider replacing the vanilla classes entirely with your own. This doesn't always work, but for example you can change the crafting recipes to output your stuff instead of the vanilla, or you can intercept all entity spawns (with an event) and replace it with your own version.  The main problem with this is that in several places in the Minecraft code they compare against specific instance instead of using instanceof. In other words, even if you extend BlockLadder there are places in the code where it looks for Blocks.ladder which will be false for your extended class. If they were more consistent with using instanceof, this would actually be one of the most powerful techniques...

 

5) Advanced techniques like ASM.