 |
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. |
 |
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.'" |
 |
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. |
|
|
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: https://wiki.thedarkmod.com/index.php?title=Setting_up_Campaigns It seems that there is some fixed support for cross-mission objective dependencies: https://wiki.thedarkmod.com/index.php?title=Objectives#Objective_Conditions 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. |
|
|
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. |
|
|
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! |
|
|
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? |
- Anonymous
