Reply to Re: Recondite Twenty-Eight: The Sixth Day
If you don't have an account, just leave the password field blank.
About the D-Mod jam & mapping:
For those of you that do not know, the problem with binary files and version control systems (whether we use something as part of github or something else) has historically been conflict resolution.
With text files (such as DinkC text files) a lot of times things get added or changed in different places, so no conflict exists and merges are easy and can be done automatically. Even when two people make their changes in the same area with the same text file(*), resolving the conflicts visually is pretty easy too, if you get both authors to review the changes together.
Changes to different screens within the binary map file would be MUCH harder to identify, isolate and resolve. That being said, it would require an intimate knowledge of how the map file is constructed. However, if someone could develop a platform independent tool that could translate from the binary map file format into a human readable text format (and back again from text to binary), then we MIGHT be able to manage merging map file changes intelligently.
Anyone have any suggestions here? Do we have (or did we have in the past) any tools enough like the one mentioned above? Do we even have something a little bit like that which we could "build on" to get the tool that would be needed?
If not, then the only kind of merging and group work possible would be to have something "on paper or images or such" that would then require resolution and follow through by some agreed-upon-arbitrator-administrator that uses WinDinkEdit as needed. But this could be very awkward. Usually, I design screens in WinDinkEdit at the same time I code, adjusting each to each other on they fly. I suspect this is not uncommon for others as well. If there is no more robust solution for mapping, maybe the best idea would be to start with an existing map from our unfinished dmods section and assign sections of it for different people to work on. Merging would still be a bit clumsy and require an agreed-upon-arbitrator-administrator, but not quite as clumsy or error prone.
(*)Example: two different assignments to the same sound number in start.c, like (a)[load_sound("corkpop2.wav", 52);] and (b)[load_sound("ratdeath.wav", 52);].
For those of you that do not know, the problem with binary files and version control systems (whether we use something as part of github or something else) has historically been conflict resolution.
With text files (such as DinkC text files) a lot of times things get added or changed in different places, so no conflict exists and merges are easy and can be done automatically. Even when two people make their changes in the same area with the same text file(*), resolving the conflicts visually is pretty easy too, if you get both authors to review the changes together.
Changes to different screens within the binary map file would be MUCH harder to identify, isolate and resolve. That being said, it would require an intimate knowledge of how the map file is constructed. However, if someone could develop a platform independent tool that could translate from the binary map file format into a human readable text format (and back again from text to binary), then we MIGHT be able to manage merging map file changes intelligently.
Anyone have any suggestions here? Do we have (or did we have in the past) any tools enough like the one mentioned above? Do we even have something a little bit like that which we could "build on" to get the tool that would be needed?
If not, then the only kind of merging and group work possible would be to have something "on paper or images or such" that would then require resolution and follow through by some agreed-upon-arbitrator-administrator that uses WinDinkEdit as needed. But this could be very awkward. Usually, I design screens in WinDinkEdit at the same time I code, adjusting each to each other on they fly. I suspect this is not uncommon for others as well. If there is no more robust solution for mapping, maybe the best idea would be to start with an existing map from our unfinished dmods section and assign sections of it for different people to work on. Merging would still be a bit clumsy and require an agreed-upon-arbitrator-administrator, but not quite as clumsy or error prone.
(*)Example: two different assignments to the same sound number in start.c, like (a)[load_sound("corkpop2.wav", 52);] and (b)[load_sound("ratdeath.wav", 52);].
