GUI Scripting: Limitations of On-Surface GUIs

From The DarkMod Wiki
Jump to navigationJump to search

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

Retrieved from "https://wiki.thedarkmod.com/index.php?title=GUI_Scripting:_Limitations_of_On-Surface_GUIs&oldid=30090"