Recent Posts1
Outpost 2 Mapper / Re: Better design for representing OP2 Maps in OP2Utility
« Last post by Vagabond on Today at 11:26:55 AM »Good news! I managed to read an Outpost 2 map to memory and then save it as a new file on hard drive. It is the exact same size as the original and loads properly into Outpost 2! You can see the pull request here: https://github.com/OutpostUniverse/OP2Utility/pull/19
Of course this only happened because Hooman has documented the exact contents of a vol file through his own research. And he provided an example in the old mapper to follow. I just wrote it in C++11/14 style without the COM added in and probably adding my own set of blunders to the process.
I created a merge conflict as well, so this branch will need to be manually merged. I saw the conflict coming, but let it develop so I could try merging them manually using TortoiseGit. Hopefully I don't regret that decision...
The next project will be introducing the enum cellType.
MapWriter currently uses fstream to save the file. Are we interested in this being a more generic StreamWriter? If so, this would be queued behind adding the enum cellType. I'm not sure this is worth our time or not though?
Currently, the MapData class in OP2Utility fairly closely mirrors the actual content of an Outpost 2 map file. We need to decide if we want to break the file into some sort of TilesetManager as the originally mapper did. Since Outpost 2 saves all the tileset and tileGroup information straight in each map file, it is all contained in MapData. We could separate this data off into a TilesetManager instead though. I think there are pros and cons to both methods.
It is nice that MapData currently mirrors the saved map file structure and that it behaves like a map does in Outpost 2 (that the tileset and tileGroup information is embedded and could change for each loaded map). However, a mapper would probably prefer the data to be separate concerns. If they are separate concerns, the mapper will still need to understand that they are really not actually separate so when loading a new map it needs to force changing out the tilesets and tileGroups.
Thanks,
Brett
Of course this only happened because Hooman has documented the exact contents of a vol file through his own research. And he provided an example in the old mapper to follow. I just wrote it in C++11/14 style without the COM added in and probably adding my own set of blunders to the process.
I created a merge conflict as well, so this branch will need to be manually merged. I saw the conflict coming, but let it develop so I could try merging them manually using TortoiseGit. Hopefully I don't regret that decision...
The next project will be introducing the enum cellType.
MapWriter currently uses fstream to save the file. Are we interested in this being a more generic StreamWriter? If so, this would be queued behind adding the enum cellType. I'm not sure this is worth our time or not though?
Currently, the MapData class in OP2Utility fairly closely mirrors the actual content of an Outpost 2 map file. We need to decide if we want to break the file into some sort of TilesetManager as the originally mapper did. Since Outpost 2 saves all the tileset and tileGroup information straight in each map file, it is all contained in MapData. We could separate this data off into a TilesetManager instead though. I think there are pros and cons to both methods.
It is nice that MapData currently mirrors the saved map file structure and that it behaves like a map does in Outpost 2 (that the tileset and tileGroup information is embedded and could change for each loaded map). However, a mapper would probably prefer the data to be separate concerns. If they are separate concerns, the mapper will still need to understand that they are really not actually separate so when loading a new map it needs to force changing out the tilesets and tileGroups.
Thanks,
Brett
)