 |
For completeness, should probably also allow the form (reportedly widely used by id Software at one time): set "cmd" runscript <function_name>; (I'm not sure about where double quotes are needed here) |
 |
Here is an example of how runScript command works in Doom 3 / TDM (it should work in 2.11 too). First, define a global function. For instance, I added to tdm_player.script: void testfunc() { sys.println("It works!\n"); } Then add somewhere in GUI script the call. For instance, I added it in readable.guicode in onAction handler: runScript "testfunc"; When I click Attack when reading a readable, this script function is triggered and I see the message in console. ----------------------------------------------- Here is how it works internally. runScript is a separate type of command, which accepts one string argument ARG --- which function to call. Whenever GUI script executes this command, it pushes "runScript ARG" command into idWindow::cmd (see Script_RunScript). Then at some moment someone pulls these commands from all windows. In my particular case, it happens in idPlayer::Weapon_GUI --- see the call to idEntity::HandleGuiCommands there. At this moment it sees runScript command and tries to find script function with ARG name. The name may contain "::", but as long as the function is found, it is called with no arguments. So you cannot invoke object methods like this --- only freestanding functions. I'm not sure game scripts support something like C++ static methods... but if they do, you should be able to call them as well. |
|
|
I think the real problem is that HandleGuiCommands is only executed in one code location, and only if player clicks "Attack" on this very frame. It turns out I was just lucky to write test code exactly in the only place where it works =) It is obvious that the system of passing commands from GUI was not intended as something that just does whatever is said immediately. It was instead designed as something that caller may act on if he wants. It was not intended that all commands are queued up until someone pulls them. Instead, they are stored immediately, and freely cleared between actions. So whenever someone calls idUserInterface::HandleEvent, it executes some GUI scripts inside, and might return a sequence of commands to the caller. That's what happens when player clicks Attack while interacting with GUI, but it is context-sensitive: some other action on the GUI might have no handling of the commands, or even different handling. Of course, if you call runScript in onTime handler, it probably won't do anything, because no one is looking at the resulting commands from them. The issue I see right now is that script can call GUI event via Event_CallGui. It internally calls idUserInterface::HandleNamedEvent, which does not return the commands (they are just gone). I think I can extend this so that returned commands are bubbled up to Event_CallGui, which schedules script calls in the future. However, anything else is context-sensitive --- that's by design. |
|
|
r10460 Cleaned up commands chaining on runScript GUI command + reduced error for unknown script function to warning. r10461 Merged definefloat and float, added vec4 keyword. Regarding "vec4", I check that it works with attached hacky patch =) "float"s is already used e.g. for lightgem crouch display. vec4_in_gui_hacky_background (897 bytes) |
|
|
There are several things to decide here. 1) Regarding "namedEvent" in GUI: how does it work in games where it exists? Does it trigger the event with this name on current window only, or on all windows in the UI? Does it trigger event immediately (unlikely), or does it schedule execution until the script handler is over? Maybe it works via the same window cmd system as runScript command? 2) Regarding runScript. What use cases do we want for this feature? Looking at specific examples, we can decide how to adjust the current architecture... |
|
|
It's been a year since I've thought about gui scripting. Let me start with runScript, and how I should change my wiki entry to more correctly express its *current* capabilities (as of 2.11). I understand the call can only be used effectively within an onAction handler. Some questions: Can the global function called be in any .script file, or only in the map_name.script file (invoked with or without "map_name::" prefix)? Can that function have a loop (perhaps containing a wait), or must it be executed and completed in 1 frame? HMart said that another way it could be used is as the name of a placeholder spawnarg (like gui::gui_parm6) on the attached entity, that has the function name, e.g.: runScript "gui::gui_parm6"; True? |
|
|
Also, thanks for "vec4" keyword. I will change wiki to say it's forthcoming in 2.12 |
|
|
Yes, if you have a GUI, you can put it into "onAction" handler of some window/button so that it gets executed on LMB click. The global function can be anywhere, files don't matter at all for script I believe. The script function is executed in a new script-thread, so there is no problem if it would wait/take time. As for putting function name into gui parameter, I think it should work due to how GUI scripting works in general. |
|
|
OK. Other questions are - - does runScript have to be the last statement in an onAction event block? - if not, can two calls be in separate arms of an if...else... (only one of which will execute)? - or can there be arbitrary number of runScript calls within a given event block (each given its own script-thread)? As for use cases for *extensions* of runScript, what immediately comes to mind is to allow it to be in onTime and indeed every "on..." handler, so it can be used for debugging, by calling functions that in turn print to console. |
|
|
There can be any number of runScript, in if-s or not, last or not. It is executed like any other command. However, the command does not immediately call the script when executed. It only puts into into a buffer. When GUI script is over, all the script threads are created in "delayed" fashion (i.e. it will start at this or next frame --- not sure about details). This is of course true as long as someone pulls the information from the buffer... |
|
|
FYI, HMart in the past provided some code to extend namedEvents: https://forums.thedarkmod.com/index.php?/topic/20100-idtech-4-gui-scripting/#comment-439778 |
|
|
Wiki page "GUI Scripting: Commands" discussion of runScript is now updated to reflect info here. Check it out. |
|
|
Yes, he provided a particular implementation: global event and immediate&nested execution. But he never questioned whether this is compatible with e.g. Quake 4 or not. |
 |
I'm quite interested in getting the runScript functionality to work (better). First off, someone asked for possible use cases. I can give several. 1) In the recent thread https://forums.thedarkmod.com/index.php?/topic/22217-gui-displaying-different-sections-of-xdata-file/ , datiswous asked if it was possible to develop a template for an enhanced type of briefing where people could specify a different background for each page of text (possibly by having different xdata items for each page) 2) It would also make it easier to develop a in-game journal type of readable which is added to when the player does certain actions. A current example of this is done in the first mission (Monastery) of a House of Locked Secrets but the implementation is quite cumbersome because a) Each xdata item contains the whole contents of the 'previous' xdata item plus the added text. b) The in-game actions have to be performed in a pre-determined order. 3) Readables could be made more sophisticated e.g. having tabbed pages (e.g. in a paper address book). 4) You could have dynamic entity guis (e.g. destination displays at railway stations which change when the train has left). However for any of these to work properly, the scripting language will need to have access to the gui based variables ("text" etc). Scripts *can* access these but only if the qui has been created as an overlay. There are a number of script functions that manipulate gui variables but they all take an overlay handle as a parameter. This can be passed in by existing readable scripts because it has created the overlay in the first place - a script function called from a gui script won't have that value and that's assuming the overlay exists in the first place which won't be the case for briefings or entity guis. |
|
|
"But he never questioned whether this is compatible with e.g. Quake 4 or not." Fair enough. You asked some additional questions - as "(1)" above - that I can't really answer. I guess I thinking of this as analogous to a LMB press, that tries to find an onAttack handler in a stack of gui's. However, the fact of the match-by-name makes this more precise and also could (conceivably) be raise-one-event to many-event-handler-instances. I think I was just channeling HMart's namedEvent enthusiasm when I suggested this as a feature. Maybe this needs to be dropped or kicked down the road, pending a compelling use case. |
|
|
"However for any of these to work properly, the scripting language will need to have access to the gui based variables ("text" etc). Scripts *can* access these but only if the qui has been created as an overlay. There are a number of script functions that manipulate gui variables but they all take an overlay handle as a parameter. This can be passed in by existing readable scripts because it has created the overlay in the first place - a script function called from a gui script won't have that value and that's assuming the overlay exists in the first place which won't be the case for briefings or entity guis." There are other C++ internal pointers, such as "idUserInterface *gui", and maybe, with work, a pointer like that could be exposed and made viable for use when an overlay handle is not available? |
|
|
More elegant: if you have a custom non-overlay GUI, give it's (top-level only?) windowDef an FM-unique name, e.g., not "Desktop". Then there would be new script functions that take that name instead of an overlay handle. |
|
|
Reading what boissiere wrote, I think none of the issues are solved simply by the "runScript" feature. In fact, similar cases inside core TDM are solved by having a persistent game thread which polls some GUI variables and modifies other GUI variables if necessary. That's how readables are implemented at least. Having GUI code run game scripts in this case is bad idea, because: 1) Having both GUI and script control some common state will cause terrible logical issues and race conditions. 2) GUI scripting are very bad in terms of features, and totally broken in terms of order of evaluation. ---------------- As for accessing entity GUI (i.e. the GUI which is attached to an entity via spawnarg in .map file), it is indeed possible to expose these GUIs (and their variables) to game scripts just like overlays. But this will work only for fully mission-defined GUIs, which are probably quit rare, no? I mean: TDM is not Sci-Fi with screens and computers... |
|
|
I have created forum thread: https://forums.thedarkmod.com/index.php?/topic/22239-gui-features-runscript-and-namedevent/ Perhaps migrate to there, since I guess these discussion can become quite lengthy =) |
|
|
I see your point about the very bad features and potential for logical/race issues. "As for accessing entity GUI (i.e. the GUI which is attached to an entity via spawnarg in .map file), it is indeed possible to expose these GUIs (and their variables) to game scripts just like overlays. But this will work only for fully mission-defined GUIs, which are probably quit rare, no? I mean: TDM is not Sci-Fi with screens and computers... " Perhaps this is chicken-and-egg... fully mission-defined GUIs may be rare to date because of lacking functionality. boisserie gave the train-station-schedule example. I think "magic mirror" effects, puzzles, and dynamic location maps could benefit. |
 |
re "TDM is not Sci-Fi with screens and computers." Did TDM lose the computer screen ability that Doom 3 has? I can see mission authors wanting to mix in sci-fi elements. In fact, I have a mission in mind that I'd like to create that would use sci-fi computer screens. I recommend that we keep or restore in-game GUI screens. |
 |
[quote]Did TDM lose the computer screen ability that Doom 3 has?[/quote] See: https://forums.thedarkmod.com/index.php?/topic/12987-interactive-gui-surface-question/ |
|
|
It is weird to call this issue "fixed", because: trivial p.3 was done it was learned that p.1 works as intended p.2 is not done I'm pretty sure the namedEvent command (p.2) should still remain in the bugtracker. |
 |
Moving to 2.13 since there are open sub-tasks |
|
|
I read this is moved to 2.13 . I thought I just mention this before 2.13 moves into beta. Although maybe you already do a search for this prior to beta (?) I personally don't understand namedevent, so cannot comment on it's functionality. |
|
|
The now-quiet forum discussion indicated some interest in namedEvent, but worries about implementation and use difficulties. Perhaps the pain-to-gain ratio is not promising at this time, and the idea should be moth-balled. I'm OK with that. |
- Anonymous
