View Issue Details

IDProjectCategoryView StatusLast Update
0006509The Dark ModGUIpublic28.04.2024 16:07
Reporterstgatilov Assigned Tostgatilov  
Status suspendedResolutionfixed 
Target VersionTDM 2.13Fixed in VersionTDM 2.13 
Summary0006509: Add GUI debriefing stage to main menu
DescriptionCurrently, we have GUI briefing and briefing video before the mission starts, but after mission success there is only debriefing video.
It would be great to add an optional GUI debriefing stage after mission success.

As far as I understand, it can be mostly copied form GUI briefing.
I suppose it should be after debriefing video..?


related to 0002933 resolvedgrayman Add ability to select player start points to mission briefing 




29.03.2024 20:12

reporter   ~0016596

Thank you for considering the feature! I've wanted something like this for a long time. One thing that makes me sad in TDM is when a mission abruptly ends: Obviously every FM has an ending, but I never liked just transitioning to a stats screen as if nothing you did in the world mattered. I'd absolutely love a debriefing GUI just like the briefing one, where you can either have text or an image slideshow with music and a voice-over readout which is even better! If any of the old FM's can be updated to use this I'd love to replay them just for that.

Regarding which should come first between video and GUI: I think that just like the briefing, it makes sense to have the video first. I don't mind either way, but I think that order is consistent and makes most sense.

There is one bonus I'd absolutely love, if of course it's easy enough to do: Please allow customizing this GUI based on completed objectives so multiple endings are supported! Allow some pages in the GUI to be added / removed / changed (contain different text) based on what you did in the world. For example: If you completed the loot objective there's an additional section that says "I also got enough gold to pay my rent for the rest of the year", but if not that page can either be left out or instead say "in spite of a successful heist I may still be kicked out next week as I didn't get enough to cover my expenses". This would be a simple way to support multiple endings in standard FM's just by customizing the ending presentation, which I'd absolutely love as someone who's wanted branching paths and multiple ends in TDM.


01.04.2024 22:29

reporter   ~0016611

I too like this suggestion. I made a personal note about something similar as a suggestion for Tears of St. Lucia a few months ago: "Add a denouement to the story after having returned to the starting point: An article in The Bridgeport Review reporting on the night, with comments from the priest expressing rage at the burglary and desecration of the statue, and disgust and disdain when hypothesizing on how the thief may have entered the church using the sewers (insinuating how the priest will never feel safe on the toilet again). If the player did not knock out anyone and returned unnoticed: include a report on the guard who is recovering from from a lashing early in the morning, after being accused of causing the accident which damaged the statue, and the priest mounting a feeble defense in the paper for ordering the lashing: 'We didn't know at the time that a thief may have been responsible for breaking the statue. How could we? We did what we thought was right at the time. We can't allow atrocities like these to go unpunished.'"


13.04.2024 13:27

administrator   ~0016644

Added debriefing stage:
  r10709 Added debriefing state to mission success sequence of main menu.
  r10710 Renamed gui::BriefingText to gui::DebriefingText for less confusion.
  r17022 Added optional "debriefing" state if mission is finished successfully.
Right now it is mostly copy/paste of briefing.
The default debriefing displays pages of text from similar xdata file.

It would be hard to customize order of states, so now GUI debriefing comes AFTER video debriefing.

One difference from briefing stage is how "back" behaves.
On briefing, it is usually visible and leads back to main menu, even if there is a briefing video.
This is a bit strange, but I guess it is easy for the user to start mission again to watch video.
On debriefing, Back button by default is visible only if "debriefing video" state is enabled, and it leads to that video state.
The idea is that it player accidentally skipped the video, he can watch it again without going through "success" screen and loading final save.

For the very same reason, I'd like to add "back" button to the final "Success" state.
Of course only if any of the two debriefings are enabled.

As for customizing debriefing based on player actions, I really like the idea.
There is already support for "persistent info" that carries between mission in campaigns (supposedly set by game script).
Just make sure this info can be used in briefing GUI of the following mission, and make it available in the debriefing of this mission too.


14.04.2024 07:52

administrator   ~0016651

Some more changes:
  r17023 Minor refactoring in Success screen.
  r17024 Added "Back" button on Success screen.

As for objective-dependent briefing/debriefing.
I looked wiki here:
It seems that there is some fixed support for cross-mission objective dependencies:
Also there is "persistant info" (don't ask me why it has 'a'), which allows to carry any data from mission to mission in script.
However, I don't see any usages of this info anywhere else (except for carrying over), so I assume it is not exposed to GUIs.

I think we can simply expose all persistent info into gui.
For instance, let's support you have set "killed_berny" persistent info to string "1".
Then you will be able to access it in GUI as "gui::mission_persistent_killed_berny".
It should return "1" and thus you can use if in if-s and arithmetics (I think GUI auto-evaluates strings most of the time), but not in #ifdefs.


14.04.2024 14:23

reporter   ~0016652

Semi related point: Should we perhaps include a default map entity you can trigger to store or modify persistent info, maybe with a new spawnarg to filter trigger_relay by such info? It seems like one of those things that may be used for a lot of stuff, authors may not need to write a script for it every time unless it has special and map unique uses.


20.04.2024 15:32

administrator   ~0016659

A major typo fixed:
  r10720 Fixed persistant -> persistent type everywhere.
  r17027 Renamed "persistant" to "persistent" (paired with svn rev 10720).

Note that some script events names contained "persistant" as well, and they are renamed.
As the result, "northdale1" mission is broken now.

BIG UGLY TODO: Fixed northdale1 mission when 2.13 beta starts!


21.04.2024 10:28

administrator   ~0016660

It turns out there are two independent instances of persistent information.

One is called idGameLocal::persistentPlayerInfo.
This one was introduced by ID and is saved e.g. when you load a savegame from incompatible version.
In this case player is forced to level start, but he retains some properties (I guess something like weapons, ammo, health).
This information is synced to mapSpawnData.persistentPlayerInfo in session.

The second one is idGameLocal::persistentLevelInfo.
This one was added by TDM guys to support campaigns, this one is accessible in game scripts.
It is not synced with anything, at least because session was closed source when it was implemented.

Right now it seems I should choose persistentLevelInfo, but in general it would make probably sense to merge the two?


28.04.2024 11:22

administrator   ~0016671

A bunch of commits adding the above-mentioned behavior for persistent info:
  r10721 Synchronize "persistent level info" between game and main menu GUI.
  r10722 Added printPersistentInfo console command.
  r10723 When loading from savefile, consider the loaded game data source of truth.

The idea is that persistent info "killed_berny" is available:
  in game script:
    sys.setPersistentArg("killed_berny", "1");
    float value = sys.getPersistentFloat("killed_berny");
  in main menu GUI code:
    set "gui::persistent_killed_berny" "1";
    if ("gui::persistent_killed_berny" == 0) { ... }
All the persistent arguments are fully passed everywhere throughout mission or campaign.
If you set a persistent argument at some moment, its value will remain on this playthrough.
It is stored and restored from savefile, and it is cleared on starting new mission.

So, what can you do:
1) Customize game depending on choices in GUI briefing --- set persistent args in briefing GUI and query them in main function of game script.
2) Customize debriefing GUI depending on game state --- run game script when mission ends and save all the needed into into persistent into, then query then in debriefing GUI.
3) Pass information between missions in campaign --- well, this works the same way it worked previously.
4) Some hardcoded customizations.

Speaking of p.4, I have modified how starting location customization works.
Now you need to set "gui::persistent_builtin_playerStartEntity" in briefing GUI.
Note that we kinda reserve persistent arguments starting with "persistent_" prefix this way =)

Also now you can set "gui::persistent_builtin_startMap" in briefing GUI, which specified which .map file to load.
This is like "override" for a mission: you cannot change the number of maps in campaign or skip any, you can only replace one.
I sincerely hope this feature won't become popular though =)


28.04.2024 11:24

administrator   ~0016672

More commits to assets SVN:
  r17030 Updated campaign sample with new "persistent info" capabilities.
  r17031 Fixed GUI warnings in tdm campaign sample.
  r17032 Removed "resetTime "Video" 0;" from briefing video GUI (SDK-controlled campaigns only).

The feature took a very long time to implement.
Not because it is hard to do, but because it is hard to test (not a mapper myself).
I have reviewed and renewed the "tdm_campaign_sample" campaign.
Now I think it uses all the 4 points I listed above.


28.04.2024 13:27

administrator   ~0016674

Now running script code on mission end is easier:
  r10724 Run script function named "on_mission_complete" or "on_mission_failed" when mission is finished.
  r17033 Deleted auxilliary objective from sample campaign, use new on_mission_complete script function instead.


28.04.2024 16:07

administrator   ~0016675

This can't be marked as resolved because:
BIG UGLY TODO: Fixed northdale1 mission when 2.13 beta starts!

Issue History

Date Modified Username Field Change
28.03.2024 17:24 stgatilov New Issue
29.03.2024 20:12 MirceaKitsune Note Added: 0016596
01.04.2024 22:16 Fiver Description Updated
01.04.2024 22:17 Fiver Tag Attached: gui
01.04.2024 22:29 Fiver Note Added: 0016611
13.04.2024 13:27 stgatilov Note Added: 0016644
13.04.2024 13:27 stgatilov Assigned To => stgatilov
13.04.2024 13:27 stgatilov Status new => assigned
14.04.2024 07:52 stgatilov Note Added: 0016651
14.04.2024 14:23 MirceaKitsune Note Added: 0016652
20.04.2024 15:32 stgatilov Note Added: 0016659
21.04.2024 10:28 stgatilov Note Added: 0016660
28.04.2024 11:22 stgatilov Note Added: 0016671
28.04.2024 11:24 stgatilov Note Added: 0016672
28.04.2024 11:25 stgatilov Status assigned => resolved
28.04.2024 11:25 stgatilov Resolution open => fixed
28.04.2024 11:25 stgatilov Fixed in Version => TDM 2.13
28.04.2024 11:41 stgatilov Relationship added related to 0002933
28.04.2024 13:27 stgatilov Note Added: 0016674
28.04.2024 16:07 stgatilov Status resolved => suspended
28.04.2024 16:07 stgatilov Note Added: 0016675