TGEA 1.8 Beta: Terrain texture paths saving incorrectly
by Jesse (Midhir) Liles · in Torque Game Engine Advanced · 12/05/2008 (10:49 pm) · 29 replies
I'm having an issue with the mission editor's saving of terrain texture pathnames.
I started up the New Mission Template mission in the Stronghold game example.
I opened up the mission editor using F11.
I changed the mission name in the inspector and used Save Mission As... to give it a new filename.
I quit TGEA, reloaded it, and opened up my new mission.
All of the terrain textures loaded black, and the console log gives errors of the following sort for each
texture that has been saved into the .ter file:
ClipMapBlenderCache::registerSourceImage - couldn't locate texture 'D/Dev/Torque/scriptsAndAssets/data/terrains/Test/dirt_grass' for blending.
I am not able to hand-edit the .ter file to see if the problem is with the saving or the loading of the pathnames. As all of the pre-existing missions in the Stronghold demo work I'm assuming this is an error
with the way the terrain editor is saving path information.
I started up the New Mission Template mission in the Stronghold game example.
I opened up the mission editor using F11.
I changed the mission name in the inspector and used Save Mission As... to give it a new filename.
I quit TGEA, reloaded it, and opened up my new mission.
All of the terrain textures loaded black, and the console log gives errors of the following sort for each
texture that has been saved into the .ter file:
ClipMapBlenderCache::registerSourceImage - couldn't locate texture 'D/Dev/Torque/scriptsAndAssets/data/terrains/Test/dirt_grass' for blending.
I am not able to hand-edit the .ter file to see if the problem is with the saving or the loading of the pathnames. As all of the pre-existing missions in the Stronghold demo work I'm assuming this is an error
with the way the terrain editor is saving path information.
#2
12/07/2008 (9:18 am)
And thanks for reporting, of course!
#3
12/28/2008 (2:19 pm)
Rene, this one got fixed in the final 1.8? because it seems like its still there... please let me know, to decide how to proceed, is kind of a showstopper right now; thanx.
#4
This isn't always why it breaks though. I've seen some really wierd paths being saved out that sometimes even mention my drive's root, and finally leads to the incorrect path. Will update this post later.
My first guess was that Torque::Path::MakeRelativePath () is doing something fishy, but it's used elsewhere without problems so it's not obvious what the issue might be. I think I've got this isolated to how the terrain editor handles filenames that are given to it via the file dialogs. For example this section in TerrianFile::save ()
Works as expected, but mMaterialFileName didn't contain the correct path. It contained this:
Which when given to MakeRelativePath () even with the correct terFilePath makes some really odd garbage.
What's also making me confused is how mMaterialFileName [iterator] contains more than one filename? And the first filename in it doesn't have the root drive's letter?
This doesn't happen if I don't resave. Then all is okay but the textures are still black. But as soon as I resave, the strings contain all this garbage.
I'll be back.
Edit: Been sitting trough this all morning and I really can't get my head around it. Somewhere (probably in the editor) a string is "cat" onto another which creates a double path which makeRelativePath can't follow.
I'm going to stop porting for now and work with what works and what I know my way around better. It's so frustrating working with this issue when all I want is to continue with our prototype.
Hoping someone from GG can comment on this when they get back from holidays.
12/31/2008 (2:01 pm)
The paths are saved relative to the terrain file, and when the mission file moves this relativeness might change.This isn't always why it breaks though. I've seen some really wierd paths being saved out that sometimes even mention my drive's root, and finally leads to the incorrect path. Will update this post later.
My first guess was that Torque::Path::MakeRelativePath () is doing something fishy, but it's used elsewhere without problems so it's not obvious what the issue might be. I think I've got this isolated to how the terrain editor handles filenames that are given to it via the file dialogs. For example this section in TerrianFile::save ()
... matRelPath = Torque::Path::MakeRelativePath (mMaterialFileName[k], terFilePath.getPath()); ...
Works as expected, but mMaterialFileName didn't contain the correct path. It contained this:
Quote:
Development/1.8/GameExamples/Stronghold/game/scriptsAndAssets/data/missions/Stronghold/Snow01Colored
C:/Development/1.8/GameExamples/Stronghold/game/scriptsAndAssets/data/missions/Stronghold/path
C:/Development/1.8/GameExamples/Stronghold/game/scriptsAndAssets/data/missions/Stronghold/Dirt01
C:/Development/1.8/GameExamples/Stronghold/game/scriptsAndAssets/data/missions/Stronghold/Snow02Colored
Which when given to MakeRelativePath () even with the correct terFilePath makes some really odd garbage.
What's also making me confused is how mMaterialFileName [iterator] contains more than one filename? And the first filename in it doesn't have the root drive's letter?
This doesn't happen if I don't resave. Then all is okay but the textures are still black. But as soon as I resave, the strings contain all this garbage.
I'll be back.
Edit: Been sitting trough this all morning and I really can't get my head around it. Somewhere (probably in the editor) a string is "cat" onto another which creates a double path which makeRelativePath can't follow.
I'm going to stop porting for now and work with what works and what I know my way around better. It's so frustrating working with this issue when all I want is to continue with our prototype.
Hoping someone from GG can comment on this when they get back from holidays.
#5
I got around it by modifying terrainEditor.ed.cs's ETerrainEditor::changeMaterial function.
Change the lines
into
You have to resave all of your missions/terrains, but it's going to get me through until an official fix.
01/11/2009 (10:58 pm)
Still a problem.I got around it by modifying terrainEditor.ed.cs's ETerrainEditor::changeMaterial function.
Change the lines
// make sure the material isn't already in the terrain. %file = filePath(%file) @ "/" @ fileBase(%file);
into
// make sure the material isn't already in the terrain. // WLS - BEGIN UGLY, UGLY HACK! // %file = filePath(%file) @ "/" @ fileBase(%file); %texPath = filePath( %file ); %pos = strstr( %texPath, $defaultGame ); %texPath = getSubStr( %texPath, %pos, strlen( %texPath ) ); // Hack on Hack %file = %texPath @ "/" @ fileBase( %file ); // WLS - END UGLY, UGLY HACK!
You have to resave all of your missions/terrains, but it's going to get me through until an official fix.
#6
01/22/2009 (4:52 pm)
Are we going to keep getting these kind of threads unanswered by GarageGames?
#7
01/22/2009 (6:00 pm)
And why take the time? They DID after all already get the money out of us, it cost even more for them to offer customer support, even if it is just a few quick minuets. Im actually kinda concerned any other place you spend near $300 for a product, you get a certain level of treatment; i feel like the cash cow who just got milked. Hell I have had better customer support at McDonalds, for $0.99 of my money- whats that tell you?!
#8
01/22/2009 (6:35 pm)
there are bug fixes comming they will just cost the mere amount of the upgrade to T3D and its successor. This thread is just one of the many examples of the bug fixes you will get and get and get.
#9
I think you're overreacting. Read their blogs. Both Matt and Brett said they would release bugfixes before T3D. I just miss the transparency that existed in the 1.7/1.8 betas. I spent several hours trying to hunt down the bug in this case, and eventhough I failed at finding it, it's not something I introduced myself and hence some communication wouldn't hurt.
You guys (GG) used to be so good at marking threads and saying if you intend to work on the issues mentioned. Haven't seen that at all lately. Just saying that I miss it, and I'm extremely offtopic here now so bye bye.
01/23/2009 (2:13 am)
@Caylo:I think you're overreacting. Read their blogs. Both Matt and Brett said they would release bugfixes before T3D. I just miss the transparency that existed in the 1.7/1.8 betas. I spent several hours trying to hunt down the bug in this case, and eventhough I failed at finding it, it's not something I introduced myself and hence some communication wouldn't hurt.
You guys (GG) used to be so good at marking threads and saying if you intend to work on the issues mentioned. Haven't seen that at all lately. Just saying that I miss it, and I'm extremely offtopic here now so bye bye.
#10
Thats not off topic, It is the underline topic of all bug reports! Some Feedback often saves developers 100's(ok many) of hours of work.
You guys (GG) used to be so good at marking threads and saying if you intend to work on the issues mentioned. Haven't seen that at all lately. Just saying that I miss it, and I'm extremely offtopic here now so bye bye.
01/23/2009 (12:37 pm)
overreacting = sarcastically exaggeration, but yet. Thats not off topic, It is the underline topic of all bug reports! Some Feedback often saves developers 100's(ok many) of hours of work.
You guys (GG) used to be so good at marking threads and saying if you intend to work on the issues mentioned. Haven't seen that at all lately. Just saying that I miss it, and I'm extremely offtopic here now so bye bye.
#11
Sorry for tuning in so late. Pretty sure I know why it messes up. Will look into it.
01/23/2009 (1:04 pm)
Sorry for tuning in so late. Pretty sure I know why it messes up. Will look into it.
#12
01/23/2009 (1:08 pm)
!!!
#13
01/23/2009 (1:55 pm)
Most sincere thanks, Rene.
#14
@Stefan
Hey man, don't do this. I owe you (and Novack and anyone else here) an apology for neglecting this for so long and you thank me. Slap me in the face instead :)
01/23/2009 (2:12 pm)
@Stefan
Hey man, don't do this. I owe you (and Novack and anyone else here) an apology for neglecting this for so long and you thank me. Slap me in the face instead :)
#15
First, in tools/missionEditor/scripts/editors/terrainEditor.ed.cs replace the existing ETerrainEditor::changeMaterial method with this:
And in the engine code in gui/missionEditor/terrainEditor.cpp within the setTerrainMaterials console method change the line (2198) that says
to
I tried to break it but so far couldn't get the nice black-terrain effect back. If you have more success, please report.
This time, there won't be a delay...
//EDIT: typo
01/23/2009 (2:39 pm)
Ok, here we go. Two changes.First, in tools/missionEditor/scripts/editors/terrainEditor.ed.cs replace the existing ETerrainEditor::changeMaterial method with this:
function ETerrainEditor::changeMaterial(%this, %matIndex)
{
EPainter.matIndex = %matIndex;
%defaultFileName = EPainter.mat[%matIndex];
if( $Pref::TerrainEditor::LastPath $= "" )
$Pref::TerrainEditor::LastPath = expandFilename("~/data/terrains");
%dlg = new OpenFileDialog()
{
Filters = $Pref::TerrainEditor::TextureFileSpec;
DefaultPath = $Pref::TerrainEditor::LastPath;
DefaultFile = %defaultFileName;
ChangePath = false;
MustExist = true;
};
%ret = %dlg.Execute();
if(%ret)
{
$Pref::TerrainEditor::LastPath = filePath( %dlg.FileName );
%file = %dlg.FileName;
}
%dlg.delete();
if( !%ret )
return;
// Make the absolute filename returned by the dialog (absolute) relative
// to the game directory. Note that while material filenames are stored
// relative to the terrain file *within* the terrain file, they are kept
// relative to the game directory while in-game.
%file = makeRelativePath( %file, getMainDotCsDir() );
// Make sure the material isn't already in the terrain.
for(%i = 0; %i < 6; %i++)
if(EPainter.mat[%i] $= %file)
return;
// Add it to our matrix and update the terrain.
EPainter.mat[EPainter.matIndex] = %file;
%mats = "";
for(%i = 0; %i < 6; %i++)
%mats = %mats @ EPainter.mat[%i] @ "n";
ETerrainEditor.setTerrainMaterials(%mats);
EPainter.setup();
("ETerrainMaterialPaint" @ EPainter.matIndex).performClick();
}And in the engine code in gui/missionEditor/terrainEditor.cpp within the setTerrainMaterials console method change the line (2198) that says
file->mMaterialFileName[i] = fileList;
to
file->mMaterialFileName[i] = String( fileList, len );
I tried to break it but so far couldn't get the nice black-terrain effect back. If you have more success, please report.
This time, there won't be a delay...
//EDIT: typo
#16
Saving and jumping out of the mission and opening it again, the terrain is once again blank.
Anyone else who also tried the fix?
01/23/2009 (4:22 pm)
Changed the script, and the console method line. When I switch material now, all materials turn blank in the window (gray) but the color on the terrain seems to be OK. Only the first material (which also is the one I changed) retains its old name, the others have no name anymore.Saving and jumping out of the mission and opening it again, the terrain is once again blank.
Anyone else who also tried the fix?
Quote:
ClipMapBlenderCache::registerSourceImage - couldn't locate texture 'scriptsAndAssets/data/terrains/Winter/Snow06Colored.pngnscriptsAndAssets/data/terrains/Winter/PatchySnow02ColorednscriptsAndAssets/data/terrains/Winter/Snow01ColorednscriptsAndAssets/data/terrains/orctown/pathnscriptsAndAssets/data/terrains/Winter/Dirt01nscriptsAndAssets/data/terrains/Winter/Snow02Coloredn' for blending.
#18
01/23/2009 (7:24 pm)
Thx Rene!
#19
01/26/2009 (9:31 pm)
Also terrain painting is at 100% blend with no way to change it like TGE.
#20
Thanks for the fix!!
01/27/2009 (12:28 am)
We have this bug too and it is very frustrating, applied your patch and doing some testing.Thanks for the fix!!
Associate Rene Damm