New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Level save with populated forest results in "FileStream::open::empty filename" #1277

Closed
aurodev opened this Issue Apr 18, 2015 · 6 comments

Comments

Projects
None yet
4 participants
@aurodev

aurodev commented Apr 18, 2015

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");

@crabmusket

This comment has been minimized.

Show comment
Hide comment
@crabmusket

crabmusket Apr 18, 2015

Contributor

Thanks for the report! Is this on the development branch?

Contributor

crabmusket commented Apr 18, 2015

Thanks for the report! Is this on the development branch?

@crabmusket crabmusket added the Bug label Apr 18, 2015

@aurodev

This comment has been minimized.

Show comment
Hide comment
@aurodev

aurodev Apr 19, 2015

I think it was 3.6.3 development.

aurodev commented Apr 19, 2015

I think it was 3.6.3 development.

@crabmusket

This comment has been minimized.

Show comment
Hide comment
@crabmusket

crabmusket Apr 19, 2015

Contributor

Okay, thanks!

Contributor

crabmusket commented Apr 19, 2015

Okay, thanks!

@aurodev

This comment has been minimized.

Show comment
Hide comment
@aurodev

aurodev Apr 19, 2015

yw!
Just now built and tested 3.7 release with the same behavior.
I need to get up to speed and get on the forums.

Perhaps grab the forest "dataFile" somehow from the .mis or %missionFile in main.cs...

Thanks for the hard work guys!

aurodev commented Apr 19, 2015

yw!
Just now built and tested 3.7 release with the same behavior.
I need to get up to speed and get on the forums.

Perhaps grab the forest "dataFile" somehow from the .mis or %missionFile in main.cs...

Thanks for the hard work guys!

@Areloch Areloch self-assigned this Apr 21, 2015

Areloch added a commit to Areloch/Torque3D that referenced this issue Apr 21, 2015

Fixes issue #1277
Adds the file path to the saveDataFile call (missionpath\missionname.forest as the format)
@John3

This comment has been minimized.

Show comment
Hide comment
@John3

John3 Apr 23, 2015

Contributor

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.

forestbug

Edit: I confirm is the same bug.
ForestDataFile::write() - Failed opening stream!

Contributor

John3 commented Apr 23, 2015

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.

forestbug

Edit: I confirm is the same bug.
ForestDataFile::write() - Failed opening stream!

crabmusket added a commit to crabmusket/Torque3D that referenced this issue Apr 27, 2015

Fixes issue #1277
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.
@Areloch

This comment has been minimized.

Show comment
Hide comment
@Areloch

Areloch May 12, 2015

Contributor

Fixed with the assocaited PR. Apparently formatted the comment incorrectly to have github automatically associate them. Closing manually.

Contributor

Areloch commented May 12, 2015

Fixed with the assocaited PR. Apparently formatted the comment incorrectly to have github automatically associate them. Closing manually.

@Areloch Areloch closed this May 12, 2015

@crabmusket crabmusket added this to the 3.7 milestone May 12, 2015

RichardRanft added a commit to RichardRanft/Torque3D that referenced this issue Jul 25, 2015

Fixes issue #1277
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