ZeroNoRyouki

It looked like it, a bit at least Nop, wasn't me. I like forums so much that I was not aware that you could smite someone gh PS: @Draco18s, to solve your THREE-CLASSES problem you could have a barebone mod class and delegate all the work to the proxy as you are kind of obbligate to use it anyway

we were talking about proxies there But yes, you can divide your game logic betwen the mod class, the proxy and other class as you like. My concern with the OP code is that, right now, he will have the same code in both proxies

First off all, I don't care what the 1st tutorial you find on Google say and I was not talking about his use of interfaces to abstract the proxies It's his implementation the problem With the way he is doing it, he will end with "common" code both in his ServerProxy and ClientProxy classes, be it a straight copy of the full code (like he has now) or calls to other classes, as he have to execute it on both enviroments And that's "bad"

You have duplicated code in your proxies: that's not how the proxy system work All game-logic and non-side-specific code should go in a "base" proxy class. You then extend this class to create a "server" proxy class (this will not happen very often) and a "client" proxy class for side-specific code In the most common scenario you will end with a CommonProxy class to use as the server proxy and a ClientProxy (created extending CommonProxy) as the client proxy (you can name the classes as you like it, those are just the most used names)

I'm working on a port of Big Reactors to 1.9.x and I've rewritten the classes of the blocks in the multiblock structure (reactor and turbine) and split then in multiple classes to handle specific jobs. So I have a generic base class that handle a generic multiblock-block and that add an ASSEMBLED (boolean) and FACING (EnumFacing) states to the block blockstate. Build upon that class I have other classes for the specific device (controller, power taps and so on) that add their specific states So for example, the reactor controller block can be idle, off or on, part of and assembled machine or not, oriented in one of the 6 directions. But not all state combinations are actially used in game (for example, a controller can never be in the "on|unassembled|north" state) so I have a bunch of combos that MC generate but that will never see use, ence my question about the possibility/need to remove them if they are a performance problem I known that I can group properties toghether but that move the stage management toward the end of the inheritance tree and I don't like that idea too much Right now I have no medata to worry about since none of that state is persisted because it depends on the state of the multiblock structure itself

Noted! Thank you guys Z

Thank you Ernio and diesieben07! I'm already using the Forge blockstate so it's not a question of having to much to type while writing the json file I'm just wondering if the unused combinations that get generated but not used in game have some negative effect on the game performance I'm building the block blockstate between all the base classes of the block so there are some unused combos

Hi! is there a way to remove invalid / unused entries from blockstate? Let's say I have a block with 2 properties: ASSEMBLED (true, false) and FACING (up, down, north, south, east, west) and that my game logic will only use FACING=north when ASSEMBLED is false Can I make MC ignore/forget the unused combinations? Or there are no drawback with leaving there around unused? Thank you! Z PS: my blockstate file include all the possibile combinations, so I have no errors

You are welcome

Hi, glad it worked for you too You need to export the material library (.MTL) along with the OBJ file and place it in the same directory of the OBJ file Then, open the MTL file in a text editor and change the path of your texture files using the same format as in all the other resource locations you use in your mod (basically, yourmodid:path_to_texture) Hope that helps Z

Yup, with plain vanilla blockstate All the blocks use the same blockstate: { "variants": { "state=single": { "model": "sand" }, "state=invisible": { "model": "thedarkkin:transparentBlock" }, "state=renderer": { "model": "thedarkkin:mblock1/multib1.obj" } } } "single" is for blocks that are not part of a formed multiblock (I used the vanilla sand block model because this was a proof of concept rather then an actual machine) "invisible" is for blocks that are part of a formed mutiblock but are not the mutiblock render delegate. they are actualy invisible in game "renderer" is for the block selected to be the render delegate of the formed multiblock Basically when the multiblock form itself, I select one block and delegate to it the job of rendering the 3D model (using the "render" blockstate and it's OBJ model). All the other block will render as an invisible cube. You must create the 3D model keeping in mind where the render delegate of your choice is in the whole structure. Mine was in the center of the bottom layer The block class override getActualState() and return one of the three possibile states according to the state of the multiblock (how to actualy do that depends on how you implement your multiblock logic)

The log is quite clear FML is tryng to load your com.drmdgg.beesmod.proxy.ClientProxy class (as you specified in your SidedProxy annotation) but it cannot find it Check the class full name and the annotation Z

The first two advices that came to me are based on the code of the many mods I've checked: - stay away from "copy&paste" code - don't be afraid to use the stack Z

Probably because the block's functionality should persist after the player quits the game. and what's preventing it?

uhm sorry to intrude, but I really don't understand why you fell the need to save that data on disk and load it all back after a restart If the TE chunk isn't loaded you can't do anything with the TE even if you known it should be there.. or are you also implementing some sort of chunk loading on demand? Also, what do you do about "abandoned" blocks: say that a player on a server build it's sorting system with dozens of your blocks and then for some reason never use it again (he build a new base somewhere else, never log back in, etc). Are you going to keep track of his TEs forever? Just keep track of the TEs that are actually loaded in the game: they are the only ones that players can actually use

Just do this in your client proxy pre-init event handler: RenderingRegistry.registerEntityRenderingHandler(YourEntityClass.class, new IRenderFactory<YourEntityClass>() { @Override public Render<? super YourEntityClass> createRenderFor(RenderManager manager) { return new YourRenderClass(manager); } }); DO NOT get a reference to the render manager yourself, left MC do that for you

And what does the error log say?

Just use MultiMC or similar launcher to create a clean 1.8 instance, add the last raccomanded version of forge, put Tabula and iChunLib 5.x in the mod folder and enjoy

I think that they are just kind of lazy.. the zombie villager texture is the normal zombie one with a new head and cloth added below so they could have used only one texture I may be able to pull this off my overriding RenderLivingEntity::renderModel and make it bind a texture / render the model part for each of the parts of the model (so bind+render the head with one texture, bind+render the body with another texture and so on) I'm not sure how this will go performance wise

Hi! I'm playing around with entities and models and I'm wondering if it is possibile to use multiple textures (from multiple files) to render each parts of the models Let's say I have a ModelZombie (composed by the head, body, two legs and two arms) and I want to apply texture A1.png to the head, B5.png to the body, C3.png on one leg and so on. The actual texture files are chosen randomly (between A1, A2, A3 etc) when the entity is created I known I can return a different texture in the Render class based on the entity data but that is a single texture file for the whole model

You are creating 32 block states, half of wich are invalid for your game logic (powered=true,signal=0 / powered=false,signal!=0) Desync Becasuse what is hitting the wire is the raw chunk data (a block id / metadata hash for each block in the chunk) not the single block IBlockState

I can help you with the IUpdatePlayerListBox problem: it's called ITickable now (package net.minecraft.util) Z

@SideOnly=Server will not keep the annotated code out of the compiled jar, so it will not work for the public version of the mod and it's not needed for the private version @Major Squirrel: I don't know how much code you will actually have in common between the "public" and "private" version of the mod but, again, I'll suggest to go with 2 distinct and separate mods (and 2 separate projects) to keep things clean and separate and to define an API to let the 2 mods interact with each other (if you end up with more than a couple of interfaces see the @API annotation) Z

If he goes with the 2-mods structure I suggested he can keep all the private logic in the server-only mod and just release the public mod without need (and headaches) of having multiple versions of it Z

If I ever need to do something like this, I will go with 2 mods: modA: a server-side only mod to deal with the database engine and all the bits and pieces you want to keep off the client modB: the actual mod you want to make The logical server-side of modB will delegate all database-related jobs to modA, if modA is actually present Z