Forum: Poser 11 / Poser Pro 11 OFFICIAL Technical


Subject: How to fix the V4 "Eyes Won't Close" bug?

Psych2 opened this issue on Apr 18, 2020 ยท 17 posts


Psych2 posted Sat, 18 April 2020 at 8:42 PM

hborre posted at 7:27PM Sat, 18 April 2020 - #4386650

Take a look here for some insight; https://www.renderosity.com/mod/forumpro/?thread_id=2882483. The 2 links mentioned no longer exist so don't bother to follow up on those. Here is a more recent post (2 yrs ago?) about the same problem at Smith Micro forum: https://forum.smithmicro.com/topic/9070/v4-eyes-don-t-close/9. Hope this can solve your problem.

Thanks for the links!

I did see these helpful suggestions yesterday in my own search and tried changing the relevant deltas where I could but with no solution to the problem. I must admit the script editors some of the others used are way beyond my level of experience. But I did try a few other things...

I renamed the original V4/M++ folder with separate Runtimes back to what it was so my original Library listing could find it again -- even while the new V4/M++ installation with a shared Runtime and functional Morphforms was on the same HDD and also listed in the Library -- and now the V4 eyes open-close function worked again. However, since I had two different V4 Runtimes on the same HDD -- a big no-no -- that broke the newer V4 installation... not a huge surprise. It is interesting to note that the Eyes Open - Close deltas are the same on the working original installation as the non-working one... so the problem must lie somewhere else... probably in the M++ part of the shared Runtime.

At any rate, I now have V4 eyes working again in my original V4 installation, along with the most important (to me) morphs still working -- just not the Morphforms that can make full arm/leg/body movement and body shape adjustment easier. And if I need the Morphforms for something, all I have to do is temporarily rename the original installation's folder and the newer installation should resume full morph duties again. It's the best workaround I know of until/unless a better solution is revealed to me.

One other note I should mention: I also tried a brand new V4/M++ shared Runtime installation on a non-system HDD, just in case that was enough separation from V4/M++ on my C:/ drive to prevent a conflict; the problem still persisted, though.