"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!

I get the same disappointing window drawing issues in Poser 12 on macOS Sonoma. I have been using all the beta versions of Sonoma, and Poser 12 is now effectively unusable. This COULD be related to a change in the version of wx that Poser 12 comes with. I have not tried updating wx within Poser's Python Shell, since that previously broke some things in Poser's UI prior to my migration to Sonoma.

I have another Mac running Ventura, and it remains fully compatible with Poser 12.

Poser 13, having a more recent version of wx does not appear to exhibit the same problems.

From everything I have seen, there will NOT (unless there are VERY pressing reasons) be another release of Poser 12 to address this, sadly. All efforts seem to be on Poser 13, but that is a MAJOR task, given the truly enormous number of issues which remained unaddressed by SMS even prior to Bondware's acquisition, and we've had Poser 11.3 and Poser 12 releases followed by Poser 13, now, so there's no going back.

"Winter is coming!", BRRRrrrr.

That's rather unfortunate to hear, given Apple is committed to their own silicon replacement for Intel, which is based on ARM.
I'm using Win11Pro under Parallels 18 VM on an M1 MacBook Pro. Poser 11 and 12 for windows have run just fine in that.
I'm aware that installers for some software intended for windows computers will fail to proceed if they detect a CPU that is not x86/x64, as the ARM CPUs will be.
Later macOS systems have Rosetta2 which can emulate intel CPUs, though if software has a specific CPU type test, that's a moot point.

I am hoping that the assertion that Poser will not be built for ARM is a windows specific consideration, not ARM in general, else there will never be an Apple Silicon native version of Poser 13 and later.