Hi, I have purchased a number of books regarding the Soviet armed forces and I am planning to make a number of requests for corrections to existing units in the game that have errors, as well as request new units.
However, I am unsure how to go about this.
A have a few questions-
1. What is the best format for requesting changes? Is there a certain format that is preferred?
2. What is the best format for making new unit requests? Is there a certain format that is preferred?
3. What information do you guys require for new unit requests? Just the name? The "visible" parameters that can be seen in the database? Or more? Also, what information do you guys "want" for new unit requests (ideally)?
4. There are certain cases where some units have to be "changed fundamentally". For example, the Tu-95M apparently is a conventional bomber, while the Tu-95MA is the nuclear capable basic production version. So should I request for the Tu-95M to have all nuclear weapons be removed and request a new unit called the Tu-95MA? Or should I request for the Tu-95M to be renamed Tu-95MA, and request a new unit called the Tu-95M that does not have nuclear weapons.
5. What is your stance on hypothetical loadouts? For example, the Tu-95M in the game currently has access to the Tsar Bomba. This would have been a pretty impractical weapon. Even for large population centers like London and Paris it would still be overkill. It was, however, briefly under consideration for small scale production (it would have not been usable against the US, but would technically work in Europe). Therefore it could be included as a "hypothetical loadout". Is the unit marked as hypothetical as well? Regardless, if I am to request a hypothetical loadout, which is exclusively hypothetical (the unit itself that carries it is not changed in any way) do I request a new unit or do I just request it as a new loadout for the "regular" unit?
6. What is your stance on the naming conventions of certain units and weapons? For example, the Tsar Bomba is currently named "AN.206 Nuclear Bomb [Tsar Bomba]". I think this should be changed to "RDS-220 50mt Nuclear Bomb [Tsar Bomba]" or something similar to that, as the "RDS" designation is more well known for Soviet nuclear bombs in general. Also, the yield would be nice to see when selecting the loadout as opposed to having to separately open the database. Is a request like this reasonable?
7. What is your stance on removing loadouts? For example, the 350kt bomb the Tu-4A has is completely unhistorical and thus it should be removed and replaced with the correct loadouts. This could mess up existing scenarios as far as I know however. Is this type of request acceptable?
8. How many requests do you "accept"? That is, for example, there a number of interesting Tu-16 variants, that saw service in some capacity, and thus in order to make a fully accurate order of battle for a certain scenario, they could be included. However, realistically, it is unlikely people will make such a scenario immediately, and, even though they did see service, it was in much more limited numbers compared to the "premier" Tu-16 variants. So should these be requested later when I do make the scenario? Or should I make one set of requests that are more "priority", fixes to existing Tu-16s in the game and missing major Tu-16 variants, and then make a set of requests that are more "low priority", things like Tu-16 variants that were produced in smaller numbers but are the nonetheless interesting and could be important to scenarios.
9. What is your stance on hypothetical requests? Are there limits to what you accept? For example, there was a seriously designed Tu-4 interceptor variant. Tests with the missiles were even conducted before it was cancelled. Would something like this be acceptable (it would be interesting to see it in action)? Also, would hypothetical units be requested as part of a "low priority" series of requests? Or do you only accept hypothetical requests on a "case by case" (that is, when people need them for scenarios) basis as opposed to having them all requested simply because they could have existed?
10. What is your stance on renaming hypothetical units? For example, the anti-submarine warfare variant of the Tu-91 carrier based strike aircraft in the game is called "Tu-91, Anti-Submarine Warfare" or something similar. However, had the Tu-91 ASW variant been built, it may have been designated "Tu-91PLO". PLO was the suffix often applied to ASW variants of aircraft that were not purpose built for ASW work. Would this sort of request be acceptable, despite not being technically historical?
I know this is alot of questions but it would be nice to have this cleared up, in order to avoid causing problems for the database managers. Also, I would like to make efficient requests, not providing too much info, not providing too little, and not making requests that will be automatically rejected anyways, and also, making requests that are as easy to understand as possible, not making them in a messy manner.
Some questions about making database requests
Moderator: MOD_Command
-
SunlitZelkova
- Posts: 334
- Joined: Tue Mar 06, 2018 11:49 pm
Some questions about making database requests
Formerly known as Project2035, TyeeBanzai, and FlyForLenin
RE: Some questions about making database requests
there is a thread for db updates here: tm.asp?m=3436106
in my opinion it is a mess, looks out of control to me, but in the context of a forum I suppose it is one way to do it.
I think you have good questions, I think the db additions/changes would be better handled in some other fashion - like an issue on Github - I think you can setup issues to be like a form so you can require people to submit certain info. Each issue could be its own db item, allowing a conversation about that item to be in one place and then be closed when done or they decide not to pursue it. Seems like that would be easier for the devs, but more of a pain for users as GH is a separate site with a separate login (that could be a good thing though).
As for changes affecting an existing scen, I think that is why the dbs are versioned - so new changes in a new db won't change an older scen linked to an older db. At least that is my understanding.
Anyway you look at it I would think there is an endless number of possible db changes, and I don't think it is an easy thing to accomplish. Would be cool if there was some sort of volunteer effort that could help but even that would still need review and probably a fair amount of work to setup.
in my opinion it is a mess, looks out of control to me, but in the context of a forum I suppose it is one way to do it.
I think you have good questions, I think the db additions/changes would be better handled in some other fashion - like an issue on Github - I think you can setup issues to be like a form so you can require people to submit certain info. Each issue could be its own db item, allowing a conversation about that item to be in one place and then be closed when done or they decide not to pursue it. Seems like that would be easier for the devs, but more of a pain for users as GH is a separate site with a separate login (that could be a good thing though).
As for changes affecting an existing scen, I think that is why the dbs are versioned - so new changes in a new db won't change an older scen linked to an older db. At least that is my understanding.
Anyway you look at it I would think there is an endless number of possible db changes, and I don't think it is an easy thing to accomplish. Would be cool if there was some sort of volunteer effort that could help but even that would still need review and probably a fair amount of work to setup.
RE: Some questions about making database requests
There was at one point a guy who had the primary responsibility of keeping up with Database requests,( if you look at the old posts in that thread, you see that happening. I believe he moved on to other things, his responsibility was given to someone else that already had other game responsibilities so the time spent on keeping up with requests and updates has slowed and the organization has suffered as a result.
But yes that thread is where requests should go with some way to demonstrate the accuracy of the change or request (wikipdia on its own is not enough)
I hope this area gets more attention going forward as it's one of my favorite aspects of this sim.
But yes that thread is where requests should go with some way to demonstrate the accuracy of the change or request (wikipdia on its own is not enough)
I hope this area gets more attention going forward as it's one of my favorite aspects of this sim.
-
SunlitZelkova
- Posts: 334
- Joined: Tue Mar 06, 2018 11:49 pm
RE: Some questions about making database requests
Whicker- Thanks for the info about the different DB versions. I didn't think about that. Now that I think about it though, if I am remembering different memories correctly, some small fixes they do do in "normal" game updates, without waiting for the next DB version (for example, something like correcting the fuel load of an aircraft or ship), whereas with removing loadouts and adding new units, they wait for the next DB version.
FTBSS- That is interesting to know about the different DB managers. While for older units it is good to use reliable sources (especially with aircraft from the 40s and 50s, there is tons of "verified" data on their performance, loadouts, and so on), for more modern units sometimes a news report or a page from a random website is the only "source" there is for information. They have said that pictures are the best way to prove things like loadouts, that might be one way they counter the lack of "verified" written information on modern units. But yeah, if possible, requests should have more than Wikipedia as their source.
One of my questions has been more or less answered, thanks for the replies guys!
FTBSS- That is interesting to know about the different DB managers. While for older units it is good to use reliable sources (especially with aircraft from the 40s and 50s, there is tons of "verified" data on their performance, loadouts, and so on), for more modern units sometimes a news report or a page from a random website is the only "source" there is for information. They have said that pictures are the best way to prove things like loadouts, that might be one way they counter the lack of "verified" written information on modern units. But yeah, if possible, requests should have more than Wikipedia as their source.
One of my questions has been more or less answered, thanks for the replies guys!
Formerly known as Project2035, TyeeBanzai, and FlyForLenin
-
Rory Noonan
- Posts: 2418
- Joined: Thu Dec 18, 2014 1:53 am
- Location: Brooklyn, NY
RE: Some questions about making database requests
Hi. I'm the developer who's responsible for DB3k updates. Paul (Sirius) looks after the CWDB.
Great questions, I'll answer them individually.
No particular format for either. What is important is that you're specific about what you want changed (or added) and why. Put as much detail in your request as possible, and format it so it's easy to read. It's easier for me if you have a post for each platform that needs changing or adding, rather than combining them into a wall of text in a single post covering 50 platforms with 100 changes.
References are also important. And I need to be able to verify them. If it's a book a scan of the page you're referring to along with a bibliography/citation would be best. Web sources need to be credible. Photos are great, but only if they're able to clearly portray what you want.
An ideal unit request has all the data that I need to add it, without having to do heaps of independent research, and is easily verifiable. A great place to start would be to cover all the points in the DB Viewer. There is other stuff that needs to be taken into consideration but generally if I have a lot of the points covered in the DB Viewer I can manage the rest on my own.
With this particular example it's probably enough to explain what the problem is and I'll decide how to approach it. It's a human looking at these issues, not an algorithm, so if you run up against something you're not sure about we can work together to get the solution.
Loadouts can be marked as hypothetical without affecting the associated unit. Just request it as a new loadout for the existing unit.
On hypothetical in general; it is a fine balance between adding cool hypotheticals and adding real platforms and loadouts. Rule of cool definitely appliies, but when it comes down to it hypotheticals will always take a back seat to real life additions.
The database currently has over 68,000 individual records and there have been multiple people who've had input to it over its 20+ year lifespan. There's bound to be some variation in naming conventions, and while in a perfect world it'd all be uniform, in this world renaming takes quite a low priority so long as things are not wildly different and they are easily distinguishable.
If you are going to ask for bulk renaming, present it in the following format:
Record Type; DBID; Name; Year In Service; Year out of Service; Country; Service; Comments
e.g.
Aircraft; 999; Example Aircraft; 1985; 0; Armenia; Air Force; 14x, low availability rates
Note that for years in and out of service '0' indicates ongoing or unknown.
Removing stuff is tricky. Best to explain what you want and why, I'll work out how to implement it without breaking stuff.
On average there are 10 posts per week on the DB3k request thread, and most of them are multi-headed requests in that they are asking for multiple changes. DB updates can take upwards of 8 hours each of dev time accounting for verifying, data input, validation, and testing; not to mention some of the admin tasks like logging in our issue tracker and creating changelogs etc.
Since this is a Sisyphean task we have to prioritise. Unfortunately it's not possible to give strict priorities because there's a lot of 'gestalt' in determining priority of requests. In general however, the priorities are along the lines of:
1. Game breakers; problems with existing platforms that make them not work at all in their current state
2. New and notable platforms
3. Corrections to existing platforms that don't cause game breaking problems
4. Scenario designer requests for platforms for particular scenarios
5. The rest
Even with that short description there is quite a bit of variability; with the qualification that 1 will always be first priority, the rest can sometimes shuffle around depending on circumstance. Hopefully it gives you an idea of priorities though.
If it 'adds something' to the game then it's likely to be added. If it's just hypothetical for the sake of it then it's going to be at the bottom of the pile. The problem with hypotheticals is that they're endless; we could add Spitfires armed with Harpoons to the DB but does it actually make the DB more useful or interesting to have that?
This obviously is subjective but while there is no limit to hypothetical platforms, real ones will always take priority.
This is low priority, but if it's quick and easy to do I may just do it to get it off the list.
On the other hand who can say for sure what a hypothetical unit ahould be called, and is the change an improvement or just a subjective whim?
More info is always better than less, however an unformatted wall of information just makes it harder to pick out what's important. As mentioned above, a bullet list of data points from the DB viewer would be the best place to start.
All requests are added to the issue tracker and will in theory be looked at; the closest thing to an 'automatic rejection' is a request that is unclear or unreferenced, or worse, delivered in an abusive manner. Thankfully these are not common.
I suppose a good analogy is visiting the hospital. If you show up to the emergency department with a severed arm, you are going to get seen right away. However if you come in with a cold, you will eventually get seen but the more people that come in with severe injuries and illnesses while you're waiting, the longer you will wait. In the C:MANO context if you report a game breaker we'd aim to have that fixed ASAP, however if you want an esoteric platform added that is not likely to see widespread use then expect to see other more useful changes happen first.
Great questions, I'll answer them individually.
ORIGINAL: FlyForLenin
1. What is the best format for requesting changes? Is there a certain format that is preferred?
2. What is the best format for making new unit requests? Is there a certain format that is preferred?
No particular format for either. What is important is that you're specific about what you want changed (or added) and why. Put as much detail in your request as possible, and format it so it's easy to read. It's easier for me if you have a post for each platform that needs changing or adding, rather than combining them into a wall of text in a single post covering 50 platforms with 100 changes.
References are also important. And I need to be able to verify them. If it's a book a scan of the page you're referring to along with a bibliography/citation would be best. Web sources need to be credible. Photos are great, but only if they're able to clearly portray what you want.
ORIGINAL: FlyForLenin
3. What information do you guys require for new unit requests? Just the name? The "visible" parameters that can be seen in the database? Or more? Also, what information do you guys "want" for new unit requests (ideally)?
An ideal unit request has all the data that I need to add it, without having to do heaps of independent research, and is easily verifiable. A great place to start would be to cover all the points in the DB Viewer. There is other stuff that needs to be taken into consideration but generally if I have a lot of the points covered in the DB Viewer I can manage the rest on my own.
ORIGINAL: FlyForLenin
4. There are certain cases where some units have to be "changed fundamentally". For example, the Tu-95M apparently is a conventional bomber, while the Tu-95MA is the nuclear capable basic production version. So should I request for the Tu-95M to have all nuclear weapons be removed and request a new unit called the Tu-95MA? Or should I request for the Tu-95M to be renamed Tu-95MA, and request a new unit called the Tu-95M that does not have nuclear weapons.
With this particular example it's probably enough to explain what the problem is and I'll decide how to approach it. It's a human looking at these issues, not an algorithm, so if you run up against something you're not sure about we can work together to get the solution.
ORIGINAL: FlyForLenin
5. What is your stance on hypothetical loadouts? For example, the Tu-95M in the game currently has access to the Tsar Bomba. This would have been a pretty impractical weapon. Even for large population centers like London and Paris it would still be overkill. It was, however, briefly under consideration for small scale production (it would have not been usable against the US, but would technically work in Europe). Therefore it could be included as a "hypothetical loadout". Is the unit marked as hypothetical as well? Regardless, if I am to request a hypothetical loadout, which is exclusively hypothetical (the unit itself that carries it is not changed in any way) do I request a new unit or do I just request it as a new loadout for the "regular" unit?
Loadouts can be marked as hypothetical without affecting the associated unit. Just request it as a new loadout for the existing unit.
On hypothetical in general; it is a fine balance between adding cool hypotheticals and adding real platforms and loadouts. Rule of cool definitely appliies, but when it comes down to it hypotheticals will always take a back seat to real life additions.
ORIGINAL: FlyForLenin
6. What is your stance on the naming conventions of certain units and weapons? For example, the Tsar Bomba is currently named "AN.206 Nuclear Bomb [Tsar Bomba]". I think this should be changed to "RDS-220 50mt Nuclear Bomb [Tsar Bomba]" or something similar to that, as the "RDS" designation is more well known for Soviet nuclear bombs in general. Also, the yield would be nice to see when selecting the loadout as opposed to having to separately open the database. Is a request like this reasonable?
The database currently has over 68,000 individual records and there have been multiple people who've had input to it over its 20+ year lifespan. There's bound to be some variation in naming conventions, and while in a perfect world it'd all be uniform, in this world renaming takes quite a low priority so long as things are not wildly different and they are easily distinguishable.
If you are going to ask for bulk renaming, present it in the following format:
Record Type; DBID; Name; Year In Service; Year out of Service; Country; Service; Comments
e.g.
Aircraft; 999; Example Aircraft; 1985; 0; Armenia; Air Force; 14x, low availability rates
Note that for years in and out of service '0' indicates ongoing or unknown.
ORIGINAL: FlyForLenin
7. What is your stance on removing loadouts? For example, the 350kt bomb the Tu-4A has is completely unhistorical and thus it should be removed and replaced with the correct loadouts. This could mess up existing scenarios as far as I know however. Is this type of request acceptable?
Removing stuff is tricky. Best to explain what you want and why, I'll work out how to implement it without breaking stuff.
ORIGINAL: FlyForLenin
8. How many requests do you "accept"? That is, for example, there a number of interesting Tu-16 variants, that saw service in some capacity, and thus in order to make a fully accurate order of battle for a certain scenario, they could be included. However, realistically, it is unlikely people will make such a scenario immediately, and, even though they did see service, it was in much more limited numbers compared to the "premier" Tu-16 variants. So should these be requested later when I do make the scenario? Or should I make one set of requests that are more "priority", fixes to existing Tu-16s in the game and missing major Tu-16 variants, and then make a set of requests that are more "low priority", things like Tu-16 variants that were produced in smaller numbers but are the nonetheless interesting and could be important to scenarios.
On average there are 10 posts per week on the DB3k request thread, and most of them are multi-headed requests in that they are asking for multiple changes. DB updates can take upwards of 8 hours each of dev time accounting for verifying, data input, validation, and testing; not to mention some of the admin tasks like logging in our issue tracker and creating changelogs etc.
Since this is a Sisyphean task we have to prioritise. Unfortunately it's not possible to give strict priorities because there's a lot of 'gestalt' in determining priority of requests. In general however, the priorities are along the lines of:
1. Game breakers; problems with existing platforms that make them not work at all in their current state
2. New and notable platforms
3. Corrections to existing platforms that don't cause game breaking problems
4. Scenario designer requests for platforms for particular scenarios
5. The rest
Even with that short description there is quite a bit of variability; with the qualification that 1 will always be first priority, the rest can sometimes shuffle around depending on circumstance. Hopefully it gives you an idea of priorities though.
ORIGINAL: FlyForLenin
9. What is your stance on hypothetical requests? Are there limits to what you accept? For example, there was a seriously designed Tu-4 interceptor variant. Tests with the missiles were even conducted before it was cancelled. Would something like this be acceptable (it would be interesting to see it in action)? Also, would hypothetical units be requested as part of a "low priority" series of requests? Or do you only accept hypothetical requests on a "case by case" (that is, when people need them for scenarios) basis as opposed to having them all requested simply because they could have existed?
If it 'adds something' to the game then it's likely to be added. If it's just hypothetical for the sake of it then it's going to be at the bottom of the pile. The problem with hypotheticals is that they're endless; we could add Spitfires armed with Harpoons to the DB but does it actually make the DB more useful or interesting to have that?
This obviously is subjective but while there is no limit to hypothetical platforms, real ones will always take priority.
ORIGINAL: FlyForLenin
10. What is your stance on renaming hypothetical units? For example, the anti-submarine warfare variant of the Tu-91 carrier based strike aircraft in the game is called "Tu-91, Anti-Submarine Warfare" or something similar. However, had the Tu-91 ASW variant been built, it may have been designated "Tu-91PLO". PLO was the suffix often applied to ASW variants of aircraft that were not purpose built for ASW work. Would this sort of request be acceptable, despite not being technically historical?
This is low priority, but if it's quick and easy to do I may just do it to get it off the list.
On the other hand who can say for sure what a hypothetical unit ahould be called, and is the change an improvement or just a subjective whim?
ORIGINAL: FlyForLenin
I know this is alot of questions but it would be nice to have this cleared up, in order to avoid causing problems for the database managers. Also, I would like to make efficient requests, not providing too much info, not providing too little, and not making requests that will be automatically rejected anyways, and also, making requests that are as easy to understand as possible, not making them in a messy manner.
More info is always better than less, however an unformatted wall of information just makes it harder to pick out what's important. As mentioned above, a bullet list of data points from the DB viewer would be the best place to start.
All requests are added to the issue tracker and will in theory be looked at; the closest thing to an 'automatic rejection' is a request that is unclear or unreferenced, or worse, delivered in an abusive manner. Thankfully these are not common.
I suppose a good analogy is visiting the hospital. If you show up to the emergency department with a severed arm, you are going to get seen right away. However if you come in with a cold, you will eventually get seen but the more people that come in with severe injuries and illnesses while you're waiting, the longer you will wait. In the C:MANO context if you report a game breaker we'd aim to have that fixed ASAP, however if you want an esoteric platform added that is not likely to see widespread use then expect to see other more useful changes happen first.
-
Rory Noonan
- Posts: 2418
- Joined: Thu Dec 18, 2014 1:53 am
- Location: Brooklyn, NY
RE: Some questions about making database requests
Hey Whicker,ORIGINAL: Whicker
there is a thread for db updates here: tm.asp?m=3436106
in my opinion it is a mess, looks out of control to me, but in the context of a forum I suppose it is one way to do it.
I think you have good questions, I think the db additions/changes would be better handled in some other fashion - like an issue on Github - I think you can setup issues to be like a form so you can require people to submit certain info. Each issue could be its own db item, allowing a conversation about that item to be in one place and then be closed when done or they decide not to pursue it. Seems like that would be easier for the devs, but more of a pain for users as GH is a separate site with a separate login (that could be a good thing though).
As for changes affecting an existing scen, I think that is why the dbs are versioned - so new changes in a new db won't change an older scen linked to an older db. At least that is my understanding.
Anyway you look at it I would think there is an endless number of possible db changes, and I don't think it is an easy thing to accomplish. Would be cool if there was some sort of volunteer effort that could help but even that would still need review and probably a fair amount of work to setup.
We use an in-house issue tracker that functions much like you suggest; while the DB thread may look a mess the raw data from it is split into discrete tickets and we do communicate quite a bit on them.
A form for db requests is something I've considered, but so far I think the investment of time to come up with an elegant solution for a public form would be seriously offset by just doing DB requests as they are done now; after all if something is unclear I can always ask the poster for clarification.
-
michaelm75au
- Posts: 12455
- Joined: Sat May 05, 2001 8:00 am
- Location: Melbourne, Australia
RE: Some questions about making database requests
A note about removing entries.
If an item is removed from a database version, then a scenario based on an earlier database (with the item) can't be upgraded to the latest DB. The scenario won't run properly.
I have seen this with some of the older Community scenarios.
I'm not sure if the database upgrade process has a check for this case now??
If an item is removed from a database version, then a scenario based on an earlier database (with the item) can't be upgraded to the latest DB. The scenario won't run properly.
I have seen this with some of the older Community scenarios.
I'm not sure if the database upgrade process has a check for this case now??
Michael
RE: Some questions about making database requests
Thanks Apache, good to hear, one thing that isn't so great about the way it is in the forum is for users - not easy to tell if your issue has already been asked or not. No big deal to me though,
-
SunlitZelkova
- Posts: 334
- Joined: Tue Mar 06, 2018 11:49 pm
RE: Some questions about making database requests
@apache85, Thanks for the answers!
Formerly known as Project2035, TyeeBanzai, and FlyForLenin
-
SunlitZelkova
- Posts: 334
- Joined: Tue Mar 06, 2018 11:49 pm
RE: Some questions about making database requests
I asked some questions while making a request the other day, but I realized that the DB update request thread was an inappropriate place to post them so I am asking here, along with two new questions-
What is the criteria is for requesting units that have little info about them?
Apparently, the Type 055 destroyer was added to the game when much about it was unknown too, and it was simply given characteristics from the Type 052D as a placeholder. In addition despite much being unknown about the Type 095 SSN, it has been added to the game very recently as well. I am considering requesting the H-20 stealth bomber and the Type 096 SSBN. Based on comparison between the F-22 and the J-20, it might be possible to create placeholder H-20 values by making it a sort of downgraded B-2. In the case of the Type 096, it could be an upgraded Type 094, while there are decently accurate predictions of the range of its new SLBM, the JL-3. When CMANO was first released, 2017, 2018, and 2019 were the "future" for scenarios made at the time of the release. Given the precedent created by the Type 055, I hope it will be possible to have units added with placeholder/estimate values, as the required information may take quite long to (or never) be released in the case of China, due to the geopolitical situation. Especially as the "future" for CMO scenarios becomes the mid and late 2020s.
What your stance on "ultra-hypothetical" units? (can they can be requested or not?)
For example, the possibility of Japan acquiring nuclear weapons and/or ballistic missiles has been raised in recent years due to the threat of North Korea. Many predict a Japanese ICBM would be based on the M-V space launch vehicle. This is where the data values for a hypothetical Japanese ICBM unit could come from. An SSBN could be based on the Soryu class, etc. Suitable placeholder units exist in the DB for the most part, but particularly for the ICBM, a new unit would be better. Of course, the data for the units would be realistic, no record breaking speeds for aircraft, sci-fi weapons, or whatever. And obviously, they would only be requested if someone needed them for a scenario they planned to make.
What is the post format everyone has been using lately to make requests for the DB3000?
I think I saw the person in charge of the database mentioning it made it easier for him. If I that format makes processing requests easier for the devs, I would like to learn how to use it.
Is it possible to request "placeholder" units that feature new technology not yet in the game? Namely, HGVs
HGVs are currently limited to the professional edition of the game. However with the introduction of the DF-17 HGV armed ballistic missile in 2019, and, given that the "future" for scenarios is now in the mid to late 2020s (as opposed to having been in the late 2010s when the game was first released) HGVs will become more and more necessary for designing scenarios with an accurate order of battle. Assuming HGVs cannot be added to the commercial version (in the same way built in comms jamming has been denied for the commercial edition despite its presence in the PE) would it be possible to add placeholder unit? These would technically be normal ballistic missiles, just with a very high speed to prevent interception (and thus would not behave like HGVs, such as having their flight profile, etc.). This would allow the addition of HGVs in the commercial version without having to actually add the HGV mechanics into the game.
EDIT- One more question
What is the criteria is for requesting units that have little info about them?
Apparently, the Type 055 destroyer was added to the game when much about it was unknown too, and it was simply given characteristics from the Type 052D as a placeholder. In addition despite much being unknown about the Type 095 SSN, it has been added to the game very recently as well. I am considering requesting the H-20 stealth bomber and the Type 096 SSBN. Based on comparison between the F-22 and the J-20, it might be possible to create placeholder H-20 values by making it a sort of downgraded B-2. In the case of the Type 096, it could be an upgraded Type 094, while there are decently accurate predictions of the range of its new SLBM, the JL-3. When CMANO was first released, 2017, 2018, and 2019 were the "future" for scenarios made at the time of the release. Given the precedent created by the Type 055, I hope it will be possible to have units added with placeholder/estimate values, as the required information may take quite long to (or never) be released in the case of China, due to the geopolitical situation. Especially as the "future" for CMO scenarios becomes the mid and late 2020s.
What your stance on "ultra-hypothetical" units? (can they can be requested or not?)
For example, the possibility of Japan acquiring nuclear weapons and/or ballistic missiles has been raised in recent years due to the threat of North Korea. Many predict a Japanese ICBM would be based on the M-V space launch vehicle. This is where the data values for a hypothetical Japanese ICBM unit could come from. An SSBN could be based on the Soryu class, etc. Suitable placeholder units exist in the DB for the most part, but particularly for the ICBM, a new unit would be better. Of course, the data for the units would be realistic, no record breaking speeds for aircraft, sci-fi weapons, or whatever. And obviously, they would only be requested if someone needed them for a scenario they planned to make.
What is the post format everyone has been using lately to make requests for the DB3000?
I think I saw the person in charge of the database mentioning it made it easier for him. If I that format makes processing requests easier for the devs, I would like to learn how to use it.
Is it possible to request "placeholder" units that feature new technology not yet in the game? Namely, HGVs
HGVs are currently limited to the professional edition of the game. However with the introduction of the DF-17 HGV armed ballistic missile in 2019, and, given that the "future" for scenarios is now in the mid to late 2020s (as opposed to having been in the late 2010s when the game was first released) HGVs will become more and more necessary for designing scenarios with an accurate order of battle. Assuming HGVs cannot be added to the commercial version (in the same way built in comms jamming has been denied for the commercial edition despite its presence in the PE) would it be possible to add placeholder unit? These would technically be normal ballistic missiles, just with a very high speed to prevent interception (and thus would not behave like HGVs, such as having their flight profile, etc.). This would allow the addition of HGVs in the commercial version without having to actually add the HGV mechanics into the game.
EDIT- One more question
Formerly known as Project2035, TyeeBanzai, and FlyForLenin
-
Rory Noonan
- Posts: 2418
- Joined: Thu Dec 18, 2014 1:53 am
- Location: Brooklyn, NY
RE: Some questions about making database requests
SunlitZelkova, we meet again [:)]ORIGINAL: SunlitZelkova
I asked some questions while making a request the other day, but I realized that the DB update request thread was an inappropriate place to post them so I am asking here, along with two new questions-
What is the criteria is for requesting units that have little info about them?
Apparently, the Type 055 destroyer was added to the game when much about it was unknown too, and it was simply given characteristics from the Type 052D as a placeholder. In addition despite much being unknown about the Type 095 SSN, it has been added to the game very recently as well. I am considering requesting the H-20 stealth bomber and the Type 096 SSBN. Based on comparison between the F-22 and the J-20, it might be possible to create placeholder H-20 values by making it a sort of downgraded B-2. In the case of the Type 096, it could be an upgraded Type 094, while there are decently accurate predictions of the range of its new SLBM, the JL-3. When CMANO was first released, 2017, 2018, and 2019 were the "future" for scenarios made at the time of the release. Given the precedent created by the Type 055, I hope it will be possible to have units added with placeholder/estimate values, as the required information may take quite long to (or never) be released in the case of China, due to the geopolitical situation. Especially as the "future" for CMO scenarios becomes the mid and late 2020s.
What your stance on "ultra-hypothetical" units? (can they can be requested or not?)
For example, the possibility of Japan acquiring nuclear weapons and/or ballistic missiles has been raised in recent years due to the threat of North Korea. Many predict a Japanese ICBM would be based on the M-V space launch vehicle. This is where the data values for a hypothetical Japanese ICBM unit could come from. An SSBN could be based on the Soryu class, etc. Suitable placeholder units exist in the DB for the most part, but particularly for the ICBM, a new unit would be better. Of course, the data for the units would be realistic, no record breaking speeds for aircraft, sci-fi weapons, or whatever. And obviously, they would only be requested if someone needed them for a scenario they planned to make.
What is the post format everyone has been using lately to make requests for the DB3000?
I think I saw the person in charge of the database mentioning it made it easier for him. If I that format makes processing requests easier for the devs, I would like to learn how to use it.
Is it possible to request "placeholder" units that feature new technology not yet in the game? Namely, HGVs
HGVs are currently limited to the professional edition of the game. However with the introduction of the DF-17 HGV armed ballistic missile in 2019, and, given that the "future" for scenarios is now in the mid to late 2020s (as opposed to having been in the late 2010s when the game was first released) HGVs will become more and more necessary for designing scenarios with an accurate order of battle. Assuming HGVs cannot be added to the commercial version (in the same way built in comms jamming has been denied for the commercial edition despite its presence in the PE) would it be possible to add placeholder unit? These would technically be normal ballistic missiles, just with a very high speed to prevent interception (and thus would not behave like HGVs, such as having their flight profile, etc.). This would allow the addition of HGVs in the commercial version without having to actually add the HGV mechanics into the game.
EDIT- One more question
Criteria for requesting units that have little info: Request away, but be prepared to have placeholders and calculated/derived data points rather than sourced data, as there is no source. Probability of being added is related to how useful the DB item would be (and to a lesser but significant extent, how cool it is), effort to add, details provided and chances of more information coming to light. Feel free to suggest placeholders in the request.
Stance on ultra-hypothetical: Rule of cool applies more so than above, but otherwise pretty similar position.
The post format: That's something I've been using to automate logging and recording the DB requests. It works great, but it looks pretty janky. Something better is on the way now that I'm back from holiday break [:)] Feel free to use it if desired, or ignore it completely: the automation works without it, but the formatting makes everything run much smoother.
HGV placeholders: The Professional and Retail/Commercial versions of Command both use the same database files; the ability to *use* the database items is governed by game code and doesn't have much to do with the DB files. Because of this, there's no need for us to add placeholders for DB items that will come to Civ eventually, as they're the same DB entries and are unlocked via code.
-
Rory Noonan
- Posts: 2418
- Joined: Thu Dec 18, 2014 1:53 am
- Location: Brooklyn, NY
RE: Some questions about making database requests
ORIGINAL: Whicker
Thanks Apache, good to hear, one thing that isn't so great about the way it is in the forum is for users - not easy to tell if your issue has already been asked or not. No big deal to me though,
Thank you for reminding me of this; I'm working on a solution for that!
-
SunlitZelkova
- Posts: 334
- Joined: Tue Mar 06, 2018 11:49 pm
RE: Some questions about making database requests
Thanks for the answers!
Formerly known as Project2035, TyeeBanzai, and FlyForLenin
-
caohailiang
- Posts: 48
- Joined: Sun Jun 07, 2020 10:17 am
RE: Some questions about making database requests
Hi Rory,
I know you are probably quite busy handling these new DB requests, but if i may ask what would be the usual lead time for an item to be added? or if one can know the status of the request, is it rejected or accepted, or just in the queue?
for example if you would kindly look at these 2 posts about 3 weeks ago:
Post #: 6670
Post #: 6671
maybe more info is needed?
First time i put out new request to the DB, appreciate your guidance!
//Hailiang
I know you are probably quite busy handling these new DB requests, but if i may ask what would be the usual lead time for an item to be added? or if one can know the status of the request, is it rejected or accepted, or just in the queue?
for example if you would kindly look at these 2 posts about 3 weeks ago:
Post #: 6670
Post #: 6671
maybe more info is needed?
First time i put out new request to the DB, appreciate your guidance!
//Hailiang
RE: Some questions about making database requests
ORIGINAL: caohailiang
Hi Rory,
I know you are probably quite busy handling these new DB requests, but if i may ask what would be the usual lead time for an item to be added? or if one can know the status of the request, is it rejected or accepted, or just in the queue?
for example if you would kindly look at these 2 posts about 3 weeks ago:
Post #: 6670
Post #: 6671
maybe more info is needed?
First time i put out new request to the DB, appreciate your guidance!
//Hailiang
Based on personal experience only:
Generally there is no time frame for when, and sometimes its not at all. Foremost its a request for the DB editors for an update for their consideration not an instruction.
The DB doesn't get updated as often as the sim mechanics so the updates are saved up and bulk released not trickled out.
Usually if its an error in the DB which is causing the DB to freak out and crashes it gets fixed quickly,
If it people having OCD about something trivial eg the Vikhr ATGW having the correct product code (9M127 not 9M120) then possibly never. [:D]
If its a significant new capability for a key platform from a major country in strategic power terms then probably sooner rather than later.
Hope this vagueness is something of by way of an answer.
K
RE: Some questions about making database requests
Hey there,
could someone post a summary of the DB request post's format here ? Pretty please.
I haven't been able to find the post in which it's explained.
PS: does Paul also prefer that formatting for CWDB related requests ?
Edit : Nevermind, This is the way : The New DB Request Tracker
could someone post a summary of the DB request post's format here ? Pretty please.
I haven't been able to find the post in which it's explained.
PS: does Paul also prefer that formatting for CWDB related requests ?
Edit : Nevermind, This is the way : The New DB Request Tracker
Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, NVIDIA GeForce GTX 1650 4 Go, Windows 10 64bits, 32 GB RAM, Regional settings = French, Belgium
(Previously known as JanMasters0n)
(Previously known as JanMasters0n)
RE: Some questions about making database requests
<type></type>
<summary></summary>
<detail></detail>
<evidence></evidence>
Generally this format had favour at one point, it seems to vary as to who is doing the updates.
It is an imprecise art
<summary></summary>
<detail></detail>
<evidence></evidence>
Generally this format had favour at one point, it seems to vary as to who is doing the updates.
It is an imprecise art