Great...now I have a multi-phase AIRBOSS...

[Ettico]

...but no multi-phase campaign to test it on.

Cart before the horse? Not really. What's the use of building a multi-phased campaign if you don't have anything to manage it?

It's more of a chicken vs egg thing. Anyhow, I've thrown together a sort of dummy multiphase campaign that has all the files in it, except they're just random files. I've been using the dummy campaign to test and debug. The thing seems to be working. Kicks in the phases on cue and appears to be shuffling the files around correctly when the phases shift.

Hope I haven't created a Monsta. How the heck am I going to explain how the multi-phase system works? It's not all that ingenious or anything, it's just hard to explain. Oh well. It's probably easier to explain to people than it is to explain to a program.

You don't have to worry about it. The multi-phase version is the previous version with the waypoint-path-renumbering bug removed and the multi-phase option added. You don't have to go multi-phase. But you can, if you're crazy like me.

For practical purposes, the change only requires 2 configuration files to reside in all the DCG campaign folders. These files tell AIRBOSS whether the campaign is multi-phase or not, and if so, the why's and the wherefore's of it. The additional files don't do anything if it's not a multi-phase campaign, but they have to be there, because I've programmed AIRBOSS to look for them and read them.

What does a multi-phased campaign do? Not that much, really. At certain predetermined dates, the front line moves and may change directions (this is in addition to normal DCG front movement). The infrasructure changes. The designated target locations change. And the task force waypoint paths change. That''s all there is to it. But it means, for example, that a single DCG campaign can consist of a running battle spanning thousands of miles of ocean. Or land.

I'll try to make sure this doesn't have any bugs in it before I upload it.

 

[Ettico]

As I hinted at before, the multi-phase option opens the way to having successive phases of a DCG campaign "kick in" as a result of campaign conditions, rather than at predetermined dates. This version doesn't do that, but theoretically, it could happen.

As a generality, each additional option opens the way for yet another possibility. As the code increases in size and variability (if not in efficiency), the program's "knowledge" increases, sometimes making additional changes less difficult to implement. Or not...

About the "efficiency" of the code...

This code is probably as inefficient as any that's ever been written. But efficiency and bugs are two different things. Inefficient code might make 3 trips to do what efficient code could do in one trip. But it can still get the job done. But bugs prevent the code from getting the job done correctly.

Probably the only reason I've gotten this far is because I haven't been worrying about efficiency at all. I've been doing whatever I could think of that would work, the simplest way I could think of. Except when I couldn't think of any simple way, in which case I did whatever complicated thing I could think of, probably in the most inefficient possible way.

Bug after bug has reared it's ugly head, but so far I think I've been able to find and swat them one by one, usually in the process of trying to add and debug something else. At the moment, the program seems to be doing everything I wanted it to do, however inefficiently.

One more thing. Incorrect player input or missing files can cause an error condition. When that happens, program execution halts, an error code is displayed, and the line of code where the error occurred is highlighted and displayed. If you have any clue about Basic code, that can tell you something about what happened. There are no error handling routines in the program, and that's the main reason why.

It's important to know that if and when an error occurs, you should close the QBasic interpreter, restart it, and reload the program. For some unknown reason, the interpreter seems to get hung up on the notion that an error condition exists, and may continue to foul up unless you do this, even when the original error-causing condition no longer exists.

 

[merlin2]

Hi Ettico:

sounds great;
a couple of questions:
could this system accomodate changes of season? (texture switches) or seasonal airports?
could it accomodate historical upgrades to airfields (e.g. Gibraltar first was simply a field, then a short strip unpaved, then eventually a 1-mile concrete runway.) assuming that historical airfields were available.

thanks for the great work!

 

[Ettico]

Hi Ettico:

sounds great;
a couple of questions:
could this system accomodate changes of season? (texture switches) or seasonal airports?
could it accomodate historical upgrades to airfields (e.g. Gibraltar first was simply a field, then a short strip unpaved, then eventually a 1-mile concrete runway.) assuming that historical airfields were available.

thanks for the great work!

Only with great difficulty.:d The AIRBOSS 'system', (such as it is), is only designed to do specifically what AIRBOSS does. So a lot more code would have to be written to do what you're suggesting.

But what you're talking about amounts to file swapping. Even a QBasic program is capable of doing file swapping. The necessary files would have to exist, and they would have to exist in standardized locations where the program could find them. Folders would have to have standardized file names so the program could recognize them. And it would be much simpler if each folder or file the program had to deal with had a file name of 8 characters or less.

On the bright side, it wouldn't take much much in the way of AI intelligence or decision making ability. Just knowing which files to swap, when to swap them, where they are, and where they go.

Here's my formula for converting a text date to a number a program can understand and respond to. Say you have a text date in this form: "01/10/1943" - 'After laboriously extracting the numerical parts of the date and converting them to integer values:

DAY = day + month x 30 + year x 365

"DAY" is an integer value that roughly expresses the number of days that have passed since the death of Jesus. The formula is not precise, but it doesn't have to be precise for practical purposes. That's basically what it takes to make it possible for a program to compare dates and respond accordingly. Basically, a computer program doesn't know a date from an orange unless you reduce them to numbers.

It's an interesting idea, but I don't really see myself getting on it right away. I still haven't built a multi-phase campaign to use the latest version of AIRBOSS with. OTOH, anybody who knows how to write QBasic code or is willing to learn, can write a program to do just about anything a computer program or the programmer can do. And different QBasic programs can be chained together to form a system that executes sequentially and automatically. Different QBasic programs can even pass variables to each other when they chain, although it's much simpler if each program in the chain can function independently.

The bottom line is yes, a QBasic program can be written that would change the seasonal textures and scenery at predetermined times. BUT - and this is a BIG BUT - how would one write a program that's adaptable to all the individualized scenery and installs that people have? Only with great difficulty, and it would require individual users to inform the program of the user's custom setup. Everything would really need to be standardized.

 

[Ettico]

When I started trying to tell AIRBOSS how to manage a multi-phase campaign, the program was not happy. It posed the following objections:

1. I don't want to do it.

2. You can't make me do it.

3. If you try to make me do it, I'll just pretend I did it, and you won't know I didn't really do it.

4. Even if I wanted to do it (which I don't), I have no idea what you're talking about.

Nothing new, really. The same objections were posed at every stage of the process.

But now the program executes quietly without throwing any tantrums. When I check out the dummy files I'm testing it on, everything seems to be in order.

I'm tempted to upload the program as is, just to get rid of the waypoint-path-renumbering bug that's in the previous uploaded version. But the only way to know for sure if it all works is to build an actual multi-phase campaign and play test it.

 

[miamieagle]

Great work!:ernae: