Level save with populated forest results in "FileStream::open::empty filename" #1277
Comments
|
Thanks for the report! Is this on the development branch? |
|
I think it was 3.6.3 development. |
|
Okay, thanks! |
|
yw! Perhaps grab the forest "dataFile" somehow from the .mis or %missionFile in main.cs... Thanks for the hard work guys! |
Areloch
added a commit
to Areloch/GG-Torque3D
that referenced
this issue
Apr 21, 2015
Adds the file path to the saveDataFile call (missionpath\missionname.forest as the format)
Closed
|
HI, don't know if the same bug, I was playing around t3d 3.7rc with walkabout. Added some trees save the level and the next day I open my level and all trees was gone.
Edit: I confirm is the same bug. |
crabmusket
pushed a commit
to crabmusket/Torque3D
that referenced
this issue
Apr 27, 2015
Adds the file path to the saveDataFile call (missionpath\missionname.forest as the format) This correctly utilizes the forest object's datafile field if it's set. If not, it will create a new forest item with the missionPath\missionName.forest convention. This also removes the checks for the hardcoded "theForest" forest object name, so that if it is renamed for some reason, it doesn't break. Lastly, this corrects a minor semi-related bug, where if you are in the forest editor and have a brush selected, and then click to paint, but no forest object currently exists, it prompts to create one. Once the forest object is created, it would trigger the editor to inspect the newly made forest object. If you attempted to paint the currently selected brush, there was a mis-match in the inspector information, and it would trigger a crash. This has been corrected by re-initializing the forest editor's selected tool mode so it can be utilized immediately after the forest object is created.
|
Fixed with the assocaited PR. Apparently formatted the comment incorrectly to have github automatically associate them. Closing manually. |
RichardRanft
pushed a commit
to RichardRanft/Torque3D
that referenced
this issue
Jul 25, 2015
Adds the file path to the saveDataFile call (missionpath\missionname.forest as the format) This correctly utilizes the forest object's datafile field if it's set. If not, it will create a new forest item with the missionPath\missionName.forest convention. This also removes the checks for the hardcoded "theForest" forest object name, so that if it is renamed for some reason, it doesn't break. Lastly, this corrects a minor semi-related bug, where if you are in the forest editor and have a brush selected, and then click to paint, but no forest object currently exists, it prompts to create one. Once the forest object is created, it would trigger the editor to inspect the newly made forest object. If you attempted to paint the currently selected brush, there was a mis-match in the inspector information, and it would trigger a crash. This has been corrected by re-initializing the forest editor's selected tool mode so it can be utilized immediately after the forest object is created.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When saving a level following addition of trees with the forest brush the editor asserts with "FileStream::open::empty filename".
Even when ensuring an existing forest data file is selected in the inspector and also when previously saving a level with an empty forest successfully.
v.3.6.3 from git
File:
game\tools\forestEditor\main.cs ->
function ForestEditorPlugin::onSaveMission( %this, %missionFile )
{
ForestDataManager.saveDirty();
if ( isObject( theForest ) )
theForest.saveDataFile();
ForestBrushGroup.save( "art/forest/brushes.cs" );
}
Temp Workaround:
Hardcoding a path/filename:
if ( isObject( theForest ) )
theForest.saveDataFile("tempForestFile.forest");
The text was updated successfully, but these errors were encountered: