Edit to Add: I made an error that affected the accuracy of the "Battle Number". 0.4.1a fixes it. Thanks for the encouragement!

So... here is the next installment... Intel Monkey 0.4.1a is released.

Here are the release notes:

quote:

V0.4.1a

SigInt

Added a Type field to separate Actor into Type and Actor. If Actor begins with a Ship Type, this is moved to Type. Using the same logic from the Combat Report, if the Ship Type that begins Actor is followed by a "-", then the Ship Type is not subtracted from the beginning of Actor. This avoids stripping the "PT" off of the name "PT-73", for instance. Added the Type field to the SigInt report, along with a sort button for it.

Combat Report

The Battle tab is now implemented. The Battle tab shows the combat report segment for one battle at a time. Presently the battle can be searched by Battle Number, the six-digit number assigned to each battle when the combat report is read in. You can forego typing the leading zeros in the search field. Notice that on other tabs in the Basic Combat Report, the Battle Number is listed for each record. You may also move forward and backward through the listing of battles by using the "Previous Battle" and "Next Battle" buttons.

Batch Files

Beginning with this version, there are batch file (.bat) included for each (player) version of Intel Monkey. These run Intel Monkey, and then have a 'pause' statement. This will allow you to see any error messages that might crop up. I recommend that you have your shortcuts refer to those .bat files instead of directly to the .py files.

Changing an exiting shortcut is very easy. Select it, then right-click on it and click on "properties" (which is at the bottom). You should see the cursor is already in the "Target" field, sort of in the upper middle of the window that opens. Press the "End" key to go all the way to the end of the field. then just change ".py" to be ".bat". Since the bat files have the exact same names as the Python files that small change will point the shortcuts to the right place.

Massiev developments her, thanks for all of this. Two questions/suggestions....

Can a search ONLY show what you have searched for? On some screens it seems to juts put the records that fit the criteria at the top....

Is it possible to say search for battles that took place at a specifi location and show the set of them?

Roger

With this early functionality, the internals are a little bit "on the cheap". Obviously not totally so, but not like they will be when we have things in a format where queries can be more discerning.

With that in mind, the SigInt, Ships, and LCUs are one big sequence of text lines in the display window. When changing the sort order (by clicking on one of the buttons), the entire text window is deleted and all the lines re-written. When you search on one of those screens, the search always starts at the top of the text window and finds the first occurrence of what you searched for, positioning the scrolling so it's the top line visible (unless it's in the last few lines).

So, with the current early implementation, to see something in a group, first click on a sort button that will group it that way, then search for it. As an example, if you want to see all the SigInt for Hanoi you first sort by "Target/Date", then search on Hanoi. That technique will work for anything that is first on a "Sort by..." button in any of those three screens (SigInt, Ships, LCUs).

I think that might have cleared up the first question, which seems to be about current function?

The second part:

quote:

Is it possible to say search for battles that took place at a specifi location and show the set of them?

The current Battles implementation is a little bit different. It only shows one battle at a time, searching by Battle Number or by advancing "Previous" or "Next". I do indeed want to implement the sort of query you describe. I've been planning to get the data into a database that will support more complex queries, not to mention stop reading in all the files in the archive folder every time the program runs! The current displays are intended to be totally re-worked, so that instead of a series of text lines they are actually data fields displayed.

So, it will take a bit of doing and the only question is should we do an early version of that function or what until more things are re-worked internally? That also includes getting the other basic functions running (combat report tabs for Troop and Aircraft, plus operations report and combat events) so I know what their data looks like.

That's a mouthful but it's just to convey the big picture that I have in in mind. I would like to hear your opinion about short term versus long term functionality. For example which would that sort of Battles report (grouped by location) fall into? What other short term stuff seems important?

Is it possible to say search for battles that took place at a specifi location and show the set of them?

Roger

As an aside (I still want your opinion on short-term versus long-term stuff), I've been checking and I have some of the necessary structure built in, but it's not what I used to get the current "Battles" tab up and running quickly. How would it be if I left the current Battles tab as is (until it gets ripped out one day) and work on adding a second Battles tab with that kind of search & filtering capability?

The ability to look at one location and see over a period the changes in the battle conditions is very useful. I am currently doing it via a very long winded process and what you are producing is a real time saver.

So, with the current early implementation, to see something in a group, first click on a sort button that will group it that way, then search for it. As an example, if you want to see all the SigInt for Hanoi you first sort by "Target/Date", then search on Hanoi. That technique will work for anything that is first on a "Sort by..." button in any of those three screens (SigInt, Ships, LCUs).

I think that might have cleared up the first question, which seems to be about current function?

Yes I see that works, on location or on hex pairing. Can live with that (lol) but as you say eventually into a DB format will give a much greater degree of granularity of searching.

quote:

The current Battles implementation is a little bit different. It only shows one battle at a time, searching by Battle Number or by advancing "Previous" or "Next". I do indeed want to implement the sort of query you describe. I've been planning to get the data into a database that will support more complex queries, not to mention stop reading in all the files in the archive folder every time the program runs! The current displays are intended to be totally re-worked, so that instead of a series of text lines they are actually data fields displayed.

So, it will take a bit of doing and the only question is should we do an early version of that function or what until more things are re-worked internally? That also includes getting the other basic functions running (combat report tabs for Troop and Aircraft, plus operations report and combat events) so I know what their data looks like.

That's a mouthful but it's just to convey the big picture that I have in in mind. I would like to hear your opinion about short term versus long term functionality. For example which would that sort of Battles report (grouped by location) fall into? What other short term stuff seems important?

I'm replying to Roger, but I'm really seeking everybody's input too.

All the above seems fine to me. From my own point of view the movement on this has been rapid and has provided me with enough of a glimpse of where it could go to stop me doing other analytical work - which took ages - because this is going to be so much faster when done. Given most of us are in dynamic ongoing games I'd go for short term messy stuff, and the polishing and database can come once the basic stuff is available. If we have the basics in to play with then we have the main stuff, the rest is nice but can take longer, and to an extent without the basics we don't know how the more detailed databases stuff would be best done...

OK. In essence "getting something useful out there" has been my approach, both from a delivery standpoint and to get more (and better) information on what things should really look like. You've given me some very useful feedback on how battles information is being used (even prior to IM, of course), which in turn instructs me in how to store, process, and present battles information.

The other piece is more along the lines of 'what to do first?' In terms of the basic functionality we have on the plate:

- Improving the capture of LCU information from the combat report. Currently all LCUs involved in ground combat are captured. But LCUs that are the recipients of naval or air bombardments are not captured, nor are those noted in amphibious landings, etc. Only ground combat (whether bombardment, deliberate, or shock attacks). This could require significant attention, depending on what is required to actually solve the problem. Might be a bit of a quagmire.

- Implementing the capture and display of Troop information from the combat report.

- Implementing the capture and display of Aircraft information from the combat report.

- Implementing the capture and display of information from the operations report.

- Implementing the capture and display of information from the combat events report.

- Implementing a much improved, and specific, Ground Battles tab (or window), including: * Ability to filter on locations. * Ability to filter on dates. * Ability to show groups of battles. * Ability to show summaries of key data (Unadjusted Assault value, Adjusted Assault Value, Troops, Guns, casualties, etc.). * Ability to show calculations (ratio of Unadjusted AV to Adjusted AV, ratios, given the current battle's odds and AV ratios - what the next Odds result would look like if all factors were the same, etc.)

- A natural complement of Ground Battles tab would be a Naval Battles tab.

The first item, additional LCU data, is somewhat speculative. The next four, troop and aircraft data from the combat report, the operations report, and the combat events report, will certainly provide less return than the items implemented so far. The Ground Battles tab could be the first one to start providing some advanced capabilities of both reporting and analysis.

The game, because its a game and is nice and neat formats all the information in different 'information streams'. You have ops reports, sigint reports, combat reports etc etc.

In reality in HQ there's somewhere a file or index card with the various fragments being added all the time. Some will be hard evidence, some will be sigint, some will be FOW stuff. But the game keeps this stuff separate. I am doing a 'fun' job of pulling some info from Combat Reports, but that does not capture the sigint or the ops stuff.

In essence all activity happens somewhere to something, at some time. So the best tool is one that allows the combination of all the information together in one big database that then can be searched/filtered according to:

Where it happens When it happens What participates What happened (less essential)

So if I am interested in lets say Koepang, I want to know the 'dossier' on Koepang which will involve any combat, and bombardments, any landings, any flights, any air intercepts, and sigint, etc etc. Some intel guy will bring that to my desk in HQ..... I won't have to go and ask for five different files....

So the best tool is one that takes all the information and stick it all into a growing database that is searchable as above.

There may be a danger in developing IntelMonkey as a whole series of interesting information streams that don't easily give the big picture....

Only you know how much time and effort any of this is taking you. It might be worth playing with the ground one and seeing what level of detail can be extracted, if that's the way forward, and the lessons learned from that, and the feedback would then make the implementation of other aspects simpler and more 'shaped' by user feedback.

In essence develop one aspect as far as you choose and see how useful it is, a narrow thrust rather than a broad Front assault.

1st let me say how grateful I am that you have built this tool. I went out and bought a book on Java just so I could start analyzing the intel reports. An then a week later Intel Monkey comes out.. sweet!

So I'm just trying it for the 1st time today. I was surprised to see that the 'E' boat "astern Army" was spending all of it's time in Tokyo.

1942-03-04 E astern Army - - is located at Tokyo 114,60 1942-04-03 E astern Army - - is located at Tokyo 114,60 1942-04-16 E astern Army - - is located at Tokyo 114,60 1942-05-05 E astern Army - - is located at Tokyo 114,60 1942-05-21 E astern Army - - is located at Tokyo 114,60 1942-05-30 E astern Army - - is located at Tokyo 114,60 1942-06-04 E astern Army - - is located at Tokyo 114,60 1942-07-06 E astern Army - - is located at Tokyo 114,60

Must be the Navy equivalent of a hanger queen. I guess any boat that only goes backward and is operated by the Army is an oxymoron.

1st let me say how grateful I am that you have built this tool. I went out and bought a book on Java just so I could start analyzing the intel reports. An then a week later Intel Monkey comes out.. sweet!

So I'm just trying it for the 1st time today. I was surprised to see that the 'E' boat "astern Army" was spending all of it's time in Tokyo.

1942-03-04 E astern Army - - is located at Tokyo 114,60 1942-04-03 E astern Army - - is located at Tokyo 114,60 1942-04-16 E astern Army - - is located at Tokyo 114,60 1942-05-05 E astern Army - - is located at Tokyo 114,60 1942-05-21 E astern Army - - is located at Tokyo 114,60 1942-05-30 E astern Army - - is located at Tokyo 114,60 1942-06-04 E astern Army - - is located at Tokyo 114,60 1942-07-06 E astern Army - - is located at Tokyo 114,60

Must be the Navy equivalent of a hanger queen. I guess any boat that only goes backward and is operated by the Army is an oxymoron.

Cheers, Guy javascript:void(AddText(''))

Good job! I just noticed that myself and was on the way here to post it.

Second one, also in SigInt: If the 'actor' is "Radio call sign of CV Akagi" or any ship, that is being missed as a ship. This SigInt message is in a different format from the others, with what I interpret as the 'action', namely "Radio call sign of" being at the beginning and then followed by the actor. I'll have to code to catch it farther upstream when the records are first parsed.

The rest of it - moving to, Georgetown, hex # - is fine. But the actor part is rough.

What's the best way to handle that? My first thought is: - Catch the ship type (DMS) and put it in the Type column. - Make the Actor column blank so it will sort differently than specific named ships. - Put the class in the Optional #1 column (in this example as "W-17 class").

The rest of it - moving to, Georgetown, hex # - is fine. But the actor part is rough.

What's the best way to handle that? My first thought is: - Catch the ship type (DMS) and put it in the Type column. - Make the Actor column blank so it will sort differently than specific named ships. - Put the class in the Optional #1 column (in this example as "W-17 class").

What do you think?

Good Evening,

In my humble opinion the output should be like:

Date DMS W-17 Class is - - moving to Georgetown

Which would involve parsing the "W-17 Class" as the actor. All that class would sort together and superb human eye would do the rest of the correlation required.

The rest of it - moving to, Georgetown, hex # - is fine. But the actor part is rough.

What's the best way to handle that? My first thought is: - Catch the ship type (DMS) and put it in the Type column. - Make the Actor column blank so it will sort differently than specific named ships. - Put the class in the Optional #1 column (in this example as "W-17 class").

What do you think?

Good Evening,

In my humble opinion the output should be like:

Date DMS W-17 Class is - - moving to Georgetown

Which would involve parsing the "W-17 Class" as the actor. All that class would sort together and superb human eye would do the rest of the correlation required.

Cheers, Guy

Extending that logic to the next post, "a Japanese xAK" would be Type "xAK", Actor "Japanese". Make sense?

For this record the 2nd actor is a generic so there would be no need to double the records. HOWEVER it would be very difficult to encode a set of rules that would reliably tell the difference between a generic and actual actor. Since having actor/actor records doubled would be very handy it is most likely worth the small cost of doubling the actor/generic records.

1942-06-11 - 16th Recon Regiment is loaded on a Japanese xAK moving to Manila -

This bunch of records calls out for a more sophisticated parsing but the correct approach is not obvious.

For this record the 2nd actor is a generic so there would be no need to double the records. HOWEVER it would be very difficult to encode a set of rules that would reliably tell the difference between a generic and actual actor. Since having actor/actor records doubled would be very handy it is most likely worth the small cost of doubling the actor/generic records.

1942-06-11 - 16th Recon Regiment is loaded on a Japanese xAK moving to Manila -

This bunch of records calls out for a more sophisticated parsing but the correct approach is not obvious.

SigInt: - Added that a ' ' has to follow a ship type at the front of Actor. 'E' at the beginning of LCU names was being picked up as a ship type. - Added logic to handle 'Radio call sign of CV Akagi...' (for example). - Added 'is moving to' as a parsing term as the term 'moving to' was leaving ' is' as part of ship names. - Added logic for 'a xxx class xxx' as the Actor. - Added logic for 'a Japanese xxx' and 'a(n) Allied xxx' as the Actor.