Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: Double question: allowing interaction with item and overriding key presses  (Read 1086 times)

bloop_bleep

  • Bay Watcher
    • View Profile

How do I allow an adventurer to interact with a custom item in his inventory in a specific way using the 'I' key?
Also, how do I temporarily override the function of a specific key and replace it with my own callback, and then be able to change it back?

I'm talking about Lua scripts now, not C++ plugins.
Logged
Quote from: KittyTac
The closest thing Bay12 has to a flamewar is an argument over philosophy that slowly transitioned to an argument about quantum mechanics.
Quote from: thefriendlyhacker
The trick is to only make predictions semi-seriously.  That way, I don't have a 98% failure rate. I have a 98% sarcasm rate.

lethosor

  • Bay Watcher
    • View Profile

How do I allow an adventurer to interact with a custom item in his inventory in a specific way using the 'I' key?
Also, how do I temporarily override the function of a specific key and replace it with my own callback, and then be able to change it back?

I'm talking about Lua scripts now, not C++ plugins.
Overriding keys isn't typically something you can do with Lua.
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

Atkana

  • Bay Watcher
  • [CURIOUSBEAST]
    • View Profile

I've considered that there might be a hacky way to do the key overrides by using an invisible GUI, but I've never gotten around to seeing if it actually works. If you're familiar with the DFhack GUI stuff the pseudocode would go something like:
Detect when the menu where you want to override the key is opened
Open the invisible GUI.
The invisible GUI (screen?) uses the onInput function to detect when there's an input. If the input is for the key you want to override, do whatever it is you want to do. If the key isn't, then send it via simulateInput to the original screen.

There also might be something useful in the confirm plugin, which somehow intercepts keypresses. Maybe now's the time to mention I'm not familiar with most of the things I'm suggesting :P

lethosor

  • Bay Watcher
    • View Profile

I've considered that there might be a hacky way to do the key overrides by using an invisible GUI, but I've never gotten around to seeing if it actually works. If you're familiar with the DFhack GUI stuff the pseudocode would go something like:
Detect when the menu where you want to override the key is opened
There's an easy way to do this if a new screen is opened, since that triggers an onStateChange event. There's not an easy way to do it otherwise.

Quote
The invisible GUI (screen?) uses the onInput function to detect when there's an input. If the input is for the key you want to override, do whatever it is you want to do. If the key isn't, then send it via simulateInput to the original screen.

If you're using a screen, that means you have access to the parent screen, so you should probably use self:sendInputToParent() (or maybe parent:onInput() or something similar?) instead of simulateInput().

Quote
There also might be something useful in the confirm plugin, which somehow intercepts keypresses. Maybe now's the time to mention I'm not familiar with most of the things I'm suggesting :P
Most of the input-handling stuff is in the plugin (C++). The only part that's in Lua defines the confirmations, to allow them to be updated without recompiling the plugin, because we had issues with some confirmations being too aggressive.
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

bloop_bleep

  • Bay Watcher
    • View Profile

But can I use that on an already existing screen? Maybe if I somehow edited the class method at runtime... is that possible? Could be, given that almost everything is a first-class object in Lua.
On a relevant note, how do I access the main adventure mode screen?
Logged
Quote from: KittyTac
The closest thing Bay12 has to a flamewar is an argument over philosophy that slowly transitioned to an argument about quantum mechanics.
Quote from: thefriendlyhacker
The trick is to only make predictions semi-seriously.  That way, I don't have a 98% failure rate. I have a 98% sarcasm rate.

lethosor

  • Bay Watcher
    • View Profile

But can I use that on an already existing screen? Maybe if I somehow edited the class method at runtime... is that possible? Could be, given that almost everything is a first-class object in Lua.
On a relevant note, how do I access the main adventure mode screen?
It looks like Putnam's script creates a new screen over an existing screen, then sends input to the parent (native DF) screen (that's what sendInputToParent() does).

If by "class method" you mean the C++ method DF uses to handle input to whatever screen you're talking about, then no, you cannot edit that from Lua. It's compiled, and doesn't have anything to do with Lua. (You can intercept calls to it, but only from C++, and that's not exactly editing the method either.)

You can access the adventure mode screen the same way you can access any other screen - dfhack.gui.getCurViewscreen(), if it's the current viewscreen. If it's not, you could try dfhack.gui.getViewscreenByType() (see the Lua API docs for more information).
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

bloop_bleep

  • Bay Watcher
    • View Profile

What do you mean by "over"? Does he create a child screen, or what? Sorry, I'm quite new to using DFHack's GUI module.
Logged
Quote from: KittyTac
The closest thing Bay12 has to a flamewar is an argument over philosophy that slowly transitioned to an argument about quantum mechanics.
Quote from: thefriendlyhacker
The trick is to only make predictions semi-seriously.  That way, I don't have a 98% failure rate. I have a 98% sarcasm rate.

Putnam

  • Bay Watcher
  • DAT WIZARD
    • View Profile

I use the SC_VIEWSCREEN_CHANGED state change to show a viewscreen (which ends up as a child viewscreen) whose first step in rendering and in input checking is to render the parent and send input to the parent. TransparentScreen in the file i linked is the most barebones possible version--take that and add what you need to it.

lethosor

  • Bay Watcher
    • View Profile

To clarify, each instance of a DF (and therefore DFHack) viewscreen has a "parent" and "child" viewscreen instance. It doesn't have anything to do with parent/child viewscreen classes - the screens can be different classes entirely. You can see this by running "gui/gm-editor gview.view" and selecting "child" until it's nil. The first screen is a placeholder viewscreen that doesn't do anything, and the last one should be the gui/gm-editor screen itself (also a viewscreen). This process is what DF does to determine the current viewscreen.

Most (all?) DF screens simply render and process input themselves. However, since they have separate feed()/render()/logic() methods, screens can call those methods on their parent screens. For instance, to implement an "overlay", you can create a screen that renders its parent first, then draws some more things to the screen, which overwrites whatever the parent screen drew there.

Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.