Bypassing JSON for texture registering

[dagobertdu94]

Hello,

 

I would like to create blocks and items dynamically if someone is providing a special info file for blocks/items.

The problem is that every texture and every json file needs to be in my mod file at the right place, but I want to load such

block model files and/or block textures from anywhere. In 1.7.10 this was a bit easier to do but since 1.8 it seems to be impossible.

Is there any way to do it so I want it?

Thanks for any replies!

[desht]

Creating any registry objects (which includes blocks and items) dynamically is a big no-no.  You can't do it.

[dagobertdu94]

4 hours ago, desht said:

Creating any registry objects (which includes blocks and items) dynamically is a big no-no.  You can't do it.

I can create blocks and items dynamically as long as I do that in preinit.

I mean the registration of the textures and models.

[dagobertdu94]

2 minutes ago, diesieben07 said:

preInit? Which version are you modding? You should be using DeferredRegister or registry events.

As it seems I would say everything from 1.12.2 up to 1.15.2...

3 minutes ago, diesieben07 said:

Regardless, dynamically creating registry entries based on configuration is a bad idea and highly discouraged.

Well, I know that already from other topics but I want to do that, because my mod is already using a dynamic registration for other things of my mod and now I want to build something similar to import textures and model files from anywhere at runtime. I wouldn't want to use a mod if I had to copy a huge amount of files (textures and model files) in a jar mod file myself before I could use a mod, I think this makes some sense...

(Sorry for my bad english.)

[dagobertdu94]

3 minutes ago, diesieben07 said:

Dynamically registering registry entries is not supported. In fact in 1.14.4 and 1.15.2 registry events deliberately fire before configs are loaded.

FInd a different way.

Then I need to add that I load my own config files a little bit different than forge it does. (In 1.6.4 it never worked properly for me and since then I never used them again...)

4 minutes ago, diesieben07 said:

In neither of these versions should you register anything registry entry in preInit. Use the registry events.

1.12 is also no longer supported.

Well, since 1.7.10 I ever registered my things in the preinit using the findRegistry command in GameRegistry, and in 1.14.4 and 1.15.2 I was forced to use that registry events since the findRegistry command in the GameRegistry was removed.

[dagobertdu94]

2 minutes ago, diesieben07 said:

Please stop going against every system that is in place.

Then I know now why all good mods aren't available for the newest version. It isn't anything against you, if you should think so...

[Cadiboo]

Everything you want to do is possible, but I’m general it causes bad things to happen and is highly discouraged. If you want to do what you’ve mentioned right and compatibly it will require quite a bit of work to do right as you will need to deal with situations where objects haven’t been registered when a client connects to a sever. How are you planning on handling this?

 

You’re also going to need to handle all assets (models, textures) and data (recipes) in a compatible way that allows them to be overriden by resource and data packs.

 

If you’re trying to register objects only if another mod is present, there are other, more compatible ways of adding mod-specific content.

9 hours ago, dagobertdu94 said:

Well, since 1.7.10 I ever registered my things in the preinit using the findRegistry command in GameRegistry, and in 1.14.4 and 1.15.2 I was forced to use that registry events since the findRegistry command in the GameRegistry was removed.

You’ve been meant to use the registry events since 1.7.10. If everybody used the registry events correctly, dynamic registration would be possible, but people don’t and therefore supporting universal dynamic registration becomes impossible.

 

If you were a bit more clear about what you were doing and why you might find that people were more helpful. For example instead of saying “I want to do something that is discouraged because of how difficult it is to do right and incompatible with badly made mods it is” you could lay out why you want to do this, what you plan on doing in your mod and how you’re planning on handling edge cases (such as unregistered objects on connection) to ensure that everything continues to work properly.

Edited February 6, 2020 by Cadiboo

[Draco18s]

53 minutes ago, dagobertdu94 said:

Then I know now why all good mods aren't available for the newest version

Not really.

The main reason "all the good mods aren't available on the newest version" is because people move on. No one wants to spend all of their time supporting something they "finished."

(Or in some rare cases, like myself, I'm prevented from updating due to a missing feature in Forge that I'm having PR'd as well as trying to update Custom Ore Gen, which is taking a while as I don't understand a lot of the underlying systems)

[dagobertdu94]

In the meanwhile I am updating my mods to the latest version, too.

But I have problems with some things, like the ore gen or some events.

I just can't find some important things I used earlier.

Sometimes the old versions are better because I don't have to call multiple methods to do something which is in as example 1.12 only requiring a single method call.

And I used the GameRegistry to register all of my recipes, which I can't use anymore since the method got removed.

And of course without JSON I coudn't make my item models because I never understand to do that in Model classes.

[Draco18s]

13 minutes ago, dagobertdu94 said:

which I can't use anymore since the method got removed.

It got "removed" because recipes are now data assets, which means that mod pack makers don't need to use CraftTweaker. They can just supply fixed json files.

[TheGreyGhost]

Howdy

 

If you want people to be able to add variations of a Block or Item using a configuration file, so that you can let the artists create assets without having to modify code, then you might be able to get close to what you want by using BlockStates for Blocks or NBT for items.

 

It's more complicated than just coding all the blocks or items individually, so I wouldn't do it without a good reason.

 

If the differences between your blocks are largely cosmetic, or are based on a few different types of behaviour that can be combined in different ways, then you could (eg) just register a single block, but reserve 256 blockstates for your block.

You then read in the configuration file and assign blockstates accordingly.  Your single block then alters its behaviour and appearance based on the blockstate, to match the configuration file settings.

 

A similar approach is possible with Items and NBT storage.  

 

The purists don't tend to like this approach but it can be very useful for letting non-programmers work on assets / artwork and change the game behaviour rapidly without having to manipulate code.  It also lets many people work on the same blocks & items without clashing all the time due to code merge problems.   I have done this before with Entities (breeds of dragon) which had a large number of configurable parameters to modify their appearance and behaviour (such as size, health, colour, textures, agressiveness, type of breath weapon, etc) and it worked very well.  Adding a new breed of dragon involved adding an extra configuration file for that breed, no code modification at all.   Apart from making adjustments much easier, it also made the code very much simpler and a lot less brittle.

 

-TGG