T3D 1.1 Preview - Solution Files Aren't Created - NOT A BUG

#1 Very odd, it does for me. I generally don't use the Toolbox, but just tried it.

#2 Very odd indeed ... I just tried again.

Fresh install on a Virtual Machine ... during the copy the "Source Project" tab stays blank and no Solution files are copied across. I have tried names from "Test" to "This is a Test" and all different iterations.

I cannot get the solution files to be created. It's fine for me on the 1.1 Betas and the 1.0.1 release ... but 1.1 Preview just doesn't want to play with. :(

I have checked all the folders and it is only the suo and sln files that aren't being created. :(

Here is a screen shot of the problem: No solution file.

#3 Solution files ... as in BuildFiles folder with the VS20** stuff? Works on my box ... but I'm using VS2008

#4 Okay ... seems to be a problem with my laptop and install. Now I just need to figure out ... why???

:(

It seems that the generateAllProjects.bat is causing an issue on my installation. It crashes during the install of 1.1 and if I try to run it manually.

I am looking in to the problem now ... but here is a screen shot of the problem during the install: CLI Problem.

#5 Okay ... it is because a have a version of PHP installed on my laptop (this is for work purposes).

I replaced this: "%TORQUEDIR%enginebinphpphp" in the generateProjects.bat file with just "php" and all the files were compiled correctly.

The php is found in my path and all is good again. :) I have just tested 1.0.1 and it does the same ... I only recently installed PHP and hence this problem cropped up.

Not really a bug I suppose, but maybe something to keep users informed about. I have to manually run the generateProjects.bat file ... but at least it works. :)

#6 I see that this thread has already been flagged NOT A BUG, but it does concern me that by installing stock PHP on your computer breaks the Torque project file generator procedure.

QuintonD, where did you download PHP and how did you install it to cause the problem? I'll try reproducing it and if it fails on my end then it is definitely a concern for everybody. In my opinion the Torque installer and toolbox should NOT break upon other tools, libraries, programming languages, etc... being installed unless said software actually broke dependencies. In this case by installing PHP should have not broken the provided php-cli at all unless its a bug in that version of the provided php-cli.

#7 This has more to do with your system path variables than anything directly Torque related.

#8 @Nathan: Standard PHP install from php.net. Version 5.2.14. It is not a WAMP server, it is only PHP.

@David: I also thought that it has something to do with the Paths. If I remove this entry "C:Program Files (x86)PHP;" from my System Paths setting and reboot then the problem still persists.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:UsersQuintonD>php
'php' is not recognized as an internal or external command,
operable program or batch file.

C:UsersQuintonD>

Please explain how this can be a System Paths issue when PHP is no longer found in the System Path.

In my opinion it is not a bug either, however it is important to note that this can cause issues for other users. Especially if the user is expecting the tools to work as expected.

I have installed many different software tools and utilities and never encountered an issue like this.

My Apache installation is not running and therefore PHP is not memory resident at that point in time.


So here is another test I ran. Simple PHP file:

<?php
	echo("PHP is working!!!");
?>

The first image shows me running this PHP file from inside the normal PHP folder and it works. View the image here

The second image show me trying to run the same PHP file from inside the Torque 3D folder ... and it doesn't work. View image here.


The easiest way to overcome this was to copy my PHP executable and corresponding DLLs over to the Torque folder and it worked.


I have no idea why an installation of PHP would effect a non-installation, I can only assume there are some registry settings somewhere that conflict.

If at all possible, it might be prudent to see if PHP is installed and then use the other installation first ... then again, I may be the only one experiencing this and in that case ... well then it isn't worth it.

Remember, all I was trying to do was help. Sorry if I didn't ... at least I know how to *patch* my installations now ... hopefully nobody else gets the same issue.

Anyway ... hopefully this information helps somebody out ... don't really care at this point ... just slightly annoyed right now.

#9 Anyway, if anyone encounters this issue. All you have to do is copy your php.exe, php5ts.dll and any other dlls that your php install needs over to the Engine/bin/php/ folder.

You can check what dlls you need by executing the php executable with a simple php file and it will tell you what dlls it is missing.

Thereafter your Torque Toolbox will work as expected ... not sure why it does this ... but frankly couldn't be bothered looking for a more elegant solution ... wasted enough time on this.

Anyway, here is a screen shot of my "modified" solution. Click Here

Keep on trucking. :)

#10 I'm sorry that you took offense to my post. There was no ill-will behind it. I have seen this once before many years ago when we first introduced the packaging solution and have never had anyone run into it since. The user ended up solving it by removing Apache as a service and running it as an application to remove the child service dependency, I believe. It was years ago and it wasn't until reading through your response that that memory clicked.

I've had this problem on Windows servers when running Apache as a service, though usually it was with mod_Perl version loading and unloading regardless of the conf. I've only had to scrub the registry once to fix things like this under Apache and I believe that was because of a botched nightly build rather than a stable release version. Usually stopping all services relating to it, setting them to manual, and then rebooting (which is irritating on Windows Server 2008 R2) will flush it and allow you to update your versions. However, sometimes it just works the way it is supposed to and cleanly unloads the modules. It is rare, though, unless you have a redundancy cluster setup that is chained for replication or dedicated services. Then everything is messy, regardless.

I've taken to only using Apache on linux servers since I have had a more consistent experience with version testing there than on Windows.

Again, no offense intended. Sorry that I was not more verbose in my reply.

EDIT: I shouldn't post in the morning. I end up adding random words to my sentences that make no logical sense when reading them back!