Matrix Games Forums

Okay, since the old H3 community likes to talk about this so much, I've taken David Heath's suggestion to start a new thread and talk about it. Let's talk it to death, shall we? [:D]

Now, let's establish the situation that we are going to discuss. If anyone would like to add a parameter, please throw them on.

Situation:

There is an ANW scenario called SCEN.
It has been written using DATABASE0.
DATABASE0 is a third-party database written by EDITOR.

SCEN consists of two ships in a group on side BLUE and one AIRBASE on the opposing red SIDE.
The ships are CARRIER and FRIGATE.
Aboard the CARRIER is an AIRPLANE.
This AIRPLANE has a choice of two available LOADOUTS:
1) AIM-120 and,
2) Mk82 Bombs

There, now we have a situation with plenty of things that can be changed. Can anyone see anything missing? I've tried to keep it as simple as possible for the novitiates who may be try to follow along.

Anyone have anything else to add to this baseline?

Most in the community are not on board with this theory.

So why not flesh out this example and then we can figure out exactly why it is or is not correct?

Pretty presumptuous to say that you speak for "Most in the community".

[Deleted by Admins]

ORIGINAL: VCDH

Herman, this would require a signifigant amount of disk space for this to happen and it's simply not practical. The whole point of the modular database and the rebuilds feature is to keep one DB for a group of scens. You yourself have balked at using other databases yet you advocate a DB for each and every scenario? You are contradicting yourself. [Emphasis added by HH]

Yes, I get those e-mails too.

Move on from this Herman, it's not going to happen.

Later
D

What the heck are you talking about? I know of no contradiction. Please elaborate.

This is a thread for discussing practical considerations. If there is an error, please indicate where that error exists. I'd certainly like to know where the logic goes astray.

As JPKoester did on the other thread, I think that he already agreed to the technical aspects of the DB arrangements and the limitations / requirements of the Signature feature.

Let's go through the example and you can point out every instance where there is an error in fact and we can test for it. It's all out there for players to test for themselves.

My apologies, the word many would be more appropriate. Not here to flesh out anything, alot of people have already thought these things through. Many I know simply disagree with you, no time for debate and nothing personal. we just disagree. Creative differences are all good!

Look, these user databases are pretty much stand-alone mods, I cannot undue ten years of work in mine to suit your system. Others won't either. An ODB by Dale Hillier "will" ship with 3.7 and without user databases. That is decided.
If you have a user database you created yourself, promote it on it's own merits. That is all any of us are trying to do. We are all in the same boat there.

I just wish we could set aside some of these brewing issues with you shipmate, for the common good. This infighting serves no purpose. I am saying this in public. Creative differences are not a good enough reason to create a rift in the community or should they necessarily be fodder for the public forums.

I have never written you before. Why would I lie to you.

Write me away from the forums at tom_herron2003@yahoo.com

Tom

ORIGINAL: VonTommer

My apologies, the word many would be more appropriate. Not here to flesh out anything, alot of people have already thought these things through. Many I know simply disagree with you, no time for debate and nothing personal. we just disagree. Creative differences are all good!

Look, these user databases are pretty much stand-alone mods, I cannot undue ten years of work in mine to suit your system. Others won't either. An ODB by Dale Hillier "will" ship with 3.7 and without user databases. That is decided.
If you have a user database you created yourself, promote it on it's own merits. That is all any of us are trying to do. We are all in the same boat there.

I just wish we could set aside some of these brewing issues with you shipmate, for the common good. This infighting serves no purpose. I am saying this in public. Creative differences are not a good enough reason to create a rift in the community or should they necessarily be fodder for the public forums.
<< snip >>

I fail to see how the discussion jumped from "How DB changes affect scenarios" to this. However, you seem to view this as an attempt to raise angst or create a rift in the community. I can most assuredly state that this is not the case. This was, and is, meant for civil discussion.

AGSI has decided on a feature implementation. This discussion is meant to delve into the ramifications of that decision and that new feature. This is not unlike a discussion over any new feature. It is not a criticism of anyone or anything.

Just like the use of Copy Protection, some potential customers might want to know what they are getting into. It is neither Evil nor malicious. It is what it is.

This is a practical discussion. What does it do? And how does it work?

We are all just trying to keep positive dialogue going, for the better of all. Dissention is a good thing, but not always. Alot of people would be more helpful to you if your tone was less demanding. Alot of us have paid our dues in spades here. Earn that respect don't demand.

Later friend,

Tom

[Deleted by Admins]

ORIGINAL: hermanhum

As JPKoester did on the other thread, I think that he already agreed to the technical aspects of the DB arrangements and the limitations / requirements of the Signature feature.

Hello Herman,

you managed to come up with a sequence of events in which a database change somehow effects a scneario negatively, so what? All database authors and scenario designers know numerous ways for this to happen, one of them being your example from the previous threat of the database designer removing a unit (which is used in a scenario) from the database. Not surprisingly, there are (and always have been) many ways in which a malicious!!! database author can screw up a scenario that uses his database (after all the scenario depends on the database). These things have been known forever, therefor we don't need to analyse the situation you so adequately lay out above to find out about them.

Since a) all involved people know of the problems and b) database authors and scenario designers usually work closely together this has never been a problem.

The simple facts are:
1. The database is owned by the respective database author and he can do with it as he pleases even if it screws up all scenarios created for that database. (database authors usually don't want to do that, so no problem)
2. The scenarios are the product of the scenario designer who is also responsibe for making it work with the database it was designed to. The scenario designer can update the scenario when a new database version becomes available, however, he may chose not to do so. Now we have tried to make the update process as easy as possible (by implementing the batch rebuild function in the scenario editor), however, from time to time, depending on the changes in the database the update process still might need manual intervention.

If you have ideas on how to improve the batch rebuilder, we want to hear about them and we will consider implementing them. However, in my personal opinion posting the various ways in which a database change can damage a scenario, raising angst for the users who will never have to deal with it is not the way to do it.
1. It is the job of database designers and scenario authors to deal with it
2. even if the user creates his own scenario and wants to update it database changes which will require manual interventiopn are extremely rare - some would even say they don't happen

The fact that no other member of the community that visit this board (numerous very well known database authors and scenario designers included) seems to have a problem with the scenario update tools provided speaks for itself.

Cheers,
JP

Edit: only fixed a typo

ORIGINAL: VCDH

In this thread HERE (the 7th post down), you said:

Even if he has his OWN PERSONAL database, it is not a solution. As he adds / modifies his own database, he is STILL required to update his pre-existing scenarios. Otherwise, they won't run with his latest edited version of his own database. So, in order for someone to enjoy his work, the author is going to need to save both the scenario and the database he used to create it at the same place in order to save himself all the work of constantly updating his work. That's just an immutable fact under the current ANW setup.

On May 15th at 1247 my time, at the request of AGSI, I sent you the ANW DB that I have been working on for the six dedicated MP scenarios. I recieved a reply from at at 1835 my time which was CC'd to AGSI, your buddy Freek Schepers and Vincenzo Beretta where you stated:

I've gotten the ANW Db and have taken a quick look at it. It presents some major problems. I understand your request for more bugs to be reported with it and I will try to do so whenever possible. However, there are some major problems that I feel that I need to point out. I have coloured the pertinent areas in red.

You need to understand that of the guys working together, I am the only one who understands the reference to "Version #s". None of the others has ever bothered to learn the platform editor and there is absolutely no way for them to differentiate between these types of units within the SE. So, to expect anyone to use only 'fixed' units or other descriptions is quite impossible. For myself, the request is very inconvenient, yet barely possible. To ask that I first use the DBE to find fixed units before trying to locate them in the SE is awkward, to say the least.

So you don't want to use the DB that I sent you, yet you have no problem using the PDB. However you espouse that a dedicated DB for each and every released scenario is a requirement?

So just what are you trying to say Herman? I would have figured you'd have learned your lesson after the fisaco at that other forum. It appears that you haven't.

If you require confirmation of this I will gladly send you a copy of this mail.

ORIGINAL: hermanhum
This is a thread for discussing practical considerations.

Your fix is not practical. It will never be implemented. This decision is final.

Holy cow,

Note only do you mix up two different ideas, but you decide to insert a third issue. Okay, let's see if we can unravel this mess, shall we?

I shall refer to this quote as Quote#1:

Even if he has his OWN PERSONAL database, it is not a solution. As he adds / modifies his own database, he is STILL required to update his pre-existing scenarios. Otherwise, they won't run with his latest edited version of his own database. So, in order for someone to enjoy his work, the author is going to need to save both the scenario and the database he used to create it at the same place in order to save himself all the work of constantly updating his work. That's just an immutable fact under the current ANW setup.

This statement was made in a discussion over what happens when changes are made to a database and how it affects any scenario that was made from that same database. This quote was taken from:

http://www.matrixgames.com/forums/tm.asp?m=1128867&mpage=1&#56335;&#57077; #7

It is a practical discussion over cause, effects, and consequences. And, your colleague already confirmed the technical veracity of it on:

http://www.matrixgames.com/forums/tm.asp?m=1128867&mpage=1&#56337;&#56810; #30

So, what's the problem? Have you discovered a technical inaccuracy?



I shall refer to this quote as Quote#2:

I've gotten the ANW Db and have taken a quick look at it. It presents some major problems. I understand your request for more bugs to be reported with it and I will try to do so whenever possible. However, there are some major problems that I feel that I need to point out. I have coloured the pertinent areas in red.

You need to understand that of the guys working together, I am the only one who understands the reference to "Version #s". None of the others has ever bothered to learn the platform editor and there is absolutely no way for them to differentiate between these types of units within the SE. So, to expect anyone to use only 'fixed' units or other descriptions is quite impossible. For myself, the request is very inconvenient, yet barely possible. To ask that I first use the DBE to find fixed units before trying to locate them in the SE is awkward, to say the least.

This was sent in response to a request from Don Gilman to use the ANW/H4DB to report bugs whenever posssible. It was an explanation on how difficult it was for users to re-create bug situations with the official AGSI databases. This was, again, technical response to a request.

How does this correlate in the slightest with:

So you don't want to use the DB that I sent you, yet you have no problem using the PDB. However you espouse that a dedicated DB for each and every released scenario is a requirement?

I did espouse that a dedicated DB / scenario as being the most practical solution in preventing problems.



Lastly, what does this have to do with the price of oranges?

So just what are you trying to say Herman? I would have figured you'd have learned your lesson after the fisaco at that other forum. It appears that you haven't.

VonTommer has politely asked that the incivility and angst not resurface on this forum. It would be nice if that could be true, wouldn't it?

[EDIT] Broken link

ORIGINAL: jpkoester1

you managed to come up with a sequence of events in which a database change somehow effects a scneario negatively, so what? All database authors and scenario designers know numerous ways for this to happen, one of them being your example from the previous threat of the database designer removing a unit (which is used in a scenario) from the database. Not surprisingly, there are (and always have been) many ways in which a malicious!!! database author can screw up a scenario that uses his database (after all the scenario depends on the database). These things have been known forever, therefor we don't need to analyse the situation you so adequately lay out above to find out about them.

<< snip >>

If you have ideas on how to improve the batch rebuilder, we want to hear about them and we will consider implementing them. However, in my personal opinion posting the various ways in which a database change can damage a scenario, raising angst for the users who will never have to deal with it is not the way to do it.

Apologies for the snipping, but I'll answer to the specific points.

Back it up. I made no insinuation about any malicious or negative consequences. The basic fact is this:

If you change a single item in an ANW database (spelling error, punctuation, value...) it has a ripple effect. Good or bad, there is an effect. That is the entirety of the situation.

To jump to the conclusion that all changes are bad or negative is neither implied nor stated. You've already acknowledged this fact.

Now, if you think that it was raised as an attempt to introduce angst for new users, that is simply not correct. However, to say that it will affect few, if any, users is mis-leading and does not present a fair view for any potential players. The effect is there. Attempts at minimalizing and trivializing it are not fair, either. It is what it is.

ORIGINAL: hermanhum

Apologies for the snipping, but I'll answer to the specific points.

Back it up. I made no insinuation about any malicious or negative consequences. The basic fact is this:

If you change a single item in an ANW database (spelling error, punctuation, value...) it has a ripple effect. Good or bad, there is an effect. That is the entirety of the situation.

And my argument is: So what? Of course a database change has an effect on the scenario (otherwise, why change the database if it has no effect). This has always been like this and will always be like this. You are right, the only solution to it is for users to have a seperate database folder for every scenario and never update the respective database or scenarios. Then each scenario with its respective database can remain in a static state. The question is, do people actually want this or do they want to use the most up-to-date database with the most up-to-date scenario so they have the most up-to-date information. We don't believe they want static database and scenario combinations, but every user can sort his databases/scenarios whatever way he pleases, so problem solved for everyone that feels that way.

To jump to the conclusion that all changes are bad or negative is neither implied nor stated. You've already acknowledged this fact.

Now, if you think that it was raised as an attempt to introduce angst for new users, that is simply not correct. However, to say that it will affect few, if any, users is mis-leading and does not present a fair view for any potential players. The effect is there. Attempts at minimalizing and trivializing it are not fair, either. It is what it is.

I don't see your point. Does a database change effect a scenario (if the change involved one of the units included in the scenario)? Sure it does and nobody will deny it. The database is updated to reflect the latest information on any given platform. Do the users of the scenario want the most up-to-date information? We believe so, but even if they don't they can easily keep the old database/scenario combination without any need to update anything.

What do you want to achieve with this thread?

Cheers,
JP

ORIGINAL: jpkoester1

I don't see your point. Does a database change effect a scenario (if the change involved one of the units included in the scenario)? Sure it does and nobody will deny it. [Emphasis added by HH] The database is updated to reflect the latest information on any given platform. Do the users of the scenario want the most up-to-date information? We believe so, but even if they don't they can easily keep the old database/scenario combination without any need to update anything.

What do you want to achieve with this thread?

Cheers,
JP

If you look at the date stamps on this thread, it was started when someone claimed that changes would have little or no effect. This thread was meant to examine, in detail, the effects of different changes to databases and their effect on any ANW scenarios made with them.

You have confirmed the effect of DB changes in other threads [as italicized] and this thread was discontinued until VonTommer re-raised the issue.

Now, everyone agrees that DB changes have consequences, but disagrees with the severity or those effects. Some seem to say that changes are mostly inconsequential and I say that those statements are false and mis-leading.

It seems as though the only way to honestly examine this is with a thorough discussion and examples. Of course, everyone can simply cling to their opinions and not be willing to examine them in the cold hard light of facts, too.

ORIGINAL: hermanhum
If you look at the date stamps on this thread, it was started when someone claimed that changes would have little or no effect. This thread was meant to examine, in detail, the effects of different changes to databases and their effect on any ANW scenarios made with them.

You have confirmed the effect of DB changes in other threads [as italicized] and this thread was discontinued until VonTommer re-raised the issue.

Now, everyone agrees that DB changes have consequences, but disagrees with the severity or those effects. Some seem to say that changes are mostly inconsequential and I say that those statements are false and mis-leading.

It seems as though the only way to honestly examine this is with a thorough discussion and examples. Of course, everyone can simply cling to their opinions and not be willing to examine them in the cold hard light of facts, too.

Hello Herman,

changes in the database can roughly be divided into two categories based on the impact they have on the scenarios:

a) Changes that only affect the balance of a scenario. These are changes easily handled by the scenario rebuild function. Lets say the database author becomes aware that in reality a certain weapon has a greater range than in the database. The database author adjusts his database to reflect that new knowledge. As a result of this adjustment side A of scenario X now has a different chance of winning the scenario. The scenario remains playable, but might become easyer/harder to win. If the scenario designer feels that the new database values change the balance too much he will have to manually edit the scenario (maybe add a unit or remove one) to again reach the difficulty level he had intended. However, this is not necessary for the scenario to continue functioning from the technical point of view. These changed regularly do happen as database authors try to keep up with the most current publicly available information, but they rarely affect a scenario in a way that would require the scenario updater to manually change anything after running the scenario through the rebuilding function. (opinions on this may of course vary, but lack of response leads me to believe it is the overwhelming majority that think this way)

b) Changes that effect the technical playability of a scenario. These changes are not easily handled by the scenario rebuild function and do require the scenario administrator (who does the update) to manually edit the scenario to keep it playable. This might be the above discussed removal of a unit which used in the scenario from the database. In this case the scenario rebuild function can not "guess" which other unit to use in order to replace the lost one. Here the person doing the scenario upgrade will have to manually check the scenario and test it in order to make sure it still works as intended after the rebuilding process. Changes like this are rarely - if ever - made by database authors (because they know very well which changes would cause these problems), and if they are made they are usually publically announced so scenario editors can act accordingly. I fail to see the problem.

Feel free to take apart your example above in order to analyse which changes to a database fall into which category I described. However, the resulty should turn out to be pretty intuitive (remove loadout from db--> b), update weapons range --> a), delete aircraft from db -->b, change sensors on FRIGATE -->a) etc...) and you will only discover what is already widely known in the community.

Unfortunately, I am getting the feeling that you are arguing for arguments sake. You of course are correct in your technical assessment, however, you have not shown in which way any of this will effect the average user in a real life situation (apart from the issue of using the wrong scenario with the wrong datase which we have taken steps to avoid). No other community member seems to be seeing the problem you are seeing either, and until that changes, I will retire myself from this apparently pointless discussion.

Cheers,
JP

ORIGINAL: jpkoester1

<< snipping excellent categorization of Database changes >>

b) Changes that effect the technical playability of a scenario. These changes are not easily handled by the scenario rebuild function and do require the scenario administrator (who does the update) to manually edit the scenario to keep it playable. This might be the above discussed removal of a unit which used in the scenario from the database. In this case the scenario rebuild function can not "guess" which other unit to use in order to replace the lost one. Here the person doing the scenario upgrade will have to manually check the scenario and test it in order to make sure it still works as intended after the rebuilding process. Changes like this are rarely - if ever - made by database authors (because they know very well which changes would cause these problems), and if they are made they are usually publically announced so scenario editors can act accordingly. Emphasis added by HH I fail to see the problem.

<< snip additional categorization of Database changes >>

The categorization of types of Database changes is excellent. However, the characterization that I have highlighted in green is patently false. I am not saying that these are either malicious or malevolent acts. They are changes made in the normal course of Database maintenance.

If you disagree, that's okay. You don't have to believe me or trust me. I am happy to show you each and every instance where this is incorrect. We can do a line-by-line analysis of this and the evidence is all there in black and white, ones and zeroes. Do you want to see the proof of it?

Unfortunately, I am getting the feeling that you are arguing for arguments sake. You of course are correct in your technical assessment, however, you have not shown in which way any of this will effect the average user in a real life situation (apart from the issue of using the wrong scenario with the wrong datase which we have taken steps to avoid). No other community member seems to be seeing the problem you are seeing either, and until that changes, I will retire myself from this apparently pointless discussion.

This is just silly. Argument for the sake of argument. Lots of other things to do with my time. The title of this thread is "Maintenance of ANW scenarios" and not "How DB changes affect users in real life situations." Of course, Mr. Heath has made it abundantly clear that you are free to do this type of discussion, too. Why don't you start it up and I'll join you on your new thread once we finish up the discussion on this one, okay?

Your analysis on the different types of DB changes and how they potentially affect scenarios is good. However, you are really complicating the matter unnecessarily.

Whether or not the change is about Balance or Playability is virtually irrelevant. Yes. Irrelevant.

The simple fact that a Database has changed is the crux of the matter. Once a database base changes, a user of that database must:

1) Load all the scenarios he has written
2) Update all the scenarios he has written [He can use the Scenario Editor, the Scenario Batch Re-Build function, the tooth fairy.... The method is utterly irrelevant. The important fact is it must be done.]
3) Re-post these scenarios [Again, site is irrelevant. Important fact is that it must be done.]

There is no magic button to do these three actions. Whether they are simple or arduous depends on

a) the number scenarios that must be re-processed,
b) the severity of the changes [Balance vs. Playability changes],
c) the time to re-post them, and
d) the frequency of DB changes.

Steps 1 through 3 are unavoidable when using the ANW. If the DB editor so much as changes a single [SPACE] in a DB, any user / designer using that database is going to have to go through Steps #1-3.

So, no need to classify any changes as 'Balance' or 'Playability' types. Just knowing that there are changes is quite sufficient.

So, to make things perfectly clear: if I write a database for the game and build some scenarios for it, every time I add/change even a single character of my database (maybe just to correct a typo) I will have to rebuild all the scenarios I have done and re-upload them on the hosting site - or all the old ones will not work with the newly revised database (the alternative being to upload the correct previous versions of the DB along with the old scenarios and thus having maybe dozens versions of my DB on the site). Have I correctly understood the matter?

Yes.

Of course, there might be other solutions, but, IMO, that is the easiest and most practical.

ORIGINAL: hermanhum

Yes.

Of course, there might be other solutions, but, IMO, that is the easiest and most practical.

Then this should go in the technical FAQ (when there will be one).

[Deleted by Admins]