Geep

The wiki page "Ragdoll Corpses in Water" is updated, and now with pix. @PranQster, let me know if you'd like any changes (or make them yourself). Similarly, @angua, I recently made some tweaks and extensions to your "Swimmable Water" page.

Thanks. I'll rework the wiki page soon. Your related AI-sitting experiments are off-topic for that, so won't be included there. But there will be a pointer back to this thread, though.

@PranQster, I'd like to add a precis of your method to the "Ragdolls floating on water" wiki, including the 2 photos above. OK? Also, I wasn't sure that the monsterclip suggestion was going to work... won't ragdolls just fall through monsterclip? Did you try it?

I'm not sure where to post this, but this group seems relevant... In a 3-month time frame, a nude or semi-nude male AI is needed for a new FM. He would be paired with an existing nude female AI in a brief cutscene. I am unaware of any pre-existing TDM nude male. Please PM me for more details if you might have the expertise and inclination to help.

Yes, we're good now. Working with fflood and others, 2 works were retrieved, made runnable under 2.07, and considered. One seems to have particular promise. It's way too early to say much more about that.

Done. In my FM, I found i could live with the T pose. My wiki piece links to ways to pose a ragdoll, but I didn't really pursue them.

I mentioned the T-pose problem with a ragdoll, but at the time didn't know which of my various bit twiddles might have caused it. Useful to know it's "nodrop 1". I'll revise the wiki accordingly.

@PranQster, your postings reminded me to make coherent my 2019 notes and findings, just added to the wiki as Ragdoll Corpses in Water

I just did a rewrite of the wiki article on Caulk Please take a look. In particular, I added a section on Caulk Sky (which was new to me), with a small placeholder paragraph about Atmospheric Fog. Does anyone know if there's still a difference these days (given the Portal Sky changes in 2.06) between how fog (and its boundaries) works with portal sky versus caulk sky? If so, please revise it yourself or enlighten me. Thanks.

"Advanced Bobbing using Func_Mover" thread is set up. Could some admin please move the following posts in this thread to it: - Everything from Jack Farmer's original post of March 26 thru my last post of March 31 - Selective posts in April 1-8. Skip posts exclusively about silhouettes or path_talk nodes. (Those that touch on these topics + bobbing... duplicate?) Thanks

Conversation moved here from March/April 2020 Newbie Questions

@Dragofer, I could open a thread that included the recent work (say mid-March onward) by @STRUNK and you (and commenters), assuming an admin could move appropriate posts from here to there. How would "Advanced Bobbing using Func_Mover" sound as a topic title to you folks?

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.