Matrix Games Forums

This is just me dipping my toe into the water to gauge interest and solicit ideas...

I'm tinkering around with/thinking about creating a new scenario editor for WitP:AE

Features I'm thinking about:
- initally use the existing witploadae.exe to extract information from the scenario files and then import the data into HSQLDB (the db used by tracker).
- export a scenario from HSQLDB to a WitP:AE scenario slot (1-200) (dump db to .csv files, then import to scenario files using witploadae.exe)
- duplicate existing Scenario Editor functionality, plus new fields not exposed by scenario editor but in CSV files.
- add ease of use features like entry copying with Ctrl-C and Ctrl-V (including across scenarios)
- Allow list editing and Excel Spreadsheet Ctrl-D type duplication of values across rows
- Filtering of rows
- Scenario comparison features that would identify changes between scenarios and allow selective apply of changes.
- Scenario checker - identify common scenario issues and report on them, click from "error report row" to edit row data. Ex checks: missing bitmaps, repeated names, device mismatches between units and TOE's, unused or orphaned devices/aircraft, etc.
- Different ways of viewing and reporting on scenario (task force view that looks somehat more like the TF view/list in game).
- Allow use of SQL to do scenario updates. For example, if you want to cut cargo capacity by 30% across the board in a scenario, you could execute "update shipclass set cargocapacity = cargocapacity * 0.7 where scenario = 28;" and then export the scenario. Done.
- Some other things that are easier to show than to explain...

Random, unbaked thoughts/possibilities:
- Extract from a pair of trackerdb's (Allied and Japanese) to a new scenario. Allows creation of a new scenario from a running game. Would also give limited ability to apply oob changes to existing games (some detail would be lost like pilot skills/kills/missions).
- Maintain art files associated with a scenario
- Cooperative Scenario editing (web based version)

So ...

1) Does any of the above sound useful to you?
2) What features would you like to see in a new editor?
3) What are some of the most tedious tasks for you when you are using the editor? Can you think of a better way?
4) What "checks" would you like the editor to do on a scenario (unused devices, etc.)
5) What would be your ranking of features (Most wanted to least wanted)?

IM,

I've been having similar thoughts. I'm currently in the midst of re-writing Intel Monkey (also called IM!) and have been thinking I would take that up just after. I have no interest at all in designing scenarios. My motivation is to provide a good tool and the experience of making the tool. Even if you go ahead, I will likely also go ahead, even if nobody winds up using mine. In case any of this helps, some thoughts I've been having so far...

One group I've been thinking about is the DBB people because they are maintaining a large number of scenarios. They have to juggle lots of units that go in some scenarios but not in others (different scale scenarios with different breakdowns of units), different device attributes ('same' devices defined various ways), and so on. The other scenario designers have similar needs just perhaps at a smaller scale.

- I'm going to use SQLite for the database, which can be gotten at from just about any language and standalone with their tools if need be (http://www.sqlite.org/).
- I'll write in Python 3.6.
- The app will be packaged up (using Pyinstaller, cx_freeze, py2exe or something similar) so that Python is provided as part of the application. That will free the user from installing Python and will keep that version of Python from affecting the rest of their system. If will not matter if they otherwise have Python on their system or not, and if so there will be no conflict no matter the version.
- An installer made with NSIS will provide a single file (.exe) to the user and handle installation in the universally standard way.

Most users are pretty well non-technical. Scenario designers will likely be more technical than that, but it might be wise to assume they will need all the help they can get with the (even slightly) technical stuff. I found with the early version of Intel Monkey that the two greatest obstacles users faced were installing Python and installing Intel Monkey. Look over years and years of posts in the Tracker thread and you will see the very same thing: people struggle with installing/updating, etc. Java, and will installing/configuring, etc. Tracker. And that is not for lack of clear written instructions. The community that has great interest in this game is very mixed in technical skills, and many have difficulty even copying files from one directory/folder to another. So package up the application for near dead-simple installation to head off many headaches.

Configuration changes after installation also defeat people. What I have done in the coming version of Intel Monkey (and will do for any scenario database/editor I make) is to make configuration all point and click inside the application, in a 'User Configuration' menu. Creating a new database is also point and click, with the old one renamed instead of deleted "just in case".

You've already given way more thought to this than I have. I hope my thoughts prove useful to you.

My interest mostly started after creating some test scenarios. I could not believe how clicky the scenario editor was. My first thought was that I could write something better, but spending time decoding the structure of the scenario files was more time than I wanted to spend. I ran across a reference to witploadae.exe in a another thread. It is not perfect, but I think I can do a lot better than the one that comes with the game.

I thought about using SQLLite - and might still. The DB doesn't matter much to me. However, I considered doing some tie ins to Tracker and that swung me in favor of HSQLDB.

The comparison utility that would be a part of it will mirror something I created for work. It will look for items in the source that do not match in the destination, then note them in a conflict report and allow selective update. Essentially it will produce a conflict description that says "Facing on Weapon Slot 1 changed from F to A on Ship Class 1 - Akagi." and have a checkbox on it. If you click the checkbox and hit save, it will update the weapon facing as described in the destination scenario.

Also, the scenario editor will allow any number of "scenarios", but will export only to slots 26-200. So you could have 3 primary scenarios (301/302/303) and 4 sets of incremental changes (400/401/402/403). If you want to create a version of scen 302 with the device changes in 400, you create a new scenario 800 (just picking a number out of my ass) and copy in everything from 302. Then, you would merge in whatever devices you want from 400. If you then want to export it to play/review in game, you export to scenario files by choosing the new scenario (800) and the slot (an unused number).

If you do decide to use SQLite you can still separately read what you want to from the Tracker db. The only Python module I found to do that uses Python 2.7 (and at my age regression is a bad word! [:'(] [:D]) so when I get to that I will make it a standalone module that dumps the data to files or db to be picked up by the main Intel Monkey program.

I'm not sure if they consider the scenario files' formats proprietary and they would want a non-disclosure to directly access them, but the dump/load to/from CSV files is great and gets around that. I know the Tracker guys had to sign an ND to gain access to read the game save files directly.

The ideas you have will probably save people a ton of time!

I like the way your are thinking. Good luck.

IM, I like what you are contemplating.

One thing that I struggle with is I like to move ships like carriers and capital ships into a more orderly fashion (hull designator order).

When you move a ship, you must then go to its attached air groups and re-assign all of them to the ships new location. I know it's because the air group is assigned on the air group tab. Is there a way to move the ship, and have the air group point to the new ship location?

Like "Do you want to move all attached air groups?" option.

Is this possible/feasible?

**EDIT: The ability to filter to show only certain data, i.e. Show only CV's, or show only CV's, and CVL's.

ORIGINAL: Admiral DadMan

IM, I like what you are contemplating.

One thing that I struggle with is I like to move ships like carriers and capital ships into a more orderly fashion (hull designator order).

When you move a ship, you must then go to its attached air groups and re-assign all of them to the ships new location. I know it's because the air group is assigned on the air group tab. Is there a way to move the ship, and have the air group point to the new ship location?

Like "Do you want to move all attached air groups?" option.

Is this possible/feasible?

**EDIT: The ability to filter to show only certain data, i.e. Show only CV's, or show only CV's, and CVL's.

Yes, it is a planned feature. Planned being the keyword...

To whet your appetite, I'm going to post a couple screenshots of the Aircraft List window, which gives the idea of what the "list" windows for all types will look like. Keep in mind, I've been at this like 2 days, so it is rough and subject to change.

I plan to have 3 basic windows for each CSV file: a "List" window, a "Detail" window, and a "Compare" window (drag and drop aircraft from List or Detail windows to compare two items side by side.) List has more bulk editing features, detail has more powerful individual item editing features. You will be able to edit multiple scenarios at once (and compare/copy across scenarios). I also plan to create a compare Scenarios window which will look for discrepancies between two scenarios and easily apply changes detected. Finally, I plan add a "Scenario Checker" that looks for oddities/errors in the scenario.

Here is the Aircraft List Window in it's current form:

This other screenshot kind of gives you an idea of what I mean with the differences in editing between lsit window and detail. In the screenshot in the previous post, you can enter the the aircraft attributes (e.g. Float equipped) by clicking a check box on the list window. However, if I do that for 20 devices and 8 check boxes apiece, I'll have 160 extra columns on the list window. So, you can type it in directly, OR, you can right click to pop up a menu and select menu items.

On the detail window, you get all 3 for every device. You can enter it directly, pop up the menu and select the choices you want, or click check boxes as you desire.

Hrmm... better example of the above.

[X(][X(][X(]

Great job. If it's works, will be a huge improvement...

Here's something that comes to mind: If you have multiple installs of the game, the current editor that comes with the game won't open in the directory that you start it in. It will open in the directory that you were last in. So you can have multiple installs of the editor also, but it acts as a singular program

For example: If I have two installs, one called \Matrix Games\WitP-Extended and one called \Matrix Games\WitP-Stock. I open editor in Extended\SCEN, work on it and close it. Then I go over to the Stock\SCEN and start the editor, it still opens the Extended\SCEN path, and I have to manually change it to the Stock\SCEN directory.

Can this be written so that if I install it in the \WitP-Stock\SCEN folder and/or \WitP-Extended\SCEN folder and have it automatically know that I want it to work in that folder?

ORIGINAL: Admiral DadMan

Here's something that comes to mind: If you have multiple installs of the game, the current editor that comes with the game won't open in the directory that you start it in. It will open in the directory that you were last in. So you can have multiple installs of the editor also, but it acts as a singular program

For example: If I have two installs, one called \Matrix Games\WitP-Extended and one called \Matrix Games\WitP-Stock. I open editor in Extended\SCEN, work on it and close it. Then I go over to the Stock\SCEN and start the editor, it still opens the Extended\SCEN path, and I have to manually change it to the Stock\SCEN directory.

Can this be written so that if I install it in the \WitP-Stock\SCEN folder and/or \WitP-Extended\SCEN folder and have it automatically know that I want it to work in that folder?

I do not have a definitive answer for you because 1) I'm still in the early stages of working on it and 2) the editor I am working on does not store scenarios as files - it stores the data together in a relational database and then extracts them. Because of that, you choose where you import from and where you import to. If there is a conflict, the editor tells you so and asks you what you want to do. So if you import scenario 55 several times, it will ask you on the 2nd and later imports if you want to overwrite the old scenario or store it in another slot. In my test version right now, I have BTS (Scen 55) imported into slots 55, 201, and 202. I can modify each of those independently and then export any of those versions back to any WITP:AE scenario slot (26-200). The directory it comes from and the directory it goes to are only important when I import or export them.

I first proposed a new editor (tm.asp?m=3088504&mpage=5). As I pondered the request GP made in that thread), I considered tracking files as you describe. I may do that, but it will probably be a later version. I hope for my first version to deliver the following:

1. Editing of data that can be exported/imported using witploadae.exe
2. Much greater ease of use in editing and automation of cumbersome tasks
3. A scenario checker that could "proof" a scenario for common issues - ships missing air groups, devices with incomplete information, unused devices, etc. and potentially fix them all with a single click.
4. A scenario comparison tool that made it possible to produce a report of the differences between two scenarios and merge changes from one version to another.

I expect 3 and 4 to be features that guys that maintain multiple flavors of a single scenario will love.

One feature I left out talking about was a scenario reorg tool. I have given some thought to an automated tool that reorganizes data to collect information together logically. For example, all your ships would be exported to scenarios in sorted order by nation, type, and ship name. Obviously, some items I could not do that with - AV support, etc. are required to be in certain slots, HQ's have to be in certain other slots, etc. To the degree that I could do the above, I thought about doing it. However, I think I decided this would be too little gain given the powerful filtering and sorting in the List screen.

If you look at the screenshots above, you should notice that 1) you can filter by name, side, nation, type, and equipped device as well as special classes. So if I want to find out every plane that has a MAD device, I can choose MAD device from the "Equipped with" drop down, and the only aircraft that appear in the list will be those that equip a MAD device in any of the slots 1-20. Likewise, if I want to see all the attack bombers, I can click on the "Show only Attack Bombers check box" and only attack bombers will show. The filtering allows you to specify multiple criteria as the first screenshot shows. That list includes every IJA Fighter that is equipped with the 20mm Ho-5 cannon (in Scenario 55).

Another item you can see in the screenshot is the sort order. By clicking on the column header, it sorts by that column in ascending order. If you click a second time, it reverses the sort order. If you hold down the Ctrl key and click a second header, it does a multi level sort, so I can filter by nation (IJA) then sort by type ascending and and max speed descending.

With both those features already implemented, the reorg tool seems like overkill or at least a much lower priority for my time.

Some things you should NOT expect from the initial version:
1) AI editing screens. Simply put, witploadae does not expose the AI files to CSV editing and leaves me with 2 concerns: I have to both go to the effort to completely reverse engineer the files and at the same time run the risk of Matrix/Gary/someone raising a legal issue with the editor. I'm hoping at some point that someone official will bless that effort, but in the meantime there is plenty of valuable functionality I can provide to justify the effort.

At some point, I hope to engage Andy Mac with an effort to both improve the AI editing/chain visualization as well as develop some "dynamic" AE scripting. So far he has not responded to a question starting that ball rolling, but the idea would be to translate a scenario's OOB into something more AI friendly (Scenario would have 3 versions PBEM, Allied AI, and Japanese AI), then write programs that took map data and tracker data and dynamically created AI scripts that were able to respond to game conditions. In other words, every month, you'd run a process that takes tracker data and writes out a new set of AI files. My question to Andy was basically if the AI scripts got stored in the save game file.

Anyway, I digress and the wife has dinner ready... the other three things you will not see in the initial release:
2) map editor data
3) graphic file management
4) web based version

I feel goose pimples.

I play with the fantastic Editor all the time, and would like the ability to alter the "purchase points" designated on the scenarios.
If it is already there, I have not seen how to work it?

ORIGINAL: InfiniteMonkey


...At some point, I hope to engage Andy Mac with an effort to both improve the AI editing/chain visualization as well as develop some "dynamic" AE scripting. So far he has not responded to a question starting that ball rolling, but the idea would be to translate a scenario's OOB into something more AI friendly (Scenario would have 3 versions PBEM, Allied AI, and Japanese AI), then write programs that took map data and tracker data and dynamically created AI scripts that were able to respond to game conditions. In other words, every month, you'd run a process that takes tracker data and writes out a new set of AI files. My question to Andy was basically if the AI scripts got stored in the save game file.

Not possible.

The AI file which contains the script is stored with the scenario file. It is not stored in the saved file. Basically when a player presses the "Load Scenario" in the scenario selection screen, one of the AI script files is randomly chosen and no subsequent new editing/alterations take effect. The game then plays out according to what was contained in the AI script file which is cast in stone.

Within the script file, there are only 3 game "triggers" which impact:

• date (fixed)
• all allocated assets are "dead"
• predecessor script

IOW, you can specify a start/end date. If the end date has passed, the script no longer is in play. Similarly if all the allocated assets are destroyed that particular script ends. Assets which are currently partaking in a script will not be released to a follow on script until the predecessor script has ended.

The script writer therefore has to specify and allocate which assets are to be used. The AI does not choose them. The script writer determines on the basis of ownership, which bases trigger scripts. The size and location of human garrisons is not taken into account.

There are several old threads where the operation of the scripts are explained. This thread details how Andy Mac created scripts for one scenario.

tm.asp?m=2274569

Alfred

ORIGINAL: Alfred

ORIGINAL: InfiniteMonkey


...At some point, I hope to engage Andy Mac with an effort to both improve the AI editing/chain visualization as well as develop some "dynamic" AE scripting. So far he has not responded to a question starting that ball rolling, but the idea would be to translate a scenario's OOB into something more AI friendly (Scenario would have 3 versions PBEM, Allied AI, and Japanese AI), then write programs that took map data and tracker data and dynamically created AI scripts that were able to respond to game conditions. In other words, every month, you'd run a process that takes tracker data and writes out a new set of AI files. My question to Andy was basically if the AI scripts got stored in the save game file.

Not possible.

The AI file which contains the script is stored with the scenario file. It is not stored in the saved file. Basically when a player presses the "Load Scenario" in the scenario selection screen, one of the AI script files is randomly chosen and no subsequent new editing/alterations take effect. The game then plays out according to what was contained in the AI script file which is cast in stone.

Within the script file, there are only 3 game "triggers" which impact:

• date (fixed)
• all allocated assets are "dead"
• predecessor script

IOW, you can specify a start/end date. If the end date has passed, the script no longer is in play. Similarly if all the allocated assets are destroyed that particular script ends. Assets which are currently partaking in a script will not be released to a follow on script until the predecessor script has ended.

The script writer therefore has to specify and allocate which assets are to be used. The AI does not choose them. The script writer determines on the basis of ownership, which bases trigger scripts. The size and location of human garrisons is not taken into account.

There are several old threads where the operation of the scripts are explained. This thread details how Andy Mac created scripts for one scenario.

tm.asp?m=2274569

Alfred

Bummer. Thanks for pointing that thread out. Oh well, it was just a thought.

Here's a visual on what I was thinking for the Scenario Checker. This is a check from Scenario 55, between the Storms 2.6 by John 3rd. Obviously not all checks are implemented, the screenshot is just intended to show the idea.

This looks really promising - with what language are you programming it?

Is there any progress on this project?

ORIGINAL: Korvar

This looks really promising - with what language are you programming it?

Powerbuilder