Hi, idk whats up, just got the new version and it seems that X2egg not working, or more not making a output file. I use x2egg test.x test.egg. Theres no error just a blink line and then it says its done? But theres no output file so idk whats up with it.
x2egg is broken in 1.6.1. Try 1.6.0 instead, or wait till 1.6.2.
David
Lmao why does it keep getting mess up if you dont mind me asking ^^?
Probably because most of us who do daily development on Panda don’t actually use x2egg, so we only discover bugs in it when it gets released and the people who do use it start to complain.
David
Not complaining, jsut trying to figure it out, it just seems like its borken alot of the time. But at the same time I was asking really, like how does it get broken? I mean, do you all mess with it or something (by that i’m thinking its its own stand alone program) Or is it part of the full development so when you change someing in the program you have to also change all the sub lines of code?
Sorry if it sounded like I was complaining in a “bad” way.
Im running P3D 1.5.4, and x2egg.exe does this exact same thing. It begins to process, I see the conversion code in the output window, and it finishes, but there is no egg file produced. Im on windows Vista 32 hp.
This is a well-known phenomenon known as code rot. Any code which is not actively maintained will eventually stop working.
In the case of 1.6.1, I made a fix to x2egg to make it work in the presence of bison 2.4, a tool necessary to compile x2egg. Recent changes in bison made x2egg no longer work with the latest version. I put in a change to fix this, but in doing so inadvertently broke it with older versions of bison, and I didn’t notice this bug until after 1.6.1 was released.
I believe it may have been broken in 1.5.4 as well. I’m not sure about that, though. I do know that it worked in 1.6.0.
David
No problem, I will then load up 1.60 and use it for now. Thanks for all the hard work drwr.
So this time, you actually added an automated acceptance test for x2egg that gets run by any automated build, and detects problems, right? In general, you’re using automated tests of features to avoid code rot, right?
Just askin’ … 
Thanks for the information drwr, learned something new today/everday =).
It seems I cant get 1.6.0 x2egg to work either. Im trying it many ways - command> x2egg.exe actor.x, drag actor.x onto x2egg.exe, right click>open with>x2egg.exe, all versions so far 1.5.4 1.6.0 1.60 produce the same results - Output begins as it starts, runs to the end and no egg is produced. Am I doing something wrong? The .x file i am using is currently working perfectly in a P3D script by directly calling it, so I’m assuming the x file is ok.
This sounds like exactly the sort of useful thing that interested members of the community would be able to contribute to the project. How about it? 
Yes, you need to specify the output file on the command line too. Open a command shell, and type the command:
x2egg.exe actor.x actor.eggThis usage pattern should also be described by the output that x2egg issues if you mistakenly run it with only one parameter.
David
I didn’t specify, I was using x2egg.exe actor.x > actor.egg and it keeps returning a case error “incorrect case c:\FOLDER should be c:\Folder” and it is in fact named “Folder”. I have the line vfs-case-senstive 0 set in config.prc but it still adamently tells me that I’m doing is wrong. I have tried to make a link that directed x2egg to do its thing and was succesful - kind of- as it output an entirely blank egg file. 4 hours now, I’m giving up on it for today, I have just not been able to make x2egg do anything useful yet.
The error message means that one of your environment variables is naming your folder “C:\FOLDER”, and Panda is complaining that the actual name is “C:\Folder”. You could fix it either by finding the environment variable in question and changing it, or by simply renaming the folder to “C:\FOLDER” to match the environment variable.
This is indeed controlled by vfs-case-sensitive, and setting that variable to 0 would turn off this behavior. Since it didn’t, I suspect that you didn’t successfully set that variable to 0. Perhaps you were editing the wrong Config.prc file. In Python, you could type the commands:
from pandac.PandaModules import *
print ConfigPageManager.getGlobalPtr()to print the list of Config.prc files it actually loaded. Make sure the file you edited is on the top of that list.
David
Metal3d can you still load up the actor normally with .x? (it should still let you cus it does this auto magicly ) In case it doesn’t then you have the same bug that I have, other wise your doing something sorta out of “code” and need to check. I just came from the one you used and it work, I jump from 1.5.4 to 1.6.1 so it should work for you still if your using the 1.5.4.
Very useful I will run this straight away.
Precise, accurate - and success!
Thank you, we have discovered what the issue is. My Windows Vista does in fact have a deeply embedded environment variable that for some reason between windows and a command prompt, sets the command environment to write its paths, including files, in all caps. I will research this and if I find a way to change this properly I will post it for others.
adr thank you for your input as well, I really appreciate.
EDIT: I put the line in Panda3D-1.5.4/etc/config.prc, and the code you supplied above reports:
6 explicit pages:
(signed 1)
(signed 1)
(signed 1)
(signed 1)
(signed 1)
(signed 1)
2 implicit pages:
/c/Panda3D-1.5.4/etc/Config.prc
/c/Panda3D-1.5.4/etc/Confauto.prcso it is usin the one with the edit.
Sorry for the double post, but I have found some information that may prove useful to other Windows Vista users who have problems with their environment variables as I have, as explained in my posts above.
I have discovered that choosing start>run>command.exe always reacts this way, but by holding down shift and right clicking a Vista folder, it gives the option to “open command window here”.
When I do this everytime it the x2egg.exe commands work flawlessly.
Hmm, strange. To pursue this further, you can investigate the value and origin of that one particular variable with:
print ConfigVariableBool('vfs-case-sensitive')The top line is its current value, and where that value was defined. If it doesn’t mention your Config.prc file that you edited, make sure you spelled the variable correctly.
David
Using the above code, the output is:
6 explicit pages:
(signed 1)
(signed 1)
(signed 1)
(signed 1)
(signed 1)
(signed 1)
2 implicit pages:
/c/Panda3D-1.5.4/etc/Config.prc
/c/Panda3D-1.5.4/etc/Confauto.prc
ConfigVariable vfs-case-sensitive:
vfs-case-sensitive 1 (default value)
Set this true to make the VirtualFileSystem present the native OS-provided filesystem as if it were a case-sensitive file system, even if it is not (e.g. on Windows). This variable has no effect if the native filesystem is already case-sensitive, and it has no effect on mounted multifile systems, which are always case-sensitive.So it is still 1, although the line is correct in my config.
It seems to me my Vista install has a deeply embedded, hidden, environment variable that forces command.exe to translate paths to all caps. In explorer, my paths appear normal. When I first run command.exe as administrator, the paths appear normal. Then if I change dir, the prompt is in all caps, and no further change dirs work unless I’m in all caps. However, If I run command.exe from localuser, the behavior is normal.
I suspect this is an internal communication design on Vista, between user and administrator, but I may be wrong. I am researching this now, as this machine is my development powerhouse. Or I may resort to dual boot Ubuntu 
EDIT:
If i put the line in configauto.prc as well, I get this:
ConfigVariable vfs-case-sensitive:
vfs-case-sensitive 0 (from /c/Panda3D-1.5.4/etc/Config.prc)
vfs-case-sensitive 0 (from /c/Panda3D-1.5.4/etc/Confauto.prc)
vfs-case-sensitive 1 (default value)Stranger yet.