Database Boundaries - A Modest Proposal

Matrix Games Forums

Forums Register Login Photo Gallery Member List Search Calendars FAQ

My Profile Inbox Address Book My Subscription My Forums Log Out

Database Boundaries - A Modest Proposal

View related threads: (in this forum | in all forums)

Logged in as: Guest

Users viewing this topic: none

Printable Version

All Forums >> [New Releases from Matrix Games] >> Command: Modern Operations series >> Database Boundaries - A Modest Proposal

Page: [1]

Message

<< Older Topic Newer Topic >>

Database Boundaries - A Modest Proposal - 11/22/2021 10:14:14 PM

Scorpion86

Posts: 239
Joined: 2/26/2017
Status: offline

Greetings, fellow CMOers! Glad to see everyone could make it.

What I have to present to you this evening is a suggestion. Nothing urgently needed, just something for our honoured Devs to ruminate on.

As you know, our favorite means of electronic entertainment, a computerized simulation known as "Command: Modern Operations", derives the parameters of the units to be used in such a simulation from two databases: CWDB and DB3K.
CWDB represent units from the earlier stages of the cold war, covering a period of nominally 1946 to 1979, although some units from World War II crept in. The other database, DB3K, covers the last decade of the Cold War, the interregnum between the fall of the Berlin Wall and the War On Terror, and then up to present day and beyond.

I'm not sure, but I'm vaguely aware that these databases derive from a much older game (Larry Bond's Harpoon?) which was released 20 or 30 years ago. Back then, the 1979 cut-off date would've made much more sense. Assume the databases were originally release in the late 90's/early 2000's: the 1979 cut-off date would give a timespan of 33 years for CWDB and 20-something years for then-current units, and some 10 years more for "near-present" units.

Today, if we include units up to 2025, we are covering 46 years in DB3K database, compared to 33 covered by CWDB.

So what do I propose?

Shift the boundary year between CWDB and DB3K to 1999.

Why 1999? Although the Cold War ended in 1989, the great military drawdown afterwards was not sudden. Many cold-warrior planes, ships and missiles still soldiered on for a few years before being retired. Examples include the A-7 Corsair, the A-6 Intruder, the scores of Soviet fighters in former Warsaw Pact nations' inventory. Several vehicle types were retired, and military spending would only ramp up again after the 9/11 attacks.

Moving the boundary year to 1999 would remove unnecessary duplications of units between CWDB and DB3K, make CWDB a true "Cold War" database and give DB3K more space to grow in the future.

Of course, I can't imagine the amount of effort and bugfixing that would be necessary to achieve this, but this was an idea that I was thinking about for a long time and I had to get this off my chest.
I hope you at least ponder this idea.

Best regards, Scorpion86

Post #: 1

RE: Database Boundaries - A Modest Proposal - 11/22/2021 11:07:59 PM

BeirutDude

Posts: 2625
Joined: 4/27/2013
From: Jacksonville, FL, USA
Status: offline

While I see merit in your proposal I suspect this would break many scenarios in the 1980-1999 period which would be looking for units in the DB3K database and not the CWDB. I suspect, at bare minimum, there would have to be overlap of the databases (or even a new "Late Cold War" DB?) to keep those scenarios viable. I suspect any of that would be a nightmare for the Devs.

_____________________________

"Some people spend an entire lifetime wondering if they made a difference. The Marines don't have that problem."
PRESIDENT RONALD REAGAN, 1985

I was Navy, but Assigned TAD to the 24th MAU Hq in Beirut. By far the finest period of my service!

(in reply to Scorpion86)

Post #: 2

RE: Database Boundaries - A Modest Proposal - 11/23/2021 2:42:55 AM

boogabooga

Posts: 457
Joined: 7/18/2018
Status: offline

I don't think it's tenable to shift the boundaries of the current databases, but I think a new DB4K or something for "very" modern that overlaps DB3K would be appropriate. Perhaps from 2005 or so, or even from 2022. I agree that DB3K is feeling very full, and at this point, 1980 can't really be considered "modern". (We are as far from 1980 as 1980 was from Pearl Harbor).

A lot of this DB stuff would be driven by the needs of the Pro users.

< Message edited by boogabooga -- 11/23/2021 2:43:15 AM >

(in reply to BeirutDude)

Post #: 3

RE: Database Boundaries - A Modest Proposal - 11/23/2021 3:56:45 PM

BDukes

Posts: 1695
Joined: 12/27/2017
Status: offline

This would cause bigger problems than what seems to be a somewhat shallow issue. I'd leave things alone and start a new db when it works for the devs and working content creators.

Mike

_____________________________

Don't call it a comeback...

(in reply to boogabooga)

Post #: 4

RE: Database Boundaries - A Modest Proposal - 11/23/2021 4:03:56 PM

KLAB

Posts: 355
Joined: 2/27/2007
Status: offline

The juice is not worth the squeeze.IMHO.

(in reply to BDukes)

Post #: 5

RE: Database Boundaries - A Modest Proposal - 11/23/2021 4:10:51 PM

KnightHawk75

Posts: 1450
Joined: 11/15/2018
Status: offline

quote:

ORIGINAL: KLAB
The juice is not worth the squeeze.IMHO.

^^^^ same IMHO.

(in reply to KLAB)

Post #: 6

RE: Database Boundaries - A Modest Proposal - 11/23/2021 6:37:05 PM

Gunner98

Posts: 5508
Joined: 4/29/2005
From: The Great White North!
Status: offline

quote:

ORIGINAL: KnightHawk75

quote:

ORIGINAL: KLAB
The juice is not worth the squeeze.IMHO.

^^^^ same IMHO.

+1! Especially now that you can parse the DB entries by functional type. DB3K is big but please don't mess with anything that is already done. If a new DB is needed start it at 2025 or 2030, but that will still impact dozens of scenarios.

B

_____________________________

Check out our novel, Northern Fury: H-Hour!: http://northernfury.us/
And our blog: http://northernfury.us/blog/post2/
Twitter: @NorthernFury94 or Facebook https://www.facebook.com/northernfury/

(in reply to KnightHawk75)

Post #: 7

RE: Database Boundaries - A Modest Proposal - 11/24/2021 1:35:16 AM

Scorpion86

Posts: 239
Joined: 2/26/2017
Status: offline

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...

(in reply to Gunner98)

Post #: 8

RE: Database Boundaries - A Modest Proposal - 11/24/2021 2:07:26 AM

Pygmalion

Posts: 26
Joined: 4/14/2020
Status: offline

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!

< Message edited by Pygmalion -- 11/24/2021 2:09:27 AM >

(in reply to Scorpion86)

Post #: 9

RE: Database Boundaries - A Modest Proposal - 11/24/2021 1:27:08 PM

BeirutDude

Posts: 2625
Joined: 4/27/2013
From: Jacksonville, FL, USA
Status: offline

Thanks for your work, it is an absolutely phenomenal database for any wargame/simulation!

_____________________________

(in reply to Pygmalion)

Post #: 10

RE: Database Boundaries - A Modest Proposal - 11/24/2021 3:11:06 PM

BDukes

Posts: 1695
Joined: 12/27/2017
Status: offline

Sounds good. Looking forward to it!

Mike

_____________________________

Don't call it a comeback...

(in reply to Pygmalion)

Post #: 11

RE: Database Boundaries - A Modest Proposal - 11/24/2021 3:18:51 PM

Randomizer

Posts: 1473
Joined: 6/28/2008
Status: offline

quote:

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.

With respect, from a user standpoint this is a distinction without a difference and without a fix, the scenarios which use these assets are still broken.

-C

< Message edited by Randomizer -- 11/24/2021 3:42:39 PM >

(in reply to BeirutDude)

Post #: 12

RE: Database Boundaries - A Modest Proposal - 11/25/2021 12:55:44 AM

Pygmalion

Posts: 26
Joined: 4/14/2020
Status: offline

quote:

ORIGINAL: BeirutDude

Thanks for your work, it is an absolutely phenomenal database for any wargame/simulation!

Thank you on behalf of those that came before me. Still much, much more to do!

quote:

ORIGINAL: Randomizer

quote:

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.

With respect, from a user standpoint this is a distinction without a difference and without a fix, the scenarios which use these assets are still broken.

-C

You're right, of course. I wasn't trying to say that it's not a problem, merely that we didn't intentionally cause it out of some desire to slowly purge the CWDB of its platforms.

As mentioned, we've pushed a fix for 492, which is in final pre-release stage and will go out as part of one of the next public beta releases. Thank you for your patience in the meantime!

(in reply to Randomizer)

Post #: 13

RE: Database Boundaries - A Modest Proposal - 11/26/2021 5:44:46 AM

Scorpion86

Posts: 239
Joined: 2/26/2017
Status: offline

quote:

ORIGINAL: Pygmalion
As mentioned, we've pushed a fix for 492, which is in final pre-release stage and will go out as part of one of the next public beta releases. Thank you for your patience in the meantime!

Good to hear that CWDB was not given up on. The absence of an update for so long was disheartening, but I didn't know CWDB was so bug-ridden. I'll await CWDB492 anxiously!

(BTW, while we're at it, could you look up the F-104S situation? I made a report on it in the CWDB thread years ago. The fighter-bomber version has the radar of the interceptor and the interceptor version has the radar of the fighter-bomber, which coincidentally has less range than the missiles it carries, hobbling it as an interceptor.)

< Message edited by Scorpion86 -- 11/26/2021 5:45:30 AM >

(in reply to Pygmalion)

Post #: 14

RE: Database Boundaries - A Modest Proposal - 11/26/2021 4:12:30 PM

Randomizer

Posts: 1473
Joined: 6/28/2008
Status: offline

quote:

Good to hear that CWDB was not given up on. The absence of an update for so long was disheartening, but I didn't know CWDB was so bug-ridden. I'll await CWDB492 anxiously!

It seems as though the entire CWDB has not received anywhere close to the same level of attention as DB3000. Most of the additions to the broken v491 version were derivatives of existing platforms and the fuel problems with many ships (particularly USN CG and DD/DDG classes) have been reported since CMANO and never fixed. Most of the scenarios that I have written use the CWDB but doing so becomes less fun as years pass with errors carried over from update to update while desirable assets, often requested repeatedly by different players over time, never seem to appear. I get that resources are finite and that modern toys have priority but one can hope that at some point the CWDB gets the love that it deserves.

-C

(in reply to Scorpion86)

Post #: 15

RE: Database Boundaries - A Modest Proposal - 12/15/2021 3:05:03 PM

guanotwozero

Posts: 651
Joined: 12/27/2013
Status: offline

I'm a little curious as to why there are even two different databases, as distinct from a single one with a flag to distinguish different eras if needed. Maybe a performance issue?

(in reply to Randomizer)

Post #: 16