Issue I'm having: disk space

Hey Fellas,
So, I'm trying to save changes to a route I got off the DLS, and this showed up,
https://imgur.com/a/jCvdr
What do I do?
If you can't see it, it says there is not enough space to save :/
Is that TRZ2010? If so, you probably need to register your version, as this is probably a alternative to DRM and you dont have 2010 in your timeline.

Marcos
 
Check the number of backups under options in the launcher screen. If that's set to the default 7, reduce it to 1 or even 0 and keep manual back-ups of your work. Otherwise chews through disc space in no time. Nice little built in bug which persists even into TANE!
 
Check the number of backups under options in the launcher screen. If that's set to the default 7, reduce it to 1 or even 0 and keep manual back-ups of your work. Otherwise chews through disc space in no time. Nice little built in bug which persists even into TANE!

I wouldn't consider this a bug. It's best to have a lot of backups rather than not enough. Backup data does eat up a lot of space in T:ANE. I recently removed nearly 45 GB of backups due to a large amount of testing I've been doing.

Do I ever go back to previous versions? I sure do because they are a real CYA for a lot of oops, which can be recovered.
 
Undesirable feature, then... :) Seven backups though... it's just way too many as IIRC, it not only backs up your own work but all the accumulated gigs of data acquired from the DLS and other sources. That's a heckuva lot of Gb. All I'm suggesting is the default should be set to 1 as it has a nasty habit of resetting every time the program has a hiccup or does a rebuild.

Perhaps someone could raise the issue in the Dev' forum as it appears to get studiously ignored by N3V whenever mentioned on the main forums.
 
Last edited:
Undesirable feature, then... :) Seven backups though... it's just way too many as IIRC, it not only backs up your own work but all the accumulated gigs of data acquired from the DLS and other sources. That's a heckuva lot of Gb. All I'm suggesting is the default should be set to 1 as it has a nasty habit of resetting every time the program has a hiccup or does a rebuild.

Perhaps someone could raise the issue in the Dev' forum as it appears to get studiously ignored by N3V whenever mentioned on the main forums.

Sure we can raise that up, but then people will complain that the default number of backup days is too low and it needs to be raised up. It's one of those things...

I have actually gone back to previous days in my backups because I completely whiffed something I was working on and had saved over it, and the last time I had worked on the route was a few days before with other stuff in between. Again having the big data safety net is a good thing which does save your butt more often than not, and like any insurance it's does no good when you don't have any. I say this as a former IT guy who was responsible for backing up terabytes of data nightly, and that was incremental backups. Of all the backups I did, I only restored data twice, and both times the files were pretty small compared to the amount of stuff backed up.
 
When the idea was first conceived, most Trainz file sizes could probably be counted in a few Mb if not even Kb. Now we are often looking at 70 - 80 Mb just for a tree.

Can't remember which version this was first adopted, might have been TS2009 but I do remember it being a huge issue. A route I was working on would have difficulty saving and eventually lost the file table entries for much of the texture painting. On checking my HD was down to about 20Mb of free space. After clearing out the Trainz backups and resetting to 0 or 1 I suddenly had gigs of space available again. So I maintain default should be 1 and attempting to set higher should bring up a dialogue box regarding use of disc space. I assume the programmer is capable of doing that. Too late for TANE (probably) but IMHO needs to be implemented for the 2018 re-issue.
 
Very true about the file sizes, but that's true with a lot of data, but everything was relative with hard drives being in the MB sizes and low GB sizes. I had an expensive computer in the 1990s with two Seagate 1 GB hard disks. They were configured as a RAID and had to be matched and synchronized, because the system was used for video editing. Today we have single files which are 1 GB in size and we download 8 times that at a time when we update T:ANE to a new version.

Anyway post the request in the Suggestion Boxcar. Chris W looks there often for stuff and if no mention of it comes up, or it gets lost let me know and I'll reference it in the Trainz Dev forums.

The only thing I wish for the backup situation is restoring data could be a lot easier like it was before. Now we have to fart around with file names, and place them in the editing folder prior to a DBR. Why not build that conversion into the program, and handle that stuff automatically? Not everyone is a geek, though it seems that way sometimes.
 
How do I check my backups?
(Still kinda new to this)

To see how much space is being used:

- Open up File Explorer,
- Open C:\Users\(Your login name)\App Data\Local\N3V Games\TANE\Build xxxxxx\Backups *
- Right-click on the Backups
- Choose Properties to view the total size of the Backups folder.

*If you have more than one Build xxxxxxx, chose the most recent date created since that will be your active one.

To view the contents:

- Open up Backups folder.

There will be folders with dates formatted as YY-MM-DD.

You can delete the oldest ones, or all of them. It's recommended you keep at least the last two folders. Just remember to empty the trash after deleting the data.

To set the backups to a fewer number of days:

- Start T:ANE
- At the Launcher click on Trainz Settings.
- Click on the Dev tab.
- Change the backups number to something less than the default (7).
 
It's in the Options part of the launcher under the Developer tab.

Here is exactly my point though, the setting is tucked away by default people new to the program or (no offence) not particularly computer savvy, are getting whacked by a large proportion of their HD being requisitioned for a precaution they probably don't need!
 
I have a similar problem.
I get the 'can't save because of insufficient disk space' when trying to save one particular layout. Others seem to be OK.
I have altered the backup setting as suggested above and deleted the earlier backups - they only amounted to 0.5Gb. I have tons of disk space!
It's a layout I've brought forward from TRS12, where it works and saves OK. I have deleted missing assets, gone through faulty dependencies etc etc, still no go.
Any bright ideas?
Steve

Update:
Whatever the problem was/is for this particular layout I seem to have come up with a solution. I created a single board layout, saved it (as 'Test', very inventive!) then merged the layout that wouldn't save. I then saved 'Test' and it worked fine. I then saved it under another name, also OK. So that seems to have done it..... hopefully.
Steve
 
Last edited:
Back
Top