Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bloop_bleep]

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.

[lethosor]

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.

[Atkana]

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

[lethosor]

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.

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().

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

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.

[Putnam]

Here's an example of how I do overriding of a particular key on a particular screen

[bloop_bleep]

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?

[lethosor]

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).

[bloop_bleep]

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.

[Putnam]

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]

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.