Hi there, Some may remember the older discussion about fragmented obj files and FireFly hanging up when it get's to the "adding objects" status bar. Something else that is important in the need for a hard carraige return at the end of the obj file. See below

See this image. See the blank line at the bottom? Without it Poser get's funny. Not having it can cause long render times, errors and can even cause morph explosions if such a file is loaded as a morph. Just something to keep in mind. Anyone apart of beta testing teams might want to ref this to people. Hope it is helpful. Anton

hmm..I wonder if some of the lower-order ascii characters would help. Don't remember the actual numbers, but under 30 or so are a lot of control characters. To insert, type 'alt+the number of the character', like Alt+164 is and so on..hope this helps

You just need the hard return.

This is typically caused by a text file parser that only looks for end-of-lines (hard returns), but not end-of-file in the same breath. It may increase parsing speed, but, alas, this is the result - either an error or the last line is never parsed.

I know that Plain Old DOS did make use of an end-of-file marker, but even 15 years ago it wasn't used by all software. A lot of code I saw explicitly counted the file length. So relying on EOF being there is not a good idea.

That was exactly the solution to fixing my long render time for that character package I was seeking help with in another thread. My render time prior to adding that carriage return at the end was almost 3 hours. After adding that to each of the 4 clothing .obj files, my render time reduced to 50 minutes. Thanks again for suggesting I try that :)

I'm not talking about an EOF marker. I'm talking about checking for the end of the file (returned by most OS and language file reading routines) while reading lines from the file. If they were going by filelength (which is how I determine EOF), then a hard return at the end would be pointless to avoid the issues raised, now wouldn't it?

Remember Poser's origins folks. Think early MacOS conventions, not Windows, then it will make sense - or at least becomes explainable.