Thunderbrd
C2C War Dog
@Reisk@:
You should know that this mod is about 90% less buggy now than it was when it started. We began from a base of AND which had a LOT of little bug issues itself. My point is, debugging and fixing things is just AS important to the team as adding what we feel, personally, is valuable new content.
In many cases, the one who added an element or changed things to generate the bug (which is always a simple oversight in the way something has been done) is the best qualified to fix that bug. No one modder has 100% understanding of what every other modder on the team is doing or has done. Many times, this leads some bugs to a delay in getting resolved because we may be simply trying to figure out first how the bug got introduced - then turning the fix over to the culprit particularly when we aren't very familiar with that portion of the mod ourselves.
Also too, it's like inhaling and exhaling. Inhaling, which in a best case scenario takes place at the end of a release cycle, you spend time fixing until you can't find anything more to fix or what you know remains you know you don't know how to address.
(And that happens a lot for most of us. There's numerous bugs I've tried to address that proved mysterious to me where others were able to either fix them because they repaired something they knew was bugged about their own recent inclusion or a better programmer tracked down the problem.) Bugs can take place in the code, in python, and many mysterious and tough to pin down ones may be introduced in simple XML.
Exhaling, during the beginning-mid segments of the release cycle, you usually start addressing your modding projects that you wanted to work on. In short - adding what you want to bring to the mod.
It's a cycle of modding we all go through. After adding content, we debug that content as much as we can. But then along the way unexpected bug reports come in and we need to address those but during an adding cycle it's very difficult to get to those right away. At least for a code modder. This is because your code set is in the middle of changes that until wrapped up cannot be run. Thus, your ability to respond is frozen until your project is complete.
Once you're complete enough to run you adjustments and have playtested and self-debugged your adjustments of all problems you can find and have merged it in with all the updates the rest of the group has made to the SVN file set since you began your project and added your project to the mix to allign your files with the current SVN, THEN, as in right now for me, you can get back around to addressing everything you've had to shelve until that point.
You fix all you can and once you're out of things to repair you get back to your list of things to adjust or develop on further. In the meantime, we've discussed so many adjustments and modifications to make to existing projects and project goals that if you haven't added more to your plate to do than you've gotten done during this cycle you probably aren't doing it right. lol
We've paused everything to address all bugs we can find as a team before but it leads to much of the team being frozen and has shown us that keeping everyone moving on their own projects is important to the morale of the team and to the continuing life of the project. And it doesn't make debugging any easier either.
I don't know if you've been around for many cycles here but you'll find that we do, as a group, try to address all or at least the vast majority of our known issues before releases. That's the shift that's taking place right now as we prepare for v34's release.
And I'm spending far too much time yackin' about it and not enough time fixin' stuff!
You should know that this mod is about 90% less buggy now than it was when it started. We began from a base of AND which had a LOT of little bug issues itself. My point is, debugging and fixing things is just AS important to the team as adding what we feel, personally, is valuable new content.
In many cases, the one who added an element or changed things to generate the bug (which is always a simple oversight in the way something has been done) is the best qualified to fix that bug. No one modder has 100% understanding of what every other modder on the team is doing or has done. Many times, this leads some bugs to a delay in getting resolved because we may be simply trying to figure out first how the bug got introduced - then turning the fix over to the culprit particularly when we aren't very familiar with that portion of the mod ourselves.
Also too, it's like inhaling and exhaling. Inhaling, which in a best case scenario takes place at the end of a release cycle, you spend time fixing until you can't find anything more to fix or what you know remains you know you don't know how to address.
(And that happens a lot for most of us. There's numerous bugs I've tried to address that proved mysterious to me where others were able to either fix them because they repaired something they knew was bugged about their own recent inclusion or a better programmer tracked down the problem.) Bugs can take place in the code, in python, and many mysterious and tough to pin down ones may be introduced in simple XML.
Exhaling, during the beginning-mid segments of the release cycle, you usually start addressing your modding projects that you wanted to work on. In short - adding what you want to bring to the mod.
It's a cycle of modding we all go through. After adding content, we debug that content as much as we can. But then along the way unexpected bug reports come in and we need to address those but during an adding cycle it's very difficult to get to those right away. At least for a code modder. This is because your code set is in the middle of changes that until wrapped up cannot be run. Thus, your ability to respond is frozen until your project is complete.
Once you're complete enough to run you adjustments and have playtested and self-debugged your adjustments of all problems you can find and have merged it in with all the updates the rest of the group has made to the SVN file set since you began your project and added your project to the mix to allign your files with the current SVN, THEN, as in right now for me, you can get back around to addressing everything you've had to shelve until that point.
You fix all you can and once you're out of things to repair you get back to your list of things to adjust or develop on further. In the meantime, we've discussed so many adjustments and modifications to make to existing projects and project goals that if you haven't added more to your plate to do than you've gotten done during this cycle you probably aren't doing it right. lol
We've paused everything to address all bugs we can find as a team before but it leads to much of the team being frozen and has shown us that keeping everyone moving on their own projects is important to the morale of the team and to the continuing life of the project. And it doesn't make debugging any easier either.
I don't know if you've been around for many cycles here but you'll find that we do, as a group, try to address all or at least the vast majority of our known issues before releases. That's the shift that's taking place right now as we prepare for v34's release.
And I'm spending far too much time yackin' about it and not enough time fixin' stuff!
My reason is a paraphrase of the main (only?) reason to mod any game
. The attitude is the suggested one also.
. I do miss the bug tracker and I was one of the slow ones to catch on to it 
