Geep

Following up on the bobbing topic from 10 days ago. Here is a a demo of bobr.script, a method I just developed, specifically designed for water bobbing. it shows multiple objects, whose bobbing can be turned on & off (unlike "func_bobbing"), either individually or in groups. It is visually similar to the STRUNK+Dragofer's "bob" demo, but differs from it in that - when a "stop" is requested, it eventually concludes with a return of the bobber back to its origin, the mid-point of its vertical traversal it features more physically-persuasive slow startup and wind-downs of bobbing besides bob range and time, the number of startup/wind-down cycles are set by spawnargs spawnargs are set on the triggering device (lever arms in the demo) the method is script-centric, and provides code functions that can be shared by multiple bobbers Some of these behavioral features are more easily implemented through scripting than through map trigger objects that the "bob" demo deploys. The demo specifically shows 10 positions with lever switches. From left to right, these demonstrate the following. 1) This position has no lever arm. Instead, frob the lever base to toggle bobbing. It - - uses a frob_action_script call (unlike other positions). - moves a raw func_mover (unlike other positions that show a func_mover converted from a func_static "package" model). - shows a higher vertical range than the other bobbers. These last 2 attributes are more similar to the "bob" demo. 2-8) From left to right, imagine the floating packages progressively heavier & less bouyant, so placed lower in the water, with shorter bob ranges, longer bob times, & shorter start/stop cycle counts. 9) Controls a group of 3 bobbers with same parameters, in synchrony. 10) Controls 3 bobbers with differing parameters. For more, see the install description, "Notes", & comments in script/bobr.script.

Another thought related to performance with video. The RoQ .mtr example (see https://wiki.thedarkmod.com/index.php?title=Playing_ROQ_Video_Files ) had a keyword "linear" on a separate line following the "videomap..." When I was messing around with .mtr for full-screen cutscenes, this keyword didn't seem to have any purpose. But perhaps it's helpful for performance, like avoiding hickups?

@STRUNK, would you consider doing a quick experiment, with and without your blend change, to see what the effect on hickups and framerate are? I'm thinking the blend would take more resources, but could be wrong. If blend did cause more load, then maybe deploying it should be avoided in some cases (i.e., where the skybox is not an issue).

Expanding on that first point, the MP4 format is flexible with regard to resolution dimensions, but if not doing screen capture - that is, if using real-life owl videos - probably standardized lower rez to consider are: 854 x 480 (16:9 480p) 1280 x 720 (16:9 720p)

@HMart, TDM still supports ROQ, if for no other reason to not break the existing FMs that use it. I suspect the main reason ROQ seems lighter weight is that was deployed at a time when monitors were not so high rez. So if you create or downsize your .mp4 to, say, 800x600 or 640x480, you might not see the hickups. That would make sense particularly if not needing full-screen display (nor STRUNK's multiple-window approach). With full-screen, real low rez would look a lot poorer visually. Related to @STiFU's point, I guess I'll commit to creating a wiki page about transparent videos (and ghosts), once the dust settles a bit more. This would be based mainly on the recent discussion here, particularly the wonderful work by @STRUNK

I revisted this thread because I recently got this a redeclaration error with this in my <fm>.script function: some_function_name(entity bob, ...) {...} I was getting a "Type mismatch due to redeclaration of 'bob'" error. After wasting buckets of time looking at my code, I found this forum thread, and realized it's just a naming conflict with some "bob" function in the standard distribution. And specifically \tdm_base01\script\tdm_events.script(270): scriptEvent void bob(float speed, float phase, vector distance); But what's insidious here is that the conflict is with a local function parameter name, and any decent language would not make this a conflict. Because of that assumption, it took me a longer time to realize the cause, and the easy solution to just rename the parameter. (Namespace as HMart mentioned above would work too). Maybe this is not a language design issue, just a parser bug. Don't know.

RE alpha channel, I did a quick Googling. The world agrees with .mp4 being no good for alpha. Some hints that a promising direction would be to capture in Quicktime RGB+Alpha in a .mov container, then transcode (e.g., with ffmpeg) to uncompressed (raw) RBGA in an AVI container. Or maybe lossless RGBA with the Lagarith codec (is this still Windows only) in an AVI container? No guarantee any of that would work within present TDM, methinks.

Thanks for trying it out and giving me feedback. I'm glad it's working. A concern about "videoMap loop" is that, with the audio file separate, the soundtrack wouldn't loop by itself. You could maybe give the sound file a recurring trigger in a script loop... but probably would get noticeably out of sync with the vid if looped at lot. The RoQ example shows looping of audio and video within the GUI using onTime. It essential runs forever, so may have performance impact unless further modified. The "videoMap" command also can take "withAudio", to use the embedded audio. That's used in the briefing videos, but the system to do that reportedly got some special buffer coding in TDM 2.06, so I didn't think it would work for non-briefing cutscenes. I didn't experiment with that, but you may want to.

@Dragofer, I'm confused about these functions time(m_time); //how long the movement should take move(m_translate); Are those standard func_mover functions? Or if they're hand-built functions somewhere else in the scriptobject, I'm back to pondering how to make move() work unless you can self-trigger the func_mover. As for signals and scriptobjects playing nice together in a func_mover context... maybe, but I'd like to see a working example of that. Particularly of multiple func_mover entities not interfering with each other.

@STRUNK, it may be a scriptobject approach using func_mover is not going to work, because self-triggering can't happen, as @VanishedOne found in a perhaps-different context. The whole reason for self-triggering is to reload the changed spawnargs and start the func_mover in action again. So what @Dragofer suggests would still require triggering within moveup/movedown, if you wanted to use the func_mover mechanism. BTW, my experiments did have conditional treatment within a loop. Also, I was getting syntax errors in using thread calls within a scriptobject. I could try just moving a func_static (instead of func_mover) with a scriptobject, and relying entirely on the scripting to micro-move (not ideal for performance). in that case, there would be function call(s) to turn bobbing on/off. May not work if there are re-entrancy issues that prevent more than one entity-related function from running at time. Or give up on scriptobject, just use external code/triggering with the func_mover, closer to STRUNK's example. No doubt the safe route.

RE bobbing... Just playing around writing a scriptobject attached to a func_mover. I'd like to trigger the entity from its scriptobject, but can't figure out how to do that. Tried so far: string m_bob_entity_name; entity m_bob_entity; ... // In Init: m_bob_entity_name = getKey ("name"); m_bob_entity = $m_bob_entity_name; ... // In function loop, variations like: sys.trigger(self); // probably doesn't work because "self" is referring to scriptobject, not entity $m_bob_entity.trigger(); m_bob_entity.trigger(); sys.trigger(m_bob_entity);

Oh yes, ravens. Vultures too. I'll have to check those Siege Shop fish out.

I tried downloading the original bobbing.pk4, but couldn't then open it up as a zip. Oh well, not so important at the moment. @Dragofer, when it becomes stable, please send me a copy to play around with in the floating context. I'm thinking, possibly it could be packaged up with the triggers as a on/off bobbing prefab?

@Dragofer. Hmmm, too complicated to recommend for general use. Will think about this a bit, scriptwise.

@Dragofer, not sure whether you are proposing that you use target_setkeyval - - repeatedly within the trigger_timer loop to keep halving the translate range until it reaches zero, or - once when the object is at an extreme, to bring it back to the former-midpoint, but now the new end-of-range (but then you'd have to detect which extreme it's at first)

@VanishedOne Interesting, HMart was also referencing work done in Unity.

Great to see a better fish model being brought to TDM. I once played around with a Unity-store lagoon model that had several articulated fish models, plus schooling fish behavior in C#. The latter involved each fish using per-frame nearest-neighbor detection of its closest schoolmates, then averaging their motion vectors and applying it, while striving to maintain an optimal distance from each other. I have no idea if schooling would be possible in TDM, and how one might do that.

@STRUNK@JackFarmer @Dragofer Just thinking about whether func_mover_dragofer should be added (as an experimental/advanced method) to the "Objects Floating On Water" wiki page. A drawback I see for the floating use case is that (looking at the video) the stoppage occurs at either of the 2 extremes, when what is desirable for floating is that stoppage always occurs at the midpoint of the range.

Just freshened these wiki pages: Model Scaling Triggering events when looking at something Attaching Props to AI I had a year's worth of notes about wiki work, that I've been working through this last month. Getting near the end now, then back to mapping.

Possible setting for another Netflix episode of "Ugly Delicious"

Regarding STRUNK's comment about non-full screen video... If anyone has access to circa-2006 3D Realms, it reportedly features a roadhouse with a TV showing several short videos, that loops overall. This mod forum post talks about editing the .gui and video .mtr to add additional video segments (called "channels" in the TV context), but is not self-explanatory without the original files: http://forums.3drealms.com/vb/showthread.php?t=20597 Idea might be adaptable to TDM

@HMart, fun video. Clearly getting a portal working in TDM would be its own project

The "Movie Theatre Method" could I think be adapted to non-fullscreen video. And see the other topic about "Playing ROQ Video Files" . Really, there needs to be some current R&D using modern codec, and separate wiki writeup, by someone actively working that angle, and maybe covering magic mirrors, dioramas, portals. Not going there me-self.

Not sure I've got it ALL figured out, STRUNK, or ever will, but I beat on it with a stick for a while, so here's my findings on the wiki. Enjoy: https://wiki.thedarkmod.com/index.php?title=Full-Screen_Video_Cutscenes That probably does it for what I'm adding to the wiki about video in the current cycle. Got some bits & pieces to add to other topics.

STRUNK, credit/blame for the idea of using the laptop is due to Dremple, who strictly speaking was just suggesting it as a way of testing your video in-game... probably found it amusingly anachronistic in the Doom3/TDM context. Maybe could use it in a Dr. Who/Time Lord episode? All: As I build out wiki pages about in-game videos, I'll mention some of the ideas here: inventors guild, magic screens, windows, Prey-like portals. @Amadeus, I haven't done Prey, could you post a portal pix?