 |
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? |
|
|
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 =) |
|
|
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. |
|
|
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. |
|
|
This can't be marked as resolved because: BIG UGLY TODO: Fixed northdale1 mission when 2.13 beta starts! |
- Anonymous
