The development continues with some difficulties since I wasn’t able to work on TKMap the last few weeks. From now on I will continue and focus on the Alpha release. But this turns out to be even more difficult as I thought. Because I haven’t done much the last time, I forgot the recent changes. Obviously something was strongly damaged the application. I’m currently stuck with an termination of execution which seems to be neither a deadlock nor an unthrown exception. Meanwhile I introduced an enhanced locking algorithm with deadlock detection in order to reduce future risks. Working with multiple threads can be tricky and TKMap won’t shrink in size. So that was definetly a necessary step. I will investigate further the next days what causes this issue.
The most logical solution would be a deadlock because the application gets stuck and does not further execute the initialization code. The strange thing about this is that it gets stuck at a point where it shouldn’t happen. The whole process is relatively simple and does not use any cross-thread resources, so it shouldn’t be possible to deadlock.
I hope this issue can be fixed soon as I was highly motivated for finishing the repository. I enhanced the current version about a FileSystem watcher which should detect any changes made to the local repository. Those are being processed then automatically. I already presented TKMap exclusively on the German game development forums ‘indiedev’ where I discussed a lot about the repositories. I got lots of critics about the initial system how the repository should work. I see that his approach would have been bad and so I decided to use a hybrid technique which uses a database for enhanced metadata storage (like tags or custom attributes) while the repository uses the FileSystem as basic structure. This allows editing of assets externally, moving and deleting them manually and adding them via Drag & Drop in the explorer without interrupting TKMap. Initially it was planned that all assets are being stored in one archive file (for which I developed the WIP file format ‘TAKA’ which allows addition, changing and removing of already existant files without repacking). But this would have cut a lot of features.
The repository detects changes to existing resources, applies those to the database and reloads the resource itself. It then notifies the application about the change which then refreshes and uses the new resource. This allows realtime resource exchanges without having to do anything. Adding new resources will create an entry in the database with some default values which can be changed later. Once you delete a resource the entry won’t get deleted. It is preserved for possible re-addition of that resource. If you add a resource which was added and removed earlier, TKMap prompts you to decide whether you want to reuse those metadata or overwrite them.
Since TKMap is currently broken I can’t test the new additions. I hopefully can do this soon as well as I would love to finish the repository itself. This would be a great step forward.
I’ll report back as soon as I got news – probably when the repository is fully implemented.