Geep

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.