Hi. I'm new to forge, and trying to make a mod of sorts that involves skills. However, I don't want the player to constantly have to explore for ores/trees if he/she doesn't want to. I would like ores to "respawn" when some time passes after the player successfully mines it (like wise with trees).

 

However, my inexperience with forge leads me having wondering how to achieve this. I've figured out that I can replace blocks via world.setBlock(), so my initial thought is I could replace the broken block with a default "empty ore" block that has an extra property which defines the block that was previously there. So, something along the lines of "emptyOreBlock.previousBlockID = Block.coalOre.blockID;". Along with that, I could have a counter variable that accumulates with a tick event of sorts. After a condition has passed, the emptyOreBlock would then revert back to the previous block by use of world.setBlock() and previousBlockID.

 

How to do this and whether or not my idea is even efficient is a bit beyond me. Could anyone provide any kind of tips/help/suggestions? Anything constructive would be appreciated.

What you're thinking should work just fine, although you'll need a tile entity to handle the update; plain blocks only update when a neighbor is changed.

Alright. I'll do some research on tile entities then. Thanks.

 

What about trees though? Obviously I could do the same thing, as ores, and I should also most likely have a genTree() function of sorts to call when needed. But should I just call a bunch of world.setBlock() to spawn a tree with the coordinates relative to the stump? Or would there be a better way?

Hmm, that will be a bit trickier... You could iterate down to find the bottom block (a log block on top of dirt) and place your custom block there. Then, when you want to spawn the tree, there's got to be some method you can call to do this for you; just look at the sapling code.

Didn't think about looking at how saplings generate trees, lol. Sounds like a plan.

 

One more thing that just came up -- for the player's dataWatcher, I'm limited to using indexes 19-31. With due to this, I can only track the player's current experience of 13 skills. I'd like to go beyond 13, if it's possible. Any idea of a workaround?

I have nothing against your plan for these respawning ores and trees, but just a word of caution. TileEntities that tick (which I presume these would) eventually lead to lag in larger quantities. If you don't mind a little slowdown, then press on.

If you don't require your ores to regenerate at an absolutely perfect rate, you can forgo tile entities altogether by setting your block to tick randomly, return some value from tickRate(World), and handling what you need in the block's updateTick method. While this saves some on memory, it limits you to using the block's metadata as a counter, which may or may not be feasible/sufficient for your needs. Just to toss out another option

If you don't require your ores to regenerate at an absolutely perfect rate, you can forgo tile entities altogether by setting your block to tick randomly, return some value from tickRate(World), and handling what you need in the block's updateTick method. While this saves some on memory, it limits you to using the block's metadata as a counter, which may or may not be feasible/sufficient for your needs. Just to toss out another option

 

I could do that. In fact, I'll probably do that. Store the previous block's ID as metadata within the emptyOreBlock. From there, determine a percentage that will determine whether the block respawns or not (probably just make a random number between two values). Higher tier ores will have a lower chance to respawn on tick.

 

I plan to have trees respawn similar to ores, so if using tile entities does mean taking a hit on performance, and with how common trees + ores are going to be in the world, it seems best straight from the start to make due with my plan above.

 

Think Runescape. The ore/trees of that game is what I'm trying to replicate. Well, this mod will be a Runescape mod in general. Once I figure out how to do the skills (and how to make some GUIs), I'm going to work on items, and then eventually mobs. My only issue is that I'll probably have to "combine" some skills on leave some out since the player's dataWatcher only has indexes 19-31 available.

I meant using the metadata as a counter - there aren't enough bits in there to store a full block ID (only 4 bits of metadata storage per block). If you plan on having that many respawning blocks, you're probably going to have a huge performance hit irregardless of whether you use ticking blocks or tile entities, though slower tick rates should help ameliorate this somewhat.

 

Instead of making a new fake block for every single one of your blocks, I was more suggesting that you take your original block and only allowing it to be harvested say when metadata is zero; upon harvesting, instead of breaking, you pop out whatever drop you want and keep the block there, but set its metadata to 15. When the update tick runs, decrement the metadata at those coordinates by one. Of course you will have two different icons, one for its harvestable state, and one for its dormant state.

 

Again, this all depends on your blocks - if you are using the metadata for other things, it may not be available for you to use as a make-shift timer, but if you have at least one bitflag to determine the harvestable state, you can simply use a Random to determine if the flag gets reset during the update tick, which will effectively do the same thing if you make the chance low enough.

I meant using the metadata as a counter - there aren't enough bits in there to store a full block ID (only 4 bits of metadata storage per block). If you plan on having that many respawning blocks, you're probably going to have a huge performance hit irregardless of whether you use ticking blocks or tile entities, though slower tick rates should help ameliorate this somewhat.

 

Instead of making a new fake block for every single one of your blocks, I was more suggesting that you take your original block and only allowing it to be harvested say when metadata is zero; upon harvesting, instead of breaking, you pop out whatever drop you want and keep the block there, but set its metadata to 15. When the update tick runs, decrement the metadata at those coordinates by one. Of course you will have two different icons, one for its harvestable state, and one for its dormant state.

 

Again, this all depends on your blocks - if you are using the metadata for other things, it may not be available for you to use as a make-shift timer, but if you have at least one bitflag to determine the harvestable state, you can simply use a Random to determine if the flag gets reset during the update tick, which will effectively do the same thing if you make the chance low enough.

 

Ok. How about this: I could use the metadata to determine whether the block can be harvested. If metadata > 0, then the block can be harvested. If the metadata is zero, then you simply can't harvest the block (cancel the BreakBlock event). From there, it's just figuring if I can dynamically switch the texture of the block so the player visually knows that the block can't be harvested. If all else, I suppose I could show a message, but that would just be annoying -- especially when it comes to the rare ores. I can also possibly use said metadata to determine how many times the block can be harvested. So, a block with a metadata of 4 can be harvested 4 times before it has to "respawn". This number would always be between 0 and 15, so it should work. Then just do whats needed if the conditions on a randomTick are met (change metadata/texture. Spawn tree if it's a tree stump, etc).

An interesting game mechanic would be to require the player to take some sort of action multiple times to regenerate the block.