Geep

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.

Dopefish, glad you liked some aspects. I understand regarding "underwhelming". Some of the existing FMs have wonderful deep playability. I think of these as big novels, like "War and Peace". I'm only able to manage a novella at the level of effort and skill I can provide. This one took me a year (of calendar time, not manhours), and if it took significantly longer, I'd get discouraged and bag it. So, better a bit short (and quirky) than nada. That said, with more experience under my belt, maybe future episodes can offer more to do (but I still hope for some good quirkiness).

...or maybe not. I've "over-egged the custard" there with that PR poster concept. But thanks for the interest in further episodes of the story arc, where l hope to have more ship (and ashore) exploration. joebarnin, the getting-stuck issue you noted, in the waist hold next to the galley, wasn't reported during beta testing. Was it near the surface, or down in the debris?

Thanks, everyone for the congrats. @JackFarmer, @joebarnin, maybe I should hire you guys as blurb writers, say...

Story Tease On the run from her husband, me and my girl. With a bribe to a ship's captain, we're away. What could go wrong now? Oh, dammit. Links "Away 1 - Air Pocket" Version 1.0 is available from the in-game downloader and its mirrors. As well as here. There are two extra documents contained in your installed .pk4 and also conveniently available here - For gamers needing hints, this Q&A uses "invisible ink" to selectively hide the answers: Air Pocket - Hints and Spoilers [Jan. 29, 2020].docx For understanding what's under the hood: Maintenance Guide to Away 1 - Air Pocket [Jan 29, 2020].docx For more about the innards and interations, see this FM's Beta Testing thread. Author's Note This is my first substantive TDM FM, a nautical adventure, and what I hope will be part of a longer story arc. Enjoy. Gallery Credits & Acknowledgements Thanks to TDM community members for encouragement - and assistance with newbie questions - while building this, my first FM (not counting an earlier nanoMission). Kudos in particular to Dragofer for the wonderful ship models (modified here), newly-created ship davits, and assets like kelp models from 'Down by the Riverside'. Also a custom cannon-ball hole through the hull, and much helpful guidance. The skybox is adapted from 'lagoon' by Hazel Whorley (CC BY-NC; hw_lagoon.zip at www.custommapmakers.org/skyboxes). Finally, my deep appreciation to all who tested or assisted during the beta: Biene, Cambridge Spy, Dragofer, duzenko, peter_spy, and stgatilov

Woof!

Giftwrapping did the trick. Though after positioning 15x15 = 225 vertices, my index finger is SOOooo numb. Brain too. Did a first pass to hide all vertices below the rock surface (ideally slightly below), then raised the whole mesh up until roughly 80% of the rock was beneath it. In a second pass, for selected vertices near the 20%, raised them just enough to hide the remaining rock. No problem walking, and quietly.

Tried Dragofer's method, which would have the advantage of no additional vertices (and faster if ever doing multiple rocks). I was able to replace the default skin with the custom skin, but the walking sound was still unmuffled. Same when I used: surftype15 description "moss" instead of just word "moss" to replace word "stone" in step 5. Sigh. BTW, when replacing skins in this case, the skins don't show up in the "Matching Skins" folder, instead in the "Other Skins" list. I imagine that this is because I'm using rescaled models, which append _scaledn to the model name (where n is a number, and DR doesn't yet handle this when grouping skins. Guessing this is a known issue. Probably on to grayman's giftwrapping next.