While I agree it "works" for some and not others, it can't really be a lottery. Yes you could write a program to do that, but it would be hard - and childish - to write a normal application so that it turned out that way. Computer software execution is decidedly repeatable, bad software coding not withstanding. So it HAS to be down to a root cause; question is what is it? NT vs Win9x - probably not. It has memory problems (whoa, does it have memory problems) and NT-based OSs are better at managing the impact of the symptoms, but not curing the effect. Memory, real or Virtual - no. More real memory helps, and up to around 512MB the help is very tangible. Virtual memory helps up to a point too, but again not enough to explain work-vs-not-work. User expectations - absolutely, but not to the point of explaining everything. I use parameter dials not mouse movements exclusively and the time delay effect here makes it unusable to me. Research into human factors of computers shows there is a big variation in what's acceptable in terms of response - and expectation is a big component of that. But there are still fundamental limits to this, and so when I cant get the dial to respond correctly at all in repeated tries, then something is wrong. So user expectations still can't explain work-vs-not-work entirely, IMHO. CPU/Memory/Disk speed - no. A red herring. Only real way to compare P5 to P4 is on the same system. But faster versions of the above will obviously cover up glaring performance issues. But not everyone can have upgraded systems when they went to Poser 5, so again not a root cause. CPU make/Chipset/Motherboard probably not. As verified on video cards, Poser 5 and 4 code is stuck in a time wrap based back in Poser 3 development days in terms of exploiting the hardware (theory is that its probably due to a cross-platform technology adopted back then). So the execution subtleties of the (small) differences in hardware systems these days are again not enough explain Poser 5 work-vs-not-work. Underlying PC System Stability no. Many of the EVM (Extremely Vocal Minority for those who didnt follow Poser 5-2 Forum) never had Poser 5 crash myself included. If it crashes, yes there is a problem that needs a fix. But here were really talking about how it works (not if it works) when it does work. So something else, has to be something about how people install, use, etc. Only other thing I've seen explored recently here was Runtime size, but a few reports of "it works for me and I have 20+GB" seem to debunk that. And I tested the other extreme a long time ago. Need some more data points. How about this? Those installing V3 in Poser 5 using their existing Poser 4 Runtimes appear to have got nowhere. I have no experience of this, but enough Poser gurus around here have said that you need to put V3 in the real Poser 5 Runtime, that there must be some sort of Poser 5 problem with accessing secondary Runtimes. And we know that changing from one Runtime to the next is very slow. And the (admittedly always poor in terms of error handling) Poser texture search feature initially went horribly wrong when using a secondary (Poser 4 Runtime) and still can't handle a cross-Runtime mix properly. So an hypothesis in need of bunk/debunk based on user feedback: That those who feel they have Poser 5 "working" are using the Poser 5 Runtime, and those who feel it will never work are using a secondary Runtime (i.e. their existing Poser 4 Runtime). The underlying theory being that the access code for cross-Runtime is not well designed, implemented, or more likely integrated, with existing Poser 4 code. And that accessing across the Runtimes is an "on every access" kind of thing, with commensurate impacts across the board. On one hand this seems too simple a theory to stand up to scrutiny, because surely if true CL would have soused it early, and put out some guidance. But OTOH I have noticed that a significant number of Poser-5-is-great posters extolling the virtues of the new library structure, so maybe... And I dont recollect anyone saying that they have moved their converted-to-Poser-5 Runtime back to a Poser 4 one But honestly it's too much effort for me to test this hypothesis myself, and to be honest I have so little faith left in CL's Poser 5 that I can't make the effort to free up enough disk space. So I'm interested in hearing other experiences... If true, this is still inextricably linked with user psychology of course. :-) Those who jumped in as believers probably merged their Runtimes to gain all the benefits possible. Those longer on cynicism - (guilty as charged!)- Probably erred in favor of being able to go back to Poser 4 easily and so linked their P4 Runtime in and, if this hypothesis is correct, were hoisted by their own petard. It still doesn't explain everything - or let CL of the hook. But it's an interesting line of inquiry: to determine the root cause for work/not work. And if it isn't this, then it MUST be something else. Any other theories? Or is it really just user expectations as I originally thought?