TheGreyGhost
-
Posts
3280 -
Joined
-
Last visited
-
Days Won
8
Posts posted by TheGreyGhost
-
-
That depends on what the valid range of numbers is.
If the numbers you are trying to store are heavily restricted (eg 100 different possible values) then use blockstates (more efficient). You can cache the block instances in a custom data structure that you don't need to save (since you can easily regenerate it by iterating through all blocks when (eg) loading a chunk.)
Otherwise, use a TileEntity. The list of all (loaded) tileentities is maintained by vanilla automatically, you just need to filter it.
7 hours ago, Caffeinated Pinkie said:would it be better to use the WorldSavedData system to store and retrieve it?
Down that road lies nothing but pain and suffering.... Chunks loading in and out, other mods manipulating your blocks, multithreaded access, loss of synchronisation...
-TGG
-
Howdy
This tutorial project has some examples of screens
https://github.com/TheGreyGhost/MinecraftByExample
-see mbe30, mbe31, mbe32
-TGG
-
4 hours ago, MilkyCousin said:
Hello. What should I implement in order to create a new recipe type?
// ------------- Custom recipes // you can even register your own custom IRecipe class to match complicated inputs - see for example RecipeFireworks // There are a few useful vanilla recipes and Serializers you can base your Recipe on // eg AbstractCookingRecipe, SpecialRecipe and SpecialRecipeSerializer // or go the whole hog and write your own. Lots of vanilla inspiration to keep you on the right track. // All you need to do is register your serializer (assuming you know how to use @SubscribeEvent) // @SubscribeEvent // public void registerRecipeSerializers(RegistryEvent.Register<IRecipeSerializer<?>> event) { // event.getRegistry().register(yourRecipeSerializer); // }
-TGG
- 1
-
Howdy
I think - if your json works, just leave it as is. A long json isn't a problem really, and it could take you hours to figure out a "more efficient" method.
If you are very keen - you could take inspiration from redstone wire. They change the colour based on the power as well, using multistates to build up appearance based on properties.
-TGG
-
Howdy
This working example of particles might be helpful
-TGG
-
1 minute ago, TheGreyGhost said:
Howdy
you might find this tutorial project useful
https://github.com/TheGreyGhost/MinecraftByExample
see mbe04 but probably a TileEntity and TileEntityRender is more suited to what you're trying to do (mbe21 for rendering, with mbe30 /mbe31 for examples of containers).
-TGG
-
Howdy
you might find this tutorial project useful
https://github.com/TheGreyGhost/MinecraftByExample
see mbe04 but probably a TileEntity and TileEntityRender is more suited to what you're trying to do (mbe20, mbe21).
-TGG
- 1
-
7 minutes ago, BeardlessBrady said:
It seems that AtlasTexture and ModelLoader.instance().getSpriteMap... is no longer the same as your guide. Do you know how accessing those things have changed?
It seems to still be correct for me
// we have previously registered digitsTexture in StartupClientOnly::onTextureStitchEvent AtlasTexture blocksStitchedTextures = ModelLoader.instance().getSpriteMap().getAtlasTexture(AtlasTexture.LOCATION_BLOCKS_TEXTURE); TextureAtlasSprite digitsTextures = blocksStitchedTextures.getSprite(digitsTextureRL);
These compile fine
Check you build.gradle?
mappings channel: 'snapshot', version: '20200514-1.15.1'
minecraft 'net.minecraftforge:forge:1.15.2-31.2.0'
@OnlyIn(Dist.CLIENT) public class AtlasTexture extends Texture implements ITickable { private static final Logger LOGGER = LogManager.getLogger(); @Deprecated public static final ResourceLocation LOCATION_BLOCKS_TEXTURE = PlayerContainer.LOCATION_BLOCKS_TEXTURE; @Deprecated public static final ResourceLocation LOCATION_PARTICLES_TEXTURE = new ResourceLocation("textures/atlas/particles.png"); private final List<TextureAtlasSprite> listAnimatedSprites = Lists.newArrayList(); private final Set<ResourceLocation> sprites = Sets.newHashSet(); private final Map<ResourceLocation, TextureAtlasSprite> mapUploadedSprites = Maps.newHashMap(); private final ResourceLocation textureLocation; private final int maximumTextureSize; public AtlasTexture(ResourceLocation textureLocationIn) { this.textureLocation = textureLocationIn; this.maximumTextureSize = RenderSystem.maxSupportedTextureSize(); }
and
ModelBakery::
public SpriteMap getSpriteMap() { return this.spriteMap; }
-
-
9 hours ago, Alpvax said:
I don't see how that is true at all. Why does 1 block have to fit in 1 bucket? If we just accept that 1 block is 1296mb, everything works.
I don't see why we have to add the restriction that 1 bucket is 1 (solid) block. We can just accept that melting it makes it less dense, therefore bigger.
Howdy
The problem is that you're breaking the minecraft conventions to do that, for an arbitrary coding implementation reason.
Minecraft convention is:
9 nuggets per ingot
9 ingots per block
1 block = 1 bucket (think lava or water being filled into a bucket and back again).
This magic number 1296 (16*81) is only important behind the scenes, as a coding implementation, the user doesn't need to know about it at all. The whole millibuckets question is actually a bit of a red herring, because there are really two parts to this
1) what's the internal representation of a fluid (the "atoms" or "voxellites" or whatever)
2) what do we do with the currently-accepted user convention of "millibuckets"
personally I think the best answers are:
1) 4096*81 = 331776 units per block (i,.e. final int FLUID_AMOUNT_ONE_BLOCK = 4096*81;) which allows exact representation of all the standard objects that we're interested in (and hence gives conservation of mass with no round-trip-gain-or-lose-mass problems);
2) leave milliBuckets as 1/1000 of a bucket, and present it to the user in an (inexact) metric format eg "one nugget = approximately 111 mB"
-TGG
-
Hi
You don't appear to spawn your entity?
Look at BowItem::onPLayerStoppedUsing
worldIn.addEntity(abstractarrowentity);
-TGG
-
Yes, I mean your getElementPropertyOverride functions.
Have you put a breakpoint into there, then traced back out into the caller to see how it is using your returned value?
-
Howdy
I haven't used fluids myself, but here's a working example of IBlockColor. It uses the blockstate, but you could use biome information instead (see the vanilla IBlockColor eg for grass)
-TGG
-
Howdy
At the moment, I think it's largely a matter of personal preference.
Personally I don't like deferred registries because I hate the "magic pokery" of the Annotations methods, I prefer a more imperative style because it's much easier to find references to objects using the IDE that way.
But they both work fine, with the possible exception of some of the DedicatedServer vs ClientOnly events (old-style proxy) which are much easier to use in the imperative style. I wouldn't bother to change if/until the Forge masters remove the imperative style entirely.
-TGG
-
If your getProperty function is using NBT to return a value (by storing it in the ItemStack), then yes you need to make sure the NBT values are being written. But in your case I don't think you need NBT, the bound spell should work fine because it's bound to the Item.
Is your getProperty function working? Try putting a breakpoint into it to see if it's being called at all.
-
Howdy
I'm not sure exactly what you're trying to do,but this tutorial project has working examples of overrides on custom properties, ItemOverrideList, as well as changing the rendering of items without having a json for each texture
https://github.com/TheGreyGhost/MinecraftByExample
see mbe11 and mbe15
-TGG
-
Howdy
Yes it is
Here's a working example of texturing an item with a custom quad
DynamicTexture is suitable for creating an image in code.
If you search this forum for DynamicTexture you'll find some recents posts about dynamic textures (Elytra, wolves)
-TGG
- 1
-
Howdy
This is a vector math calculation.
1) use the two positions to define the vector offset from the player's eyes to the block (Vec_block minus Vec_Eyes)
2) use trigonometry to calculate the angles...
The LookController class shows a vanilla implementation
-TGG
- 1
-
Howdy
9 hours ago, Alpvax said:Bear in mind that more players use metric systems than imperial (according to minecraft server statistics, and the fact that there are few countries which still use the imperial system).
It is far easier for users to understand that half a bucket is 500mb, than it is for them to see 648 "atoms" (If that is the approach, I would prefer to use something like "voxellites" which has no real-world bearing than "atoms" which could cause huge confusion for users of chemical mods).
And to the next argument that you would just display it as "3 1/2 buckets" or 3 1/1296 buckets", that is hugely unnatural for me (and presumably many others).
That's for sure... the long slow death of the imperial system can't come fast enough for me.
Just to be clear - I'm not proposing that the users will ever know about the "atoms" or "voxellites" or "grains" or whatever, that's just an internal representation. The amount of fluid is stored using an int, i.e.
final int FLUID_AMOUNT_ONE_VOXELLITE = 1; final int FLUID_AMOUNT_ONE_NUGGET = 4096 final int FLUID_AMOUNT_ONE_NUGGET = 4096 final int FLUID_AMOUNT_ONE_BLOCK = 4096*81; //etc addFluidVoxellites(int voxellites) { this.fluidAmount += voxellites; } addFluidNuggets(int nuggets) { this.fluidAmount += FLUID_AMOUNT_ONE_NUGGET * nuggets; } addFluidMilliBlocks(float milliBlocks) { this.fluidAmount += (int)FLUID_AMOUNT_ONE_BLOCK * milliBlocks; }
9 hours ago, Alpvax said:I'm not sure what the issue with 144mb/ingot is. Why does a melted compound have to fit in the same space as a solid one? It doesn't in real life.
THe round trip is the problem. In real life, you get conservation of mass i.e. if you melt the compound then freeze it, you get the same mass as before.
if your ingot is 144/1000 of a bucket, then converting ingots to buckets and back again gains you several extra ingots.
If you define a bucket as 1296 "millibuckets", then every metric-system-based user thinks you've taken leave of your senses
Cheers
TGG
-
Sorry dude, I don't understand your question.
TER are very difficult to debug just by looking at the code.
Screenshots of the problem plus a github link to your project will increase your chances of someone figuring it out. Or, you could copy the mbe21 code exactly and then change it a few parts at a time until it does what you want.
-TGG
-
Howdy
This working examples tutorial project has both 1.15.2 (and 1.12.2). I'd recommend starting with 1.15.2 instead of 1.12.2. You'll get a lot more support that way...
https://github.com/TheGreyGhost/MinecraftByExample
-TGG
-
Howdy
The important clue is here
Duplicate registration copper_helmet
Your copper_helmet is being registered twice.
-TGG
-
4 minutes ago, DavidM said:
Honestly I would say having so many units would be confusing to new players (and some old players).
I don't see how remembering ounces, nuggets, voxels and the conversions between them is easier than "144mb an ingot, 1000mb a bucket".
Without a unified measurement (mB), some modders may start to favor certain units over the others, or invent their own units based on atoms, causing more confusion in the system.
that's the problem - i.e. an ingot is approximately 111.1111111 mB. Your system of units has to be consistent.
The bottom line is that you have to make tradeoffs for the user, i.e. you either use a decimal representation that is inexact, or you define exact units which will be unwieldy numbers. The whole metric vs imperial argument eg 15.363 kg vs 30 lb 3 oz.
One set of exact units works fine with "nice" numbers if you are dealing in whole amounts of nuggets (i.e. 9-based)
A different set of exact units is more "natural" if you want slabs (or 16-based such as 16x16x16 voxels)
When you mix the two together (for example you want to melt nuggets into panes) then you will always have residual bits left over that become messy.
If I were implementing a user interface for this, it would for sure be an inexact decimal representation (with an exact count behind the scenes). For any practical use that I can think of, the user would not care if an ingot is shown as 111 mB instead of 111.11111 mB.
- 1
-
Well the idea is that users won't know anything about atoms. It's for the coders only.
The user will know about
ounces, nuggets, ingots, and blocks, or voxels, lines, panes, and blocks.
Or some arbitrary measure such as grams, kilograms, tons, or just an inexact decimal representation such as 0.153 blocks. They'll have no idea how many atoms are behind the scenes.
[1.16.1] Help baking an OBJ model
in Modder Support
Posted
Howdy
The model loader parses a json file into a model.The last two parameters are required to supply the json information.
The easiest way is to let forge load the model for you by using it as a block model with a "dummy" parameter; for example see this working example
https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe21_tileentityrenderer
https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe21_tileentityrenderer/RenderWavefrontObj.java
https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/resources/assets/minecraftbyexample/blockstates/mbe21_ter_block_registry_name.json
-TGG