PDA

View Full Version : Qbasic headaches



Ettico
February 26th, 2009, 12:56
I'm still working on a Qbasic program to supplement and improve Lowengrin's Dynamic Campaign Generator. The program is designed to be run after generating a DCG mission. When run, the program currently finds and fixes 4 known DCG bugs in the DCG mission file, and makes several other alterations, such as re-assigning unneeded AI CAP flights as strike escorts, implementing long range escorts, and allowing the player to change the player squadron loadouts, etc. The program does what it does so far without a hitch.

But now comes the hard part. There are 2 known DCG bugs that intermittently occur in the DCG campaign files. These bugs really need to be eliminated. The campaign files exist in a different folder from the DCG mission file. Getting at the mission file is easy enough. Just put the Qbasic interpreter and program in the same directory and run it from there. But getting at the campaign files requires changing to a different folder inside the program. Simple, right?

WRONG! Changing to the target folder is easy enough. Just put the folder containing the campaign files inside the same root folder and call it by name in the program - going down a folder is not a problem. But getting Qbasic back to it's root folder from there requires providing the program a path back to the root folder, in a form Qbasic (but probably one else in the world) understands.

I managed to solve the problem by executing a DOS command at the beginning of the program. The DOS command creates a text file containing the path to the root folder in the required strange form. The strange directory path is then extracted from the file and then used to return Qbasic back to it's root directory after it's confusing excursion into the netherworld of the DCG campaign files. The return path can't be hard coded because people have multiple installs in varying directories with varying folder names.

That done, my next step will be to concoct a routine to find and eliminate destroyed ship squadrons from the "ships" and "taskforces" files, to prevent DCG from continuing to order strikes on the destroyed ships. This is a long standing problem which has only been fixable by hand editing the destroyed ship squadrons and their waypoint paths out of the files. I have a plan for doing this, but the plan's viability relies partly on how DCG acts in certain situations when the "ships" and "taskforces" files are changed.

The next step will be to search for and fix a DCG bug which intermittently occurs in the "squadrons" file. But before I can figure out how to fix it, I'll have to get DCG to create the error so I can look at it.

If these final 2 steps can be completed, we will have a DCG that runs much more smoothly and realistically without the need for DCG file management expertise.

Still no luck finding a Qbasic compiler to convert the program into executable machine code. I located a later version of Qbasic which has a compiler. The compiler doesn't balk at compiling the code, but the resulting "DCGQB.exe" file fails to pass muster. Probably because of the way I wrote the code, but the error codes are greek to me.

miamieagle
February 26th, 2009, 14:32
I have been looking forward for a improvement for years. I hope you are succesful Ettico. I will be waiting for its uploading!


Thank you!

Ettico
February 26th, 2009, 14:42
I have been looking forward for a improvement for years. I hope you are succesful Ettico. I will be waiting for its uploading!


Thank you!

Me too, miami. I think I can get the last 2 fixes implemented, but either way, the fixes I've done so far are an improvement.

Ettico
February 26th, 2009, 14:57
I've been able to convince Qbasic to do a number of things it really didn't want to do, but it seems more determined than ever to invent excuses to avoid doing these last 2 operations.

Qbasic: Sorry, I can't kill that file because it's already open.

Me: What about that CLOSE statement just above the KILL statement?

Qbasic: Oh. Well, that only applies to certain files in certain situations.

Me: Duzzitnow.

Qbasic: Yes, it does. Really.

Edited to add: OK, it finally did what it was told. I told it to do something different, and it couldn't think of any excuses not to do it. Now, maybe I can find out if my devious plan is going to work.

UncleTgt
February 27th, 2009, 00:05
:costumes: ... reminds me of Kubrick's "2001" ...

Ettico
February 27th, 2009, 02:29
As some of you may well know, the only way to get a program to do anything constructive at all is to argue it into a corner from which it cannot escape.

And sometimes you just have to get lucky.

Qbasic, being an old programming language, cannot handle long file names. No way. A file name longer than 11 characters including the extension stops Qbasic in it's tracks.

My goal was to concoct some code to edit squadrons of sunk ships out of the DCG "ships.dcg" and "taskforces.dcg" files, so DCG would stop ordering strikes against ships that were already at the bottom of the Pacific. The odds didn't look good at all, if you count the characters in the "taskforces.dcg" filename. That's an "invalid file name" error waiting to happen, as far as Qbasic is concerned.

But luck was with me. Turns out Qbasic can be forced to execute DOS commands, so I was able to use a DOS command to shorten the offending file name to "taskforc.dcg", which allowed Qbasic to work with the file. But this option was only possible because I discovered that DCG doesn't care if the file name is shortened to "taskforc". DCG will still recognize the file and use it normally.

The upshot of all this skullduggery is, I've gotten the program to successfully edit destroyed ship squadrons out of the campaign, and DCG doesn't give a rat's patootie that I had to shorten the filename. No more being sent off to comb the ocean in a futile search for ghost ships. Well, it might happen once. A futile search might be ordered in the mission before my program edits out the sunken ships. But that's a lot better than having squadrons of ghost ships roaming around indefinitely, drawing off strikes that are badly needed elsewhere.

What a relief.

There's one more killer bug that pops up sometimes when DCG transfers squadrons to different airfields. This one will mess up your, uh, "squadrons.dcg" file bad enough to stop DCG in it's tracks. If you don't know what to look for and how to fix it, you won't have a clue what went wrong. So count the characters in the "squadrons.dcg" file name. Deja Vu all over again. I'm just hoping DCG won't mind if I lop that one off a bit too.

UncleTgt
February 27th, 2009, 03:48
:woot:I admire your persistence. Best of luck with the last hurdle ...

Ettico
February 27th, 2009, 06:46
:woot:I admire your persistence. Best of luck with the last hurdle ...

Hi Uncle Tgt,

My persistence is intermittent. I've been putting this off for a month or so.

But things are looking good so far. I lopped a character off the end of "squadrons", generated a DCG mission, and then flew it. It worked, which verifies that DCG is able to identify the files by the first 8 characters of the file names. That means all the files with long names are accessable to Qbasic by simply lopping off the forbidden characters. The odd part is, DCG seems to keep the shortened file names after they're lopped off.

I still need to get DCG to create the error so I can look at it. I haven't seen it in a while, and I need to know exactly what it does.

Ettico
February 27th, 2009, 08:17
Now that it looks like the ships and squadrons bugs can be defeated, I'm beginning to think about front movement.

I have a seed of an idea about how DCG front movement might be improved. Currently, front movement seems to be solely a function of the campaign date. When the front is set to move, it wavers some, but tends strongly to move one way or the other in accordance with how early or late in the war it is. This is OK, because the overall fortunes of the combatants shifted as time went on. But I'm thinking front movement could also be tied to the relative strength of ground and sea forces in the campaign. Air power could also indirectly affect front movement by inflicting casualties on land and sea forces, changing the balance of power and giving players a reason for all their bombing and strafing. It wouldn't be too difficult to calculate a front pressure coefficient by reading the pertinent files and doing some sensible calculations.

The hard part would be manipulating the front line coordinates without messing them up. The front coordinates exist in the "campaign" file in text form. They would have to be disassembled and converted to numeric values. Calculations would have to be done. Then the altered coordinates would have to be reassembled into text form. It sounds simple when you say it fast, but there wouldn't be anything simple about it.

I don't know if it's worth it. Just a thought.