pelep

I used to find the mcmod.info annoying too and started to hard code my mod info that way, but i realized there might possibly be some other programs that depend on the mcmod.info file. maybe a launcher that uses the file to detect mods or get info about it? i think of it as a pseudo-manifest file. anyway, i thought it might not be a good idea to get rid of the mcmod.info and ended up putting the file back just to be safe. there's almost no difference anyway and it's sort of the standard thing to have already

you really should get your facts straight before you go around insulting people.. @gmod622 an easier way to do what you want is this if(j.getItem() != null && j.getItem() == main_ProcessCraft.ShapingHammer) { if (!j.attemptDamageItem(1, player.getRNG())) { j.stackSize++; } } although, this should already work fine assuming you added it to the rest of your code correctly int d = j.getItemDamage(); if(d > 128) { inv.setInventorySlotContents(i, null); }

then i suggest learning "advanced" java... or rethinking your definition of "basic". i remember your old thread and all you needed to know was already posted in it multiple times. people even posted code for you. the only thing stopping you from making your stuff work was.. well, not having a firm grasp of basic java.. yup. sadly, this is turning out almost exactly like the last thread

@hydroflame yep @OP that's really weird because i just tested it on a dedicated server and it wouldn't even get past the "if (Class.forName() && Keyboablablaba)" part. and it shouldn't. if it's working on a dedicated server, where the heck is it getting the keyboard input from? it can't be from the clients because the only checks for keyboard input is in pressClientKey() which is called by the server. also, i don't think you need packets. you can probably just use the datawatcher.

and just to clarify. onUpdate() is only called server side. so if you call pressKeyClient() in onUpdate() and only there, you're gonna have to change your set up because it won't work on a dedicated server

i'm trying to make sense of you code, and i don't get why pressKeyClient() is in your onUpdate() method. have you tested it on smp already?

don't the entity updates get called server side only? i'm not sure actually. but i vaguely remember that it's only server side. hence the data watchers was typing that but nevermind. if they update client side first for your truck, then i guess you aren't updating it properly like hydroflame said

doesn't look like you're sending the wheelyaw info to the client

your code should work. go to (0, 0, 0) in your world and you should see it rendered somewhere there..

coplanar! that's the word i was looking for. can't believe i already said the word "plane" and didn't think of it *facepalm* lol. @hydroflame i kid you not. if you look at RenderBlocks the only calls to glTranslatef you'll find is in renderBlockAsItem()

actually, for some reason, that doesn't work with the ISBRH

the vertices have to end up aligned. you should be able to make a plane out of the 4 vertices you provided. if they aren't aligned, imagine a plan with one corner pulled away from the rest. something like that happens. what you posted would render something, but definitely not a quad. don't know what it would be either though

that code you posted makes me think you didn't take a look at the torch code.. anyway, here's an example. just two random faces. hopefully, you'll be able to figure out how to use icons from that as well @Override public boolean renderWorldBlock(IBlockAccess world, int x, int y, int z, Block block, int rId, RenderBlocks rb) { Tessellator t = Tessellator.instance; Icon icon = Block.pumpkin.getIcon(3, 0); double minU = icon.getMinU(); double maxU = icon.getMaxU(); double minV = icon.getMinV(); double maxV = icon.getMaxV(); double p = 0.0625D; //first side t.setColorOpaque_F(1F, 1F, 1F); t.setBrightness(150); t.addVertexWithUV(x + (p * 14D), y + 1D, z + 1D, minU, minV); t.addVertexWithUV(x + (p * 14D), y + 0D, z + 1D, minU, maxV); t.addVertexWithUV(x + (p * 14D), y + 0D, z + 0D, maxU, maxV); t.addVertexWithUV(x + (p * 14D), y + 1D, z + 0D, maxU, minV); //second side. just messing around a bit here double u8 = icon.getInterpolatedU(8D); t.setBrightness(block.getMixedBrightnessForBlock(world, x - 1, y, z)); t.addVertexWithUV(x - (p * 0D), y + 2D, z + 0D, minU, minV); t.addVertexWithUV(x - (p * 0D), y + 0D, z + 0D, minU, maxV); t.addVertexWithUV(x - (p * 8D), y + 0D, z + 1D, u8, maxV); t.addVertexWithUV(x - (p * 8D), y + 2D, z + 1D, u8, minV); return true; }

[Deleted]

there is. look harder. it's really not that difficult to find considering it's in the same class. anyway, create a new MerchantRecipe (you can specify the buy/sell items in the constructor) then add it to the provided merchant recipe list. although i don't think you can remove the villager's default trades through an IVillageTradeHandler because they're only added after mod trades are added

actually, i don't. i'm not very experienced with handling files/uri/url stuff. still learning about it thanks!

yep. that's what i'm doing now thanks though! and a heads up to anyone who uses eclipse and grabs the mod location through injectData, it can give you a null location if you use the vm arguments to load your IFMLLoadingPlugin instead of a dummy jar file in the mods folder. (of course, it could just be my eclipse set up that's screwing things up for me, but i doubt it is)

the trades are in EntityVillager.addDefaultEquipmentAndRecipies. that's also where VillagerRegistry.manageVillagerTrades is called. i think you can remove the vanilla trades through your IVillageTradeHandler

File coremod = new File(minecraftDir,"coremods"); for (String cont : injectedContainers) { ModContainer mc; try { mc = (ModContainer) Class.forName(cont,true,modClassLoader).newInstance(); } catch (Exception e) { FMLLog.log(Level.SEVERE, e, "A problem occured instantiating the injected mod container %s", cont); throw new LoaderException(e); } mods.add(new InjectedModContainer(mc,coremod)); } in Loader.identifyMods() the location of the coremod is passed to the mod container, but the folder name specified is "coremods". anybody know if this is just some code that was overlooked in the 1.6 update or if it's intentional?

seems like you have to register your own IVillageTradeHandler via registerVillageTradeHandler. then you'd be able to manipulate the merchantrecipelist through it. although i'm not exactly sure what the limits to what you can do with it are (sorry, man, not really in the mood to dig around code right now) so you'll have to see for yourself

i've only looked into this a few times, but i think cpw.mods.fml.common.registry.VillagerRegistry might have what you need

registerEntityEgg(EntitySquishy.class, 0x7F6A00 , 0xFFBC42); what is that method? if you're registering your entity with registerGlobalEntityID, why are you registering the egg some other way? and are you intentionally overriding fireworks?

@d4rkfly3r there is no access transformer @wuppy29 yup. i think it's the same error. but again, i never really solved it before since i didn't need to anymore. but just for the sake of figuring it out, i'm reading up on asm again. my idea is that maybe you have to visit the super classes you need first for the classwriter to work properly. again, it's just guesswork for now. i'm reading up on it, but it's slow progress i'll get back here if i find anything.

would there be such a case? lol. if you mean for stuff that need textures larger than 16x16, icons don't seem to be restricted to 16x16 sizes. and using icons is basically the same as what you suggested, except that you don't need to change the texture. but if there are cases where the icons won't work for the ISBRH, then... i dunno. luckily for me, i don't have to think about that since icons work for what i'm doing hahahahha

yeah, but draw() returns an int which is used by MC afterward. according to the comments, it gets sent to the gpu. and i honestly don't know enough about how to handle gpu/hardware related stuff, so i decided not to mess with it and opted to use icons instead yeah but if you follow the call hierarchy you realise that this int isn't used anywhere (for some reason) so my method describe above wont affect anythign in that sens i did, and it gets added to bytesDrawn in WorldRenderer. but actually, yeah, i just noticed that bytesDrawn doesn't seem to be used anywhere. so i guess that way is fine too. but i'm still sticking to icons just in case