problem with installation

My installation freezes at 99% every time no matter how long it sits.
I see others have had the problem but I don’t see a posted solution for this problem…I was wondering if anyone has a solution for me. Thanks

I haven’t heard any solutions yet, nor even any viable theories as to what’s going wrong, and why it only affects certain people. Maybe you can help us figure it out.

Maybe it’s just getting locked up on the way out. If you cancel at this point of the installation, does everything appear to be installed properly?


no the only thing I have is a folder but its empty…but I will work on it an see if i can’t find a solution. If i find one I’ll make sure to post it.


I’m having the exact same problem: The installer gets stuck at 99% with the file “shaft.egg” and its impossible to finish the installation (or cancel it).

Is there a way to skip this part of the process or finish the installation manually ? Is there any version that doesn’t have this problem ?

I tried 1.5.4 and 1.5.3 to no avail.

Thanks a lot in advance for any information !!

How much free memory is left ?
How much free space is left on your swap drive ?
How high is the CPU load ?

It’s already processing egg2bam, so everything should has been installed successfully.

If this happen to me, I’d simply temporarily rename my egg2bam.exe as soon as it’s created, and see what would happen.

drwr: can I put the eggcacher.exe step into makepanda, or is there a reason to do this step in the installer?
This seems to bother a lot of people. It would make the installer just a tiny bit larger.

Well, we could just distribute bam files instead of egg files; but the big advantage to the egg files in the distribution is that they’re human-readable, and the samples programs are intended to be educational.

I guess distributing pre-cached egg files, making the installer a bit larger, is a reasonable compromise. But I do wonder if that will actually solve the problem at hand. If the people who are running into this problem are locking up when they try to load and cache egg files in the installer, why do we think they’ll be able to run successfully when they try to run Panda themselves? I guess, at a minimum, it will make it easier to diagnose what’s actually going wrong.

Maybe you can build a temporary installer that simply doesn’t run the eggcacher step at all, and one of the people having trouble running the traditional installer can try it out, and then we can see what other problems they have?


You’re right, they should be shipped as .egg as well. Currently, they are shipped as .egg.pz though, which also confuses many people and thus defeating the purpose of being human-readable - maybe we should just make it .egg.

Actually, I don’t like the installer calling eggcacher.exe at all. On older systems, it’s already very slow, and I think the problem is that on even older systems, it takes up so much memory that it starts thrashing thus making the process much longer. (Same situation when I compile pgraph or ztriangle on an older machine before the split.)
So, even if this wouldn’t be the problem (which I doubt), I’d still like to remove the step.

OK. But the egg files are very large (thus the .egg.pz), and some of them take a very long time to load the first time (thus the pre-caching step).

It’s hard to pre-populate the cache directory, too, because the cache directory contains full pathnames to the original egg files, which might not be the same path in the user’s machine. (It would be like the problem with distributing the pre-compiled .pyc files.)

I guess we can turn off the model-cache directory, and ship with bam files, and have links to the original egg files somewhere.


Those are bad ideas.
Why not asking the user instead ?

I’d insert this before the “Preload all EGG” comment line :

            MessageBox MB_YESNO|MB_ICONQUESTION \
               "EGG caching is about to begin.$\nThis process may take a couple minute and approximately 270 MB of RAM.$\nWARNING : It might stuck if your computer resources are low.$\n$\nDo you really want to do this optional step ?" \
               IDNO SkipCaching

and this label after “SetDetailsView hide” line :


And there’s still a chance to minimize RAM usage by 45+ MB, by clearing the TexturePool, not only ModelPool, in

Thanks alot! I’ve applied your fixes.

There’s 1 bug though, in the other conditional branch (caching packed game, PPGAME).
The error message in the detail view box is “cannot find panda tree” or so.

Huh? I didn’t apply your fix for the case that PPGAME is defined.

No doubt about it. It’s just another unrelated issue which is left unnoticed.