Sadly Poser has no Python API ability to do what the UI can do, which is re-order actor parameter channels, via the Display in Calculation Order option in the parameters palette.

I have been craving such an option to work around a problematic paradigm Poser has had since its inception. I.e. forcing deformer channels to the top of the calculation order list when loading scenes.

I have figures that need to evaluate certain deformers AFTER the morph targets have been calculated, as they operate on the vertex positions at calculation time.
The concept for Poser seems to have been that deformers should all be applied to the un-morphed figure, which is not consistently helpful.
A block of morph targets don't really need to be evaluated/calculated in any particular order due to how linear algebra works, with the exception that morphs calculated after joint bending will have different effects due to the changed orientation angles.

The same applied with deformers, since applying a morph target could actually move a vertex into or out of the deformer's zone of affect.

Mostly Poser behaves, but the problems occur when conforming clothing figures apply the base figure's (conforming target) own deformers and those deformers apply to the base figure somewhere other than before all the morphs in the calculation order.

Within a given scene, constucting such figure conforming dependencies works perfectly as expected all the way through saving the scene to the library. However, once the scene is reloaded, Poser decides to apply those inherited deformer channels at the very beginning, rather than the order they are specified in the scene file.

I have repeatedly asked for this to be fixed (for years), as it completely prevents me from using QueueManager to offload renders, since the scene corruption happens when the queued scene file loads into either Poser or QueueManager. So far, no joy, and now macOS Poser support has been dropped completely.

My only recourse, to date, has been to load a saved scene and manually resort to selecting all the misplaced deformer channels and dragging them to where they're supposed to be via the UI. This can take 10-15 minutes of wasted time, since there is no Python API method which can replicate the UI channel re-ordering function.

As a long-term mac-head, I also mourn the dropping of macOS native Poser 14.
However, the latest Parallels VM actually supports running Poser 14 and the Poser installer, which prevented installation on ARM based Apple Silicon macs prior to that version of Parallels, actually allows P14 to be intalled.

Admittedly, it's not as nice or performant as Poser 13 on Apple Silicon macOS, but it is a path forward. Even with the incessant insanity of Windows 11 updates.

DSON died the moment that Poser was forced by the End Of Life of Python 2.7 to update to Python 3.7. Since DAZ declined to update DSON to support Python 3.7, it died instantly for any future versions of Poser. As mentioned by others, there are scripts available which are compatible with current Poser versions which can import DUF content. What becomes problematic is converting dual quaternion jointed figures (Genesis 3 and later) to Poser, which does not support that joint scheme.

"Yikes", "Concur", "We don't need any more of these!"

Pretty * Useless, where "*" is some vaguely defined boolean (or quantum) operator.

Just a quick speculation on the artifact you mentioned above (one tile or column of tiles with a colour change at its right edge).

That could be because the mod function is running into a whole number at its maximum range value, and just ticking over to the next number. A solution might be to use a float value just below a whole number as the range, like 31.99999 instead of 32 exactly, so the modulus will not have an isolated transition at 32.

Another consideration apart from the platforms the devs are required to support (meaning investment of time to install and understand), is the underlying architecture.
While certain platforms have emulation for x86/x64 support on other architectures, meaning one could run earlier versions of Poser (prior to 11.3/12) on macOS (just another flavour of Unix under the hood) in a Windows emulator, such as Parallels, etc., if the underlying CPU was Intel.
Indeed, that OS supplied emulation (i.e. Rosetta2) also allowed Poser built for x64 to install and run in virtual Windows within Parallels on actual ARM CPUs (M1, etc.).
That worked right up to the point when it was decided to restrict OS support to later macOS versions, plus prevent the installation of Poser on any system which identified its CPU as something other than x86/x64 architecture.

Prior to that, macOS on ARM could run the Windows Poser in a virtual environment while emulating x64 without any problems. Since then, it will not even install.
Of course, that doesn't apply to macOS Poser on ARM, thankfully that's still supported, but it was only a decision to neuter the installer which prevents Poser running in Windows on ARM, as far as I can tell.

Admittedly, this isn't Poser on Linux, but that narrowing of the platform support avenues indicates the likelihood of Poser on Linux, IMVHO.

Though I would prefer it to be otherwise, it seems that avoiding the burden of supporting additional OS/Architecture combinations is a reasonable course of action by Poser's current development team.

As further disclosure, I have had numerous Intel based Mac workstations with multiple boot partitions, including both Linux (RedHat) and Windows 7/10.
None of the ARM Macs I own support booting from a Windows partition directly, but Parallels and other VMs do provide that option (including Linux if I choose).
Again, prior to the Poser Installer restriction, they could also run Poser in Windows under Parallels on ARM. With the Windows beta programme enrolment, even Windows on ARM might be possible on the Mac ARM hardware, but Poser will no longer install if the installer fails to detect an x64 CPU.

Fingers crossed that one day, all such restrictions will vanish, and Poser can co-exist with Doom on a Raspberry-Pi running Linux ;-)

The one(two) question(s) I would have, after poring over hundreds of BVH animated pose offerings, is : Do the animations contain finger and hand pose information, and do they contain facial expressions?

In either case, are they separately applicable?

I'm certainly not trying to make things too hard, but more to set expectations, as I'm definitely interested.

I concur that the poses ought to be compatible with the latest, LaFemme2 figure (an A-Pose default), but I'm also aware that there is a huge (in Poser terms) legacy following for the Victoria 4 figure (a T-Pose default), which would need conversion if only LF2 compatible animations were offered.

LF2 will grow if such content support is provided, so starting there will be very helpful.

Nice work @Bastep.

One observation is that given how long Poser's Python API has been developing, certain methods tended to vary in what returns they would give if they normally returned a list, but the list had no content. Actor.Children() is well behaved, in that it actually returns an empty list, making it safe to iterate over in a for loop.

Other methods tended to return None, which unhelpfully breaks for loops as it cannot be iterated. A quick hack to overcome this is:

for iter in ReturnsNoneIfListEmptyMethod() or []:
    ...

That way there's always something which can be iterated over or skipped if the list is empty and the expression/method returns None.

OK. Found it. I remembered working with Andy (structure) on this prior to his tragic passing.

if sys.platform == "win32":
os.startfile( helpFile )
else:
subprocess.call( [ "open", helpFile ] )

The OS test you have is fine, so that can stay.
The next question becomes "Do you care about blocking?"
I.e. the "open" call will basically just tell macOS Finder to open the file with whatever it normally would.

If you need Poser Python to wait for that app (whichever one opens the file) to quit, then a "-W" parameter after the "open" should work.

It all gets quite a bit harder if you need to test for the file being closed, rather than the app quitting.

Hope this helps. :-D

Uh. I encountered this a couple of years ago and found a solution for macOS. I will search and post shortly (I hope).

Yup. I should note that my dict is intended to ease the writing of Poser files. Every low-level object in a Poser scene is an "actor", including cameras, lights, the UNIVERSE actor, props, and, of course figure body parts. Only the "body actors" get the string "actor" in poser files as their TypeId string. 

Poser has a long and storied history of using terms which later lead to confusion by varied usage. "Actor" is just one of many, sadly.
Early ideas were built upon, and later features introduced to Poser file syntax which rendered prior naming illogical, though they were initially logical, e.g. targetGeom channels (or morph targets) have an "indexes" attribute. Initially, this was the only attribute before the list of deltas, indicating the length of the list. However, that did not accurately indicate that zero deltas could be omitted, so, instead of repurposing "indexes" to indicate the range of valid indices or the number of vertices in the actor's geometry, a new attribute "numbDeltas" was added to (confusingly) indicate the number of geometry vertices, instead of a count of the number of non-zero deltas present.

Poser is fraught with contradictions due to the avoidance of backward incompatibility.

That, and the absolute absence of complete, detailed, official documentation of the Poser file formats and their syntax has been a hindrance which we struggle to overcome.

Understandable commercial pressures on the string of owners has also prevented this coming to fruition. We are lucky to have had such a supportive community willing to share their discoveries (even speculative) without ever having sighted a single line of code (Though some lists of constants have been known to be shared to help script developers).

A poser file parser is probably the only option short of dev additions to the Poser Python API.
The problem with the Python API is that it has so many gaping holes.
Primarily in the form of an absence of methods for creating items in the scene.

However, creating and linking nodes IS possible, but then the parser hurdle is the problem.

Others have developed their own parsers, but they are not available separately, but bundled into products (PFE for example).

As a caveat, though, first invent a reliable method for human suspended animation, before holding your breath.
I see peripherally how much the devs currently have on their plates, and new features might be fairly far down the implementation list.

I'm not trying to be a totally negative Nancy, here, just an informed optimist (i.e. pessimist). My Poser wish list is bigger than Ben Hur and SpaceX's Booster & Starship stack! :-)

Ugh! I've spent too long away from this forum. Can't remember all the formatting settings. [Sigh] ;-)

Here's what I've been able to determine:

PPM_GETIDTYPE = 'GetIdType'

ActorTypeNames = {  7 : 'actor',

8 : 'camera',

9 : 'light',

12 : 'prop', # IsPropInstance

15 : 'curveProp',

16 : 'baseProp',

18 : 'magnetDeformerProp',

19 : 'waveDeformerProp',

21 : 'sphereZoneProp',

23 : 'hairProp',

24 : 'uniformForceFieldProp',

25 : 'coneForceFieldProp',

26 : 'controlProp',

28 : 'controlHandleProp',

29 : 'groupingObject',

34 : 'measurementLine',

35 : 'measurementAngle',

36 : 'measurementCircle',

37 : 'measurementPolyline',

}

Not every valid IdType has a defined poser constant, though.

@HartyBart thanks for the heads-up! This might indeed be applicable to Poser!

I suggested to the author that the missing tongue positions could possibly be extracted using Python Speech Recognition Library and a phoneme dictionary, with the phonemes giving a clue to tongue positions.

Very interesting!