Jump to content

[ZERO] ScriptDev 0 Compiling Error. All else working


Recommended Posts

I compiled Mangos and got the server up and working just fine to where I could log into it. Then I tried adding Script Dev 0 with errors. After ferreting out info on the interwebs, I updated and re-compiled MangosZero and ScriptDev 0. The former again fine and the latter having the same error. It's being downloaded into src/bindings

Error    1    error MSB6006: "cmd.exe" exited with code 3.    C:\\Program Files\\MSBuild\\Microsoft.Cpp\\v4.0\\Microsoft.CppCommon.targets    151    6    ScriptDev0

Here's the output:

------ Build started: Project: ScriptDev0, Configuration: Release Win32 ------
 The system cannot find the path specified.
 Extracting revision
C:\\Program Files\\MSBuild\\Microsoft.Cpp\\v4.0\\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 3.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I've spent hours searching google, ownedcore, and on here to no avail. I'm a bit lost now. What do I need to do?

Link to comment
Share on other sites

What version of Visual Studio is that? I see v4.0 under MSBuild in your path. In fact, if the problem is with SD0, it is causing your compiler to complain about a Visual Studio file. The error you pasted is from VS, not SD0, though the problem may lie within SD0, it just "thinks" the problem is the VS file.

Link to comment
Share on other sites

Have you tried deleting the folder with the created binaries and cleaning the solutions before recompiling?

I just recently pulled and compiled Zero and SD0 with no errors, using VS2008 on WinXP SP3.

Did you happen to install VS2010 Service Pack 1 and the Windows PSDK?

Also, did you pull your sources from the MaNGOS Zero and ScriptDevZero develop branch instead of master in each repository?

Xenithar and I found out right in the middle of setting up his local repo that the Zero devs had changed the names of the branches. You can still use master, which is considered stable, but develop has many more improvements and is what I recommend.

Link to comment
Share on other sites

not sure how the directory must be named, likels src/bindings/ScriptDev2 - but also possible that they have changed this.

And be sure to open the project by double-clicking src/bindings/ScriptDev2/scriptVC100 [.sln]

Also the mangos dir should be places in a ascii/dos styled path. (no blancs, no accents and similar)

Link to comment
Share on other sites

Thanks for the helpful input (much easier to work with than the Arcemu folks)!

make sure you have ScriptDev2 in src/bindings

It's src/bindings/scriptdev0 but yes I believe that's the right path. It's just dev0 for MangosZero though

not sure how the directory must be named, likels src/bindings/ScriptDev2 - but also possible that they have changed this.

And be sure to open the project by double-clicking src/bindings/ScriptDev2/scriptVC100 [.sln]

Also the mangos dir should be places in a ascii/dos styled path. (no blancs, no accents and similar)

Nothing happens when I double click it for some reason. While searching for help, I noticed a couple other people talk about this as well (it's Scriptdev0 in this case since I'm working with MangosZero). Is that an issue? I've just been right clicking and going to open with: VS2010 since double clicking doesn't open anything.

I had the folder on my desktop, but have since moved it into C:/ but unfortunately get the same result. I am still having to right click Open with: however.

Is it indicative of something being wrong that I can't just double click to open scriptVC100.sln?

EDIT: Just changed the default program from the Visual Studio selector to VS2010 itself. Double clicked to open and getting the same errors ugh. The complete path by the way is C:/Mangos Files/trunk/src/bindings/scriptdev0/trunk/scriptvc100.sln

Link to comment
Share on other sites

Are you sure blanks cause trouble? I have a long-term project in VS2005 Pro and the path has numerous spaces in it. I have never had an issue due to the spaces. In fact, my only issues arise when I get close to building a test (the project uses OpenGL and OpenAL and I love testing it) and I get into a hurry and make a typo or something. Does this mean that VS2008 and/or VS2010 have gone back to DOS as far as paths are concerned?

His problem to me would seem that he did src/bindings/dev0. I run a Zero server and that is NOT correct. The correct path in Linux is src/bindings/ScriptDevZero. In Windows this could be src/bindings/scriptdevzero due to case not being an issue, but the cmake stuff expects it to be spelled that way.

Link to comment
Share on other sites

To the best of my knowledge, MS Windows handles spaces quite well, as does Visual Studio. However, some software does not, but those are usually Win32 ports of Unix or Linux. Of course, one must keep in mind that MaNGOS is developed in Linux and Windows, so it may inherit some Linux conventions for naming.

The ScriptDevZero project was moved to MaNGOS-Zero and has been renamed to ScriptDev0. The current VC++ solution files and CMake use relative pathing, so I'm not sure there's any necessity for an exact name format, other than those required by the OS. However, the conf file still expects the database to be named scriptdevzero.

Link to comment
Share on other sites

Still seems odd. I checked and the path was ScriptDevZero, not dev0. To me, that seems like the problem. As a cross-platform developer myself I highly doubt the space was the issue, but in the programming world I have seen stranger, and I have spent days on strange problems.

Link to comment
Share on other sites

  • 1 month later...

I'm currently getting this issue, however my path to scriptVC100.sln is:

"D:\\source\\MangosZero\\src\\bindings\\scriptdevzero"

Error 1 error MSB6006: "cmd.exe" exited with code 3. C:\\Program Files (x86)\\MSBuild\\Microsoft.Cpp\\v4.0\\Microsoft.CppCommon.targets 151 6 ScriptDev0

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use