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