PWHEX PRIMER: Editing and Testing

[el cid again]

Something didn't make sense: I used a pwhex file for days - then all versions of it I had seemed to fail! Stranger still,
a modification of the failed version seemed to work.

As a veteran field engineer, systems integrator and computer consultant, I didn't have a good feeling about that. Since the pwhex in question is my product - I felt some responsibility for the problems it might generate. And since sometimes it worked, sometimes not - I dreaded the worst of all problems - an intermittant one.

I set out to learn by testing what we cannot look up in the technical manual on WITP (because it does not exist). The good news is this: the problem is solid as a rock - you just cannot see it unless you come at it in a somewhat time consuming way.

I also learned that ALL versions of the "current release" - which is 5.42 and 6.42 - are bad. I did an emergency back release of 5.41 and 6.41. Those were the major big deal release - and the "current release" was only a slight enhancement anyway. I will recreate a enhanced version and call it 6.56 and 5.56 - in a few hours.

But first I want to explain things I have learned - for the sake of anyone wanting to modify any version of pwhex
and anyone wanting to understand how to test pwhex - which is not entirely straitforward. I will do this in steps below.

[CobraAus]

Vx.641 is now avail at RHS web site only

I thought vx.655 was the current version and 642 was now outdated

Cobra Aus

[el cid again]

The "current version" of pwhex was 6.42 (and 5.42) - meant to sync with versions of RHS that REQUIRED it to work. That is, if you run x.4 or later RHS you must have x.4 versions of pwhex.

[CobraAus]

ok the - whats version x.655 which I am running

Cobra

[el cid again]

ORIGINAL: CobraAus

ok the - whats version x.655 which I am running

Cobra

OK - I see it. It is an upgrade of x.642 - which also fails. x.641 is two levels back.

[el cid again]

pwhex is not possible to edit using a stock editor - or any Matrix editor. So we use something else. I use WITPExcel.
Cobra probably uses a utility done for him (in Excel I think) by his son. And Andrew says he has his own editor - which very likely is also done in Excel or something very similiar.

These all work fine in some basic sense. But because you must "put" the file (something like a "save" in a high level program) - it is possibly that Windows can mess up the writing of the file if a call to some other process occurs while the put is happening. With a large file, a put lasts a long time - so the chance of a call is high.

I used a bad procedure to modify pwhex using Excel or any similar program: trained to test, test, test, I look at every change immediately - by putting it - and running the program to see if it is right. That means when I do a long list of changes (typically I do about 100 to 200 per edition) - I have done a very large number of puts. In the conditions outlined above, the chance I have a bad put is very high indeed. Not realizing how big the gamble was, I ran it and lost the bet - creating somewhere a fatally flawed file - and all changes after that will not work right.

The RIGHT procedure is to do ALL your changes at one time - THEN do ONE put - THEN check all the changes after that.
Finally - you must then test to see if the program works. More on that next.

[Bliztk]

When I edit something for WitP, I use OpenOffice.

Excel has the custom of changing commas for tabs, thus corrupting everything.

I have 0 errors using OpenOffice, plus it`s totally free

[el cid again]

There is something unusual about the way WITP uses pwhex. You would think - when you make a change - load a scenario or saved game - and look at the display - if you see the changes you just made - you must be running the program - right? And in some sense, you must be right to think that. But not in one critical sense: there is ANOTHER way WITP uses (or at least looks at) pwhex - and it is that way that is fragile and gets busted!

What is unusual is this: pwhex must be actually loaded when you say "run this scenario" or "run that saved game" - and if you (like me) never shut off WITP - you can see all your changes - and say "wow, I got it all right" (or alternately "that didn't work - better try again") - and have no clue you are working with a busted file! Because it actually works fine! Yet you may have just busted it when you did the put. And it may not matter what ap you use when you do the put - I think the issue might be an interaction between ap and Windows - and if I am right about that - ANY put may be corrupted if Windows messes up because an interrupt is pulled. But it MIGHT be just Excel that has this issue. Not sure.

What I am sure of is this: IF you kill the WITP program - shut it down - and start up again - there is some completely different way pwhex is looked at. It may or may not be loaded - but the code looks at it to see if it passes certain tests OR the code tries to use it in a different way - and the program crashes if it is defective. What that means is that you MUST SHUT WITP DOWN before you test pwhex - and you must do this sort of load after startup to see if pwhex is good or not in the way it most often fails? Not understanding this, my test procedure was defective. I was able to create a defective pwhex, and modify it, and never know it was bad - because for me it worked! Or seemed to. Since I could see ALL my changes I "knew" it was "working" - wholly unaware that if you ran the program from startup it would fail 100% of the time. Since I tested each pwhex version 100 to 200 times, I didn't want to take the time to start up from scratch each time. I both optimized my chance of messing up the file and minimized my chance of detecting it. The worst of all worlds sort of thing.

Having figured all this out, I will do all changes in one step, do only one put (or two if I must fix something that didn't change right) - minimizing the chance of a bad put. Then I will shut down, restart and test - to see if it crashes - optimizing the chance of detecting the problem. No matter who you are - or what application you use - if you work on pwhex - I recommend a similar procedure.

[el cid again]

ORIGINAL: Bliztk

When I edit something for WitP, I use OpenOffice.

Excel has the custom of changing commas for tabs, thus corrupting everything.

I have 0 errors using OpenOffice, plus it`s totally free

I am not a big fan of Microsoft applications. I prefer Lotus to Excel - it is about 300% faster and 50% more functional.
But it became too expensive to buy every application - I must support Office - so I run it to be familiar with it. It would not shock me to learn that you are dead on right. I can tell stories like this in other situations - so it may well be correct. Microsoft is barely competent to do a multi tasking operating system - they are still learning how - it is not their roots. Presumably the next version of Windows will be better. I use XP.

[el cid again]

Since it is more than one level out of date - and I cannot find my notes - it will take a bit more than "a few hours" to redo the current form. Since I must redo pwhex, I will make a few changes in Celebes - adding the North Arm Trail
all the way - and changing a blocked hex side so we can put in a port where one is missing. Western Celebes will then have its fully developed trail system connecting its towns.

Sid

[Herrbear]

ORIGINAL: el cid again

ORIGINAL: CobraAus

ok the - whats version x.655 which I am running

Cobra

OK - I see it. It is an upgrade of x.642 - which also fails. x.641 is two levels back.

For what it is worth, my game opens fine using x.655 pwhex. I can play "head to head" and both sides open and can make ships set to new destinations, planes etc. What does it take to know it crashes?

[kokubokan25]

That's seems like only a few people use the WITP Editor X.
I have no problems managing the pwhex with this engine. However modding WITP is like a increasing black hole with each modify...

[Sardaukar]

I'd also recommend using WitP Editor X. With that you can at least be sure that mistakes in scen/pwhex files are your own doing... And I find it very user-friendly.

[el cid again]

ORIGINAL: Herrbear

ORIGINAL: el cid again

ORIGINAL: CobraAus

ok the - whats version x.655 which I am running

Cobra

OK - I see it. It is an upgrade of x.642 - which also fails. x.641 is two levels back.

For what it is worth, my game opens fine using x.655 pwhex. I can play "head to head" and both sides open and can make ships set to new destinations, planes etc. What does it take to know it crashes?

Please send me a copy at trevethans@aol.com - would be nice to confirm - and use.

[el cid again]

ORIGINAL: fremen

That's seems like only a few people use the WITP Editor X.
I have no problems managing the pwhex with this engine. However modding WITP is like a increasing black hole with each modify...

I don't think it matters - but it might be worth a try. I think the problem is the way a file of this sort is written - using a process called a put. Theoretically speaking - the risk is minimized if you use Task Manager to minimize the number of operations going on. I think all these tools are more or less spreadsheet based applications - and they work just fine on their own. It is the write process that creates the bad files - apparently.