Matrix Games Forums

The rebuild function should cover most of your list. It really is that easy [:D] Anyways off to enjoy the weekend[;)]

Late edit[;)]

Just to clarify the rebuilder doesn't check basic scenario editing stuff. It just focuses on making sure the scenario and database jive. Checking over your scenario is up to the editor .

Cheers[:D]

ORIGINAL: mikmyk

The rebuild function should cover most of your list. It really is that easy [:D] Anyways off to enjoy the weekend[;)]

Late edit[;)]

Just to clarify the rebuilder doesn't check basic scenario editing stuff. It just focuses on making sure the scenario and database jive. Checking over your scenario is up to the editor .

Cheers[:D]

That is very mis-leading. Examples are already posted on how Database changes can affect any (and every scenario).

Of course, I am quite happy to go through a step-by-step detailed analysis with anyone. However, that isn't the point of this thread.

Herman be around the chat tonight. Have a few months experience with the stuff and more than happy to spend a few showing you how easy it is. Let me via PM or email.

Oh..p.s..wiki is available too if you're busy.

Thanks [;)]

Thanks for the offer, but a chat doesn't help the folks who came to this forum for information, now does it?

Since this thread is about plans for how Matrix can help the community, why don't you start a second thread regarding Scenario Update requirements?

Then you can lay out all the parameters and we can go through it exhaustively once we are clear exactly all the circumstances we are working under? Sound good to you?

I recommend reading message #14 in this thread to see how I did it beforehand. (Sorry, I don't know how to make a link for it.) And, by all means, add as many parameters as you like so that there are no mis-understandings.

Just remember, there are a lot of folks who have never played the game before.

Then we can prepare a nice procedural manual / message for the FAQ that Matrix is surely going to put up when the game is released. Does this sound fair to you?

This stuff is pretty intuitive and feel most players should be able to look over the manual and/or wiki and have no problems. If there is a problem it'll most likely be addressed when the manual is released. The wiki can be updated at any point.

AGSI and Matrix also have a fantastic support staffs that should meet any challenge that comes up.I know I've been very happy with the assistance they've given me in the past.

Anyways I hope you enjoy the game and I know all those that participated hope you do too[:)]

Like said, it isn't intuitive. The point is to give folks an idea of what they might be getting involved with before they get their credit card.

In fact, much of it isn't even in the existing manuals. Hopefully, the newly revised ones will be more comprehensive.

Since you're unwilling, I'll set it up. Please feel free to join me on it when you have time.

ORIGINAL: Reg

I hope you guys come up with a solution to the 3rd party scenarios that is transparent and simple to use for new users.

*some stuff snipped*

Playwise, it was a huge improvement on the original but I could never get into the supplied scenarios (one Korean and a few South American skirmishes). I tried to downloading a few interesting looking scenarios and databases but to this day I have never gotten any of them to work. (I had just started night school and really didn't have the time to do much mucking around).

Your explanations above have been very enlightening as to what was going on but I feel that this remains an issue if you want to attract and retain new devotees.

What ever you end up doing, please make it simple for the casual downloader to load and run additional scenarios. Longevity of the game depends on it as well you know.

Hello Reg,

installing additional databases and scenarios in Harpoon 3 ANW will be as simple as extracting the database to a certain folder and adding all scenarios for that database to a subfolder. The new Launcher utility will automatically detect the new database and will allow you to switch to it with a simple mouseclick.

The procedures discussed above (i.e. rebuilding scenarios etc...) only apply to scenario authors who want to keep their scenario updated when a database author decides to release a new version of the DB.

Cheers,
JP

ORIGINAL: jpkoester1

installing additional databases and scenarios in Harpoon 3 ANW will be as simple as extracting the database to a certain folder and adding all scenarios for that database to a subfolder. The new Launcher utility will automatically detect the new database and will allow you to switch to it with a simple mouseclick.

The procedures discussed above (i.e. rebuilding scenarios etc...) only apply to scenario authors who want to keep their scenario updated when a database author decides to release a new version of the DB.

Good example. However, from my rudimentary understanding, I don't think that it gives a full and accurate picture of the situation. Allow me to add some details to the example:


June 2006

John has created a database called JohnsDBv1. He has written 50 excellent scenarios for it and has made them all compatible with JohnsDBv1. All of these files are posted to John's site.

Newbie buys ANW and goes to John's site and downloads all 50 scenarios and the database that makes them works [JohnsDBv1]. Everything is saved to his personal computer.



July 2006

John has been busy. He has added a few units to his database (now called JohnsDBv2) and written a new scenario, #51. He has made every one of his 51 scenarios compatible with JohnsDBv2. (How John does it is John's business. Some say that he sends the job offshore to India. [:D]) So, John, being a frugal man, deletes JohnsDBv1 and replaces it with JohnsDBv2 on his site.

Now, Newbie really likes the game. [Good for Newbie]. Newbie sees an announcement on Matrix forum that a new scen has been published. What does Newbie do when he visits John's site?

1) He loads Scenario #51 and leaves

2) He loads Scenario #51 and JohnsDBv2 and leaves.

3) He loads all 51 scenarios and JohnsDBv2 and leaves.

What is the correct answer? Take a moment to think about it. What would you do?

Tic
Tic
Tic

Time's up.

A) If he selects behind door #1, Scenario #51 will not work with the JohnsDBv1 currently residing on his computer.

B) If he selects option #2, he takes JohnsDBv2 home and installs it on his computer along with Scenario #51. He then successfully plays Scenario #51! Yeah! However, after playing #51, he wants to play some more and loads #50 from his archive. At this point he is given the Database mis-match message:

**** ERROR ****
WARNING! Scenario database signature does not match current database! Aborting load

C) Newbie takes all 51 scenarios home along with JohnsDBv2, plays them all and lives happily ever after (at least until the next version of JohnsDB is released)

Now, before everyone starts pointing fingers and saying,

"Yeah, but....."

There are many ways to get to a happy ending in this story.

Do any of the developers see an error in the details?

Am I mis-understanding something about the new Signature feature?
And if so, what?

Of course, Newbie thanks John for all the hard work and effort that he has put into his database and scenario writing by writing up a little After-Action Report for each scenario.

ORIGINAL: hermanhum
For example, when you say,

Casual players that want to experiment with creating their own scenarios will only be affected when they update the database in which case they can also use the scenario editor to quickly bring all their scenarios up to speed.

This can be quite discouraging to new designers trying to enter the field. Who wants the hassle of getting into scenario design if you are going to have to constantly maintain them?

Well, scenario maintenance has always been one of the things scenario designers had to deal with as the underlying database changes. What this boils down to is either

a) The scenario designer maintains the scenario and it continues working as intended
b) The scenario designer doesn't maintain the scenario and eventually as the database changes the scenario stops working.

The first choice might be more work for the scenario designer, but ensures that the scenario works. In the past, database-scenario mismatches have led to a lot of frustration to the majority of casual users who just want to play and end up with an out of date scenario that might not work at all.

One thing you have to realize is that the overwhelming majority of Harpoon 3 users never releases a scenario to the public, never posts to one of the community websites and doesn't come forward if they experience a problem with a scenario they download. However, they do feel the frustration when something doesn't work. Especially these people that are not familiar with the intrinsics of scenario and database design need to be protected from DB/scenario mismatches and their problems.

ORIGINAL: hermanhum
Of course, they could go through the effort, post it, and share with a few friends before abandoning it as the database it relies upon changes. This is a loss for the entire community.

Should interest in scenario designing require the participant to commit himself for life to a game?
Or, do new designers require control of their own database in order to maintain some semblance of order?

Scenarios written for databases that are regularly updated always required some maintenance. This is not something new in ANW. Before ANW outdated scenarios just wouldn't run or would run with serious problems and casual users wouldn't know why. Now in the ANW release users will know that the scenario doesn't match the database they are using. This is not a feature we implemented to hassle scenario designers or to put additional burden on them (which they always had if they wanted their scenarios to continue functioning after a DB update), instead it protects casual users that just want to play from potential crashes and other unwanted behaviour.

Ideally scenarios for each database would be collected in a central repository and when a database update is released all scenarios in the repository would be run through the batch rebuilder to bring them up to speed. Some community sites have used this approach very successfully with all scenarios posted to that site always matching the current database version.

ORIGINAL: hermanhum
The ANW ScenEdit does appear to be much more forgiving on some mis-match errors. That's good! [:)] At least it doesn't crash outright. However, the manner in which they are handled may be less than ideal.

Signature solution:

The 'signature' solution whereby every scenario is matched with its originating database is one of these bittersweet examples.

Instead of having a signature arbitrarily generated for every database, why not have it generated according to the NAME of the database, instead?

The signature can't be generated based on the DB name because databases in Harpoon 3 don't have names. The database authors simply rename the .zip archives. This information is not known at the time the database signature is created.

ORIGINAL: hermanhum
Let's take the PlayersDB 5.9.7, for example. So long as the Db author chooses to save a new version using the old name, he is, essentially, already guaranteeing that any changes that he may have made are either cosmetic or inconsequential. (i.e. spelling errors) When there is something that might be considered a major change, he could release a new version number i.e. PlayersDB 6.4.9

Since all of the major DB designers appear to use similar naming/numbering schemes, could this work? i.e. ADB v1.0.0, ColonialDBv1.8, DB2000v6.5.31 They all sport new version numbers when significant changes appear. I don't think that this will solve all of the problems. It is a half-measure, but it might save some folks from the hassle of changing their scenarios on a weekly basis. I believe that there are better solutions, but it appears as though AGSI has already chosen to implement this feature in this manner.

All this is non-applicable due to the reason mentioned above.

ORIGINAL: hermanhum
Also, instead of showing the following error message and aborting, could this be made into an optional window? i.e. "Do you wish to continue?" The act of catching the mis-match is definitely a step in the right direction. [:)]

**** ERROR ****
WARNING! Scenario database signature does not match current database! Aborting load

How about trying:

**** ERROR ****
WARNING! Scenario database signature does not match current database!
Previous signature: PlayersDB-v5.9.7
Current DB loaded: PlayersDB-v6.4.9
Do you wish to continue loading?

Again, the database name is not known by the game. Also the amount of changes from the database the scenario was created with to the database currently in use is not known. The only thing known by the game engine is that the database in use does not match the database that the scenario was created with.

Allowing the user to override the detected mismatch might be possible but needs to be carefully considered.

ORIGINAL: hermanhum
Batch Re-builder and Weapon Edit function:

There don't appear to be any instructions on how to use these new functions so they are difficult to evaluate. Are there any sample files or instructions available anywhere for testing?

[center]Two fundamental Re-Build Problems:[/center]

*snipped a number of ways for a database change to damage a scenario*

There will always be ways for a database change to affect a scenario in a bad way. Starting with potential balancing issues when a unit in the database is changed (increasing or decreasing its capabilities) up to the DB-author deleting units that are included in a scenario. These are things that scenario designers always had to deal with and it is the main reason why DB-authors and scenario designers on most community websites work together very closely. We are doing our best to provide the community members with tools that will allow them to handle most problems very quickly and easily (namely the batch rebuild function included in the ANW scenario editor). While we do know that there is always a potential for further improvements to these tools we also feel that the current solution is a huge step in the right direction. Nevertheless, cooperation and coordination between database authors and scenario designers will always be one of the prime ingredients to provide their users with a satisfying and consistent experience in playing the resulting scenarios.

Cheers,
JP

ORIGINAL: hermanhum
A) If he selects behind door #1, Scenario #51 will not work with the JohnsDBv1 currently residing on his computer.

Correct. It would be a bad idea if scenario #51 would work with JohnsDBv1 because one of the new units might be used in it. Scenario #51 should only be played with the database it was created with.

ORIGINAL: hermanhum
B) If he selects option #2, he takes JohnsDBv2 home and installs it on his computer along with Scenario #51. He then successfully plays Scenario #51! Yeah! However, after playing #51, he wants to play some more and loads #50 from his archive. At this point he is given the Database mis-match message:

**** ERROR ****
WARNING! Scenario database signature does not match current database! Aborting load

Correct. It would be a bad idea if the scenarios would continue to work with JohnsDBv2 because there might be changes in the DB that break the scenario, lead to a crash, etc...

ORIGINAL: hermanhum
C) Newbie takes all 51 scenarios home along with JohnsDBv2, plays them all and lives happily ever after (at least until the next version of JohnsDB is released)

Correct, a scenario should always be played with the database it was created for. This has been one of the prime causes for problems ever since Harpoon 3 was released. Both database and scenario authors have always mentioned it to anyone downloading their files that it is absolutely imperative to use matching scenarios and databases. The database signature system adequately addresses this by informing the users of the problem.

Cheers,
JP

ORIGINAL: David Heath
Hello Everyone

Matrix is also working on expand its support of the Harpoon community through our forums and making arangements for use of a scenario depot and an opponent registry. I would also like to hear any ideas the community may have in how we can better support the Harpoon community.


David

Hello David,

I personally would love to see a Matrix scenario depot. However, due to the dynamic nature of the database/scenario relationship it would be good if the database would also be hosted. For now I think this would be the H4DB that will ship with the product. Should updates be made available to that database all scenarios hosted at Matrix could be run through the batch rebuilder in order to ensure that the scenarios hosted at Matrix always match the current database version that is available for download.

With regard to 3rd party databases this situation is somewhat more complicated as many of these databases are updated quite frequently. Most of the community websites where these databases are hosted continually update their scenarios to keep them compatible to the newest database version and scenarios hosted at Matrix would also need to be updated. For a Matrix scnario repository for 3rd party databases I see three potential solutions to the problem:

a) Someone experienced at scenario design (A community volunteer or someone payed ba Matrix or whatever) continualy monitors the 3rd party database websites and updates the scenarios hosted at Matrix when a new version is released. Advantages: All scenarios are always updated to the current database version. Disadvantages: Potential cost for Matrix

b) The scenario designers that submit their scenarios to the Matrix repository take responsibility for updating their scenarios to the current 3rd party database version. Download of out-of-date scenarios could be greyed out until the scenario designer uploads a new version. Advantages: Low cost. Disadvantages: Might discourage scenario submission, scenario designers might abandon their scenarios, many scenarios would be out of date.

c) Matrix enters an agreement with the database designer to host a "snapshot" version of the database and only accepts scenarios compatible to that version. The snapshot is not updated as regularly as the 3rd party database (maybe once every 6 months or so) and the scenarios updated. Advantages: Scenarios always compatible to the database, scenario and database can be downloaded from one source Disadvantages: Does not take advantage of the work database authors put into keeping their database up to date, Database designers would have to agree to Matrix hosting a snapshot version.

I personally think that it would be best for Matrix to only host communitly created H4DB scenarios. I don't expect this database to be updated as frequently as the 3rd party databases which would lower administrative work in updating the scenarios. Additionally there would be less (or no?) licensing problems with hosting the corresponding database together with the scenarios. Scenario design contests could be held with the community members voting on the best scenarios which could then potentially be included in future releases of scenario packages, etc... The possibilities are basically endless.

Furthermore it is my experience that the various community websites are doing a very good job already in supporting their respective databases and scenario repositories so that an additional Matrix repository for 3rd party databases would not be much use for the users and might instead add more confusion. Instead the Matrix scnario repository might contain links to the various 3rd party database/scenario repository (including a disclaimer) so the users would have a central website from which they can reach the various 3rd party contributions.

Well, that's enough brainstorming for now. I am lookig forward to any feedback from the various participants of this forum or you David.

Cheers,
JP

PS.: Everythig above is my personal opinion only

[Deleted by Admins]

[Deleted by Admins]

ORIGINAL: jpkoester1

<< snip >>

For a Matrix scnario repository for 3rd party databases I see three potential solutions to the problem:

a) Someone experienced at scenario design (A community volunteer or someone payed ba Matrix or whatever) continualy monitors the 3rd party database websites and updates the scenarios hosted at Matrix when a new version is released. Advantages: All scenarios are always updated to the current database version. Disadvantages: Potential cost for Matrix

b) The scenario designers that submit their scenarios to the Matrix repository take responsibility for updating their scenarios to the current 3rd party database version. Download of out-of-date scenarios could be greyed out until the scenario designer uploads a new version. Advantages: Low cost. Disadvantages: Might discourage scenario submission, scenario designers might abandon their scenarios, many scenarios would be out of date.

c) Matrix enters an agreement with the database designer to host a "snapshot" version of the database and only accepts scenarios compatible to that version. The snapshot is not updated as regularly as the 3rd party database (maybe once every 6 months or so) and the scenarios updated. Advantages: Scenarios always compatible to the database, scenario and database can be downloaded from one source Disadvantages: Does not take advantage of the work database authors put into keeping their database up to date, Database designers would have to agree to Matrix hosting a snapshot version.

I personally think that it would be best for Matrix to only host communitly created H4DB scenarios. I don't expect this database to be updated as frequently as the 3rd party databases which would lower administrative work in updating the scenarios. Additionally there would be less (or no?) licensing problems with hosting the corresponding database together with the scenarios. Scenario design contests could be held with the community members voting on the best scenarios which could then potentially be included in future releases of scenario packages, etc... The possibilities are basically endless.

Excellent suggestions!

Allow me to reiterate a fourth.

4) If Matrix is willing to expend the resources, I think that the simplest solution, again, is to just post the scenario and the associated database at the same time and place.

Advantages:

A) Guaranteed happiness for the user. Never going to be a mis-match. Impossible.

B) No additional DL time. If the user is coming to load the scenario and load the database, the bandwidth being consumed is going to be exactly the same

C) This will accommodate ANY and all third-party databases. No need to limit everything to H4DB (Official DB of AGSI).

D) Designers can use the various DB and switch from the Colonial Era, to the Missile Age, and then back to WWII. No need to 'marry' any particular DB or design within one 'genre'.

E) Designer is saved considerable work. He ONLY updates when he wants to do it. (Community benefits because designer is freed from maintenance chores and is able to devote all of his time in building even MORE scenarios! Yeah!) [:D]

F) Designer concentrates on designing. No need to concern himself with the esoteric demands of database changes. Grab a DB, grab the SE, and he is off to the races! Yahoo!

G) No personnel or maintenance costs for Matrix. No need for anyone to babysit scenarios, post submissions, or update anything. Everything is left up to the users.

H) This takes removes the chore of maintenance from various website administrators, too.


Disadvantages:

A) Additional server storage space required for the database / scen. However, this can likely be offset by the fact that there are NO additional costs of maintenance / personnel.

- Also, I've been toying with the ANW editor and think that there may be some way that a scen designer can just take out the specific data he needs from any database (skeletonize it) and only save the pertinent details to the repository; potentially saving storage space.

B) Third-party databases are the product of their authors and permission would be needed from them before they could be re-posted outside of their home sites.


I can't speak for any other third-party database authors, but the PlayersDB would NOT be opposed to anyone wanting to use it in this manner. In fact, we encourage everyone to take it and post it everywhere. PlayersDB is currently hosted by three sites and is always willing to accept posting on any site that welcomes it.

Any other database authors willing to allow their work to be used in this manner?

It would be simply excellent if the various authors would allow users to make a copy of their database and re-post it to Matrix along with any scenario that they create.

Regarding hosting of Scenario's and Databases for ANW.

Let me dream a little:

From a player perspective, ideal world would be that he selects a game from the menu's of say H3.8ANW (based on a menu with DB, battleset and size, length etc) and then the program loads from the internet the latest game version and its matching DB. While the player should be aware what DB he's selecting, this can be fullproof in terms of never giving a DB mismatch or a change in behaviour as the designer meant it.
Designers and DB-owners would place the scens and all DB-versions in a repository (could be central or just based on a standard layout but owned by DB-owner). If the Scen-owner updates the scen (or has that done by anyone else) then the player gets a later DB than if the scen owners leaves it as is.
The other thing I like about this approach is that for designers, instead of download counters he now sees the actual number of times his scen was played (and maybe automatically gets the outcome in terms of vicconds achieved and units lost).

I've designed a fair number of scens for each of three databases; I really enjoyed making scens for different time periods and in general I had great support from the DB designers while I was making my scens (creating new units for example). However when it comes to maintenance that was not always the case.
Today some of my scens need an older DB-version no longer hosted on the owners website. In another case I had to rebuild all my scens for a new DB (and new owner) because they would not run anymore on the original one.

A GE that will automatically 'present' all scens to the player, and will automatically download the scen and the right DB-version might greatly increase the number of players, will make things dead-easy for players and will motivate designers who can see actual number of games played. DB-owners and Scen-owners would still be maintaining their own work so no ownership issues should arise.

I've played for 10 years and designed for 3; I hope the community somehow comes together around the H3.7ANW product - be interested in everybodies opinions!

I said I was dreaming, but I suspect the technology is not a hindrance here!

Freek

ORIGINAL: FreekS

Regarding hosting of Scenario's and Databases for ANW.

Let me dream a little:

From a player perspective, ideal world would be that he selects a game from the menu's of say H3.8ANW (based on a menu with DB, battleset and size, length etc) and then the program loads from the internet the latest game version and its matching DB.

It isn't Harpoon3, but this is exactly the same dream of a self-proclaimed "version-matching" fanatic for the Harpoon Classic line of games. Grab a scenario, run a utility, and the utility locates and loads the needed database from around the web. [8D]

ORIGINAL: hermanhum


Excellent suggestions!

Allow me to reiterate a fourth.

4) If Matrix is willing to expend the resources, I think that the simplest solution, again, is to just post the scenario and the associated database at the same time and place.

I would just like to add as a disadvantage that this would lead to the user having as many database folders as he has scenarios. After some time this would become quite confusing and to play a different scenario he would always have to find the correct database and select it in the launcher.

While this solution is technically feasible it would not be my preference. However people might disagree.

Cheers,
JP

PS.: The above is my personal opinion only.

ORIGINAL: jpkoester1

ORIGINAL: hermanhum

4) If Matrix is willing to expend the resources, I think that the simplest solution, again, is to just post the scenario and the associated database at the same time and place.

I would just like to add as a disadvantage that this would lead to the user having as many database folders as he has scenarios. After some time this would become quite confusing and to play a different scenario he would always have to find the correct database and select it in the launcher.

While this solution is technically feasible it would not be my preference. However people might disagree.

Why would the user need to have all the different folders?

If the scenario contents are all in one file (SCENARIO.zip), the *.zip file could contain other *.zip inside it.

i.e. JohnsScenario#51.zip would contain:

JohnsDBv1.zip [contains all the relevant Database info]
Scenario#51.SCN

Whenever Newbie wants to play #51, he simply unzips it to his current folder and plays. This could also be an easy way to store / manage his archives. Unfortunately, it might eat up a bit of space on his drive, too. Tante Pis! [;)]

Of course, the user would have to have as many *.zip files as he would have scenarios. Right.

All good discussion.

I agree with JP/Dale..

Third parties should probably maintain their own and Matrix deals with the H4DB which frankly needs to build a scenario set anyways . AFAIK third parties can do (or not do) anything they want with their DB's and scenario sets.

BTW any awards for brevity in posting[:D]

Thanks[:D]

[Deleted by Admins]