First off, sorry for the rather obscure title.

Secondly, does anyone know what would be the best way of achieving the following?

Handling a "hand" of cards rendered in first person view, making the active card switchable with keys 1-0 or with the mouse scroll.

The two major complications are these:

• I want to allow players to quit the card game (and return shortcuts to normal) with escape.
  
• I would also like to allow players to hit their chat key and type in a message to talk while playing.
  

The idea I'm toying with at the moment is using a custom Map renderer to render the cards held in the player's hands but how to selectively override hotbar keys is something I'm not quite sure off. it also feels a horrendously messy approach to GUI-less play.

 

If anyone has any suggestions as to a solution or a better method of play, I'm all ears!

Thanks in Advance.

I think you can use keybinding and intercept key input events by using event handling and checking for the keys you care about and checking if you're currently in the minigame and then doing what you want.

 

Here is tutorial on keybinding, assuming you're using 1.7.2: http://www.minecraftforge.net/wiki/Key_Binding

 

You can find out more about event handling at my tutorial (and others out there, like CoolAlias'): http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html

 

You'll want to handle the FML event called KeyInputEvent.

cheers Jabelar, I'll try that now (and yes, I am using 1.7.2, sorry, updated the title now)

 

((EDIT: ADDENDUM: Also, sorry, but is there any simple way of getting the local client's player when the keyevent is fired or am I stuck with using a player tickhandler to listen for the relevant keys?))

Ok, I've managed to get a somewhat hacky solution going, but I'm struggling to stop the hotbar from switching item slot.

Could anyone shed any light on how best to tackle this please?

(also, suggestions on optimising are more than welcome!)

package EmeraldCasino.events;


import java.awt.Event;

import org.lwjgl.input.Keyboard;

import net.minecraft.entity.player.*;
import cpw.mods.fml.client.registry.ClientRegistry;
import net.minecraft.client.settings.KeyBinding;
import net.minecraft.world.World;
import cpw.mods.fml.common.gameevent.InputEvent;
import cpw.mods.fml.common.gameevent.TickEvent.PlayerTickEvent;
import cpw.mods.fml.common.event.FMLEvent;
import cpw.mods.fml.common.eventhandler.EventPriority;
import cpw.mods.fml.common.eventhandler.SubscribeEvent;
import cpw.mods.fml.common.gameevent.InputEvent.KeyInputEvent;

public class cardHandHandler {

private boolean sneaky=false;
private EntityPlayer localPlayer;

@SubscribeEvent(priority=EventPriority.HIGH, receiveCanceled=true)
public void onEvent(PlayerTickEvent e){
	if(e.player.isSneaking()){
		sneaky=true;
		if(localPlayer==null)
			localPlayer=e.player;
	} else {
		sneaky = false;
	}
}

@SubscribeEvent(priority=EventPriority.HIGHEST, receiveCanceled=true)
public void onEvent(InputEvent.KeyInputEvent e)
{
	if(sneaky){
	int index=-1;
	int invSlot=localPlayer.inventory.currentItem;
	switch(Keyboard.getEventKey()){
	case Keyboard.KEY_1: index = 1; break;
	case Keyboard.KEY_2: index = 2; break;
	}
	if(index>=0){
		System.out.println(""+index+" Pressed");
	}
	localPlayer.inventory.changeCurrentItem(invSlot);
	}
}
}

Is the lack of GUI a necessity...e.g. do you want the player to be able to move-around?

 

The easiest solution that I could think of (if an immobile player was okay) would be to actually use  a GUI -- as that provides a central place to intercept key events...and if you don't have slots in your container, then no slot-selection/item moving will happen.  And you don't -have- to draw anything in the GUI, so it could be transparent...the player just wouldn't be able to move while it were open, and would have a mouse cursor on their screen.

 

 

Getting the local client has always been as easy as calling Mincraft.getMinecraft.thePlayer

Keep in mind, that needs to be called from behind a client-side proxy (like other input handling), or things will crash when deployed on server

cheers for the reply and the easy player method, don't worry, I'll side it appropiately.

Concerning GUIs, simply put, no it's not a necessity and it would help with things like locking the player in place.

My main issue is that GUIs can be unplayably small. I also quite liked the visual aesthetic of first person view and people swinging their arm to play their chosen cards.

I'll revert to a GUI if there's no other way, but I'll try the cardHand item's left/right click functions with a sneaking toggle first.