2008-03-31
The monthly news about my progress working on NL2 turned out very short for this March. The reason is that I was not able to work for the last 3 weeks because of health problems. A couple of days ago I started to work again, but right now I am able to work a couple of hours per day, only. Hopefully I will be able to report more pleasant news next month. There is not much to tell about NL2 at this point, except for that most parts of the file handling will be changed compared to NL1.x. Instead of a global folder for tracks, objects and environments, NL2 will use a project based folder architecture which means that each track is stored in a separated folder with all the resource-files required by the track (custom cartextures, scene-objects etc.) located inside. Project folders can be compressed from within the application to a single package file. Users are not required to uncompress a package file unless they want to change its content. I guess this is the most universal way to handle it without the problems NL1.x has, like file-name conflicts, requirement of additional packaging tools and file access rights issues.
The monthly news about my progress working on NL2 turned out very short for this March. The reason is that I was not able to work for the last 3 weeks because of health problems. A couple of days ago I started to work again, but right now I am able to work a couple of hours per day, only. Hopefully I will be able to report more pleasant news next month. There is not much to tell about NL2 at this point, except for that most parts of the file handling will be changed compared to NL1.x. Instead of a global folder for tracks, objects and environments, NL2 will use a project based folder architecture which means that each track is stored in a separated folder with all the resource-files required by the track (custom cartextures, scene-objects etc.) located inside. Project folders can be compressed from within the application to a single package file. Users are not required to uncompress a package file unless they want to change its content. I guess this is the most universal way to handle it without the problems NL1.x has, like file-name conflicts, requirement of additional packaging tools and file access rights issues.