Geep: Add category tag

2022-11-04T17:36:02Z

Add category tag

← Older revision		Revision as of 17:36, 4 November 2022
Line 21:		Line 21:

	You can use a frob_action_script to call either a global script function, or one in a script object that is attached to the entity with the "scriptobject" spawnarg. In most cases, there is little advantage to using a script object just for frobbing.		You can use a frob_action_script to call either a global script function, or one in a script object that is attached to the entity with the "scriptobject" spawnarg. In most cases, there is little advantage to using a script object just for frobbing.

			{{GUI}}

	On the other hand, if you want to make the surface show visual changes without player frobbing (or in addition to responding to player frobbing), then a script object running an endless loop is perfect.		On the other hand, if you want to make the surface show visual changes without player frobbing (or in addition to responding to player frobbing), then a script object running an endless loop is perfect.

Geep: create this article

2022-10-20T19:44:45Z

create this article

New page

''This is a part of a series, whose hub is [[GUI Scripting Language]]''
==Introduction==
''These limitations apply to GUIs on in-game surfaces, NOT necessarily to in-game full-screen or partial-screen overlays.''

Unlike Doom3, TDM does not support direct interactivity on GUIs applied to surfaces, what you might need to play a game on an anchronistic in-world computer. This is on purpose; Doom3 code was removed or disabled in order to build out reliable TDM frob support,
[https://forums.thedarkmod.com/index.php?/topic/21464-gui-on-a-world-object/&do=findComment&comment=475923 indicates greebo].

==Details and Implications==
* Game-related key-binding, including mouse-button-binding and mouse-motion handling, remain in place.
* Consequently, a cursor - if shown - is dead. So an on-surface GUI should have "nocursor 1".
* Key- and mouse-related events will never reach the GUI, so onAction, onActionRelease, onEnter, onEnterRelease, onMouseEnter, and onMouseExit event handlers are never fired.
* And of course onEsc is not pertinent because Escape jumps to the main menu.
* Still useful: onTime and onNamedEvent.
* GUI "buttons" on an entity cannot be individually touched, whether created by:
** child windowDefs; or
** multiple "Entity GUI"s on different surfaces of an entity, with separate GUIs.
* Touching (at the whole-entity level) is just by frobbing, and is done indirectly through a frob_action_script.
* As feedback, frob highlighting must take the place of mouse-over event handlers.
* The frob action script function can change what individual child windowDefs (including on multiple Entity GUI surfaces) show. So text, images, colors can be altered.
* As for guiDefs other than windowDefs, these cannot get needed key inputs. So editDef is useless. Others (like choiceDef and renderDef) can be driven by script. For choiceDef, this results in adequate if somewhat-reduced functionality; see [[GUI Scripting: On-Surface Menu Example#Spiders]] for details.

You can use a frob_action_script to call either a global script function, or one in a script object that is attached to the entity with the "scriptobject" spawnarg. In most cases, there is little advantage to using a script object just for frobbing.

On the other hand, if you want to make the surface show visual changes without player frobbing (or in addition to responding to player frobbing), then a script object running an endless loop is perfect.

The "Other Ideas" section of [[GUI Scripting: In-World Menu Examples]] explores some possibilities.

==The "gui_noninteractive" Spawnarg==
Doom3 provided this Boolean spawnarg to set on an entity with surface GUI(s). It was designed to indicate whether any of the GUIs on the entity are interactive. [https://modwiki.dhewm3.org/doom3world/index.php?thread_id=20799 In 2007, Tetzlaff in a modwiki post] described it this way for Doom 3:

"GUIs that are just eye candy should be set non-interactive (gui_noninteractive 1), or else they can get in the way in the middle of a fight."

However, for TDM, entity-based GUIs are all effectively "non-interactive" in the classic sense anyway, so this spawnarg, while parsed and internally set, seems to have no actual effect.

GUI Scripting: Limitations of On-Surface GUIs - Revision history

Geep: Add category tag

Geep: create this article