Izzy Axel

That's very odd, did you try setting the gradle project up in IntelliJ too, and does it produce the same issue?

Ninja'd lol, that doesn't work, see my edit

I think he means command forwarding, like doing /test <player> would then execute /kick <player>? Found it, it would be server.commandManager.executeCommand(sender, "raw command text here, minus the /");

In your main class, if you don't have it already, receive the 'FMLServerStartingEvent'. Create a class that extends 'CommandBase' and override at least 'getCommandName', 'getCommandUsage', and 'execute'. In the event handler for 'FMLServerStartingEvent', do 'event.registerServerCommand(new YourCustomCommandClass())'. 'getCommandName' should return a string of the base command name, the text you type in to activate it. Optionally, inside the command class, create a List<String> variable for the command's aliases (alternate text the user can type to activate your command), and in the constructor for the command class, initialize the aliases variable and add strings to it. Now override 'getCommandAliases' and return the aliases List. In 'getCommandUsage' return a string of the message you want the player to receive when they type the command in without any arguments iirc? It may also show in the help command. Do whatever you want to happen when the command is run in 'execute'. args[0] is the first argument after your command, args[1] is the second, and so on, for however many arguments you want to have. Args are delimited by spaces, by the way. [edit] getCommandUsage would be something like return "yourcommandname <arg0> <arg1> <etc>";

Just to make sure, you're using a Java 8 JDK?

I feel like I should add, he wasn't saying that changing to registry names would fix everything, he was saying that even if everything else was perfect, it wouldn't work until you switched to registry names. So basically, don't stop looking for answers yourself because that change didn't fix everything.

And for the record, you're spawning the EntityItem on both server and client, you should only spawn it server-side, spawning it on the client results in those ghost items.

That fixed it, thanks...now why isn't shade: false working...

Well, after making some changes based on that, the overlay works on the inventory render, but the world render still looks like that screenshot. https://gist.github.com/izzyaxel/6e64b75527e8fb6811cc7a9d676da4a2 And setting shade to false isn't working on its own, you have to do at least setLightLevel(1).

How would you/is there a way to overlay a binary transparency texture over a base texture on each side in the JSON model system? This is what I tried, but it results in a transparent block with the overlay on all sides in the inventory, and the transparent pixels being white and gray in the world: https://gist.github.com/izzyaxel/d54bc4a23236b1f44d9f230490e415a5 http://private.izzyaxel.com/screenshots/2016-08-21_19.50.09.png And the other issue, how do you make the transparent layer fullbright, without making the block emit light?

Do you mean keybindings? If so it's like key.categories.arcaneartificing=Arcane Artificing key.gatherMana=Gather Mana in the lang file, as defined by what you give to super() in your Class<? extends KeyBinding>, like https://github.com/izzyaxel/ArcaneArtificing/blob/master/src/main/java/izzyaxel/arcaneartificing/main/keybinds/GatherManaKeybind.java#L21

Ok so what you really want here is for the appropriate faces of the screen pane not to render when there's another screen pane adjacent to it? If so, you don't need connected textures or the IIcon stuff at all, since there are no borders on your textures. If so, just revert everything back to how it was before and put the shouldSideBeRendered function back in, that's all that you should need. That function will make any face not render if there's an identical block touching it, basically. The connected texture stuff is (in my mod) used for when a texture has a border around it, and you want to make the border between 2 adjacent blocks of the same type disappear, by changing the texture on both.

Just to be clear, with how you set it up, you would have your textures in src/main/resources/assets/MODID/textures/blocks/Screen#.png where # is corresponding to an index in the IIcons array.

If you're only using 2 textures, you would do: IIcon[] icons = new IIcon[2]; But is that what you want? With what you're doing in the code you posted, you'd only be checking for a screen above, that means if you placed 2 screens, one ontop of the other, only the bottom one would change texture. I don't know if that's what you want, but you'd probably want to check 'down' too so the textures both connect? As for the crash, that's probably caused by the protected constructor in the screen class, if I had to take a guess. I'm honestly not sure why that's there.

Oh yeah that was a little confusing until I did some testing with them both and found that one was for inventory and one was for world lol And, @Mr_Pyro, pretty sure IIcons are the only way to do something like this without a lot of overhead, ie using a TESR. Also a note, if you're going to be changing textures in this manner using an item, (since there's no block updates caused by neighbors) you'll need to call World#markBlockForUpdate on the block affected to make the change show up immediately.

Look at the links to my repo, that's how it works. #getIcon is called once per face of a block, so the manager is used to determine which sides have blocks of the same type adjacent to them (in this case) and return the appropriate IIcon for that situation. I don't know about other situations, but #getIcon is at least called when a neighboring block updates.

Something like this but simplified for only one side https://github.com/izzyaxel/ArcaneArtificing/blob/master/src/main/java/izzyaxel/arcaneartificing/main/handlers/AAConnectedTextureHandler.java https://github.com/izzyaxel/ArcaneArtificing/blob/master/src/main/java/izzyaxel/arcaneartificing/blocks/decorative/BlockFickleGlass.java

Yeah after you mentioned it originally, I realized why it would work lol

Oh ok, I guess I assumed if I stored the values in the Class<extends Gui> it would act like an item/block singleton and those values would be used for every player lol That's rather odd, because if I use RenderGameOverlayEvent.ElementType.HOTBAR, and have an item in the hotbar, 0.1d works just fine, it defaults to transparent and fades to transparent, but the thing with using HOTBAR is, if I have no item, or an item in the hotbar has durability, or a block in it, the HUD starts and fades to invisible. That said, 0.13d works, and that makes the HOTBAR situation confusing.

So, I made gauges for displaying how much mana a player has. It's supposed to normally be very transparent, become opaque when mana is used or received, then fade out to transparent after a few seconds of inactivity. What's happening is, its invisible when inactive and fades to invisible too. I thought it might have been an issue syncing the alpha EEP values to the client, but printing them shows it stopping at 0.1d, so I'm at a loss here. https://gist.github.com/izzyaxel/1bf5db34c24dc879455b53e0ad198e43

Oh lol I was assuming he already had the block rendering. So yeah you could use an ISBRH and draw the block using the Tessellator to make it appear to be any size you want, and use Block#setBounds to make the collision match.

Don't return null on the server element, return a Container.

Thanks!

Ok one more question, with the method of sending the sync packet to only the client who needs it (I assume this would be the preferred method, especially since if there's a problem with it, only one client will crash, instead of everyone you're sending it to), how do you get a valid reference to that player's EntityPlayerMP? That's one thing I've never known/or figured out.

Have you tried Block#setBlockBounds? That should do what you want.