-
Notifications
You must be signed in to change notification settings - Fork 1
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
Schematic generation #31
Comments
A preview of the blueprint is also needed as a complementary feature for this update. |
Upon investigation, I have discovered the anatomy of a blueprint. Note that a the header section of a blueprint is mandatory due to the checksum.
Firstly, the following section will be referred to as the header. It contains metadata about the blueprint itself.
The first few comma-separated numbers represents the icon layout and icons. They determine which icon layout, icons, and icon positions to display on the in-game menu. The long number represent the time of creation of the blueprint, in seconds since last epoch. The game version in which the blueprint is created. Lastly, the name of blueprint. However, the name of the file does not need to match the name of the blueprint. For example, the file could be call BP, while the blueprint name is RP. The section is the actual content of the blueprint.
So far, this section contains the building layouts, placements, configuration as well as their coordinates on the planet. The section is encoded using base64. For this section, it is good idea to build and improve upon existing findings; https://github.com/johndoe31415/dspbptk and https://github.com/Wesmania/dspbp. Finally, the last part is the hash.
The hashing algorithm appears to be a modified version of MD5. The hash works by taking the entire content, both header and payload, and append the hash to the end of the string. |
The actual payload base64 encoded and gzipped. As such, it should be decoded using base64, and decompress using gzip. The result is a byte string. It cannot be processed any further, so the only way to progress is to match it with existing byte data of buildings, settings, configation, etc.
After decoding and decompression, the following byte string is obtained:
|
The next step is to interpret the byte stream and understand how it stores the information of a blueprint, which will be the most demanding task of the entire feature. Hopefully, understanding the byte steam will allow me to peek into how a blueprint is generated and create one of my own. Afterward it is just a matter of retracing in the form of compression, encoding, and hashing the stream. |
The last feature to complete this project is an option to build a dynamic blueprint. It is clear that blueprints in Dyson Sphere Program is an encoded string along with some metadata. The metadata is comma-separated, and the actual blueprint information is present as the payload.
Reversing engineering the blueprint encryption and decryption will undoubtedly be the most time consuming part of this feature.
The text was updated successfully, but these errors were encountered: