heh im not on the phi builder part yet: but the plan is to offer "templates" that you can use to set your model to which would automatically generate the proper parenting and rotational settings for the model. this would allow a vast 'speed up' in the phi building process...100 joint models in 3 minutes instead of 3 hours. Perhaps even a "draw" interface where you just draw a rough line indicating bones and let it do phi automatically. Anyhow, there has to be an easier way. Its not the model part that holds me back now, its the basic 'hum-drum' stuff that just eats time. I cant go into the "one model for all models" technique until I kill this other time eating schtuff. I also may add a way to make a model conform to the standard naming practices once the template is chosen, this makes it behave better for the user and easier to set up for the critter maker...its all just text editing, and computers are wonderful for automating that :) it does not currently produce an identical 'readme' file name...that is within limits. If you save using the 'save all' feature of the program, it creates a readme file called: [modelname]readme.txt where modelname is the name you have assigned to the model. so if you make a readme for a model called "octopus" and use save all to save the file, it would save the file as octopus_readme.txt, thus preventing overwriting of readme files. Its set up this way because if you were to have 50 models selected and 'save all', it has to give each one a different name for all 50 readme files to prevent itself from overwriting things. I really probably ought to change that til it says readme[modelname].txt instead, but for now its ok. and yes, anyone who wants to help test..please send me an email. Testing will begin very soon on the packaging portion/link checking parts of the program. My email addy is: brycetech@yahoo.com the morph manager, phi-builder, cr2 editor will be added while the packaging is being tested. Actually, the link checker could be 'stand-alone' cause it doesnt need any info from the base program (other than a poser directory). If I feel really REALLY ambitious, I may try to put a joint editor in it. Poser sucks at making default falloff zones...I dont see why tho because a group has a 'top' and 'bottom' which can be determined mathematically based upon vertex points. The joint falloffs should be more reliable if a joint editor looked at this then generated a falloff zone. (thinking out loud here) anyhow, its fun to make this..so who knows what it will end up doing. Especially when testers start offering the "can you make it do "x" comments :) Poser and Bryce people are great at making suggestions..and pushing a program into an area it was not made for :) BT