Geep

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?

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.