My crazy database idea

[Shemar]

Before I proceed with proposing my solution let me explain the problem.

As I was playtesting one of the scenarios, I noticed that there were AC loadouts whose combat range did not make sense when compared to each other. For example, the loadout with 6 bombs would have ther same combat range as the loadout with 2 bombs and additional fuel tanks.

So naturaly I thought, no prob, I'll do some research, get the proper combat ranges and propose the changes to Herman, yes? Nope. As Herman explained to me, we can't go editing the database as that may break pre-existing scenarios.

So, I got to thinking, how can I have my cake and eat it too? How can I have my database, not lose any updates to the database or any compatibility to existing scenarios and -still- have it cleaned up and edited with different values for a specific scenario or battleset?

Obviously the easy solution would be to make a copy of the database and change the values to what I like, then use that version for any scenarios I want, but that is crude and I would soon end up with 100 versions of the database, not to mention each of these versions would be stuck at the current stage and not get updated with new goodies.

So this is what I will -try- to do. I am sure it is technically possible but I am not sure if I will find the time, energy and commitment to follow through:

I will make an additional database, but not a ANW database. It will be a ANW edit database, in other words, if I wanted to change a value in the PlayersDB, instead of corrupting the actual database I record the change on that external database. Then I will have a program that not only will it be able to make the recorded changes to the database, but also undo them, so that when I am finished playing the specific scenario I wanted the changes for, I can go back to 100% compatibility mode with everything else.

There is also other advantages but they are mostly related to scenario design. The main advantage, for me, is that I can get rid of clutter and have specific sets of values for specific situations without burdening the database with additional entries every time I want something different.

So, what do you think?

First of all, Herman and Co. are you ok with this? If not I will keep it all to myself and not publish any results to anyone.

Also, I would like to use the Falklands battleset as a test bed. I will attempt to create a program that modifies the database specifically for this battleset (remove superflous entries and simplify naming, edit values, change some ships to their pre-Falklands configurations etc), but for this to work properly I will also have to modify the scenarios themselves, in essense creating a new version of the battleset, one I hope will be cleaner and more historically accurate. Of course there is also the risk that these changes may also alter the balance of the scenario, something I will also have to worry about at some point.

But again, the first question is, how does the creator of the battleset feel about this? If he is oposed to the notion I will once again, keep everything I do to myself and never infringe by posting or publishing anything.

Also please keep in mind that this is just an idea and I may never get to actually working on it.

[FreekS]

I have no problem to use the Battleset and edit the scenario's to suit your new database. If you can develop a new feature that improves the player experience why not?

I would like to see the finished work before re-publishing; but if it works as intended and does not give players any issues - then I wont object to're-using them. Thanks for asking.

I do know that ANW checks if a scen was made with the Database that the player is using. If the player does not use the exact same version then the scen never loads.

I tried to make the Falklands battleset reasonably accurate - I know I've taken some liberties in the interest of balance - but if you find major realism issues let me know.

[Herman Hum]

As I was playtesting one of the scenarios, I noticed that there were AC loadouts whose combat range did not make sense when compared to each other. For example, the loadout with 6 bombs would have ther same combat range as the loadout with 2 bombs and additional fuel tanks.

So naturaly I thought, no prob, I'll do some research, get the proper combat ranges and propose the changes to Herman, yes? Nope. As Herman explained to me, we can't go editing the database as that may break pre-existing scenarios.

That is not quite accurate. It isn't that the PlayersDB cannot be edited, it is just that we do it in a very specific manner so as not to crash any scenario previously built with the PlayersDB. It's very memory intensive and causes the PlayersDB to balloon in size so we try not to do it often unless it is unavoidable.

Other DB editors do things differently. However, a major feature of the PlayersDB is the fact that it is stable for all eternity. You don't need to worry about building a scenario today and wondering if it will still function one year from now. The different versions of ANW (3.7.0, 3.8.0, 3.9.0...) may be functionally incompatible with each other, but that is not within the DB editor's control.

So, I got to thinking, how can I have my cake and eat it too? How can I have my database, not lose any updates to the database or any compatibility to existing scenarios and -still- have it cleaned up and edited with different values for a specific scenario or battleset?

Obviously the easy solution would be to make a copy of the database and change the values to what I like, then use that version for any scenarios I want, but that is crude and I would soon end up with 100 versions of the database, not to mention each of these versions would be stuck at the current stage and not get updated with new goodies.

So this is what I will -try- to do. I am sure it is technically possible but I am not sure if I will find the time, energy and commitment to follow through:

I will make an additional database, but not a ANW database. It will be a ANW edit database, in other words, if I wanted to change a value in the PlayersDB, instead of corrupting the actual database I record the change on that external database. Then I will have a program that not only will it be able to make the recorded changes to the database, but also undo them, so that when I am finished playing the specific scenario I wanted the changes for, I can go back to 100% compatibility mode with everything else.

There is also other advantages but they are mostly related to scenario design. The main advantage, for me, is that I can get rid of clutter and have specific sets of values for specific situations without burdening the database with additional entries every time I want something different.

So, what do you think?

First of all, Herman and Co. are you ok with this? If not I will keep it all to myself and not publish any results to anyone.

It certainly is a novel idea. In the dark days of Harpoon2, there was a DOS-based utility called PfEdit. I have very little experience with it, but Darren Buckley (HUD-Series editor) is a master with it. From what I've learned, it was a utility that made a customized database for each and every scenario. You can find a copy of it at Dr. Who's HarpoonPages (http://www.harpoonpages.com/harpoon2.htm). I understand that it took only the DB entries used within a specific scenario and wrapped them up into a nice neat package for that particular scenario. Unfortunately, PfEdit doesn't work on DBs bigger than 300kB (or so I've heard), but the concept is there.

I have toyed with the concept, too. With the forced introduction of the Signature function in ANW, it was an idea I looked long and hard at. Currently, whenever the PlayersDB is revised and released, it takes over 5 hours of computer runtime to re-build the 260+ scenarios written for it. This is nearing the point of pure absurdity.

The reason why we have not taken to releasing one (compacted and specialized) DB with each scenario is that we do not want to confuse users any more than absolutely necessary. Our current practice to bundle all scenarios and the PlayersDB into one neat package (a.k.a. the Library collections) so that they can DL and install with 1 click has been wildly successful.

If we change the process so that every scenario needs to be installed every time the player wishes to use it, I bet that there would be significant cries of, "I get a crash when I tried to play the scenario with the PlayersDB MM-DD-YYY...." due to mis-match errors.

It's the PlayersDB. Anything that encourages new scenarios and participation within the community is welcome. Should you decide to make a variant of the PlayersDB for your own use or for re-publication, I don't think that any of the contributors would have a problem with it. I would only ask that you recognize the lineage of the PlayersDB and the stalwart contributions made by previous editors (HUDII --> H3DB --> PlayersDB). Without the generous contributions from editors like Darren Buckley, Fred Galano, Brad Leyte, and Rene Haar, the PlayersDB would not exist.

see: The PlayersDB Project - a new Harpoon3 database (http://www.gamesquad.com/forums/showthread.php?t=31940)

[Shemar]

I have no problem to use the Battleset and edit the scenario's to suit your new database. If you can develop a new feature that improves the player experience why not?

I would like to see the finished work before re-publishing; but if it works as intended and does not give players any issues - then I wont object to're-using them. Thanks for asking.

I do know that ANW checks if a scen was made with the Database that the player is using. If the player does not use the exact same version then the scen never loads.

I tried to make the Falklands battleset reasonably accurate - I know I've taken some liberties in the interest of balance - but if you find major realism issues let me know.

Well, first let me be very clear that I won't be making a 'new' database, just a tool to temporarily change the current one :D

And of course nothing you created will see the light of day without your complete approval.

I did not see anything in the scenario itself that was not accurate (I am not informed enough on the subject to make that call anyway), but if one had the ability to freely edit the database for the sake of this one battleset, I believe things could be better (for example ships having their pre-war setups not their post Falklands imrpovements). But mostly it is about getting rid of database entries that just take up screen space (for example, loadouts not being used at all) or editing some values for more realism (something we can't do on the 'master' database so as not to break existing scenarios).

There won't be a problem with version checking as my program will surgically insert the desired edits into the existing database (and remove them once done), not create a new version of the database.

[Shemar]

@Herman: I totally agree with the concept of never breaking existing scenarios, that is why I am not even suggesting making changes to the existing database, but I intend to do some serious work into being able to both have edits at will -and- maintain full compatibility.

I also agree (as already stated) that multiple versions of the database would do the trick but it is a crude solution, so I want to create a more elegane one. It will still not be worth the trouble for individual scenarios, but for battlesets of 4+ scenarios I think it will be worth the trouble.

With the authors agreement, we could bundle the battleset with the modification program (while still having the version that runs on the master database available of course) as a complete download, so the users that feel comfortable in installing and using it can get whatever extra value it may add to their experience without taking anything away from existing content or practices.

[Herman Hum]

There won't be a problem with version checking as my program will surgically insert the desired edits into the existing database (and remove them once done), not create a new version of the database.

I do not believe that you understand the far-reaching implications of the Signature function required by ANW. This one 'feature' is very much like StarForce.

When you use the ANW editor to create a scenario, the scenario file stores a bit of information showing exactly which database was used to create that scenario, i.e. PlayersDB v8.1.1 dated XX-XX-XXXX. Now, if I were to re-post the PDb 8.1.1 again, today (without a single change!), it will not work with your scenario because the dates are different. The contents would still be the same, but the entire database is not perfectly identical and you would get this message:

http://img233.imageshack.us/img233/5035/geversionmismatchlu4.gif

Thus, any scenario made with ANW SE and PlayersDB and then posted, will not work with this edition of the PlayersDB. It isn't irreparable. To get the scenario to function with the latest release of PlayersDB, you must:

1) Install the new release of the PlayersDB
2) Load the scenario(s)
3) Re-Save the scenario(s)

Now, the scenario and the database will be perfectly synchronized. However, can you see the logistical nightmare this might entail? In order to share a scenario with others on any of the public fora, you (or they) would need to CONSTANTLY update it every time there was a change in the corresponding database. Some databases have been changed on an hourly / daily basis. Of course, if you only do one file (and never share it), it isn't a problem. However, it is a major inconvenience and quite ridiculous, IMHO.

This 'feature' can multiply player frustration because not every player knows how to synchronize scenarios and databases. He might just hit the Error Message and give up; think it is a buggy/faulty file.

Here is a partially resurrected thread from Matrix. Obviously, the long-term consequences and outright stupidity of this idea was too much for AGSI and Matrix to bear so it had to be deleted:


Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

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








Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

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









Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

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


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.

Yes, I get those e-mails too.

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

Later
D










Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

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.

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.











Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

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









Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

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?









Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

We are all just trying to keep positive doialogue 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










Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

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

Very good then. Can't say you weren't warned.

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.

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

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

Later
D









Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

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














Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

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

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

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?












Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

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.











Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

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











Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

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










Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

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 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 requ
ire 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











Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

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
3) Re-post these scenarios

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











Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

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). I
have correctly understood the matter?











Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

Yes.

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









Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~


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

[Herman Hum]

And the rest of it:

Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

ORIGINAL: Vincenzo Beretta

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?


ORIGINAL: hermanhum
Yes.


Wrong again Herman.

If you have made a change to a database platform that is not in a scenario,
there is no need to rebuild that scenario. However, because there was a
change to the DB signature file, then the game will notify you of a DB
mis-match. This is not a big deal as all you have to do is save the
scenario with the new DB.

This takes about 15 seconds. There is no rebuilding involved.

Now if you change a platform that is in the said scenario, there is the
single rebuild feature. In this case you can choose to rebuild a selected
platform AND it's magazine (that's a separate command), save the file and
move on.

This would only take a minute.

The 'rebuild all' command is practical when you are rebuilding a scenario
after a long period of DB changes.

Herman, you really should come and ask us about these things if you don't
know ok? I realize that you trying (and my how you're trying) but you're
only making yourself look bad. Common man, give it a rest.

Later
D








Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

Let me see if I understood.

In the past, up to H3 3.6.3, there was a chronic problem with third-parties
DB: if someone modified his own DB but failed to warn the community about
the changes, an unsuspecting guy loading a scenario (both one downloaded
from the net or even one he was working on) could meet any sort of problems
without having a clue about their origin - this because the DB mis-match was
not registered by the game and warnings were not given.

So, to prevent this, a safety feature has now been added: if there is even
the slightest discrepancy between the DB originally used and the one now
loaded, no matter if it is only a single character in a ship's name. This
warning is given both if the altered platform(s) are used by the scenario
*and* if they are not used. OK, I can understand this - and I'm happy with
it, since it is a way to prevent some of the DB accidents that happened in
the past.

This, however, will basically force all the DB and scenario designers to
update their scenarios everytime a new version of the DB they are based upon
is realased. If you are also the designer of the DB you will do it "at
home", while if you are using the DB written by another player you must
first download the new version and then update your scenarios and re-upload
them on the hosting sites - doing this routine once in a month if DBs are
updated once in a month, once every week if a guy decides to update his DB
once a week. Is this correct?

One last thing:

ORIGINAL: VCDH
Herman, you really should come and ask us about these things if you don't
know ok?

This is a new feature of the game to me, since I have only played Harpoon 3
up to 3.6.3. Where I can ask about technical question (both before and after
the new edition is realased) if not on this forum?







Matrix forum - Maintenance of ANW Scenarios (http://www.matrixgames.com/forums/tm.asp?m=1131841&mpage=1��)



~~~~~~~~~~~~~~
RE: Maintenance of ANW scenarios
~~~~~~~~~~~~~~

ORIGINAL: Vincenzo Beretta
This, however, will basically force all the DB and scenario designers to
update their scenarios every time a new version of the DB they are based
upon is released.

Correct. And this "procedure" translates to:

ORIGINAL: hermanhum

1) Load all the scenarios he has written
2) Update all the scenarios he has written
3) Re-post these scenarios

The word is "UPDATE" means: "to take all measures necessary to ensure that
the scenario is compatible with the current database." This might mean
re-opening and re-saving all scenario files or, it may mean more extensive
re-work.

[Shemar]

This may or may not be a problem. I will do some testing.

[MikMyk]

Shemar I'd get in touch with AGSI or Matrix people on this one. Your time might be better served by asking them about Hum as well.

[Herman Hum]

Hey Shemar,

If you are intent on wasting your time with AGSI/Matrix, you may as well ask them if they are ever going to fix the 130+ bugs already identified.

* Known Harpoon [ANW] Issues (http://www.gamesquad.com/forums/showthread.php?t=42076)

It sure would be nice to get a working game after already paying for it.

[Shemar]

I am currently in the process of creating a new database viewer/editor one that does not use Access at all, or a single line of existing code, but is a pure Win32 application that can be run alongside Harpoon (at least in Windows mode). If it is possible (due to the signature file lock) the same functions will also be able to create specialized versions fo databases.

When I have moved along enough to know I can do it I plan to contact AGSI/Matrix to see if they have any objections and if they are interested in helping in any way. Whatever I create will be free and available to all to use.

I do not plan to get involved, or take part, or choose sides in the conflict that seems to have split the Harpoon community into groups. I plan to maintain good and cooperative relations with everybody, as long as they themselves do not expect me to choose sides.

[TonyE]

You should probably talk to AGSI first as the database format is one of the things they do care about and having it publicly documented would not make you a favorite of AGSI, especially if it is done unbidden. I know that sounds silly since a person can take the Access editor and 'read' the database structure right out of it but that itself is showing that the format would have been decoded using AGSI property.

That all said, Don Gilman tends to be quite accepting if you talk first and violate all manner of intellectual property rights later...

[Shemar]

I posted on the Matrix forums about it.

The beauty of a Win32 application is that unlike an Access database, the source code is not publicly available. Therefore I will not be publicly documenting the file format of the database. Furthermore I did not use the AGSI database editor to get the file format, but a much older database comparison tool I found. In fact, I do not have the AGSI Access database editor at all.

[Herman Hum]

For those who don't care for Matrix forum:

In the past week I have been fiddling with creating a new database viewer/editor for Harpoon 3 ANW (no idea if the databases with other versions are compatible).

I have deciphered most of the database format, mainly using an old MS Access database compare tool I found and downloaded and I am pretty sure I can figure out any changes by experimenting. The tool will be a pure Windows application written in C++. Although doing it this way is quite harder than just making one more MS Access editor, I have chosen this route for these reasons:

a. The tool will not require ownership of any additional software (MS Access).
b. The tool will run a lot faster, more efficiantly and have negligible system requirements.
c. The tool will not use a single line of code from any existing piece of software, whether that is public domain or proprietary. Furthermore, by the nature of the application, nobody will be able to claim or imply that the tool uses pre-existing code, as code for a Win 32 database editor does not even exist at the moment.

The reason I am interested in doing that is because I like the idea of having an external database viewer that can run parallel to the game and not force a pause when being used. Especially for those with two monitors it can be an invaluable tool for both scenario design and playing the game. Once I have the viewer done, adding the capability to alter values and save the files back is a relatively minor task, hence the editing part.

So, first of all I would like to know if there are any objections from the publisher and the developer of the game in me creating and freely distributing this tool. I undertsand that there may be some intellectual property rights involved, regarding the database file format, but anyone with basic knowledge of programming can have access to these file formats with a minimum of effort, out of tools that were created long ago and are still openly downloadable. Additionally, even though one would be able to edit their database with the tool, they would still need the in-game database editor to create the signature file for the database, so any level of control over who can and cannot publish databases that already exists will not be altered.

Second, from the community, I would like to know if there is an interest in such a tool. I will eventually create it just for my personal use anyway, but if I know there are people out there that want the tool I will probably do it in a much tighter schedule.

Edit: Just to make something more clear, unlike MS Access database editors, a pure Windows application does not come distributed with the source code. Therefore anyone in pocession of the tool will not be able to reverse engineer it without considerably more effort than I expended creating it. I do not plan to make the source code publicly available.

I posted on the Matrix forums about it.

The beauty of a Win32 application is that unlike an Access database, the source code is not publicly available. Therefore I will not be publicly documenting the file format of the database. Furthermore I did not use the AGSI database editor to get the file format, but a much older database comparison tool I found. In fact, I do not have the AGSI Access database editor at all.

If you plan to make the viewer/editor, I hope that you can make it flexible enough for additional fields as they become available with ANW.

At this time, there are a number of fields/flags supposedly allowed in the game, but not available in the H3Editor.exe

I'm not familiar with programming so I don't know exactly how the Win32 end product will look. I use the old H3 Access editor and find it very flexible and user-friendly with many opportunities for export and a great many functions. I certainly hope that your endeavours will give us another excellent tool with the same or better capabilities.

[Shemar]

For those who don't care for Matrix forum:

If you plan to make the viewer/editor, I hope that you can make it flexible enough for additional fields as they become available with ANW.

I cannot account for future fields. If and when they become available, I should be able to add them.

At this time, there are a number of fields/flags supposedly allowed in the game, but not available in the H3Editor.exe

Analysing database objects that are currently using these fields should be sufficient to account for them.

I'm not familiar with programming so I don't know exactly how the Win32 end product will look. I use the old H3 Access editor and find it very flexible and user-friendly with many opportunities for export and a great many functions. I certainly hope that your endeavours will give us another excellent tool with the same or better capabilities.

I have not used the Access editor so I can't answer this. My primary concern is a viewer with filtering capabilities (for example instead of dealing with the huge list of all aircraft, you will be able to filter the list for aircraft whose name contains a specific text, such as 'Harrier').

Depending on community support and demand, I will keep improving it and adding new features. The only limitation to what it can be done is how much time I have to spend on it.

One thing I can say for sure is that it will be far superior to the in-game editor. For example when you are editing an aircraft, you will have a list of all (or a filtered subset of all) aircraft permanently available with their most crucial attributes, moving from one to another with ease on the same screen, instead of having to close the screen and go back to the list of aircraft to edit another one. Additionally, editing a sub-object like a loadout would be just a matter of double clicking on the specific loadout. A new window with the loadouts will pop up (without closing the one with the aircraft), with the clicked on loadout already pre-selected.

[Herman Hum]

Filtering does sound like the most useful attribute. It is currently one of the most powerful functions of the old H3.6 Access editor. A Win32 application could certainly be helpful for those folks either unfamiliar with Microsoft Access or who don't have it at all.

Everyone seems to play the game just a little bit differently. The information used by some folks is not always considered important by others. For example, a new feature in the Beta 390 Patch allows players to see an aircraft's operational ranges with the in-game database function. Although I would never use it, I can certainly see how some might find it helpful. Allowing users to select their own fields of interest is definitely the way to go.

[FreekS]

Shemar,

Is the thinking behind your idea also that a scen designer can 'search for' suitable platforms in the DB based on some criteria before inserting a ship or aircraft?

I remember spending ages trawling through all the patrol ships in the DB to find ships that might be credibly used by Pirates.

Any tool that would help select units with certain names, weapons etc would be much appreciated.

I might have your idea all wrong though!

Freek

[Shemar]

Filtering by name will definitely be part of the initial release. So you will definitely be able to find loadouts that include a specific weapon, as long as said weapon is part of the loadout's name.

Beyond that, assuming I don't get hit with a 'cease and desist' kind of treatment from Matrix/AGSI, additional functionality (for example filtering the aircraft that use a specific loadout or even more advanced, filtering the aircraft that have any loadout with a specific weapon) is possible.

As I said before, it is really not a matter of whether it is possible or not. As long as a requested feature is doable in computer terms (i.e. it can be achieved by using the information in the database in an absolute way that does not require intuitive judgement or decisions) I am fairly confident I can do it.

[Herman Hum]

http://www.gamesquad.com/forums/attachment.php?attachmentid=21112&stc=1&d=1204471404

This is how the H3.6 Access editor shows loadouts. If you double-click on the loadout numbered 1072, you can see all the aircraft currently carrying said loadout.

This is really a helpful feature. Additional detail / control in the filter would be even more welcome. :)

[Shemar]

It will take quite a while for my tool to get anywhere near the usability of the Access database tool, especially to someone who knows how to use access and add their own filters/capabilities.

However that database editor is not freely available any more to any random person that just buys the game and has the curiocity to see the exact stats of their units.

Also, for some reason H3 seems to hate MS Office 2003 so, at least for me, running it at the same time as the game and using it as a viewer would be impossible.

So, to be honest, I doubt my tool will be replacing the Access editor for those that already have it. Fortunately, it can work side by side with it so designers will have the best of both worlds. But my tool is mainly aimed at those people that do not have access to the editor and just like the idea of being able to take a peek inside the database and possibly make a tweak or two.

[Herman Hum]

However that database editor is not freely available any more to any random person that just buys the game and has the curiocity to see the exact stats of their units.

Evidently, the payment of $50 is insufficient to guarantee anyone access to an editor they already paid for:

it might be important to note that Database Editors are NOT included with the game even though this is explicitly stated on both the CD ROM case and on the Matrix sales site.

http://www.digitalriver.com/dr/v2/ec_Main.Entry17c?SID=45905&SP=10023&CID=0&PID=834987&PN=1&V1=834987&CUR=124&DSP=&PGRP=0&ABCODE=&CACHE_ID=0

http://www.gamesquad.com/forums/attachment.php?attachmentid=19089&stc=1&d=1174586955

After purchasing the game, a request for the editor must be made with NO GUARANTEE of approval or acceptance. It might be granted and it might not at the sole discretion of Matrix/AGSI. Purchase/ownership of the game does not guarantee use of a DB editor.

There is a report that the version of the Editor being released with the request form may not be fully functional.

Re: latest post from Don Gilman (http://www.matrixgames.com/forums/tm.asp?m=1386056)

The PlayersDB has done as much as possible to eliminate the need for it via inclusion of much of the data within the various Text Description files. It certainly isn't the optimal solution, but, like most of the PlayersDB features, it is entirely functional. Until such time as you can get your utility operational, we'll just have to continue limping along with this work-around, I guess.

Hurry up, already! :clown: