-
Posts
852 -
Joined
-
Last visited
Everything posted by Bektor
-
Does anyone got a clue how I can get it done like in the 3D model from Blender with the straight lines? If not I guess I'm going with dynamic rendering stuff like a friend of mine (who got no clue about Minecraft Modding, but OpenGL 4.5) suggest to me for solving this problem.
-
[1.11.2] [UNSOLVED] Block connections & Blockstates
Bektor replied to Bektor's topic in Modder Support
Hm... This still results into nearly 200 lines of json file... I've also got another problem: I've created now an array containing all of the first 6 properties and another one for the next 6 properties. How do I combine them now in createBlockState? -
Well, I've always figured this way a bit annoying, not because of the extra window which pops up, but because the launcher always re-downloads itself. As long as I'm only using the normal Launcher or launch it using Curse which then starts the normal launcher, everything works fine, but switching between those two ways always results into a re-download of the launcher... The point is to not violate the EULA while also staying compatible if Mojang should ever feel the need to change something on their launcher or login side.
-
Hi, I'm wondering how I can achieve the following with JSON files (just did some fast renderer with Blender Cycles): I've already got the basic model shape done. It should be noted that the model part of this is the base model and the rest of the model are just connections. These connections can apply to any possible side and when there is no connection the middle part should look like the end parts on all sides. The properties my block has: public static final PropertyBool NORTH = PropertyBool.create("north"); public static final PropertyBool EAST = PropertyBool.create("east"); public static final PropertyBool SOUTH = PropertyBool.create("south"); public static final PropertyBool WEST = PropertyBool.create("west"); public static final PropertyBool UP = PropertyBool.create("up"); public static final PropertyBool DOWN = PropertyBool.create("down"); My current JSON model files: cable_side.json { "textures": { "particle": "#side" }, "elements": [ { "from": [ 4, 4, 0 ], "to": [ 12, 12, 4 ], "faces": { "down": { "texture": "#side" }, "up": { "texture": "#side" }, "north": { "texture": "#side" }, "south": { "texture": "#side" }, "west": { "texture": "#side" }, "east": { "texture": "#side" } }, "__comment": "North cable side" } ] } cable_base.json { "textures": { "particle": "#centre" }, "elements": [ { "from": [ 4, 4, 4 ], "to": [ 12, 12, 12 ], "faces": { "down": { "texture": "#centre" }, "up": { "texture": "#centre" }, "north": { "texture": "#centre" }, "south": { "texture": "#centre" }, "west": { "texture": "#centre" }, "east": { "texture": "#centre" } }, "__comment": "Center cable cube" } ] } Meaning I've got the basic model already done, but I'm struggling mostly with figuring out the texture stuff and which texture to put where and when. So just the main model file remains as long as I don't have to edit those model files somewhere. Note: I've got a texture which contains the red lines and the green inner part and I've got a seperate texture for the start and end part of the model. Thx in advance. Bektor
-
Well, with creating a new class I meant creating a new class which extends ItemStackHandler as I don't see a reason to implement the whole interface for one different method, so don't worry. ^^
-
Ok, thx, guess I have to create a new class then, thought at first I'm either fixing the json problems or going with obj stuff.
-
Hi, I've got a tile entity with an inventory (using capabilities) and I'm wondering how I can limit my inventory to specific items only, for example a vanilla furnace takes only items in which can burn. Thx in advance. Bektor
-
EDIT: Ok, I reverted those changes... No clue what was wrong... now I've only got the problem from above remaining. Ok, while trying to fix the problem I got more stuff screwed up.... cable.json { "forge_marker": 1, "defaults": { "textures": { "centre": "justanotherenergy:blocks/cable_top", "side": "justanotherenergy:blocks/cable" }, "model": "justanotherenergy:cable_base", "uvlock": true }, "variants": { "down": { "true": { "submodel": { "cable_down": { "model": "justanotherenergy:cable_side", "x": 90, "uvlock": true } } }, "false": { } }, "up": { "true": { "submodel": { "cable_up": { "model": "justanotherenergy:cable_side", "x": -90, "uvlock": true } } }, "false": { } }, "north": { "true": { "submodel": { "cable_north": { "model": "justanotherenergy:cable_side", "uvlock": true } } }, "false": { } }, "east": { "true": { "submodel": { "cable_east": { "model": "justanotherenergy:cable_side", "y": 90, "uvlock": true } } }, "false": { } }, "south": { "true": { "submodel": { "cable_south": { "model": "justanotherenergy:cable_side", "y": 180, "uvlock": true } } }, "false": { } }, "west": { "true": { "submodel": { "cable_west": { "model": "justanotherenergy:cable_side", "y": -90, "uvlock": true } } }, "false": { } }, "inventory": [{ "model": "justanotherenergy:cable_base", "submodel": { "cable_up": { "model": "justanotherenergy:cable_side", "x": -90, "uvlock": true }, "cable_down": { "model": "justanotherenergy:cable_side", "x": 90, "uvlock": true } }, "transform": "forge:default-block" }] } } cable_side.json { "textures": { "particle": "#side" }, "elements": [ { "from": [ 4, 4, 0 ], "to": [ 12, 12, 4 ], "faces": { "down": { "texture": "#side" }, "up": { "texture": "#side" }, "north": { "texture": "#side" }, "south": { "texture": "#side" }, "west": { "texture": "#side" }, "east": { "texture": "#side" } }, "__comment": "North cable side" } ] } cable_base.json { "textures": { "particle": "#centre" }, "elements": [ { "from": [ 4, 4, 4 ], "to": [ 12, 12, 12 ], "faces": { "down": { "texture": "#centre" }, "up": { "texture": "#centre" }, "north": { "texture": "#centre" }, "south": { "texture": "#centre" }, "west": { "texture": "#centre" }, "east": { "texture": "#centre" } }, "__comment": "Center cable cube" } ] } EDIT: Ok, I reverted those changes... No clue what was wrong... now I've only got the problem from above remaining.
-
Bump.
-
So Forge or a mod is calling the methods multiply times, for each capability seperatly?
-
Hi, I'm wondering if it is possible for one tile entity to have multiply capabilities at one side and which would be the best way to handle tile entities with multiply capabilities (for example one for energy and one for inventory)? So how should the following methods look like in the descriped case? getCapability hasCapability Also, if a tile entitiy can't have multiply capabilities at the same side, how should I handle the null side (in case some mod like Hwyla wants to display stuff)? (As there is only one return statement and thus I can't return two capabilities, can I?) Thx in advance. Bektor
-
[1.11.2] [UNSOLVED] Block connections & Blockstates
Bektor replied to Bektor's topic in Modder Support
Well, quite a lot. (thinking of over-complex json files with a lot of lines) I guess this would be difficult because it doesn't tell the json file at which side the special model should be used. I'm also wondering how I could got about limiting the connections so that only one special model can be used to avoid multiply sides having this special model as it should indicate a connection towards a machine and the block can only connect to one machine at a time, but to a dozen cables at the same time. Also, how would I go with the JSON file? I mean, thinking of the boolean properties I would be required to create 6 entries for the 6 properties in the json file and inside of all of those entries I would again need to define 6 entries + one for when none of these other six is used, creating 42 entries... and that's totally not what I want. While also having the problem with multiply special models beeing used at the same time? -
Hi, I've got yet another problem with my json files. I guess it get's obvious what the problem is by just looking at the picture below (the alignment of the darker lines). My json file (blockstate json): { "forge_marker": 1, "defaults": { "textures": { "centre": "justanotherenergy:blocks/cable", "side": "justanotherenergy:blocks/cable" }, "model": "justanotherenergy:cable_base", "uvlock": true }, "variants": { "down": { "true": { "submodel": { "cable_down": { "model": "justanotherenergy:cable_side", "x": 90, "uvlock": true } } }, "false": { } }, "up": { "true": { "submodel": { "cable_up": { "model": "justanotherenergy:cable_side", "x": -90, "uvlock": true } } }, "false": { } }, "north": { "true": { "submodel": { "cable_north": { "model": "justanotherenergy:cable_side", "uvlock": true } } }, "false": { } }, "east": { "true": { "submodel": { "cable_east": { "model": "justanotherenergy:cable_side", "y": 90, "uvlock": true } } }, "false": { } }, "south": { "true": { "submodel": { "cable_south": { "model": "justanotherenergy:cable_side", "y": 180, "uvlock": true } } }, "false": { } }, "west": { "true": { "submodel": { "cable_west": { "model": "justanotherenergy:cable_side", "y": -90, "uvlock": true } } }, "false": { } }, "inventory": [{ "model": "justanotherenergy:cable_base", "submodel": { "cable_up": { "model": "justanotherenergy:cable_side", "x": -90, "uvlock": true }, "cable_down": { "model": "justanotherenergy:cable_side", "x": 90, "uvlock": true } }, "transform": "forge:default-block" }] } } What am I doing wrong here? (still not really a fan of those json... when do they ever work on first try ) Thx in advance. Bektor EDIT: I've also uploaded the texture file itself. EDIT 2: more problems arrived EDIT 3: I guess I will let it stay that way and repurpose the block. Somehow with another texture it looks nice that way.
-
[1.11.2] [UNSOLVED] Block connections & Blockstates
Bektor replied to Bektor's topic in Modder Support
Wouldn't this mean I've got 12 properties? 6 for all the possible sides and another 6 for all possible sides of the "side x". Also I don't see where this meets with the conditions of side x. Meaning visual stuff doesn't need to be encoded to metadata and everything else does, correct? -
Ok, thought is there no method like for a normal crafting recipe? GameRegistry.addRecipe(new ShapedOreRecipe
-
Hi, I'm wondering how I can achieve something like in the picture below, but with a few differences: Side X looks differently than the other sides when a machine is connected to side X. I thought about something like this, just that I'm calculating that stuff automatically for all sides: /** Whether this fence connects in the northern direction */ public static final PropertyBool NORTH = PropertyBool.create("north"); /** Whether this fence connects in the eastern direction */ public static final PropertyBool EAST = PropertyBool.create("east"); /** Whether this fence connects in the southern direction */ public static final PropertyBool SOUTH = PropertyBool.create("south"); /** Whether this fence connects in the western direction */ public static final PropertyBool WEST = PropertyBool.create("west"); Then I thought about adding some other property (maybe <EnumFacing> stuff??) to know the specific side (can only be one at the same time). Base idea: In the middle is a default cube and more models are added to either side depending on the connections. So something similiar to another problem I had some time ago (can't find the link currently), but with one side beeing different as stateted. My problem know is (assuming the thoughts from above are correct and the best possible way): How to handle getStateFromMeta, getActualState and getMetaFromState? How to handle the JSON file that model X will be used on side X instead of the normal model which is used for all other sides? [side x = any side && number of side x connections <= 1] How would I handle the above when it would be: number of side x connections < all possible sides Thx in advance. Bektor
-
Hi, I'm wondering how to add smelting to Minecraft 1.11.2. I know there is this method, but it isn't really ore-dic friendly. I mean, smelting in copper from 10 mods would result into 10 different copper ingots this way. GameRegistry.addSmelting(ModBlocks.ore_copper, new ItemStack(ModItems.ingotCopper), .4f); Thx in advance. Bektor
-
[1.11.2] [SOLVED] Hwyla does not display energy data
Bektor replied to Bektor's topic in Modder Support
Hm... seems like that null will return true for hasCapability and return the capability for getCapability, but in Hwyla itself the folliwing line if (accessor.getNBTData().hasKey("forgeEnergy") && accessor.getTileEntity().hasCapability(CapabilityEnergy.ENERGY, accessor.getSide())) { fails. hasKey("forgeEnergy") should return true as accessor.remoteNbt contains the keyword forgeEnergy with my values. Thought the capability of the tile entitiy seems to be null there for some reason I don't know while my energy manager isn't null. EDIT: Seems like it is an incorrect if-statement in the Hwyla version for Minecraft 1.11.2. -
Hi, I've got the problem that whenever I've got a block which should output energy to a specific side Hwyla won't display any information about the energy stored in the block. When the block doesn't require a specific side to output the energy it works perfectly fine. Parent class: @Override public <T> T getCapability(Capability<T> capability, @Nullable EnumFacing facing) { T cap = this.container.getCapability(capability, facing); /*if(cap == null) return super.getCapability(capability, facing); else { if(facing == null) return cap; else if(this.getExposedSides().contains(facing)) return cap; } return super.getCapability(capability, facing);*/ /*if(cap != null && facing == null) return cap; boolean flag = facing == null ? (this.getExposedSides().size() > 0 ? true : false) : this.getExposedSides().contains(facing);*/ if(cap != null && facing == null) return cap; return cap != null && this.getExposedSides().contains(facing) ? cap : super.getCapability(capability, facing); } @Override public boolean hasCapability(Capability<?> capability, @Nullable EnumFacing facing) { if(capability != null && this.container.hasCapability(capability, facing) && facing == null) return true; /*if(this.container.hasCapability(capability, facing) && facing == null) return true; else if(this.container.hasCapability(capability, facing)) return true; else return false;*/ /*if(this.container.hasCapability(capability, facing) && facing == null) return true; boolean flag = facing == null ? (this.getExposedSides().size() > 0 ? true : false) : this.getExposedSides().contains(facing);*/ return (this.container.hasCapability(capability, facing) && this.getExposedSides().contains(facing)) || super.hasCapability(capability, facing); } Subclass (the block which doesn't work cause it requires a specific side): @Override protected EnumSet<EnumFacing> getExposedSides() { return EnumSet.of(EnumFacing.DOWN); } Note: all code which is commented out was already tested before and didn't work... Quote from Hwyla doc: Note 2: I've enabled this feature as my mod currently does not introduce a similar functionality and like described above, it works perfeclty fine with the default implementation of my method getExposedSides. Thx in advance. Bektor
-
[1.11.2] [UNSOLVED] TileEntity getCapability for specific sides
Bektor replied to Bektor's topic in Modder Support
Bump. -
[1.11.2] [UNSOLVED] TileEntity getCapability for specific sides
Bektor replied to Bektor's topic in Modder Support
I've got this implementation right now, thought when I return just EnumSet.of(EnumFacing.DOWN) instead of the default list, it won't work, meaning that for example HWYLA won't display my stored energy for those blocks. protected EnumSet<EnumFacing> getExposedSides() { EnumSet<EnumFacing> facing = EnumSet.allOf(EnumFacing.class); return facing; } @Override public <T> T getCapability(Capability<T> capability, @Nullable EnumFacing facing) { T cap = this.container.getCapability(capability, facing); boolean flag = facing == null ? (this.getExposedSides().size() > 0 ? true : false) : this.getExposedSides().contains(facing); return cap != null && flag ? cap : super.getCapability(capability, facing); } @Override public boolean hasCapability(Capability<?> capability, @Nullable EnumFacing facing) { boolean flag = facing == null ? (this.getExposedSides().size() > 0 ? true : false) : this.getExposedSides().contains(facing); return (flag && this.container.hasCapability(capability, facing)) || super.hasCapability(capability, facing); } To check if the side (facing) is null and the capability isn't null in order to return the capability then won't solve the problem while hasCapability checks if the tileentity has the capability and if facing == null to then return true. -
[1.11.2] [UNSOLVED] TileEntity getCapability for specific sides
Bektor replied to Bektor's topic in Modder Support
If I recall correclty, you wrote once that EnumSet doesn't include the null side. Wouldn't this lead to problems with for example HWYLA and other mods? (the HWYLA doc states: Information is obtained using a null facing. Mods that do not handle this correctly are unsupported.) -
Hi, I've got the problem that I've got a base class for all energy related tile entities which defines the basic capability handling of all my tile entities which implement energy. abstract Class A extends TileEntity: @Override public <T> T getCapability(Capability<T> capability, @Nullable EnumFacing facing) { T cap = this.container.getCapability(capability, facing); return cap != null ? cap : super.getCapability(capability, facing); } The problem is, one of my tile entities requires the capability to be returned at a specific side and not for every side. Class B extends abstract class A parent class A defines to output capability at all sides subclass B should only output capability at a specific side Which would be the most efficient way of doing this? Thx in advance. Bektor
-
[1.11.2] [SOLVED] TileEntity null while it shouldn't
Bektor replied to Bektor's topic in Modder Support
Ok, don't ask what I changed as I got totally no clue what exaclty I changed, but it works now. -
[1.11.2] [SOLVED] TileEntity null while it shouldn't
Bektor replied to Bektor's topic in Modder Support
Yep.