try getLightOpacity and set it to 0 for none, 1 for leaves and 3 for water. Or 255 for Black.
I found every block’s texture on side TOP&BOTTOM is exactly same whether its facing…
It’s okay in most situation… but I made a square machine(means wide != length) and top&bottom sides’ texture become weird…
And I mentioned MultiTileEntityChest will rotate its top texture, on line 299 glRotatef(COMPASS_FROM_SIDE[((MultiTileEntityChest)aTileEntity).mFacing] * 90 - 180, 0, 1, 0);
Could you change the universal rendering method just like this? I don’t want to do every blocks’ rendering job by myself…
EDIT: If not, could you tell me what location the rendering method is?I’ll try to make it in my fork…
Wait what facing? if it has top bottom sides it doesn’t have a facing.
As for that Chest TileEntity, I copied it from vanilla, it literally does the same thing.
Just like this
I pointed the brightness changing direction from dark to light
For Blocks facing top&bottom, I just didn’t requested something to be done…
Ah I see your Issue, yeah there is a reason I tend to make the top side of my Blocks symmetrical or rotation agnostic. My Machines are all Blocks, so they use the Block Renderer without any rotation applied to anything.
As for the Chests, yep they have actual Entity Models, that’s why they rotate like that.
Chests do have some differences…At least they isn’t a full block…
So gregtech is actually didn’t do anything on those machine blocks’ rendering…?
So do you willing to solve that?
hmm… couldn’t we rotate the icon got from getTexture2
and then give that to minecraft’s render?
Technically you could, if you rewrote the texture rendering of that ITexture thing.
I personally would just make 4 textures, one for each rotation, because lazy. XD
Making 4 textures do solved the problem…although I not so willing to do that…
Anyway, thanks for your help and I will try it.
You could make 4 corner textures all with a slightly different look, then you dont really need to rotate and you also get variety.
I mentioned the large javadoc in OreDictMaterial
, which decleared an ID range to people…I need one, too.
I don’t know if I need the large range or medium range…
There are 2 mods in plan, kTFRUAddon to provide things for whole modpack, and kBioGregTech6 to make some latest BioTechnology things.
I do need to add many materials,but I don’t know if I really need 1000 space for me.
And the large range seems about to run out.
I can give you one of the 500 Ranges, and if you need more I give you another, lol
Here is the Range I will give you:
[22000:22499] kuzuanpa
Just be aware of the updated javadoc comment, and read the number I just gave you carefully because it might not be the one you expected, since I skipped over one range for the sake of making sure the extended version of your range is still in the 22K Range because OCD
the extended version of your range is still in the 22K Range because OCD
Thanks for your thoroughness
It’s okay because I can’t see each material’s ID because I use i++ when giving IDs
Uh you are aware that you have to keep the SAME ids forever in order to be save file compatible right? If you inject a Material inbetween two others inside your for i++ loop, you will fuck up save files.
So you better manually assign each and every single ID to make sure you dont screw up save files.
Also even if you do the stupid i++ thing, I would recommend ++i instead.
I already knows that since I use that method, orders of codes won’t change itself.
I may insert a javadoc to mention myself and other co-developers…
++i is a good idea, thanks.
Yeah the ++i helps you if you need to access the same material you previously created, for stuff. Just make sure that you dont forget the ID “22000” exists, not that you start at “22001”
New problem, why I specified
NBT_INV_DISABLED_IN,true,NBT_INV_DISABLED_OUT,true,
there are still these tooltips, Item IN:…ItemOUT…
These is full code of my machine
aMat = MT.SteelGalvanized; aRegistry.add("Fusion Battery" , "Multiblock Machines" , i++, 17101, MultiTileEntityBasicMachine.class , aMat.mToolQuality, 16, aMachine , UT.NBT.make(NBT_MATERIAL, aMat, NBT_HARDNESS, 12.5F, NBT_RESISTANCE, 12.5F, NBT_TEXTURE, "fusionreactor",NBT_RECIPEMAP ,recipeManager.GasBattery, NBT_INPUT,1,NBT_WASTE_ENERGY,false,NBT_INV_DISABLED_IN,true,NBT_INV_DISABLED_OUT,true,NBT_ENERGY_ACCEPTED_SIDES,SIDE_DOWN,NBT_ENERGY_EMITTED_SIDES,SIDE_UP,NBT_TANK_SIDE_IN,SIDE_LEFT|SIDE_RIGHT,NBT_TANK_SIDE_AUTO_IN,SIDE_LEFT|SIDE_RIGHT,NBT_TANK_SIDE_OUT,SIDE_FRONT|SIDE_BACK,NBT_TANK_SIDE_AUTO_OUT,SIDE_FRONT|SIDE_BACK, NBT_OUTPUT, 1, NBT_OUTPUT_MIN, 1, NBT_OUTPUT_MAX, 2 , NBT_ENERGY_ACCEPTED, TD.Energy.TU, NBT_ENERGY_EMITTED, TD.Energy.EU), "FFF", "FMF", "FFF", 'M', aRegistry.getItem(18003), 'F', IL.FIELD_GENERATORS[5]);
how can I remove them?
Uh are you trying to use a Basic Machine to OUTPUT energy? If so you are using a very wrong class for that.
Most of my generators are written on a case by case basis, and dont really have much of a common class.
hmm, I just try to use that to study codes…
Okay… So I need to handle tooltips by myself…
You need to handle more than that yourself, Basic Machine is not supposed to be an Energy Producer or Storage.
I mentioned when my tool broke, I would achieve some effects…slowness,weakness, did that feature made by GT?