Matrix Games Forums

I haven't tried RHS, but believe that this can work within that framework / mod.
Bit daunted by all the different scenarios, but will download and play with it to see if this is a possibility...
Got to get to programming now, so hopefully, I can get the plane production screen completed ... and screen shots later today.

Some really nice idaes...
Great stuff.

Where we can get it for testing? [;)]

ORIGINAL: n01487477

I haven't tried RHS, but believe that this can work within that framework / mod.
Bit daunted by all the different scenarios, but will download and play with it to see if this is a possibility...
Got to get to programming now, so hopefully, I can get the plane production screen completed ... and screen shots later today.

Since this program reads everything from the save game file, I see no reason why it wouldn't work for all scenarios and all mods. My testing has been with a stock scenario and Damian is using BigB. We're also using both Allies and Japan, so it should work for both sides.
Also, the bits that show the ship and plane sides come from the ART folder, so whatever art you have installed should be shown.

Floyd

ORIGINAL: floydg

ORIGINAL: n01487477

I haven't tried RHS, but believe that this can work within that framework / mod.
Bit daunted by all the different scenarios, but will download and play with it to see if this is a possibility...
Got to get to programming now, so hopefully, I can get the plane production screen completed ... and screen shots later today.

Since this program reads everything from the save game file, I see no reason why it wouldn't work for all scenarios and all mods. My testing has been with a stock scenario and Damian is using BigB. We're also using both Allies and Japan, so it should work for both sides.
Also, the bits that show the ship and plane sides come from the ART folder, so whatever art you have installed should be shown.

Floyd

please make the installation of the programm as easy as possible for dumb users like me...

ORIGINAL: Feurer Krieg

Nice work guys.

I'm a big user of Woos utility, but you have some nice ideas. The only problem for me is that given that I use Bodhi's utility for the intel/ops/battle tracking, Woos for naval search, upgrades and production - I don't know if I will have time for another thing to load and save each turn.

Would be nice if y'all could get together and build one program with the best elements of each.

Or better yet - if the AE team folded in some of these types of reports/screens into the main game interface.

Adding lots of stuff like is in WOOS tool to the game interface, is not hard, but it would be very time consuming. So much so, that simplistically speaking, we could either have this, or have the enhancements we got, but not both. And we said, hey this already exists, and people like it, and it is far less work to intergrate it in, than to build it again, so it seemed like a no brainer to go the way we are going.

The issue will be that the new save file will not be as open to all as it is now, so it will be problematic to switch over all of the existing utilities.

I'm not quite sure I'm reading this correctly, can you please confirm.....

1. AE will not allow any of the Bodhi, Woos, or this interface to interface with it?
2. AE will have something based upon stuff (Bodhi/Woos) that already exists?
3. AE would allow people to create interfaces like this, but by being allowed into the 'black box'?

Or is it that really you aren't sure yourselves yet given where you are in the project?

I did catch a posting from WOOS shortly after news broke on the AE edition that suggested he was in fact working within the development or alongside it..... but he's not listed as part of the team.

I'm just seeking clarification for people and especially for the guys doing all this work outside of the AE team.

Roger

ORIGINAL: Roger Neilson II

I'm not quite sure I'm reading this correctly, can you please confirm.....

1. AE will not allow any of the Bodhi, Woos, or this interface to interface with it?

Bodhi's tool is based on the txt-files, not the save game, so it will work with AE, too.

ORIGINAL: Roger Neilson II

I did catch a posting from WOOS shortly after news broke on the AE edition that suggested he was in fact working within the development or alongside it..... but he's not listed as part of the team.

He's in the list.

A modified Bodhi's should work with no problem, his uses the text files that are generated when the turn is run. No need to get into the program for that. Woos does get into the savegame file, good to know he is on the inside this time. I'm sure his current utility would not work with AE.

Darn, I need to learn to type faster. [:(][;)]

Ok, that's useful to know, but I foresee a situation where running a game I'll have Bodhi's tool running, Woos tool running plus this new one...... all this begs for one comprehensive pulling together - I know, I know, time, resources, ability to programme. I look at the guys doing this in amazement - I last did some programming in the 1980s using machine code.

Roger

ORIGINAL: Roger Neilson II

I'm not quite sure I'm reading this correctly, can you please confirm.....

1. AE will not allow any of the Bodhi, Woos, or this interface to interface with it?
2. AE will have something based upon stuff (Bodhi/Woos) that already exists?
3. AE would allow people to create interfaces like this, but by being allowed into the 'black box'?

Or is it that really you aren't sure yourselves yet given where you are in the project?

I did catch a posting from WOOS shortly after news broke on the AE edition that suggested he was in fact working within the development or alongside it..... but he's not listed as part of the team.

I'm just seeking clarification for people and especially for the guys doing all this work outside of the AE team.

Roger

WOOS is on the AE team ... so an AE version of his tool kit will be packaged in with AE.

Other utilities that rely on reading the current save files will not work with AE because AE has a different file format and the save file will be encrypted.

ORIGINAL: jwilkerson
WOOS is on the AE team ... so an AE version of his tool kit will be packaged in with AE.

Other utilities that rely on reading the current save files will not work with AE because AE has a different file format and the save file will be encrypted.

Thanks for that information.
I guess we need to decide if we spend our efforts on our program for "Classic" WitP only, or on trying to influence the AE team to adopt some of our ideas.

Nice tool. It seems to go into the direction of "show everything possible" where I tried to limit data to the things I consider important and not available from within WitP. The latter approach keeps things easier understandable, the former doesn't limit people to the data the programmer found important. BTW, the next version of WitPdecoder (publication currently hanging on some red tape cutting [correct idiom?]) does also have a AC class overview (including the patented snake-oil *cough* battle-deciding Anti-Fighter, Anti-Bomber and Bombing ratings) and some better information on repairs (in the Map Overview tab).

Some warning on directly reading the save game files. There are lots of suprises hidden inside as can be seen from the constant stream of fixes for WitPdecoder necessary to handle special cases. And RHS had an especially high number of exceptions and is thus not supported by WitPdecoder (and I didn't hear from anyone who successfully used wiptDecoder on RHS). So witpTracker running on stock and BigB doesn't necessarily mean it also works with RHS. BTW, do not forget to correctly handle passwords.

For being able to use your tool with AE you could use the CSV dumps of witpDecoder (which will stay with AE as they don't reveal any information unknown to the player). The problem with them is of course the constantly changing DB format. Since they are generated automatically by the HSQLDB engine every schema change will be visible and can break any read-in routine. Another possibility would be for me to allow also table plugins for WitPdecoder (next version currently only has a plugin that can draw onto the map in the Map overview tab, which is useless for most the information you show there). But that's probably a bit more complicated due to use interaction requirements.

And finally, any chance to dump your region assignments into WitPdecoder compatible clusters.csv and clusterbases.csv files? Would probably increase the number supported scenarios if people wouldn't have to edit .csv files in a spreadsheet program.

Woo,
thanks for your post, I don't believe we are trying to reveal "secret information", our purpose is to analyse the data in a more meaningful or useful way. I think your tool is terrific...we just wanted to extend that vision, and make the data more transparent, and more meaningful than it already is to the end user. Understanding can sometimes be found easier, in the little things.

In hindsight, I haven't really written a well explained essay here, or outlined many of our ideas, but it is 2 am ... so please excuse any failings on my part to explain adequately... here goes...

This is about having quick analysed Macro information, plus, the ability for the user to really understand what is happening, through micro historical game data.

Of course you're right that concise information is more understandable, but by providing more analysis and prediction, we can surely help users make more meaningful decisions in their production / logistical / strategic choices.

For instance, if we just showed all the air group data, with no aggregates/analysis, it would be meaningless, however if we add the dimension of showing average plane losses, incoming groups, their arrival date, the number of engines available and what might likely be produced by a certain date and potential upgrades ... thus analysing and (sometimes haphazardly - av.losses)predicting the future - thus giving meaningful warnings/advice, it would be easier for the user to calculate industrial requirements (build capacity - actually the program will do this)and make logical decisions - expand, halt, switch.
(see screen shot of my access DB, from your csv's - for small direction of what I envision here)

Ok, we don't want an automated system, the beauty for me, playing as the Japanese, are the choices I can make production wise, eg. accelerating ships or aircraft types. But wouldn't it be nice to determine out of a list of ships yet to arrive, what can be accelerated without the paper and pen calculations or LCU reinforcements, what to turn on / off regarding equip availability.

Similarly, with production, it is not just the aggregates, but what needs to be shipped, when and to where. Using base supply etc (then regional)information, and it's Qty reduction, can't we give a prediction as to when and what needs to be supplied. Shouldn't we also be able to see what ships are en route, with what and how long before they arrive ? I know the TF in game data does some of this, just not in a well organised way.

Regional and base consumption of resources etc, are not that interesting, but given tabular or graphical historicity, they jump to life, ala your fine program. By also calculating what surplus there is, and will be, surely we can also advise on expansion ... fb.asp?m=1612397 (some elements here - without the expansion)

Of course aggregates are important, such as a count on ship losses,(how many ppl hate counting these for their AAR's?)
fb.asp?m=1625019
But there are nut cases, like me, who just desire as much as possible when I want it, such as analysing all the pilot information(mission/experience increase etc) but and also having the ability to see a quick "to do" list...

Or taken the fact that plane factories, in the industry screen, show limited information why can't we show this ... and (beyond the scope of this program) maybe within AE, allow users to just show all the plane factories, and organise it centrally, instead of ferreting around, writing notes and jumping from base to base ... fb.asp?m=1579085

Some of our ideas are pipedreams, but many are useful, and I hope others will find them as such, so maybe you can have a look at this when it's semi-finished or use some our thoughts within AE ... but then, that is also up to the users desire & hopefully your teams willingness to listen to some fresh perspective, even if it is late to the party.

I don't want to burden, the team with unnecessary coding/testing as I like everyone else is eagerly anticipating this add-on, however, if the savegame file is to be encrypted, then programs like this will be useless, and we will have no choice, so can we please make these info screens useful?

Lastly, I speak for Floyd here,(he had the foresight to implement this) but the base clusters are fully dynamic and editable within the program, there is no fiddling outside the program.

Sincerely, Damian

Since a lot of players (including me) will continue playing their "classic WitP" PBEMs after the release of AE, I hope you two will continue working on your tool.

Hi Damian,

ORIGINAL: n01487477
Of course you're right that concise information is more understandable, but by providing more analysis and prediction, we can surely help users make more meaningful decisions in their production / logistical / strategic choices.

For instance, if we just showed all the air group data, with no aggregates/analysis, it would be meaningless, however if we add the dimension of showing average plane losses, incoming groups, their arrival date, the number of engines available and what might likely be produced by a certain date and potential upgrades ... thus analysing and (sometimes haphazardly - av.losses)predicting the future - thus giving meaningful warnings/advice, it would be easier for the user to calculate industrial requirements (build capacity - actually the program will do this)and make logical decisions - expand, halt, switch.

You might want to look into Data Mining (once you have the basics running), since a lot of what you write sounds really near to the requirements for it. E.g. running some self-learning clustering algorithm (or one specified by you) might help the user find commonalities between his airgroups (or LCUs, ...) which are difficult to find with the naked eye. Of course the problem might be that the clusters found do not reveal any new information (e.g. all the fighters deployed in Burma landing in a different cluster than the fighters deployed in the NEI).

ORIGINAL: n01487477
Similarly, with production, it is not just the aggregates, but what needs to be shipped, when and to where. Using base supply etc (then regional)information, and it's Qty reduction, can't we give a prediction as to when and what needs to be supplied. Shouldn't we also be able to see what ships are en route, with what and how long before they arrive ? I know the TF in game data does some of this, just not in a well organised way.

I think this paragraph nicely defines the difference between witpDecoder and witpTracker. At least as I see it. I wanted to write a tool which provides enough information to a (somewhat) experienced player (= me) to play WitP by the seat of his pants (e.g. one sends resources to an industry cluster if reserves near 50 days worth). witpTracker on the other hand seems (as far as I understand you) to intend to provide the ability to predict more exactly what is needed (like e.g. "I have to send either a convoy from Brunei latest if 24 days are left or from Palembang if 28 days are left"). This definitely helps new players who don't know the rules of thumb and allows experienced players to play more at the limit (improving performance). The disadvantage of the second approach in my eyes is possibly a tool more complicated to use and surely a tool more complicated to program. Specifically the latter means that witpDecoder will not do it (but maybe someday plugins will allow other people to include such functionality).

ORIGINAL: n01487477
Or taken the fact that plane factories, in the industry screen, show limited information why can't we show this ... and (beyond the scope of this program) maybe within AE, allow users to just show all the plane factories, and organise it centrally, instead of ferreting around, writing notes and jumping from base to base ... fb.asp?m=1579085

This lack of central industry control is one of the gripes I had with the WitP UI which brought me to writing witpDecoder. Look at any other game with an economic component and you will find that there is a central way to influence your production. Not so in WitP where you have to go through bases. Not very solvable with an external, data displaying tool, alas.

ORIGINAL: n01487477
but then, that is also up to the users desire & hopefully your teams willingness to listen to some fresh perspective, even if it is late to the party.

My team?
*looks around*
Damn, where did they all go?
Hmm, has there ever been one?

If you talk about the AE team as a whole, I think it has been decided that a lot of the data presented by WitpDecoder cannot be easily shown by WitP itself (but you would have to ask Joe about that). That's why there will be a WitpDecoder (possibly with different name) for WitP-AE.

I like Bohdi's utility in large part because it organises intel data similarly to what I'm used to. I'd like to see an effective moving ships tracker algorithm added, but that would be a really big deal, involving input from my current research in autonomous robot control.

Damian and I will continue to work on this program.
When AE comes out, we will then decide what to do next.

ORIGINAL: herwin

I like Bohdi's utility in large part because it organises intel data similarly to what I'm used to. I'd like to see an effective moving ships tracker algorithm added, but that would be a really big deal, involving input from my current research in autonomous robot control.

I'm not sure what you mean by "moving ships tracker algorithm". Do you mean tracking the movement of enemy ships?

ORIGINAL: floydg

ORIGINAL: herwin

I like Bohdi's utility in large part because it organises intel data similarly to what I'm used to. I'd like to see an effective moving ships tracker algorithm added, but that would be a really big deal, involving input from my current research in autonomous robot control.

I'm not sure what you mean by "moving ships tracker algorithm". Do you mean tracking the movement of enemy ships?

The knee-jerk engineering solution would be a Kalman filter, but that has a series of weaknesses:
1. A Kalman filter is an optimal linear filter, but ships follow curved paths (geodesics or rhumb lines).
2. Ships maneuver or sail to waypoints and change course. Kalman filters are too dumb to pick up on situational clues or take account of how ship captains actually maneuver their ships.
3. The expansion of the covariance matrix for the Kalman filter over time does not model how ship tracks become uncertain after a few days off the screen.

On the other hand, a non-linear filter can be faked out by deceptive tactics and will be sensitive to the order and timing of updates to tracks. Association of track reports to the correct track is also a hard problem--we run into this in auditory scene analysis.

So I use the Bohdi utility and draw my own conclusions from the pattern of reports. If you provide something similar, the reports should be colour-coded in some obvious way based on how old they are.