Added HibernationEntry support

[TKGNET]

As discussed:

• hibernationEntries support added with arkNameCache shuffling
• changed program.cs for testing and singleplayer support
• tested against saves with and without hibarnation

Todo:

• adapt ArkSavegameToolkitNet.Domain to reflect objects in hibernationEntries
• improve performance by parallel execution of hibernation entries (more refactoring needed)

Sugggestions:

• make arkNameCache static (it is in qowyns code already) or move caching to ArkName . Cache can be reset in LoadEverything or Dispose if you are worried about memory, but there are just about 80k entries.
• ArkArchive is tightly coupled to memoryMappedFile. ArkArchive should just depend on fileName and should be interfaced to allow different implementations. F.e. loading the file into a ByteBuffer and using BitConverter methods is definitely faster (~1 second)
• no measurable performance improvements with excludedPropertiesTree
• use an options class to encapsulate savegame options
• a lot of unused code / classes (GameObjectReader?)

Cheers

[tsebring]

Thanks for the contribution! :) Will look at this once I get some more free time.

I have some questions with regards to the suggestions you had.

• What is the purpose of making ArkNameCache static?
• I agree that it would be ideal to have the option to allow different implementations. My testing when originally translating from java showed that MemoryMappedFile was ideal from a performance/memory overhead standpoint. Do you have a comparison to show that ByteBuffer and BitConverter are faster and in which cases?
• ExcludedPropertyTree offer 10-20% performance improvement on large savegames in my testing. Memory footprint is also reduced. How did you test it to reach the conclusion that it offers no improvement?

There are features in the codebase (like streaming using GameObjectReader) that was never finished. This is just a hobby project and I have to prioritize which things to put work into between all projects I work on.

Right now the high priority in ArkSavegameToolkitNet is keeping up with new patches.

[TKGNET]

Hi Tobias, no sweat to integrate this change into your project, just htought it might make it easier for you.

As you already know I used the ArkSavegameToolkitNet library a while ago for a VB.Net project of mine, to read the singleplayer values of structures, creatures and player info.

When studio Wildcard introduced hibernation, it broke the model and I went through the task of a) understanding how ark saved their data (qowyns code and wiki) b) fully port it to a vb solution As I said it runs ok, with and without hibernation saveGames.

I was just piqued about the performance of qowyns java code: I always thought .NET would be more performant then a java solution, so I cleaned up the code and started some benchmarks using the VS profiling tools.

Now to your questions:

1. what is the purpose of making arkNameCache static ? well, I am not a big fan of static classes, but for caches I make an exception. Would it improve performance ? No. But it would put the task generating arkNames solely into one class only, with a single responsibility of creating arkNames and do it as performant as possible. It is more a question of code style than of other uses, everybody might see this different. I just prefer single responsibilities, and dislike shuffling caches around. And if you are concerned about the memory: it is just 80k string entries (which can and should be disposed), I am more concerned about the strings beeing generated by the application and its impact on GC. Do it your way, it was just a suggestion.
2. MemoryMappedFile vs MemoryByteBuffer(java) I agree: memoryMappedFiles are solid, i.e. if you are not concerned about the memory footprint. But there are other valid implementations: f.e. BinaryReader over a fileStream (less memory, worse performance). Nevertheless when I benchmarked the .Net and java solution, it showed GetInt and GetString were the bottlenecks. 3 mio calls is heavy. So I experimented with other solutions , f.e.ByteBuffer and BitConverter methods. More or less the same as the MemoryMappedFile solution (which is cleaner I agree). But in my VB.Net solution the performance was/is much better: gained a second (non concurrent test), which is quite an improvement, though still far from the java implementation. Elapsed tie went down from 3.5 seconds to ~2 seconds. But C# seems to perform better than VB, so I cant say how much performance gain you would get there. And honestly: just to test c# I would have to repeat the refactoring I already did.
3. excludedPropertyTree well I measured it, cant support the 10-20% performance improvement. But as I said: C# and VB might behave different, i.e. in these high throughput scenarios.

And yes, I agree aberration patch is more urgent, so far i have fun playing the game again ;)

cu, pete