Bektor
-
Posts
852 -
Joined
-
Last visited
Posts posted by Bektor
-
-
On 10/26/2017 at 1:11 AM, Draco18s said:
Use the Forge format where each property is separate from each other:
http://mcforge.readthedocs.io/en/latest/blockstates/forgeBlockstates/#sub-models
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?
-
On 10/24/2017 at 0:50 AM, ModMCdl said:
Curse/Twitch, which is one of the most popular launchers, requires you to go through the original launcher as well. Take a look at how they do it: https://mods.curse.com/client
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...
50 minutes ago, JimiIT92 said:If i open the regular launcher from another launcher, than what's the point?
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
-
2 hours ago, Draco18s said:
A custom class.
The horror!
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. ^^
-
2 hours ago, Draco18s said:
Custom ItemHandler classes.
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.
-
-
11 hours ago, Draco18s said:
if(cap == Inventory) { return inventoryHandler; }
if(cap == energy) { return energyHandler; }
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 hour ago, Draco18s said:
Yes. And?
Well, quite a lot. (thinking of over-complex json files with a lot of lines)
1 hour ago, Draco18s said:You could also use an enum:
NOT_CONNECTED, CONNECTED, CONNECTED_MACHINE
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.
-
43 minutes ago, Draco18s said:
Use bool properties, like the fence and cobblestone wall do. There is no reason to get fancier than that.
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.
44 minutes ago, Draco18s said:they do not need to be encoded in metadata because their properties of the world
Meaning visual stuff doesn't need to be encoded to metadata and everything else does, correct?
-
28 minutes ago, Draco18s said:
Yes it would, and all of those ingots would be identical as far as the game was concerned, except for stacking.
That said:
Ask the oredict for a list of copper ingots.
Pick one
Tell the game to smelt your ore block into that ingot.
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
-
On 10/20/2017 at 9:09 PM, Draco18s said:
If you can't test Hwyla in dev, create yourself a dummy item that when right-clicked on a block, will query the energy capability from side-null (as that is the side Hwyla uses). Then set a break point in your code and figure out what pathway it takes.
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:
QuoteAdded native support for Forge Capabilities.
Information is obtained using a
nullfacing. Mods that do not handle this correctly are unsupported.-
Forge Energy storage and capacity.
- Displays the blocks currently stored energy and maximum capacity.
-
This feature only works on energy handlers that provide
IEnergyStorage.
These features are disabled by default to prevent conflicts with other mods that introduce similar functionality.
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
-
-
-
On 10/16/2017 at 5:19 PM, jabelar said:
So? Just handle null parameter then. By them saying they obtain it using a null facing presumably means they call some methods and or look at block state files with null as a parameter. You can handle null how you want -- pass back information from whatever you consider the main side, or whatever you consider the current side, etc.
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.
-
6 minutes ago, diesieben07 said:
Make a method getExposedSides in your base class, which by default returns EnumSet.allOf(EnumFacing.class). Then you can customize that in subclasses.
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
nullfacing. 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
-
On 10/15/2017 at 2:11 AM, diesieben07 said:
I am not sure then...
Ok, don't ask what I changed as I got totally no clue what exaclty I changed, but it works now.
-
1 minute ago, diesieben07 said:
Did you create a new world?
Yep.
[1.11.2] [UNSOLVED] Block Model JSON
in Modder Support
Posted
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.