-
Posts
16559 -
Joined
-
Last visited
-
Days Won
155
Posts posted by Draco18s
-
-
So, then what would work for SMP? Or do I need to just look at how NBT Data actually works? How do I make sure that the data is specific for each player? Do I need to declare it within a specific class or what?
You need to figure out when you need to reference this data value and figure out where you can get a reference to the player.
Forge Events are probably the best solution.
-
Or
@Override public boolean isItemvalid(ItemStack par1ItemStack) { if(par1ItemStack !=null) { if(par1ItemStack.getItem() instanceof Block) { return true; } return false; } }
-
EntityPlayer player;
NBTTagCompound nbt = player.getEntityData();
I'm pretty sure this would crash,since you are referencing to a non instanciated object...
Obviously. I was merely declaring the object so that the OP knew what type it was.
The proper way would be: [code] EntityPlayer player = Minecraft.getMinecraft().thePlayer; NBTTagCompound nbt = player.getEntityData();
Also,@OP:
I think you misunderstood the use of NBT Data.This simply returns a list of informations stored in nbt.You have to use nbt.setInteger/setByte/etc... to save them.
That won't work for SMP.
-
Wait for it....
-
I got that, but why? ... Oh, wait. I thought you meant you'd be poking me with that stuff there.
Ended up using renderStandardBlockWithColorMultiplier rather than renderStandardBlockWithAmbientOcclusion.
The AO was causing odd shadows that I didn't want, and while the lighting is imperfect with the other, it's better than weird shadows.
func_102027_b is slightly better, but only if I boost the lighting value by ~50%
(func_102027_b is "render non-standard block with AO" but MCPBot is not online for me to update that function name and description)
-
Have a look at lines 7032 - 7043 of the RenderBlocks class and you'll see what I mean.
*Pokes with*
I'm confused.
I mean I'm poking with the stuff there.
-
Have a look at lines 7032 - 7043 of the RenderBlocks class and you'll see what I mean.
*Pokes with*
-
EntityPlayer player;
NBTTagCompound nbt = player.getEntityData();
-
Make a block have a slightly shorter collision box (look at Soul Sand) and then use an onCollide effect (check Soul Sand again) and use entity.addPotionEffect(Potion.jumpboost).
You'll have to tweak that a bit, but it should point you in the right direction.
-
My grandfather would like you. You're trying to teach common sense.
You mean uncommon sense. Or perhaps even super-sense.
But yes.
What I'm doing is teaching people how to debug their own fucking code and resolve their own stupid mistakes rather than ask for help all the time.
I mean yeah, I just posted my own fairly basic question, but I've been stuck trying to figure out what I'm missing for an hour now, trying all kinds of things to get the effect I want.
-
public class RenderFakeBlock implements ISimpleBlockRenderingHandler { public boolean renderWorldBlock(IBlockAccess world, int x, int y, int z, Block block, int modelId, RenderBlocks renderer) { renderer.renderFaceXPos(block, (double)x, (double)y, (double)z, block.getBlockTexture(world, x, y, z, 4)); renderer.renderFaceXNeg(block, (double)x, (double)y, (double)z, block.getBlockTexture(world, x, y, z, 4)); renderer.renderFaceYPos(block, (double)x, (double)y, (double)z, block.getBlockTexture(world, x, y, z, 1)); renderer.renderFaceYNeg(block, (double)x, (double)y, (double)z, block.getBlockTexture(world, x, y, z, 0)); renderer.renderFaceZPos(block, (double)x, (double)y, (double)z, block.getBlockTexture(world, x, y, z, 3)); renderer.renderFaceZNeg(block, (double)x, (double)y, (double)z, block.getBlockTexture(world, x, y, z, 2)); } }
This is what happens in world. Note that both setups are exactly the same. My block is set to get a texture from a neighboring block (the only valid one being the pumpkin in the center).
http://s22.postimg.org/q4hd2p3cx/2013_06_20_11_22_02.png[/img]
Even for the one showing up not-black, it will flicker a little when you look at them directly (get fully bright, as they should be, then when you look away, they drop about 2 lighting levels).
I suspect this is due to a missing function call on my part, but I can't figure out what call that is.
-
5 then.
Now look at your base class.
-
So... I finally solved it.
Appearently in MC forge uses the case sensitive mod id,while in eclipse doesn't.
Since my mod id in the resources folder was "mods/dmod" while in my src files was "DMod" the textures didn't want to load.
Wow. How obscure is that.
Glad you solved it!
-
Does it not output anything?
No, it outputs.
-
The good news is: I had already tried that.
The bad news is: I can't quite return that from my function.
Function as of now just in case it will help:
public EntityPlayer getName() { return EntityPlayer.username; }
*Facepalm*
First off, the return type of that function is wrong.
Second you need a player reference, the username property is not static.
public String getName(EntityPlayer player) { return player.username; }
Basic programming stuff, this.
-
I know it can be done in 1.5, although I haven't done it with items (hell, even the block I use that does it doesn't do it for its own item renderer!)
-
Lets see.
You have a constructor which is passed arguments.
You have a function that runs in the constructor that needs arguments.
There are vanilla blocks that operate in a similar manner.
2 + 2 = ?
-
EntityPlayer.username
Use your javadocs.
-
No I dont need to, because you are never going to have the on state block in your hand, but thats not my question, my question is why are they the same names
Because the constructor of BlockFencePiston sets the unlocalized name to the same string in both cases.
-
Did I get the first right? Because if I did, then 16... again. But if not, then I'm not sure I know.
Oh your first answer was right.
It is not correct this time.
-
Ok,I will try to use getUnlocalizedName2();
EDIT: Nope,getUnlocalizedName2(); doesn't work either,as I was expecting.
Anyway,you are wrong about the substring part.
Here is the getUnlocalizedName(); code from block.java.
public String getUnlocalizedName() { return "tile." + this.unlocalizedName; }
Since I don't want the "tile." I do substring(5) to get rid of it.
Ah, I forgot it prepended that.
In either case, I just hand-code my icon registration and skip the unlocalized name stuff (other than to give the block a name).
-
16 is printed... why?
Now how about this:
class myclass { int myInt = 5; function myclass() { int myInt = 16; anotherFunc(); } function void anotherFunc() { System.out.println(myInt); } }
What does that output?
-
.
BlockUniMatterBlock has an unlocalized name of "blockUniMatterBlock".
Stripping off the first 5 characters gives us "UniMatterBlock"
Icon registration uses that string as the file name.
There is no file named "UniMatterBlock.png"
There is one named "blockUniMatterBlock0.png"
The 0 we can ignore because of subblocks, point is, if you don't do the substring part, it might actually work.
-
I'd like to see the whole line, as well as what you're setting the unlocalized name to.
Registering 2 of the same blocks
in Modder Support
Posted
What does this mean?