talezero/integration
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Improved Docs, AnimationStepApplyMesh+Materials, some other minor tweaks

Browse Source
This commit is contained in:
jyelon
2026-02-06 17:34:26 -05:00
parent a2e179e15b
commit 56765fdc16
28 changed files with 731 additions and 165 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
Docs/Displaying Widget Blueprints.md
View File

@@ -32,7 +32,7 @@ To call a Lua function, use the blueprint node 'Invoke Lua Function' or 'Probe L
By default, luprex puts a crosshair on the screen. When you aim the crosshair at an object, you are said to be "looking at" that object. Sometimes, looking at an object causes a "look-at widget" to pop up. Here's a typical example of a look-at widget, which displays the hotkeys for that object:
![](Displaying%20Widget%20Blueprints_html_fc056206a4099c85.jpg)
![](Images/Displaying%20Widget%20Blueprints_html_fc056206a4099c85.jpg)
Luprex contains all the following mechanisms to support the idea of look-at widgets:
@@ -213,7 +213,7 @@ Currently, there is no way to pop up any widget other than a look-at widget. The
The configuration for a widget blueprint could be complicated. Consider this menu:
![](Displaying%20Widget%20Blueprints_html_24d3706fb604c218.jpg)
![](Images/Displaying%20Widget%20Blueprints_html_24d3706fb604c218.jpg)
This menu could be a single widget blueprint, *MenuWidgetBP*. In its *BeginPlay* event, it could probe *gui.getmenu(actor, place),* which might return { "Resume", nil, "Save Game", "Load Game", nil, "Session", "Difficulty", "Options", nil, "Main Menu", "Quit Game" }. This design would make it possible for one widget blueprint to represent all the menus in the game.
@@ -221,7 +221,7 @@ We will provide common blueprints like *HotkeyWidgetBP* and *MenuWidgetBP* in ou
Here's an interesting window from a role-playing game:
![](Displaying%20Widget%20Blueprints_html_ae2696951c4fbe2a.png)
![](Images/Displaying%20Widget%20Blueprints_html_ae2696951c4fbe2a.png)
Since there are hundreds of spells in this game, it would not be good to have a separate widget blueprint for each one. Instead, it's probably best to have a *SpellWidgetBP* that can render any spell. This might probe *spell.getinfo(actor, place, spell),* which might return a vector like this: