Matrix Games Forums

ORIGINAL: scout1
If I have 4 games, slots 005, 006, 007 and 010, all of which are the same exact scenario, I still need an independent subdirectory for each fully populated to run the info on each. True ? Not complaining, just want to make sure I follow directions ....

Why do you continue to ask questions which I have answered before, here in the forum and in the tool documentation (which is now even seperately downloadable) ....

ORIGINAL: scout1
And since I haven't gotten that far yet, is the info provided available to be printed for offline evaluation ? IE is it limited to screen viewing only or are there options ?

.... and others which can be easily found out by just using the tool? Answering these questions costs time, which I can better use for improving the tool or using and thereby testing it.

From witpDecoder.log

Sorry, but couldn't load it from the machine I was on. Will dive in and "attempt" to keep my questions more focused.....

[X(] [X(] [X(] [X(] [&o] [&o] [&o] [&o] [&o] [&o] [&o]

Excuse me while I <DROOL> over that industry screen..........

OMG, what am I going to do with all my spreadsheets??!! I might just have enough time to start another PBEM. [:D]

ORIGINAL: Mike Solli

OMG, what am I going to do with all my spreadsheets??!! I might just have enough time to start another PBEM. [:D]

[:D] [:D] [:D] Better find a good lawyer, Woos! I predict there is a future in divorce court as an "expert witness" for you. [:D] [:D] [:D]

ORIGINAL: Mynok
Excuse me while I <DROOL> over that industry screen..........

Be aware that it has a few problems.
A) As stated in the doc you have to create a list of bases per cluster (Japan, Taiwan, ..) by hand for each new map (and possibly per scenario if that changes bases).
B) It has no idea if all the bases in the cluster have an uninterrupted connection and can thus exchange their resources and oil. E.g. if you would attack the Soviets and take Okha in the first turn, its oil storage and production would be counted in the "East China, Korea, Russia" cluster even though its oil could not be used automatically by any factory in that cluster until the Russian lands opposite of it are taken also (on Andrew Brown's map their is an oil pipeline). So use with care!

Knowing what bases are connected is the easy part. Adding up all the industry, resources, oil and making calculating what the needs are.....that's the time consuming drudgery.

WOW!! [X(][X(][X(]

I just found this!!

Amazing!! [8D]

Thanks Woos, [&o] I'm going to try it out. It looks just great!

So we can assume that security of PBEM is breached...[&:]

Great tool anyway...
I would prefer those functions included in game though

i can't download new .jar file
object not found error

Now that I learned about the next complication in the save file format for bases it seems about time to explain why using a DB with integrity constraints is a good thing and dumping data into a file in various ways as WitP does is bad. Maybe some people at Matrixgames will learn.

WitP save files contain information about bases. Even information about bases not used. Normally a base is not used if its type is set to 0. That is except for dot bases, which use a secondary type indicator, which, if set to "base" even if the primary one is 0, indicates a dot base. That is unless it is a special kind of dot base which even has the secondary indicator set to 0, too. I don't know what is special about them, so the only way to distinguish them from non-existant bases is to check whether they have a position defined. So, to get you all back on track, it is a base
a) if its type is set or
b) if the type is 0 but the secondary type is set or
c) if both types are 0 but the position is set.

Can you still follow? Well, now the interesting question, when is an entry in the save file not a base? You think you know it? Well, forget it. In addition to everything you might think because of the above statements a base is also not a base if
a) its type is set but
b) its position set to -1,-1.
Completely logical, isn't it? I mean just setting the type to 0 wouldn't have been an alternative.[:@]

Not imagineing such a complication is the reason for the error "Some Dude" reported above and will currently prevent the use of witpDecoder on any restricted scenario (e.g. the Coral sea scenario). * Edit * Coral Sea scenario will never be supported by witpDecoder. After solving the above problems it turned out that also the Truk base is used as Headquarter for the "Truk Base Force". Now that is an interesting hack given the WitP save file format but can not be supported in witpDecoder which - for good reasons - dinstinguishes between bases and LCUs.

Now, how did I find it (and why are integrity constraints so great)? Well integrity constraints let you formulate your understanding of the data you intend to store. witpDecoder for example tells the DB that it assumes that all bases will have different positions (quite obvious if you look at the map). Storing the second base with a -1,-1 position into it the DB complains with the exception seen in Some Dude's posting. Result: Report is investigated and error found and fixed instead of lots of headaches later on why other functions don't work as expected.
Using an DB and formulating into it that the leader part of the ship-leader relationship needs to be unique would have found the leader bug long ago. Now it is still in and I can't put that constraint into the witpDecoder DB unless I want to prevent lots of people from using the tool.

OK enough ranting. Answers to the questions:

ORIGINAL:Arkady
So we can assume that security of PBEM is breached.

Please read the section on "PBEM security" in the documentation (available seperately via a link in the first post).

ORIGINAL:Sneer
i can't download new .jar file
object not found error

witpDecoder2.jar was an intermediate version between 0.1 and 0.2. Now that 0.2 is out I removed it since you don't need it anymore (and it would break things).

Now that I learned about the next complication in the save file format for bases it seems about time to explain why using a DB with integrity constraints is a good thing and dumping data into a file in various ways as WitP does is bad. Maybe some people at Matrixgames will learn.

A-freaking-men!!!! [&o] With all the *free* database engines out there now with full referential integrity functionality, there is zero excuse to not use one for a game of this scope. ZERO. Oh....and they were available when UV was being designed too.

One of my favorite slides ever is from Tom Kyte, an Oracle developer. It is part of his worst practices seminar and it reads:

Probably you should reinvent as many database features as possible

[:D]

Excellent tool & great work Woos, can't wait for the Allied side to come out even though it won't help much in the industry side for most but in my custom CHS I've made some a/c factories for certain a/c instead of a flat rate so interested in seeing how they come out.

ORIGINAL: Mynok
A-freaking-men!!!! [&o] With all the *free* database engines out there now with full referential integrity functionality, there is zero excuse to not use one for a game of this scope. ZERO. Oh....and they were available when UV was being designed too.

WitP suffers from some of the same problems many major programs like MS Word suffer from, their roots are very long. UV added a graphical interface and some improvements to the old DOS game Pacific War. I would not be surprised at all if the databases in WitP were essentially the same format as the original game. Some fields may have been added over time, but I would bet it's essentially the same.

Back when Pacific War was developed, it was rare to have a game with a database big enough to have to worry about things like referrential integrity. The programmers of those early games probably had little or no experience with any kind of database.

I wouldn't be surprised if the data is the way it is simply because it's based on a very old game engine.

Bill

I think you nailed it, wdolsen. We are dealing with software paleontology.

Watching this thread with interest.&nbsp; I want to see how it turns out when you finally get the Allies up and running.&nbsp; Looks very promising so far.

Just installed the tool - BRILLIANT [&o]
Now all I must do is remember to upload the savegames before they get overwritten

I beleive you only need the latest savegame, anyway.

ORIGINAL: Knavey
Watching this thread with interest. I want to see how it turns out when you finally get the Allies up and running. Looks very promising so far.

Currently I'm adding support for "automatically appearing" resources at bases (like e.g. United States and lots of Chinese bases). The Japanese don't have that so their is no support in V0.2, the Allies rely heavily on that so not including it would give wrong values on the Storage and Industry tabs.

Then one of the next thing will be to include a "Nationality" object, which will abstract the now hard-coded knowledge of how to get only certain things into/out of the database. While I'm at it I'll probably also add "IJN","IJA" as well as "Chinese", "Russian", "CW", ... as different nationalities to support people playing m vs n games to only get vague information about the other "friendly" nationalities. Once that is done, some GUI changes are needed, the up-front DB initialization needs to be shifted around and then its ready.
I think I predicted 2 weeks of Japanese-only happyness about half a week ago. That's still about right. I also want to play the game after all.


And Dino is correct, currently most of the history functions are not implemented, so loading lots of old savefile yields no advantage (after the first 5 the "5dayAvgGain" column in the storage tab should fill). Additionally the next version will change the database format (so you will have to read in all old savegames again). And before at least V1.0 is reached the database format will continue to change from time to time. So currently no need to have a lot of save games read into the tool as long as you have the latest 5.