Mod Loading Order/Creating Blocks at Runtime

[TheMasterGabriel]

Hi,

I currently trying to make a dynamic block that is mod-friendly. By this I mean my mod will generate tons of sub-blocks based on all the game's registered blocks (kind of like Forge/RedPower Microblocks, if I remember correctly). The fact that I want this to be mod-friendly brings up the question of mod loading order: Is there a way to force my mod to load after every other mod? This way, I can ensure that when I generate all the sub-blocks at runtime I account for every single added block, not just vanilla or the blocks added before my mod loads. (And by extension, what is the latest ModState I can register blocks in?)

 

As a side note, the reason I am trying to dynamically register blocks is because I need the data to persist across sessions. I am basically trying to make a camo-like block (from TGG's tutorial here), but instead of getting its copied block from its surroundings, it needs to remember what block it was. My first thought was just to use a TESR and save stuff to NBT, but there could potentially be thousands of blocks in one area at a time (as someone could make an entire base out of this block), so I'm guessing that would cause massive amounts of lag (which is what happens with a mod like Carpenter's Blocks), even if I use a FastTESR. Further, I'm hoping that my camo block can copy blocks with tile entities, like furnaces and chest, and maintain the functionality of said blocks. I don't think that would be possible if I were to use a TE to save my block's data, as I wouldn't be able to use the TE's of those copied blocks.

 

Also if anyone has a better method of doing this, or knows a better alternative, feel free to elaborate. - TMG

Edited March 21, 2017 by TheMasterGabriel

[Draco18s]

You cannot create block and items after preInit.

[TheMasterGabriel]

Alright, then my original question stands. How do I affect mod loading order? I read somewhere that its sorted alphabetically, so ideally without having to name my mod 'zzzzzzzz'.

[TheMasterGabriel]

33 minutes ago, diesieben07 said:

You can put "after:*" into dependencies in your @Mod and your mod will load after every other mod (unless that mod also has this tag).

 

Yea, that was another one of my first guesses, but I didn't want to use it because it doesn't guarantee the order in all cases, as you pointed out. If there is no other way however, then I suppose it will do. I may not get all the blocks, but at least I will get most of them.

[TheMasterGabriel]

Yes, but I'm trying to make the copied block function exactly like the actual block. Copied chests should look and work exactly like normal chests (to both vanilla and to other mods interacting with said blocks), and the same applies for furnaces, crafting tables, etc. I'm not sure that would be possible if I used my own TE to serialize the copied block data, as I said above.

 

Also, I've run into problems with mimicking blocks that have an EnumBlockRenderType other than EnumBlockRenderType.MODEL, which is another problem I have to figure out.

Edited March 21, 2017 by TheMasterGabriel

[TheMasterGabriel]

Yea, I've started to fear that. What I was thinking for the TileEntity thing was to, if I used pre-baked models, tell each subblock to provide the TileEntity that corresponds with its pre-defined copied block state. So that a copied chest, for example, would know that it was imitating a chest and provide and instance of TileEntityChest. This runs into problems when blocks check if Block at a certain block position is the same as itself rather than checking if the TileEntity at the position is an instance of its own tile entity, but that's the only real problem I can see with that system.

 

In terms of imitating block's whose render type is not MODEL, any advice/is it possible?

[TheMasterGabriel]

1 minute ago, diesieben07 said:

Set your render type to be MODEL. Then in your model do nothing (return an empty list of quads) if the currently imitated block has INVISIBLE or ENTITYBLOCK_ANIMATED. In case of LIQUID delegate to the forge liquid model.

 

But will that work for rendering chests and shulker boxes, for example? Both of those blocks are ENTITYBLOCK_ANIMATED.

[TheMasterGabriel]

4 minutes ago, diesieben07 said:

Your block will need a TESR by default. Normally it would just do nothing and in the case of a block with a TESR it would delegate to that.

 

Hmm, that might cause a problem. I'll see what I can do.

[TheMasterGabriel]

Just another question, would this be an instance where using a FastTESR is acceptable? I'm not really sure on where/how they are supposed to be used, so a link or something would be helpful for now/going forward.

[TheMasterGabriel]

So I've run into another problem. It looks like I'm going to have to abandon the entire TE serialized block data in favor of generating blocks at runtime. The reason is because I cannot perfectly emulate other blocks within my own block class. Methods like Block#isPassable ruin that, as they accept World and BlockPos parameters instead of an IBlockState parameter. If I delegate that method from my block class to my copied block class, there is a chance of it crashing. For example, if my copied block is BlockSnow, running Block#isPassabe crashes the game as it first gets the current block state at the passed position (which would be my copied block), and then tries to read an IBlockState property off the blockstate, which of course fails because my block doesn't contain that property (which for snow is LEVEL).

 

So as of now, there are really only three ways (two of which may or may not be possible) I can think of solving this problem:

- Create a new Block singleton, which holds the copied IBlockState, for every single IBlockState entry within the BlockState map (and setting my block's default state to that blocks default state, and setting my block's IProperty list to that block's IProperty list to overcome the error I described above). Of course, the problem with this is that it depends on mod loading order.

- Stick with one block instance and the TE thing, but give my block every single IProperty from every single registered block so that I don't run into the problem above (is this even possible?)

- Someone dynamically change what IProperties my block holds depending on my copied block (which I save in an unlisted property). Are the properties listed in Block#createBlockState malleable, or are they registered once and that's it. (I suspect the latter, seeing that an IBlockState map exists).

 

In all the cases, I somehow need my block to hold every single IProperty and IUnlistedProperty of either its copied block or every single block, so that I can make sure that every interaction/event that would happen to the copied block is duplicated in my new block.

 

As always, if anyone has a better alternative, please tell me.

[Draco18s]

41 minutes ago, TheMasterGabriel said:

- Stick with one block instance and the TE thing, but give my block every single IProperty from every single registered block so that I don't run into the problem above (is this even possible?)

No, because mods can define their own properties.

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/api/blockproperties/Props.java#L22-L36

 

What you can do though is create a dimension:

https://github.com/Draco18s/ReasonableRealism/tree/master/src/main/java/com/draco18s/industry/world

Place the stored block into that dimension and when you need to pass interaction to it, get that world and perform operations on it:

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/industry/entities/TileEntityFilter.java#L145

Edited March 22, 2017 by Draco18s

[TheMasterGabriel]

15 minutes ago, Draco18s said:

What you can do though is create a dimension:

https://github.com/Draco18s/ReasonableRealism/tree/master/src/main/java/com/draco18s/industry/world

Place the stored block into that dimension and when you need to pass interaction to it, get that world and perform operations on it:

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/industry/entities/TileEntityFilter.java#L145

 

 

Oh that's an interesting idea... So when I pass the world parameter through, pass through a WorldServer instance that I get via DimensionManager instead. Hmm. That may solve my tile entity interaction thing as well. I'll have to investigate that.

 

15 minutes ago, Draco18s said:

No, because mods can define their own properties.

 

 

I had realized that. My idea was to use ASM to discover (not alter) any fields that met the property requirements and add them to a list (assuming it wasn't on the list already), which I would then use in registering my block. The dimension idea might work better, however.

 

Edit:

Also, this needs to work in every dimension, so I presume I would need to create a 'dummy' dimension for every single registered dimension. I run into the loading order problem again there, though.

Edited March 22, 2017 by TheMasterGabriel

[Draco18s]

6 minutes ago, TheMasterGabriel said:

Edit:

Also, this needs to work in every dimension, so I presume I would need to create a 'dummy' dimension for every single registered dimension. I run into the loading order problem again there, though.

Nah, don't bother.

 

The likelyhood of a collision is very low. Add on top of the fact that you're going to store the blockstate in your TE, so if the location in the dimension doesn't match the stored block state, you overwrite it, make the calls you need, then you're done.

[TheMasterGabriel]

4 minutes ago, Draco18s said:

The likelyhood of a collision is very low. Add on top of the fact that you're going to store the blockstate in your TE, so if the location in the dimension doesn't match the stored block state, you overwrite it, make the calls you need, then you're done.

2

I suppose that's true. Alright, I'll give it a go. It may not be a pretty solution, but it's a solution nonetheless.

[TheMasterGabriel]

Unfortunately, I found another problem. Some block methods, like Block#tickRate, don't provide any useful arguments whatsoever (World and BlockPos, or IBlockState). That means I cannot get the copied block state from my block's iunlistedproperty in order to call Block#tickRate on it. The only way to do this would be to have direct access to the IBlockState via a local field, as BlockStairs does. I may end up having to go with the "new block instance for every single valid iblockstate" method after all.

[Draco18s]

Block#tickRate is used by virtually nothing, externally.  It's used internally for a block to define how often to regularly schedule ticks (eg. redstone wire/repeater) internally. It doesn't take a blockstate parameter because it's irrelevant.

Edited March 22, 2017 by Draco18s

[TheMasterGabriel]

2 minutes ago, Draco18s said:

Block#tickRate is used by virtually nothing, externally.  It's used internally for a block to define how often to regularly schedule ticks (eg. redstone wire/repeater) internally. It doesn't take a blockstate parameter because it's irrelevant.

2

Yes, but because I'm trying to make a block that is an identical copy of what its mimicking (in terms of looks, functionality, and interaction), all those methods are important. Block#tickRate was just an example, there are other methods like Block#isCollidable and Block#getTickRandomly which are called by external things (or could be called by other mods). Because it needs act just like its copied counterpart, I need to take into account everything, even things not currently used in vanilla (as other mods may use them).

[Draco18s]

isCollidable() -> only called by Block#canCollideCheck which is passed an IBlockState (and literally the only thing that overrides this to do something special is stairs, and stairs uses it to call back to the stone block that they're the variant of--does the same thing with tick rate --and as the stone block class doesn't override it, it returns true).  This really isn't significant.

 

tickRate() -> only called externally by the command block and ForgeFluids--both for causing update ticks after making a change--universally returns 10 in all cases.  Called internally by tripwire and tripwire hooks for the same purpose.  This really isn't significant.

 

getTickRandomly() -> you should just return true in all cases.  Scheduled block updates override random updates anyway (if there's a tick in the queue the block at that position doesn't get a random tick--I've only observed this with blocks I've coded I haven't dug into the tick scheduler to verify, but I've scheduled ticks for hours into the future and not had it receive a random tick).  This really isn't significant.

 

======

 

Pretty much if there is no World/BlockPos/IBlockState parameter passed to a block method, it's used by so little that the state-ness of a block needing to alter functionality isn't needed.  They're basically dead-end functions.

[TheMasterGabriel]

22 hours ago, Draco18s said:

Pretty much if there is no World/BlockPos/IBlockState parameter passed to a block method, it's used by so little that the state-ness of a block needing to alter functionality isn't needed.  They're basically dead-end functions.

 

I suppose. I guess testing will be the judge.

 

On 3/21/2017 at 1:11 PM, diesieben07 said:

Then you can use a special baked model to ensure your block looks like the one it's mimicing.

1

Do you have any pointers on how to achieve this? I'm not aware of any baked model that has access to a World and BlockPos instance in getQuads so I can fetch the information from my TE. My original idea was to store the copied block state in an unlisted property, which I would set when my TE deserialized from NBT, and then read that property from within my model to use in getQuads. However, it appears that TEs' World objects get set after they read from NBT, so I cannot set said property. (Although for whatever reason, TEs on the client side have access to their World objects during NBT reading).

[TheMasterGabriel]

Yes I figured that, which is why I am using an unlisted property. The trouble is getting the unlisted property to persist across loads. I can serialize it in my TE's NBT tag, but I cannot set it back again when my TE deserializes. When a TE is loaded server-side, its internal world instance has not been set yet, thus I can't use World#setBlockState. TE's positions are set, their world objects are not. The exception is when a TE is loaded client-side, because for some reason their world objects are set before their NBT loads (even though the code executed is exactly the same?).

 

Under normal circumstances, this wouldn't pose a problem, as I could just set the world in TileEntity#setWorldCreate, which is called before the NBT stuff (this is what signs do). However, as I want my copying block to act just like their counterparts, I do not have that liberty. My block, when it is mimicking a block with a TE, returns that associated TE in Block#createTileEntity (which is necessary, as other TEs depend on instanceof among other things). To get around this, I thought of using a capability, which I would attach to TE on creation. Using a capability allows me to save the copied block data in any TE instance, rather than just my own. But again, I run into the null world problem during deserialization.

 

The only solution I can think of at the moment would be to use that weird client-side thing to my advantage. Since TEs on the client do have world access during NBT load, I could set the blockstate on the client and then send the update to the server via a packet. However, I prefer not to do that as the server generally should handle all that stuff. (and it seems a bit hacky)

[TheMasterGabriel]

9 minutes ago, diesieben07 said:

So, in getExtendedState you get your tile entity, grab the stored block state, put it into your unlisted property and return the resulting IExtendedBlockState.

 

Oh, I see the problem with what I'm doing. I cannot use Block#getExtendedState to set my block's unlisted property because it gets called after Block#createTileEntity, which uses my block's unlisted property to decide what TileEntity should be created.

[TheMasterGabriel]

11 minutes ago, diesieben07 said:

You cannot use unlisted properties outside of getExtendedState!

 

 

Hmm. I did not know this. So, for example, I cannot cast the IBlockState parameter in Block#isOpaqueCube to an IExtendedBlockState?

 

11 minutes ago, diesieben07 said:

Why do you need multiple TileEntity implementations in the first place?

 

 

Again, my block needs to be able to replicate any block that it wants to, including blocks with their own TEs. If my copied block clones a furnace, for instance, it needs to provide TileEntityFurnace. Likewise for more complicated TEs, like chests. Without doing so, tons of things would fail. For instance, if my block were mimicking a chest, it would delegate the onBlockActivated method to BlockChest. However, Chests require that the TileEntity at their current position be an instanceof TileEntityChest for them to do anything. Using my own TE would cause this to fail (Unless there is some hacky way to trick Java's instanceof check by allowing my TE to dynamically extend any TE instance, which doesn't make sense let alone exist).

Edited March 23, 2017 by TheMasterGabriel

[TheMasterGabriel]

18 minutes ago, diesieben07 said:

I mean, if you use TileEntityFurnace, how are you going to store the fact that you are replicating a furnace? TileEntityFurnace does not have an IBlockState field you can use for that.

 

 

 

57 minutes ago, TheMasterGabriel said:

To get around this, I thought of using a capability, which I would attach to TE on creation. Using a capability allows me to save the copied block data in any TE instance, rather than just my own.

 

 

 

 

Yea I thought that using a capability would solve this problem, but then I ran into the server-sided null world object problem, not to mention the fact that I didn't think the order in which code would run (my block requiring its TE to load and set my block's copied property, which it would use to know what TE? What ever could be the problem with that.)

 

18 minutes ago, diesieben07 said:

The only way to properly do this, including TileEntities, is to create a fake world which contains the original block.

 

 

 

 

 

 

 

 

So this goes back to @Draco18s  idea of a dummy dimension. So all my overridden methods that delegate to my copied block need to use that dummy dimension's world instance instead of the current one. Also, my ExtendedBlockState would not read from my own TE. Rather, it would check what block is at its current position in the dummy dimension and return that IBlockState? That seems to make sense to me.

 

Side note, is it safe to use DimensionManager.getWorld(id) on both logical sides? I'm asking because some of my delegated methods are server-specific while others are client-specific (like Block#randomDisplayTick).

 

Completely unrelated: Why is the quoting system so unbelievably annoying. What is with the random numbers appearing, not to mention the huge blank spaces like above.

Edited March 23, 2017 by TheMasterGabriel

[Draco18s]

3 minutes ago, TheMasterGabriel said:

Side note, is it safe to use DimensionManager.getWorld(id) on both logical sides? I'm asking because some of my delegated methods are server-specific while others are client-specific (like Block#randomDisplayTick).

No.  And not actually for the reason you think.  I forget exactly what happens when using DimensionManager.getWorld(id), but it's not reliable.

 

Here's how you should do it:

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/industry/CommonProxy.java#L10

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/industry/client/ClientProxy.java#L20

Edited March 23, 2017 by Draco18s

[TheMasterGabriel]

Oh fake worlds! What fun!

 

Alright, I'm going to have to completely redo my system. All for the best though.