Has anyone come up with a fix for the "No Figure" bug? Or at least an explanation?

What happens: At apparent random, P7 loads an old PZ3 and you have supposedly "no figure." Fact is, the figure is visible but it can't be selected, and if you save the file, the code for the figure is discarded. Specifically, I loaded a 27Meg PZ3 with a Poser version # of 4.2, including Steph Petite and the six or seven conforming items of Traveller's Fantasy Dancer (each of which is a figure).

The file opened in mesh display (not likely to be how I saved it, but who knows?), with no figure on the figures lists, even though all of them were displayed on screen. And none could be selected, even though they were all clearly visible. There are also no lights. The default lights are listed in the PZ3 text file but not shown on the Light display.

All the material settings have been discarded, so there were no materials displayed. Switching to Texture Shaded turns the figure assembly to preview colors, even though there are supposedly no figures to apply these colors to! I've tried a handful to tricks to whack P7 upside the head and get my $#%$ figures back, including selecting from every selection list I know of,  adding a prop to poke the memory, and even adding a figure to activate the lists. The new stuff is there; the old stuff "isn't." Nothing seems to work. I saved the file to a new name, and the new file dropped all but 110K of data, including all the original figures and the lights. So now, sure enough, there really are "no figures." That's fixed.

I've tried adjusting the version number in a text editor. That introduces new anomalies, but still no figures. I have about ten old PZ3s that this happens with. The trigger seems to be a high figure count, but not necessarily. I have a PZ3 with six complete P4 men plus Judy, and it loads just fine. Another includes Jessi, Syd, Judy, and Steph, plus an MD scene; and it works fine as well.
This kind of screwup in backwards compatibility is just unacceptable. I suppose I can open the 4.2 PZ3's in Poser 6 and save them to fix the problem, but who knows? I haven't even been able to determine if it's the "age" of the file that causes the problem. I'm about ready to dump Poser altogether. This program is so bug-infested, it's an insult to the user. And yes, I have a powerful, up-to-date computer, malware-free, network-isolated. And I was seeing these problems both before and after SR1.1. And frankly, no other program on this computer acts up like this. None. The problem is Poser 7, not the equipment or the user.

I have days invested in each of these now unusable PZ3s. If anyone knows of a way to get around whatever brain damage Poser is inflicting here, I'd much appreciate it.

Mick

"So now, sure enough, there really are "no figures." That's fixed."

Good line.

=========

When I've seen this sort of thing in earlier versions, it was because
the PZ3 had a missing bracket or had been corrupted somehow.  

So I wonder if P7 is misreading some specific character or line in the file...
Have you tried resaving the PZ3 in a word processor, just in case P7 is
allergic to something like a CR/LF or tab character?

Quote - Have you tried resaving the PZ3 in a word processor, just in case P7 is
allergic to something like a CR/LF or tab character?

Good idea. I'll give it a try. I'm reasonably sure the PZ3's in question have not be meddled with in an editor, but who knows? ....

Interesting. Once I convinced OO2.2 to open the file and save it (gasp, choke, 27M), it created a file one character smaller than the original (and hosed OO2.2...).  In spite of the one character difference, TextPad reports the files are "identical," meaning that the missing character is a hex value the text editor can't see. More to the point, the new file loads with the same problems as the old one. I also tried switching to OpenGL, since the file has the neck spike characteristic of the new "hose SreeD" feature. No dice. The next step is to open it in ZPad and remove the figures one at a time (starting with Steph, since her neck spike suggests a problem there). What fun.

Thanks for the suggestion.
Mick

Regarding ZPad: Its lack of a bracket-collapse function is maddening, as usual. I'm ready to pay for the update when this is remedied. Meantime, the Match Bracket function can't find a matching close for the top-level bracket. After a bunch of spot checks, I gave up trying to find the error in ZPad. TextPad agrees that a bracket is missing. More digging....

Progress! Removing Steph in a text editor (don't try that at home) fixed the file. I may be able to salvage everything by inserting her into the stripped file and then re-comforming all the clothing figures.

Ok, here's the problem in the old file. An entire chunk of the PZ3 has been mislocated in the text stream. I have an addchild: abdomen 12 immediately below the Delta stream for a head morph. The Head brace is missing, and the add child lines begin with an incorrect indent. They are followed by material sets for a different figure (part of the costume). Eventually (about 170 lines below), delta values that appear to go with the interrupted stream appear, but the very next line has a Delta ID that means it is NOT part of the Delta stream. In a word, a chunk of 170 lines of the PZ3 has been inserted in the wrong place, probably overwriting the correct chunk. The file is truly toast.

I have a backup which I'll look at later. The archival date and time stamp says the file is five years old and has the same content. So apparently P5 ruined it. How comforting.

Oh well, thanks for listening.
Mick