Global Key Press

[Squat]

How would I handle if the player presses a key regardless of whether or not he's inside of any input boxes and without altering the player's script file itself?

I can get the menu to pop up for any reason, but I only know how to capture inputs in the player script and an input area. There's a few reasons I don't want to touch the player script on this.

1. This is a beta and I expect it to change so if I weave something in it's gonna have to be weaved in to the new stuff again.

2. Player inputs trigger per tick, which is like 200 times per second or at the framerate or something, I'm not sure the interval, but it's fast.

3. I have to add the delay input code, again furthering complicating the weaving because I only want to delay that particular input and not move or shoot.

4. I change character.gsl files almost daily and they're all radically different.

I can code everything so far fine but I want to keep what I build as a stand-alone entity, not redo it, and so I can basically bundle it separately.

Could I attach an object to follow the player with its own input area?

The good news is that I've gotten a custom inventory menu to pop up and it works ok. I don't have any clue yet about how to overlay another image on top of that, but I think I might have an idea where to look and I know that you definitely want to set your ruler to pixels and use guides to get the position and size of both cropped images and also the text fields.

Cropping is like this leftcrop, topcrop, rightcrop, bottomcrop and then you can position it. So I'm hoping that if you just make a new image and set the cropping of a particular icon and then set its position to match your icon containers and go showForm("Cheese_Icon")...which leaves the million dollar question:

How does menu layering work? What form gets put on top of what and is that controllable? I'm hoping it's a matter of which gets shown first with all new show commands putting the new forms on top of what was put out already. I'm hoping anyway. That or a depth field to manually set layering. I haven't looked deep enough, I believe the answer may lie in the docs.

Thanks for the help.

[pixel_legolas]

You know there was a thread about INCLUDE so you include separate .gsl files to the main. This will make things easier because you can keep different things like movement and camera and stuff in separate files, and just change those. Then, even if the main.gsl file is changed because of new templates or such, the other gsl files will still stay the same

[zknack]

you *should* be able to create an object, and attach it to a bone on the player.

The object *should* be able to have it's own input area, and inventory if you will.

If you've already gotten visual inventory menu working, then I am very jealous ;-P

That is amongst my bigger 'to-do' items still remaining, along with getting all of my
item types counting properly (and showing on the custom hud), and melee combat
+ ledge grabbing.

*shakes his head* you are an incredibly fast programmer Squat. I wish I had one
like you on my team.

[Squat]

It's only a new form and a new.PSD file and all it does is come up on screen and that's all. If I do get something running, you'll have it right after that. This is really all I've done:

FPS.LAY added this:

Form FPS_Inventory
{
   HorizontalAlignment Center
   VerticalAlignment Top
   Size 800 600
   Enabled 0
   
    FocusedSprite
    {
        //Crop 358 232 392 266
        File Inventory.psd
    }
      Label CheeseWheel
   {
      Location 230 530
        Font FPSFont
      Size 60 20
      TextPlain 0
      TextHorizontalAlignment Left
   }
}

Then, because I'm cheating, I just put this into a dummy object to make sure it can be called:

bool HandleEvent( Object@ object, const String& in event, GameEventParams@ params) //handled per tick if within input box
{

   
   if(params.player != null) //player interaction
   {
      if(event == "EnterProximity")//handled one time upon entry to input box
      {
         ShowForm( "FPS_Inventory");
      }
      if(event == "ExitProximity")//handled one time upon entry to input box
      {
         HideForm( "FPS_Inventory");
      }
      return true;
   }
   return false;
}

Put it anywhere between other forms. The only thing I'm proud of is getting a handle on how to place and size the text fields. Now I can put as many as I like, anywhere I like in the form and it's respective to the top-left 0,0 origin of your image. Let me learn how to show another icon aligned over the top of a static form and I'll put up a tutorial.

Don't be jealous zknack I didn't figure much out at all, you're WAY ahead of me on the HUD, I've seen what you've done.

[zknack]

It's a good start - on both our parts, I'd consider my hud more ground breaking if it actually did what I want it to completely ;-)

Your scripts thus far- and Gruberts- are much more 'clean' and streamlined than mine in my own opinion, and thanks to you two,
I'm going to try getting the heart hud more streamlined and self-contained. You've both given me alot of inspiration on how to
possibly approach getting it to be more of a module that's plug & play capable if you will.

Hopefully as a community we can keep this steady, regular flow of information, ideas, and upgrades moving so that others may
be able to more readily create their dreams as well.

[Ransom]

Look at menu.gsl in the GUI folder.  This is how a form can be loaded from a key press independent of any game object's script.

bool HandleKeyPress( const String& in key)
{
   if (key == "KeyEsc")
   {
      if (GetGameManager().GetPaused())
      {
         if (inGame)
         {
            ResumeGame();
            return true;
         }
         return false;
      }

       GetControl( "ResumeGameButton").SetEnabled( true);
      ShowForm( "MainMenu");
      SetRelativeMouseMode( false);
      GetGameManager().SetPaused( true);
      return true;
   }

   return false;
}

Note, thats not the entire script, just the pertinent section.

[Squat]

Very nice, thanks for that. I'm going to look into it today.

Does that code right there hard-set it to the ESC key? Can we still let the user set the controls if we wanted to default it to "I" and they can change it to "TAB" or something?

[Ransom]

Apparently, menu.gsl does not respond to entries made in the input.cfg file...

if (key == "KeyEsc")

...must be the actual name of a key, not a user defined name (like normally set up in the input file, for example...

KeyMapping KeyI InventoryMenu

 

You could change the gsl to...

if (key == "KeyI")

...and then the "I" key would pull up the form.

However...

if (key == "InventoryMenu")

...would not work.

I think it would still be possible to allow your player to redefine this key, but you'd have to do some extra scripting to get it done. 

[zknack]

*chuckles*
I don't think I've seen anyone with a menu for the user to change or define keys yet. It's possible, definitely through
the menu functions that have been documented thus far- but it'd be a heck of a lot of GUI scripting for sure.

though, come to think of it, if we created a secondary input file that is called for by the game- and a button on the
config form to 'revert to default' (which would then clear contents of customInput, and then copy over contents of
defaultInput...).. Hmm.. I thinks I have an idea here...

A gui form using primarily the
bool GetPressed() const @ Control             Event@ AddOnKeyPress( const String&) @ Control
       
functions, and filefinder class functions... as well as file class functions... Hmm - it actually shouldn't be that hard in theory.
Buttons, and forms are fairly easy in the gui editor.

Just like switching inventory items (for me) is starting to use the following-

int GetDragAndDropDestinationIndex() const @ Control
int GetDragAndDropParentIndex() const @ Control

Food for thought, hopefully it helps get your gears spinning too.

[gekido]

you should not use the handlekey method that the menu does for anything important in-game.  it should simply be used for 'override' keys like popping the main menu.

too many people seem to think that you can use that method as a proper way of handling input globally and this is very much not recommended or a good idea.

simply setup a controller with a handleevent function - as long as the object has the 'make player' checkbox enabled, it can accept input and do whatever you want with the results.