Elegant modding and Substitution

[Koward]

Hello.

 

The substitution mechanism allows to alias an item/block with one of our own.

Though added a long time ago it started working well only recently, thanks to all those who worked on it.

 

Imagine one wants to modify a vanilla item, for whatever reason.

He extends it and then two ways appear :

[*]Remove all ways and references to obtain the item and re-add these with the custom item.

[*]Use substitution to create an alias.

 

My question is : which solution would provide the most elegant and easy to maintain code, and what are the trade-offs and limitations of each way ?

[Animefan8888]

Hello.

 

The substitution mechanism allows to alias an item/block with one of our own.

Though added a long time ago it started working well only recently, thanks to all those who worked on it.

 

Imagine one wants to modify a vanilla item, for whatever reason.

He extends it and then two ways appear :

[*]Remove all ways and references to obtain the item and re-add these with the custom item.

[*]Use substitution to create an alias.

 

My question is : which solution would provide the most elegant and easy to maintain code, and what are the trade-offs and limitations of each way ?

Assuming substitution doesn't break in following updates substitution would be the most easy to maintain.

[Koward]

Assuming substitution doesn't break in following updates substitution would be the most easy to maintain.

 

Indeed. If the substitution is a complete equivalent of solution 1.

I have not tested something : while I know alias replaces old item in stacks and a few other instances, I've yet to check if the original instance saved in Items (for vanilla) is replaced too (whether all item == Items.BOW would become true for a Items.BOW alias), else that means substitution would not be completely equal to solution 1 in some cases.

[jabelar]

I like the idea of substitution but only last tried it while it still wasn't working. If it's working now that is great news.

 

But previously the way I did this was also fairly easy to maintain -- I simply intercepted the placement of the block using events and placed my block instead. This at least works for blocks that will appear during world-gen. If you're worried about creative mode where there will be custom tab with list of all blocks, you'd have to intercept that too to show your custom block.

 

So not that hard to intercept. But again a working substitution system would be better. Just wanted to say how we used to do it when substitution didn't work.

[Koward]

But previously the way I did this was also fairly easy to maintain -- I simply intercepted the placement of the block using events and placed my block instead. This at least works for blocks that will appear during world-gen.

 

That's one case. One case is easy to maintain. If you want to substitute let's say 25 items/blocks you may have a dozen different cases and events where you remove the old and replace with the new. At each update those can potentially change and break partially or completely your code.

That's why substitution would be easier to maintain. It's an abstract task, the way it works internally could be updated, improved by the Forge team in the future without us having to worry about it at all.

[jabelar]

I do understand how substitution is better. In fact I'm one of the first people that tried the original substitution system!

 

Just saying that before substitution worked, I usually used events. It was possible to organize the handling of multiple blocks fairly easily with switch or if-then-else statements. But as you mentioned it was definitely a bit of work to handle all the cases for sure and more work to maintain.

 

[Animefan8888]

I do understand how substitution is better. In fact I'm one of the first people that tried the original substitution system!

 

Just saying that before substitution worked, I usually used events. It was possible to organize the handling of multiple blocks fairly easily with switch or if-then-else statements. But as you mentioned it was definitely a bit of work to handle all the cases for sure and more work to maintain.

If you added the Items to a map of <Item, Item> where the first one was the original and the later one was the replacement you could just loop through that list to compare items. Then if the Items matched you would your replacement for the original item right there. Though that is only really useful if you have lets say 10+ plus replacements. And of course you could do the same for Blocks.

*Edit Correction you could just use map.contains(item) then if true do the replacement. No need for a for loop.

[jabelar]

If you added the Items to a map of <Item, Item> where the first one was the original and the later one was the replacement you could just loop through that list to compare items. Then if the Items matched you would your replacement for the original item right there. Though that is only really useful if you have lets say 10+ plus replacements. And of course you could do the same for Blocks.

*Edit Correction you could just use map.contains(item) then if true do the replacement. No need for a for loop.

 

Yes, that's the kind of thing you would do in each event.

 

However, in terms of the work that Koward is referring to, keep in mind that you also have to replace all behavior that the original block might have had. So there are lots of events you might need to handle.

 

Like for example seed items might only grow on tilled soil, so if you replaced all tilled soil with a custom tilled soil, you have to handle that interaction. In other words, in terms of events you need to handle not just the initial generation of chunks (in the chunk populate) but also things like item right-clicking, block breaking, block placing, blocks and decorations creative tabs, and so on.