Geep

BTW, here's what the intentionally minimal GUI looks like: windowDef Desktop { rect 0 ,0 ,640 ,480 backcolor 1,1,1,0 background "video/cutscene_video"; // mp4 shader defined in materials/cutscene_video.mtr file. ..." onTime 0 { resetCinematics; // reset Video to start Desktop::matcolor 1,1,1,1; // show video localsound "video/cutscene_video"; // sound shader (logical name, not file name) } }

Tried @Dragofer's suggestion for showing video using an atdm:gui_message object with custom gui. This solves the "wait until triggered" problem, but still some tough nuts to crack: 1) While the video plays, there's the large TDM main menu cursor clock-hand atop it in screen center. Tried adding code to the GUI to hide it, but no luck with: showCursor 0 showCursor "0" menugui 0 menugui "0" I could try to hide the cursor clock-hand from triggering script instead, if I could find a command that would do that. 2) There's no way (yet) to skip the video. Maybe I can wire up an onAction block for that, to respond to LMB. Or less likely, a custom GUI button atop the video? 3) ESC throws you back to the main menu, but resume only works for the video, not the audio (when using GUI localsound with a separate sound file). Might be workarounds.

OK, that's another approach that doesn't use the darkened room method. Too brain dead now, so later for trying that. Thanks

"I'll get back to you" is what I say. And sometimes I even mean it. Anyhow, just an update on my problem, about the video cutscene use-case. Good news: I've got to where I can play video+audio in the darkened room, and associate the player with a camera looking at the screen therein (called video_wall). Bad news: Where I still need ideas is how to delay the start of playback until I trigger it with a script call to sys.trigger($video_wall). Some context - I have a onTrigger() block within my custom GUI that the screen refers to. But no indication it's ever being called. Instead the video (which is set to the background before/outside the block, and seemingly can't be set inside the block syntax-wise) runs immediately. The screen is on a func_static. Maybe it needs to some other class, that has some sort of waitfortrigger spawnarg, in order to catch a trigger and relay it to the onTrigger() block. Thoughts?

Just chuckling over that again. Maybe do a future episode where everyone is a horse? Call it Red Dead Redemption 3: After the Rapture? Neigh, maybe not.

I'm going over to the func_cameraview and video-on-ingame-surface method now. Using a .gui more like Drumple's RoQ example, and generally sticking close to his method. No luck so far in getting video to appear on wall, though (either mp4 or roq).

I was able to get an .mp4 video+.ogg audio to run as a briefing in my test map, by cloning the methods and assets used in Goldwell's Shadows of Northdale ACT II. (I'll be writing that up for the wiki. @Springheel, see my PM). I'm now trying to get the same vid to play as a non-briefing full screen. Dragofer, at one point you seemed to imply that this could be done without a func_camera and videoWall, just using an GUI overlay. So I tried that, having a trigger call this target in <fm>.script: void dovideo() { float overlayHandle = $player1.createOverlay( "guis/overlay_video.gui", 100 ); sys.wait(5); $player1.destroyOverlay( overlayHandle ); } Where the 5 second wait is just a placeholder for whatever would really be needed. Which in turn invokes my overlay_video.gui: I know the gui is being parsed, though whether I structured it correctly, don't know. But nothing happens in-game. So should I just move on to deploy a videoWall+func_camera? And forget about createOverlay call, just activate the camera pointing to a videoWall painted with overlay_briefing.gui?

I guess a "change in sound" could include voice-over audio, perhaps delivered by an off-screen narrator AI. Though lots more effort to do that well than a text message.

"Curious hybrid" - that's an apt descriptor of a lot of software projects. Particularly ones that are cross-platform or the work of many loosely-managed hands over many years. It's tough to then try to revise such projects towards a holistically consistent approach. That said, if you could come up with a few relatively-quick hacks to avoid data loss, I'd thank you.

BTW, it's not the optional jewelry objective that kept your mission from ending successfully.

Ah, sorry, that's a feature, not a bug. As an optional objective, finding the jewelery is worthwhile, but as you have seen, has its risks. You didn't heed a warning, and paid the ultimate price. There was a small hint at the end to confirm why you died. Details:

Regarding that thread note, the worry I have is not so much starting the GUI, but whether you could get the game to resume afterwards. Dunno.

I don't know if this is already wish-listed, but after getting bit once again by this aggravating usability issue and having to tediously re-enter my work, let me report it: Consider a usual popup dialog window, which typically has [Save] and [Cancel] buttons and an [X] in the upper-right corner. Examples include the main dialogs of the Objectives and Conversation editors, and their respective child dialogs. In traditional desktop Windows, treating the [X] as equivalent to hitting Cancel is poor practice. What you should do is: 1) When [X] is hit, determine if the user has made any changes to the data managed by the window (or its children). Circumstances will suggest how best to do this. 2) If so, bring up this popup dialog: "Do you want to save changes to <whatever>?" [Save] [Don't Save] [Cancel] (where [Cancel] here only dismisses the "Do you want to save..." popup, not its parent. Treatment of the other cases is obvious.) An alternative, acceptable particularly for child dialogs, is to remove the [X] entirely. You can still hit [Cancel], definitely knowing you're throwing changes away.

Destined, the pauseGUI routine is worrisome. The tdm_events.script entry for it has this warning, that it interferes with execution of normal threads, but unfortunately gives no hint how to create a thread by "a special SDK method": /** * Pauses the game. This should only be called for threads that are explicitly maintained * by a special SDK method, because ordinary threads won't get executed during g_stopTime == true. * Note: This is used by the objective GUI threads. * Note: Must be called on the player entity, not the sys entity. */

nbohr1more and Dragofer - these are 2 interesting ideas. I wonder if anyone has ever tried either with video before? I was hoping not to be the pioneer on this one.

Good to hear. Yup, not running out of air is one of this mission's motivators. In earlier iterations of this FM, you could swim into the lower fully-immersed bunks and easily get stuck and drown. Those bunks are blocked with debris now (and player clip) to solve that.

Sounds like a way "to trigger the camera the simple way, where view would just return to player's last position, as it would be in other engines" is needed. I think, returning to my desire for pre-recorded video cutscenes, I understand the basic playback approach of dark room+videowall+func_camera+teleport, and will explore it. I still view this as a messy workaround, inferior to direct video+audio playback. I gather the engine already has the ability for direct playback of sample videos (but only invoked by the command line, and displayed in a small test rectangle). So a new-feature request to the engine devs, to extend this to full-screen and script-invocable, is warranted, even if it should come too late to help me.

Ah, I see this from stumpy in the distant past: So it's the func_camera that would be locked onto the video wall image in the darkened room. (Not clear to me why the player would have to be teleported to the room... couldn't one be anywhere when the cinematics is invoked? Is that needed to solve potential audio conflicts, because, say, func_camera doesn't have microphone capabilities? Or just to get the player isolated from any potential AI attack?)

Oh, I guess what I thought was a "video briefing" mode was (after consulting the "Advanced" section of the "Briefing" wiki info) just programmatic timed slide manipulation like zoom & rotation. Hmmm, perhaps the video-wall method is all we got at the moment. Any known way to instantly freeze then later unfreeze the player controls?

Probably teleporting into a dark room with a video-wall is not the best way to go for a true cutscene. You'd need to center the player's view on the wall and lock him there, i.e., disable keyboard and mouse controls. Plus you'd be scaling each vid pixel twice (once onto the videowall, then onto the physical screen) with attenuation of quality. Looking instead for a variation of the TDM "briefing video" method, but that can be invoked anywhere throughout the story, perhaps more than once with different content. May need to add a visual hint about it being a cutscene. I've seen letterbox top & bottom black bars used for that in other games. Probably that FX could be done in a video editor or FX package, rather than TDM. All still theoretical so far. I have no video capture software or video editor on my dev box yet.

Thanks, Dragofer & peter_spy, don't know how I overlooked that wiki page about video. Complicated as expected. One thing I didn't see in a quick scan of the article was how to actually start the playback (of a non-briefing vid), from either a script, trigger/target, or STIM/Response.

Sure

A general question: Is it possible to playback a "full screen" video clip for a cutscene in a FM, as opposed to a live puppeteering of AI? If so, this would have some advantages. The dev could - - pre-record (using a screen-recording tool) multiple takes of AI action that is a bit unpredicable, selecting the best take - do rapid, multiple quick edits (using a video editor) that would be tedious to do with TDM scripting and camera placement - possibly incorporate elements beyond TDM game assets (e.g., models of giraffes, children, dirigibles, etc.; crowd scenes, and so on )

Feb. 7th it got released.

OMG, this is the Internet I'm on? No wonder I couldn't figure out where to stick the postage stamp! Yucks aside, thanks for the encouragement.