Matrix Games Forums

Thanks scott, but it turned out to be a classic windows fix. I had a power surge and the computer shut down......... I figured why not[8|]
now it works (Thanks for your replies Woos)

Soooooooo - anybody have my problem - just restart the stinking box. Hope it works for you, now I can rest.

Scott - I must have deleted a dozen db s and reloaded the tools folder another half dozen times. But now WHOOOOPPEEEE!!!!!!!!

[8|] I guess i shall have to play without the WITPstaff.
Back to pencil and paper.

Sunderland,

problem acknowledged. The save game contains a (non-existing) base number although the unit is not moving to any base. Now I have to find out if there is any intention behind that. Alas I know no easy fix for you.

Kaleun,
You neither answered my questions nor send a savegame. That makes it difficult to help.

Woos,

I have been getting the same error reported by Sunderland. The first occurrence of this error was on the first turn that I did a "Reserve" order for a land unit, where it then followed a retreating enemy unit. This may have just been a coincedence, but I thought I'd let you know, just in case it helps with some bug-killing in the game. Thanks.

Enhancement suggestion.

in the sea/ship classes tab, it would be really, really handy to have the rearm level of the largest battery.

Stupid question time..where can you download it from ? [8|]

woos
 
thnaks for the Info. My workaround for anyone whos interested, and wants to use WITPstaffwho has this problem ( and I do being a wannabe sad logisitcs geek who wants to avoid using pen and paper) is to play the game as normal, and if when you load a turn into WITstaff there is a problem, look at the log file, see which unit is causing the problem, reset its destination and save again within AE, then load that turn again in WITPstaff. So far its worked, and the same unit does not seem to cause a problem go to go. I asusme the data i am interested in ( use of resources etc, who is in supply and not, is not affected.

woos
 
i think I saw a similar issue to Apbarog in a leter turn to the one I sent you which was also when a unit set to reserve followed up and moved into the next hex

ORIGINAL: 51st Highland Div

Stupid question time..where can you download it from ? [8|]

WitpStaff is actually installed when AE is installed. In your start menu you should see the option for Witpstaff.

Two things:
You do need to download a hotfix DLL = tm.asp?m=2178234

If you have trouble running from the start menu under Vista, you need to directly execute the Java file, IIRC. I don't have a thread reference handy but look in <AE install>/tools/witpstaff for a witpdecoder2.jar file and just open that (or create a desktop shortcut)

Cheers thanks for that [:)]

ORIGINAL: apbarog

Woos,

I have been getting the same error reported by Sunderland. The first occurrence of this error was on the first turn that I did a "Reserve" order for a land unit, where it then followed a retreating enemy unit. This may have just been a coincedence, but I thought I'd let you know, just in case it helps with some bug-killing in the game. Thanks.

Make that three of us now. And like apbarog, my issue is with a reserve unit which started a pursuit.

Make that three of us now. And like apbarog, my issue is with a reserve unit which started a pursuit.

I have reported it in WitpAE's bug tracking system but got no answer yet. People are probably busy fixing bugs which are relevant for WitpAE and this one is not.

Does any of you a previous save (i.e. before the Pursuit)? It might be necessary for the developers to observe turn processing to find out why the value is changed to an illegal one.

I have an example of a pursuit. I cannot say conclusively that this turn is a good example for a couple of reasons. After the first pursuit, much earlier in the game, WitPStaff stopped working, with the error message that someone listed above. So I've been unable to use WitPStaff since, and cannot say that this turn would "break" it. Also, I broke down a division so that I would be able to pursue with part of it for this example. If this example does not help, I'll find one where I can keep the unit whole next time.

Ok, I'm playing as the Japanese versus the AI. Here's the turn where I set up the attack and pursuit. The 6th Division in hex 85,52 near Wuchang is divided into A, B, and C. A is plotted to deliberate attack. B and C are plotted to reserve.

Here is the next turn, after the attack has occurred. B and C pursued but did not move. They did accumulate some movement to the next hex (84,52).

Hope this helps.

Woos tried staff for the first time today and I got the following message.........."java is not recognized as an internal or external command, operable program or batch file...............press any key"

running Vista.

What do I need to do?

Here's a new example of "reserve" movement that may be causing WitpStaff problems.

1/21/42-- At 85,49, 1 Ind Brig deliberate attacks. 13 Tank Rgt and 9 armored Car Co. set to Reserve.

And here is the resulting turn. The attack occurs, the defender retreats, and 13 Tank Rgt and 9 Armored Car both pursue to 86,48.

ORIGINAL: Lord Sunderland

Hi woos

Looked at the logfile- doesn't make much sense to me-"There is a problem with LCU 8000 (22nd/A) as follows:
Couldn't write things to the DB due to java.sql.SQLException: Integrity constraint violation - no parent LCUsMarchOnlyToExistingBases table: LCUStatus
java.sql.SQLException: Integrity constraint violation - no parent LCUsMarchOnlyToExistingBases table: LCUStatus"

When I look at this unit in game it was marching to 89, 56, and was prepping for Chuhsien- Don't see any obvious fault there.

I get the same exception for a different LCU and march location.
Couldn't execute the following command:
UPDATE "LCUStatus" SET "posx"=77,"posy"=59,"prepLoc"=369,"prepPerc"=58,"exp"=55,"moral"=63,"fatigue"=4,"commanderID"=624,"hqID"=74,"targetID"=1,"targetx"=77,"targety"=58,"storedSupply"=264,"requestedSupply"=254,"turnsTillAvail"=0,"isRestricted"=false,"isStatic"=false,"supportGivingSquads"=111,"supportRequiringSquads"=141,"supportNeutralSquads"=0,"disabledSquads"=5,"loadcostAP"=3921,"loadcostAK"=84,"estAV"=125,"estAA"=0,"withdrawDays"=0,"opmode"=0 WHERE "lcuID"=3441
There is a problem with LCU 3441 (1st Ind.Inf.Group) as follows:
Couldn't write things to the DB due to java.sql.SQLException: Integrity constraint violation - no parent LCUsMarchOnlyToExistingBases table: LCUStatus
java.sql.SQLException: Integrity constraint violation - no parent LCUsMarchOnlyToExistingBases table: LCUStatus
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.jdbcStatement.fetchResult(Unknown Source)
at org.hsqldb.jdbc.jdbcStatement.executeUpdate(Unknown Source)
at de.retsiemuab.witpDecoder.a.b(Unknown Source)
at de.retsiemuab.witpDecoder.data.j.a(Unknown Source)
at de.retsiemuab.witpDecoder.data.j.b(Unknown Source)
at de.retsiemuab.witpDecoder.data.p.c(Unknown Source)
at de.retsiemuab.witpDecoder.c.a(Unknown Source)
at de.retsiemuab.witpDecoder.gui.aU.run(Unknown Source)
at org.eclipse.swt.custom.BusyIndicator.showWhile(Unknown Source)
at de.retsiemuab.witpDecoder.gui.bq.a(Unknown Source)
at de.retsiemuab.witpDecoder.gui.W.widgetSelected(Unknown Source)
at org.eclipse.swt.widgets.TypedListener.handleEvent(Unknown Source)
at org.eclipse.swt.widgets.EventTable.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Widget.sendEvent(Unknown Source)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Unknown Source)
at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
at de.retsiemuab.witpDecoder.gui.aQ.a(Unknown Source)
at de.retsiemuab.witpDecoder.Main.a(Unknown Source)
at de.retsiemuab.witpDecoder.Main.main(Unknown Source)



It seems the error occurs if movement to a non-base hex coming from a non-base hex occurs.

apbarog,

Thanks for the saves. Yes, the 6th/B got its destination set to 1 in the second save but didn't have in the first one, so I guess it is the Reserve-Follow action. Also this seems to be a spreading disease, basically all your armor in Yohore Baru had it (I had to set them all to move to Mersing and save again to be able to load the first save).

The interesting thing is that it is always the number "1" the destination field is set to wrongly. In principle this is a legal base number but it is unused in all current scenarios. Maybe that's why it is not causing problems in WitpAE. Well, if it not going to be fixed I will simply assume that setting that field to 1 from time to time is now standard and have the next version of WitpStaff ignore it. Then better don't play scenarios where a base 1 exists


captskillet,

you did read post 1, didn't you?

Glad to hear it, Woos. After playing the first couple of weeks of the campaign game using WitpStaff, I couldn't imagine trying to manage the Japanese industry without it. Looking forward to the next release.