Geep

Still another new topic, from 2019 work: Objects Floating in Water This covers func_bobbing and moveable methods at a tutorial level, with pointers to other methods. By tomorrow, I'll add links to it from other relevant pages.

Another wiki topic added: Your Mission - From Beta Testing to Release and Beyond with links from the endings of: A - Z Beginner Full Guide Page 6 How to pack your Mission The material here will be largely obvious to old hands, but worth stating explicitly for the benefit of newcomers. From the Introduction: This article elaborates typical steps for beta-testing a mission beyond its packaging, namely: distribution, forum presence, and testing. This process continues to Final Release and any updates. Consider this a follow-on to - * A - Z Beginner Full Guide; and * How to Pack your Mission, which fully describes the vital process of packaging and testing a .PK4 archive.

@roygato With respect to first point: One of things that attracted me to TDM was the player-controlled save system. Like you, I try to save periodically. I just assume getting killed/failing the mission is gonna happen, so no big deal when it does. But I can see if someone's playing style is to avoid saving, then mission-fail becomes a much bigger issue. (The FMs I personally give up on are ones that I can't crack no matter how many times I reload and retry. Ones that require feats of manual dexterity beyond me... running around a table in a tight loop with a demon chasing me while trying to fire 2 arrows backwards at it, for instance.) In any case, there was a bit of discussion with @Dragofer during the Air Pocket betatest about replacing the specific mission-fail with essentially what @joebarnin proposed. As joe notes, is this technically possible? At the time, I was thinking about paralyzing the player's movements, while still allowing the bar to be dropped. Best idea I could come up at that time was enclosing the player momentarily in a dynamically-placed box. Revisiting that now, other possibilities would be: just a momentarily-present playerclip ceiling; a force field as Dragofer suggested; or a script that continually repositions the player to a fixed location. But still, no matter the implementation, for that to be of any help to players at the end of their air gulp, they would have to quickly diagnose the problem, find the bar in their inventory (it may not be the last thing they picked up), put it in their hands and drop it. I dunno, still seems like a bit much to do in a great hurry, when they can just replay it and be careful not trigger the problem in the first place. Could've dropped this trap entirely, of course, but, well, then we couldn't have this fun discussion!

Added my first TDM Wiki topic, "Video Briefing".

Ah, Springheel was able to fix me up with a wiki account after all. I'm a happy camper now.

Abusimplea, my bad! I've overlooked the fairytale-gold-compulsive community. NeonsStyle, the mission fails not because of the objective to get the jewels, but because of getting something else adjoining the jewels that the player was warned against getting. I admit that's a close and perhaps narrow parsing of the objective, which may tie into Filizitas's points. Filizatas, I don't know if the objective in question - and its fail trap - is any more "artificially constructed" than those in many FMs; all I can say is that it (and the warning) made sense to me in context. It certainly is true that the game overall is thick with objectives. That, and the sense of prescriptiveness you felt, is something I regret a bit, and that I will swerve away from in the future. As you noted, the second half is much more open-ended, with less (you would say insufficient) guidance. I might add that in the first beta of the game, you could spot Emily right away once you got to the surface, so at least some of what-to-do was more immediately clear. However, testers wanted more playtime, challenges, looting. They also wanted access to the spyglass, which I thought conceptually conflicted with distance-based-triggering unless Emily was a bit secluded. Those reasonable suggestions to improve the FM led to my changes in response - for which I take full responsibility - and to where we are today. All grist for thought for the next FM. Thanks for feedback.

It does set up a tension between a thief's "inherent nature" and "what's safe for me given the circumstances". I thought my particular embodiment of that tension was interesting, but you found it aggravating. So it goes. It's still a feature for me, but my future episodes will go in other directions (though never promising not to aggravate some of the people some of the time.)

@taaaki@stgatilov I'd postponed for a year, until recently, asking again for permission to edit the TDM wiki. But though I'm now considered qualified, it's evidently a no-can-do for ANY newcomer to get a new (registered) wiki account. This is either because of a loss of "institutional" knowledge or of actual code or capability during some previous crash/recovery. Needless to say, this situation is not helpful to growing and renewing the TDM community. (I'm trying real hard here not to have hair on fire.) Could you folks, as admins, do some research, perhaps reach out to MediaWiki if necessary, and find a solution? Thanks.

@fllood, I wasn't able to PM you, due to "not receiving messages". What's the process for interest in "abandoned works" now?

RE the wiki, I'm guessing there was might have been some custom settings to restrict normal user registration, and custom code (probably php and/or MySQL proc) to do the managed registrations, and that it has been lost. Do we have any contacts with MediaWiki gurus that might help with this? I guess I could take over some existing user account of a user who is long gone (assuming the password could be reset), but (unless the username could also be changed, which I doubt) that would mis-attribute my contributions. So not a great solution.

On another topic, I was looking at a video gui tutorial that referred to ipn.gui in a Doom3 context. Anyone, please PM me if you have that file.

Hope there's a solution

Got some content ready to go, just been waiting for @Springheel to see my request to add me to editors.

Hoo ha, got it working! Change GUI to... onTime 0 { nocursor 1 // This work ONLY in this location, not in Desktop or after reset/matcolor here ...

...or with a custom scriptobject with overlay levels of 100 or 200 instead of 10. My forehead's flat from banging it against wall.

I meant "No luck with nocursor 1..."

No luck with nocursor 0, either at the Desktop or within the onTime block. I'll play around some more, but am lacking much insight into GUI structuring. Stumpy, do the windowDef names "VidFrame" and "RoqFile" have special meanings regarding processing? Should I use "RoqFile" even if its an mp4? Dragofer, I'll try boosting the overlay level.

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?