Encarta Instant Answers

Today we celebrate Queens day here in the Netherlands. Actually it is kind of confusing as it is supposed to be tomorrow, but as that is a sunday so they moved it one day ahead. And now to confuse you foreigners even more, tomorrow is not even the birthday of our current queen, it is the birthday of the previous queen. The current queen has her birthday in January, which is probably not the best season to have a public holiday.

But enough for this introduction,  I don’t know why, but I was playing with the Encarta Instant Answers a little bit and I though I would ask it who our current queen is. I must say the answer is a little surprising:

Encarta® Instant Answers: I don’t know about the Queen of the Netherlands, but I do know that the ruler of the Netherlands is German occupation.

Did I miss something? Have the Germans been ruling us all the time without us noticing it? Our royal family is German of course, if you go back long enough in time, but I think Encarta Instant Answers has been mixing up some articles about the Netherlands and the Second World War here.

The math of the gate

I have been able to create some nice mathematical formulas that describe the end position of the gate, based extension length and the different heading and pitch angles. Of course these equations are rather complex, with a lot of sine and cosine functions, so that makes them hard to solve by hand. So I think to do it with some smart computer program and that sort of works. But unfortunately this set of equations does not have a single solution, so a simple answer was not possible.

The next step I took is to implement these equations in a little tool that just tries to find the closest answer by trying a lot of different angles, etc. This worked rather well (and also rather fast), so I will be using this approximation for my gates later on.

Now the next step is to put some data for different aircraft types in the equations and see if I can create proper animations from that. I will be giving that a try over the next few days, but I think this is going to work fine.

Wireless trouble

The last few days my wireless connection seems to be a bit unrealiable. Every few minutes the connection drops and it takes a while to reconnect. So until I have figured out what causes this, expect me to be online a bit less (especially on MSN).

Some more animation tricks

To some of you it might seem that I only hang around forums and create new tools, but sometimes I also work on some actual scenery. I do that as part of the NL2000 team. For the Schiphol scenery I have been working on the animated gates the last week and this gave me a good chance to test some new animation ideas I had.

These gates will use the ActiGate module to show different animations based on the aircraft type you use. I know Nick has been working on the same for his Shannon scenery and he has made all the animations in GMax. But for Schiphol this was not really something I was looking forward to. The reason is that while Shannon has 1 type of gate, Schiphol has three different types. And to make things worse, not all positions where these types are used have the same layout. So that would mean I would have to make a load of different animations, based on parking position, gate type and aircraft type. I am just too lazy to do that.

So I came up with a new idea. If I know the distance of the aircraft door from the stoppoint of the gate, then with some “simple” mathematical formulas it is possible to determine the animation matrices, based on the layout of that specific gate. So this way I only have to collect this aircraft related data and after that enter a few parameters for each gate (like relative position of the stoppoint from the origin of the gate model). I have already tested the ASM coding need to get this working, now the only thing I have to do is to finish the math and implement it in some sort of tool (unfortunately the math you can do in BGLC itself is so limited, that it will not be enough).

While doing this, I also tested an coding idea I had for quite some time already. This is to do the condition checking at a different location in the source code. The advantage of this new location is that animations used for attachpoints can also be affected by the condition and besides that it means less code tweaking in other sections. The downside is that you are a bit more limited in the commands you can use to perform the condition check, but it seems I have it all working now (after a few crashes of FS).

So once I have finished these gates, I will hopefully have some time to make a few articles or tutorials about the new things I have found. And after that CAT deserves an update as well of course. But I don’t expect I have time for that very soon.

No math?

The last two days I posted rather positive about those new animation macros I was writing. Today I am a little less positive, as it seems I have hit a limit of BGLC/MASM (as far as I know BGLC is build on MASM).

It seems I can only do very simple mathematical calculations in those macros. But to do fun stuff, I need more than a sum or a multiplication. I would like to calculate square roots and cosines as well. So I guess I need to do a little more research if such functions are available in MASM or if I can add them easily.

Animations made easier

I have made some progress again on the animation macros I wrote about last week. As I have never written programs in assembler code before, it is quite a nice challenge to learn how to use conditions and loops in those macros (but it is also fun of course).

I have already defined a command that generates all the tables needed to interpolate the frame number from the tick18 counter. Instead of loads of code in your ASM file, that are hard to understand, there is now simple one call to the new macro. When compiling the MDL object, the macro will take care of the creation of the proper tables. There is a similar macro that takes care of the calls to the commands that perform the actual interpolation.

Both these macros have been constructed so that they use a local variable base to store the frame number. This means the animation does no longer depend on the user variables. This is an approach I have been using in CAT for some time already and I prefer it a lot over the default MakeMDL approach. Both the macros also take a few arguments, one of them is the number of frames in the animation. If you set this value to more than 1024 frames, the changes I described on the forum some time ago will be added to your code and you should be able to make longer animations.

So with all this, I hope that tweaking animations will become easier until there is a nice tool to do it for you. It should also help more people to explore animations with over 1024 frames. At the moment I am still finishing and testing these macros myself, once they are ready you can be sure I will release them (with a little bit of documentation on how to use them).

Animation macros

Tonight I have been trying to do something new, writing some new macros for BGLC_9. I had been playing with the idea to make a few new macros for animation commands for a while already and now I gave it a try. It seems to be working better than I had expected, as it is very well possible to make a macro that creates those long interpolation tables. All you end up with in your code in the end is one simple call to that macro.

That certainly makes the ASM code easier to read in the end. And when I have finished a few more of those macros, I hope I can also perform tweaks to the animations much faster (that is the main reason I started this for). So in the end I hope to be able to make animations of a gate for different aircraft types, without having to animate them all manually in GMax. Just by giving a few parameters (distance, height, etc) and the macro should perform all the funny math for me. If this is really going to work, I still have to see, but until now it is great fun to write those macros.

An award!

Real life kept me busy the last two weeks, so that prevented me from posting more often. But yesterday I received some news that woke me up again, I have been awarded a Most Valuable Professional (MVP) Award by Microsoft. Wow…

As I am sure you can imagine, this was a very nice surpise to me. I am honoured that my contribution to the FS community gets recognised this way.

As I am still a bit overwhelmed by this news, I don’t know what else to write for the moment. I just want to share this news with you for now.

Time for a user manual

Tonight I have been working on MDL Tweaker II again. I have finished the vertex list dialog, that allows you to alter vertices of your object and also provides an option to “normalize” the normal vectors of the vertices. This last option is useful if you want to make objects that do not change color with the direction of the sun, like the autogen trees do.

Each time I finish one of the dialogs, the tool is getting closer to loosing the alpha status. The more recent versions also seem to be rather stable already. Before the first beta version will be released, I still want to implement a dialog to view the BGL command list of the object and also a statistics page. But first I am going to add the functionality to the texture list dialog, that allows you to correct the texture size. This would make my little CorrectTexScale tool obsolete, but integrating it into MDL Tweaker II would be a logical choice of course.

The more closer I am getting to a beta version, the closer I am also getting to writing the user manual for this new tool. Until now I just dropped the alpha versions on the forum and everybody played with it. But a user manual is really needed of course. It would help the novice user to learn more about the capabilities of the tool and also for the experienced user it is useful, as he can then discover all hidden features I have put in. So I really think I should start with creating the user manual in the Wiki soon.

CAT is "fixed"

The CAT headache is solved for now, as I have released a new version. As I already wrote about before, this new version does also support the ASM source files created with FSDS3. Although both GMax and FSDS3 use MakeMDL to export and create the ASM file, there was a little structure difference. I have learned CAT these differences now, so that both formats are supported.

But the other problem Nick and I found while debugging a few days ago was more difficult to solve. Actually I could not really solve it, I could only add an option that gives the user a choice between two ways of doing it. And both have there ups and downs.

The first way is to apply the animation condition on the animation trigger. This is how I had been doing it since CAT v1.01. The advantage of this method is that, when the animation condition fails, the reverse animation will nicely be shown to return to the static state. But when multiple copies of the same object (sharing the same GUID thus) were placed this did not work. After some thought, this behavior was very logical of course. When you call a library objects you are expecting the object to share the same memory space (that is one of the advantages of libraries). So that means they also share their local variables to store the animation state. If the animation condition then fails for one of the objects you placed, that means the animation state is set back to static state for all of them. So this means that you animation will never ever start, unless the animation condition is true for all copies you placed at the same time.

One alternative for this would be to create a new GUID for each object you place, but when you need to place 100 gates at an airport or so, this is no real option. It also destroys most of the advantages of using a library. The second alternative is to apply the animation condition, like I did before CAT v1.01. So in that case the animation condition works on the animation itself and not on the trigger. So the trigger can remain shared between all objects and when the animation condition fails a switch is made to the static condition right away, so if the animation condition fails before the trigger fails, this means you get a sudden jump.

In the new version of CAT you can use both methods, so depending on the condition under which you want to use your object, you can choose the best way to apply the animation condition.