Izzy Axel

KeyHandler Ok, now what? This seems like way too thin a wrapper, and the things a player could want to do with a key handling packet are so varied, arbitrary, and limited to what can be realistically serialized...there's no way I could create a generic or templated packet that's of any use to anyone. Please, point it out if I'm derping, but I'm not seeing anything else helpful I can do for the user with this system. Put it all together, and this system just seems to be worthless in it's existence in comparison to what the keystate map system does for the API user.

In a way it is, but it is dogma that is based on experience. Now maybe it doesn't matter so much in Minecraft which is only keyboard-controlled. But when I'm programming my own games I usually want to provide options where controls coming into the server can come from end users who are either local, remote, and using either gamepad controller or keyboard. In that case, it is easier to maintain a scheme where the server just receives functional commands ("move left", "strafe right", "jump") and the clients convert whatever the user happens to prefer for input to those commands. Technically though you can certainly do the conversion on the server. I think my main argument to you would be that people who play minecraft may play across multiple servers but prefer to have same keybindings on each. In other words, it is logically a setting that carries along with the client. So makes more sense to handle it in the client, store it as a preference on the client machine, and so forth. If the master information on keybindings was stored on the server, then user would have to go through extra work to configure on each server, and that might be a (minor) pain. The server doesn't change keybindings at all, it only keeps a record of the clients current keybinding and polls it lazily, if the user changes his keybindings outside a server, the next time he logs onto the server, the server's record will be updated, not the other way around. And this isn't persistent data, the server doesn't save any of this info to a file, there's no reason to, its all generated dynamically. I do get that reasoning, and I wouldn't do this if it made switching control types harder/break, but my system works entirely off of Minecraft's GameSettings#keyBindings, I never do anything with raw LWJGL keyboard input. That's why I need the Keybinding map on the server, so a user of the API can ask for "JUMP" and "FORWARD" and "SLOT_6" and "ATTACK" enums, and it'll give them the correct key's state no matter what the player sets it to. This keeps things generic and modular, if that's the right word; there's no hardcoding.

I guess I'm still confused as to your purpose. Why would "end user of the API" want to check this? The whole point of keybinding is to allow users to map keys without anyone else needing to know about it. And if you mean you want to allow another mod to know about it, well they can have their client-side code check out the keybinds directly. Yes, they can do that client side. The core idea of Sapphire is to reduce the work other mods have to do to a minimum while retaining flexibility. The keybindings map is to counteract moving user-level (API user that is) keyhandling to the server. On the client side, its really easy to check the current keycode for x action, so if I'm moving those interactions to the server to get rid of all the code normally written to send packets to the server and act on them in a standard keyhandling system, I want to retain how easy it is to check if the key is down, and for that I need the given user's current keybinding layout. (and lets be honest here, this system also takes out the possibility of the user doing some really messy, overwrought, bad things, and sending way too many packets) Its just...I have yet to get an answer that holds water as to why storing and updating keystates on the server like this is a legitimate problem, so it just sounds like dogma to me.

I think that's much too frequent, I had the updates at 30 second intervals (I don't think people don't change their keybinds that much lol) and I have a config option for it, bounded at min 10 seconds.

The server still doesn't *care* about it, it's for the end user of the API to check against, my original design was to keep an array of structs on the server of each player's keystates and current keybinding info, to make it very easy to query keypresses, only requiring a player's entity ID and the current desired keybinding's keycode, which is why I wanted to store keybinding info server-side. The idea was for keystate info to be available to the dev using the API, server-side, with no "boilerplate" code involved, but I'm currently evaluating moving it to a callback event system instead, where the user registers an implementing class instance for a key or set of keys. (Frankly I'm not sure why I'm doing that, other than I don't want to deal with dogmatic preaching about how bad and wrong, it is, I guess. The original system works beautifully on both SSP and SMP, btw, and is sterile.) Without the keybind change event, I had to resort to sending update packets on entity construction and at intervals, so I wanted to make sure I couldn't make it more efficient. That's what this question was about/why it was asked and the background on what it's used for. If I go through with the callback route, I won't need to do this anymore. Here's a bit of an excerpt from an example jetpack I made, to show you what it does in practice: Example

Its there for the user of the API to check against, and nothing more.

I'm keeping a record of each player's keybinds server-side for my API's keyhandler

That works for the keyboard, but not for binding things to the mouse... [edit] Actually it doesn't work quite right anyway: @SubscribeEvent public void changeKeybind(GuiScreenEvent.KeyboardInputEvent.Post event) { if(event.getGui() instanceof GuiControls) { Sapphire.LOGGER.info("Sapphire: ", "Keybind changed"); } } It prints twice, and it'll activate when a key is pressed on the screen in general, not just when a keybind is changed. This will fire a series of packets, so I want to minimize how often this is triggered to only when necessary. It would be ideal to have it only happen when a keybind is changed to a key different to the one it is atm, and for the event to provide the keybind name and new key, so only that info would have to be sent in a single packet.

If the KeyEvent gets called when the player is in the Gui you could just check if the current gui is an instance of the KeyBind Changing gui. The problem with that is GuiKeyBindingList doesnt inherit from GuiScreen, so both checking Minecraft#currentScreen and using the KeyboardInputEvent and checking GuiScreenEvent#getGui() don't work.

I'm pretty sure there isn't, but is there a Forge event or a light way to detect the player making keybinding changes?

Ok? We can't help with no code...

I think you need to read more carefully, I didn't say ByteBufUtils, I said ByteBuf. And likely because the functions you were using don't do what you thought they did, or were being used incorrectly.

Won't be the solution, but doing 'damageItem' with a value of -1 won't do anything, that function calls 'attemptDamageItem' which explicitly checks if the int passed in is above 0. [edit] ...Ok wow I really overlooked something, you're not writing the altered NBT to the stack's NBT. That...might be a problem

You should probably post the whole item's code, not just the one function, and use a service like pastebin or github's gist, with the syntax highlighting set to Java, (name the file xyz.java for gist) it makes code a lot easier to read.

I did that everytime and for me it works (haven't tested it without yet, so you could be right... I think, that you are right, I know your coding tutorials ) I think, that he means choosing the workspace. Then it would be right, what he does. If the project doesn't appear, then he should import it like you said. 'setupDecompWorkspace' runs 'setupDevWorkspace' and then links the decompiled/deobf minecraft source to your project, so yeah, you should only run 'setupDecompWorkspace'.

He's asking because of 'if(itemStack.getItemDamage() > 0)', that's the only place you set the nbt, so that's where you should be looking, to see if it's actually getting run.

Why are you using those ByteBuf functions? Have you tried this.scroll = buf.readInt() in fromBytes and buf.writeInt(this.scroll) in toBytes? That's all you need, ie: Packet example [edit] Forgot to mention, if you have multiple variables you need to read them and write them in the exact same order.

That would be why then, that line is executed by setupDecompWorkspace, so save yourself from running it twice, and edit the build.gradle before running it.

I always do it like this: Extract MDK into a directory Edit build.gradle to suit the project, add 'idea{module{inheritOutputDirs = true}}' to the end of it Open CMD window in that directory Run 'gradlew setupDecompWorkspace --refresh-dependencies', wait for it to finish Import the build.gradle file in IntelliJ with "Use auto-import" checked, wait for it to finish Run the 'genIntellijRuns' task in IntelliJ's Gradle sidebar and reopen the project when prompted If the forge source isn't in the external libraries after all that, I close IntelliJ and open a CMD window in the project directory and do 'gradlew idea --refresh-dependencies'. It sounds like adding that line to the build.gradle file may help?

IntelliJ also will show a box of matching overrideable super methods if you start typing a method name inside a class, and set the whole thing up when you select it and hit enter. That's my personal favorite

Yeah, though iirc Subnautica does just use a screen fade, and it doesn't look great there either lol

Ah ok, so it's @Optional.Method(modid = "") then? That's...very useful lol

Wait, what? In my 1.10.2 workspace I don't have the cpw package at all, the only Optional I have is net.minecraftforge.fml.common.Optional

Receive the RenderGameOverlayEvent.Pre, and use Minecraft.getMinecraft().thePlayer#getAir() to check the player's air value. If it's below a certain amount, draw a quad over the screen using the resolution stored in the event, turn GL blending on, and use glColor4f(0f, 0f, 0f, x), where x is an equation that increments upwards over time, preferably using partial ticks, to fade the black box in. At least, that's how I'd try it first.

As far as I know, it needs to have a TileEntity and custom ItemBlock, and transfer NBT between the 2 when picked up/placed down, but this is knowledge from 1.7, you may be able to do it differently, without a TE in 1.10. [edit] https://gist.github.com/izzyaxel/d481621602569273a76d275b711afa62