MC2 Editor

Correct, the editor project is not part of the XNA build projects because Visual C++ Express cannot build them as they require MFC. If you have Visual Studio Standard or Professional you can build the project with no problems. In the Source\Editor folder you will find the projects for building the editor code. Compile both of these: EditorMFC.vcproj and Editores.vcproj and you should be set.

Thanks!

I tried the editor version that comes with the source code release without any modifications and this one crashes with the same error message; might well be not my changes that create the issue; here are two re-occuring error messages:

EXCEPTION : Unknown exception code 0xC0150010 in NTDLL! (+0x42345)
Address : 0x7C943345
Location : NTDLL! (+0x42345)

EXCEPTION : Attempt to write to address 0x06150038 in EDITREL! (+0xBF1ED)
Address : 0x004C01ED
Location : EDITREL! (+0xBF1ED)

Any idea what is going wrong?

I can statrt the editor from the final built folder or copy it into a standard installation of MC2.

I open it ,create new mission (whatever size or base texture: same effect) and give it a name or not, change some parameters or not (no impact at all) and save or save as...==> error message

Any findings? I am stuck with the problem

Sorry for the really long delay with this but I have the proper solution now.

In EditorInterface.cpp go to line 1734 you should see this line of code:

TCHAR *curDirStr = new TCHAR[curDirStrSize];

Change the line to this:

TCHAR *curDirStr = (TCHAR *)gos_Malloc(curDirStrSize);

There's also a crash on exit you may want to fix, in EditorData.cpp goto line 953 you should see this line of code:

land->terrainName = new char[strlen(name2)+1];

Change the line to this:

land->terrainName = (char *)gos_Malloc(strlen(name2) + 1);

You should be all set now, let me know if you continue to have problems!

Thanks!

I just spotted this post.
I hope I misread something, either in your post or in the code itself. If not: are you seriously suggesting to use gos_Malloc to allocate the resource, then pointer (not even array) operator delete function to release it?
There are two valid options for the code here:
1. gos_Malloc / gos_Free.
2. operator new[]() / operator delete[]() (not "operator delete()", "operator delete[]()")..
Using either of "p = new char[ n ]" or "p = gos_Malloc(n)" and later releasing that memory with "delete p;" is obviously an error.
To spell it out:
Never use mismatched resource allocation/release functions.
This also illuminate what I believe to be an oversight in MFCPlatform.cpp. It doesn't implement "operator delete[]()" while GamePlatform.cpp does. Not that it would have helped to fix this case, as the code in EditorInterface was already broken and did not use it, but for completeness and consistency perhaps it should be added?

While on the subject of bugs, I think I encountered one in EditorObjectMgr.cpp. In EditorObjectMgr::init() it opens bldgListFileName ("data\arts\buildings.csv"). Please have a quick look at that one in a text editor. The second line starts with "Streetlight3,-1,". Now see what happens in the loop in init(). It extracts the "building" filename. Fine. Next it extracts the group (number)... that is -1. It then tries to cLoadString() id "IDS_GROUPS + group" (into a 64-byte string, make a note of that too), which (obviously or thankfully, depending on view) doesn't exists. That is a bug in itself, trying to access what this code already should know is an invalid resource.
But it gets better. cLoadString() (MCLib\Utilities.h) calls gos_GetResourceString(), which when it notices this resource doesn't exist sets the string it returns to ""%s:%d Not defined"", with the name of the resource dll potentially way to long fro the reciever to handle.
I suspect it worked during development 'cause it wasn't stored in directories with these pathlengths, but in the default installation directory of this release this string when expanded from gos_GetResourceString() ends up as "z:\mechcommander2 source\finalbuild\editores.dll:10099 Not defined", which is 66 characters. I wonder how it comes noone else encountered this. Shorter installation directory path?
Anyway, with a 66-character string returned, cLoadString() throws a fit as this is larger than the 64 bytes of the buffer provided from EditorObjectMgr::init(), resulting in a STOP.
Almost funny to see the result of this tiny little error in EditorObjectMgr::init() :-)
I suggest wrapping "cLoadString( IDS_GROUPS + group, GroupName, 64, gameResourceHandle );" in EditorObjectMgr::init() in "if ( group >= 0) { }".

EDIT: I'm terribly sorry. This is of course not enough, and will always crash in a debug build with /GZ, and only by pure luck in release mode. The correct code must of course be:

if (group >= 0)
{
cLoadString( IDS_GROUPS + group, GroupName, 64, gameResourceHandle );
}
else
{
GroupName[0] = '\0';
}

Sorry for the inconvenience.


It's only hack, and should e.g. strings in editores.dll be edited this will crash anyway, but at least init() wont any more try to access resource ID's it already knows are not for it to probe.

I'm sorry if it seems like I'm hijacking this thread. I just thought it more appropriate to keep the number of MC2-specific threads as low as possible.
It seems I've stumbled across yet another MC2 Editor bug. When starting the editor and selecting a New Map 60x60, I was more than a bit surprised to see "newmap.tga" ending up at ~9MB while"newmap.burnin.tga" was at the more appropriate size just over 2MB.
Set a breakpoint at CreateScaledColorMap() in EditorData.cpp, and it will all become clear where this bug comes from.
The code unconditionally creates a destination TGA size of the same dimensions as the source JPG, meaning 1536^2. However, even that it does this in error, it only fills the target TGA with 768^2 pixels worth of data (60*12.8 = 768). Then, even that it only used a quarter of the memory allocated, it writes the whole 9MB buffer to disk.
The loop towards the end of the function at first glance doesn't seem to potential memory overrun (like trying to copy 'jpgColorMapWidth * 4' bytes/line into dest), why I currently can't see any other explanation to this than that it's another bug.
Comments?
EDIT: The error is quite simple. It's that it calculates physWidth to be the image width in bytes for a 32-bpp image (4Bpp), but then squares this number too, making it w*h*4*4. The correct fix is to simply replace the two instances of 'physWidth * physWidth' with something more appropriate. 'physWidth * newWidth', or perhaps even 'newWidth * newWidth * 4' to be explicit and help coming generation understand this code quicker.
EDIT2: While at it, perhaps 'image', that becomes allocated from the Heap_TextureOther GOS heap (by the call to DecodeJPG()), also should be released once this function is done with it? Add "void* const pToFree = image;" just after the call to DecodeJPG(), then after "free(tmpImage);", "gos_Free(pToFree);" should be added. While not critical, it's not nice wasting up to ~9MB of the users memory for nothing.
(does it start to seem someone had a somewhat bad day when he wrote that function? :-) )