So do you have any particular suggestions on how to break this up? I was just going to break it up into base code changes and content, but it sounds like you want it in smaller pieces then that. I’m not sure how to break up the base changes without having some bugs in the middle.
Try to isolate sections that don’t require other sections and send those first. Then ones that require only those.
For example, when working on Z-levels, I first sent the mapgen/map loading/saving part. It didn’t change mapgen, just optimized it for z-levels.
In your case, you may want to first send the changes that don’t change anything in the game, just prepare for other changes.
For example, isolate just the renames, class/struct changes, direct array reads into getter functions etc. This would be the first PR.
The second would be submap drawing - here you’d change the single tile type into arrays (which at the moment would hold only 1 element each).
Then you could break up “composite map tiles” into multiple tile types. For example, “wasp infested house” into “house” and “wasp infestation”.
Finally you’d have the overmap generation: you could break it up into phases - first terrain phase (ground/water/forest), then cities, then overlays (like wasps).
Don’t be afraid of making a separate branch and selectively importing the changes. Usually the longest part of writing source code is designing it. If you have things figured out, you’ll reintegrate them (copy+paste+adjust) very fast. Starting over again and selectively importing changes will probably improve the quality of your code too.
…Huh. Why didn’t I think of that?
Yeah, that sounds like a good way to proceed.
Coolthulthu not only does awesome stuff, he also gives awesome tips, I see 
Yes indeed, that he does.
Alright, here’s a pull request with only the changes to switch over to using bitset. I’m not entirely sure I did the whole pull request properly, so you might want to examine it closely. If you have any questions or run into any problems, go ahead and tell me.
So now that I have a pull request up, should I wait for it to be merged before I do anything more?
In theory, yeah. Given the 0.C stable pending, this isn’t likely to be immediately merged. Should be able to make a branch from the branch you PR’d and continue working: that would keep all its changes yet permit you to continue.
This.
Learn to git merge and git mergetools.
While doing the z-levels, I created like 6 branches in a “chain”. That way I can easily push each next branch as a PR and it won’t cause conflicts. Git recognizes identical commits in both branches as the same commits.
One thing I didn’t find out is if you can automatically update the newer branches with changes to the older one. I merge the changes from older branches to the newer ones manually.
Well, I had put in the pull request, but it hasn’t been merged and is now incompatible with the next version. Should I fix it up so that it is compatible with 0.C, or should I just wait a bit for development to reach a more stable place?
Waiting on DDA dev to slow down is pretty much an exercise in futility. Better to update and get it in.
I’m going to change quite a bit of map code, but I’ll try to stay away from mapgen.
Update your branches so that they are mergeable.
How good are you with git? Need tips? Git has good utilities to help solve conflicts.
Some more advanced editors have git plugins, and some of those plugins can help you merge, even.
That said, I still recommend SourceTree as the GUI git client, it has excellent merge tools where you can compare line by line…
I’m decent enough with git, and I have the git plugin working with netbeans. I’m on linux, though, so my options for git are somewhat limited.
I’ll take a look at it soon, we usually get jammed up with PRs and conflicts after a release because:
a. exausted from release
b. huge backlog of PRs from the week+ of not merging them
c. lots of conflicts from b