|
Pygmalion -> RE: Database Boundaries - A Modest Proposal (11/24/2021 2:07:26 AM)
|
quote:
ORIGINAL: Scorpion86
Yeah, as many of you noted, I also figured that it would be a disproportionate ammount of work for little benefit. But I can't help but feel that the current break year between databases, the units that are duplicated from CWDB to DB3K, and the predominance of late 80's "Cold War Gone Hot" scenarios makes so the CWDB is underused and relatively negleted. We had all DB3K updates from 478 to 492, while CWDB skipped directly from 478 to 491, and with lots of aircraft deleted...
I'd like to again clarify that nothing has been deleted from the CWDB. Nothing is ever deleted from either database. The issue with the missing aircraft comes from a missing enum value (for the US Army Air Forces, to be exact) that causes an error when aircraft assigned to that operator service are called, and has been fixed for 492.
I'll also say that there were certain factors outside of our control which made it impossible for us to work with CWDB for several cycles. It has not been neglected because we don't care about it as much as DB3K. My team and I love the CWDB and are ecstatic to be working with it again. In fact, it was CWDB work that brought me on with Matrix/WS in the first place!
491, our return-to-regular-cycle for CWDB, was primarily focused on fixing an enormous number of bugs and errors (~40,000, IIRC) that had accumulated over time -- and, as evident from the aforementioned enum bug, as well as other recent reports, it's clear we've not quite dealt with everything CWDB has to throw our way just yet. (We also inevitably introduced some new bugs in trying to fix the old ones. We're working on those, too.) Once we've squashed the new wave and things settle down a little, however, we plan to turn our focus with CWDB fully towards new additions, with concurrent releases continuing alongside DB3K.
Regarding the original topic of a date split, I'm actually quite sympathetic to this suggestion. Although, as other users have mentioned, the enormous amount of work (and issues with backwards compat) makes a change to the current date boundaries unlikely, creation of a "DB4K" incorporating contemporary features (not to mention a lot of backend fixes and improvements that would make life easier for anyone editing the DB) is something that's come up a few times in discussion.
Of course, that's a long way off -- if coming at all -- and, as raised by Boogabooga, will likely depend significantly on demand/requirements of Pro users. But your suggestions have been noted, and I hope one day when the winds are right we can do something about it! [:)]
|
|
|
|
