Pilot Activated Lighting

[n4gix]

I read through the entire Wiki entry. Although I have no answers to the specific questions you asked, I can say that rarely have I read such a well written and articulate tutorial!

Excellent!

 

[Timmo]

wow- Very in depth wiki article- Im sure it will be of great use to the community.

I noticed that you queried if it works in FSX- I would also be interested in that as I've just recently completed an airport with PAL....it was on Avsim so if their library isn't able to be recovered Ill need to reupload it and may as well try this out.

 

[arno]

Hi,

It will work in FSX, but you need to use the FS2004 code (gamepack) to be able to apply the tweaks.

 

[arno]

Hi Taylor,

That is a great tutorial. Here are the answers to your questions.

QUESTION FOR ARNO: PLEASE CONFIRM WHETHER THIS TUTORIAL APPLIES TO ANYTHING OTHER THAN FS2004.

See my previous reply. The tweaking only works with FS2004 style code, but the resulting MDL file does still work in FSX as well. For the tutorial I think marking it as FS2004 only is best therefore.

QUESTION FOR ARNO: WHERE DOES THIS LOCAL VARIABLE DECLARATION NEED TO GO IN YOUR CODE? WHY DID I HAVE TO JUMP AROUND THIS TABLE IN MY FINAL CODE?

It can be anywhere, although personally I prefer to put it at the start or end of the code so I can find it easier . As you already figured out you need to make sure that these bytes are not read by the scenery engine, as it would not be able to find any BGL opcode in there. So therefore the jump around it is needed.

QUESTION FOR ARNO: CAN YOU PLEASE EXPLAIN THE SYNTAX OF THE TABLE OFFSET IN THE BGL_INTERPOLATE COMMAND?

Simply said it is just the offset into the currently set variable space that marks the start of the table. In the animation code that the GMax export makes this is usually calcuated by subtracting the label that marks the start of the table from the marks the start of the local variables. But if you know the offset already you can also enter the value.

 

[trfsd]

[The local variable declaration] can be anywhere, although personally I prefer to put it at the start or end of the code

Does it matter which RIFF section it goes in? In your animation examples, you put the variable declarations at the beginning of the ANIP section and did not JUMP over the declarations. My code does not involve any animations and therefore has no ANIP section. I found that I had to put my variable declarations in the BGL RIFF section to make my BGL_INTERPOLATE command work. Also, it only worked if I used a JUMP to skip over the declarations. I don't understand how this works, but as long as it does I guess I'm okay with it.

[The offset to the start of the table] is usually calcuated by subtracting the label that marks the start of the table from the marks the start of the local variables.

I think I get it now. The local vars and the interpolation table are stored in two different local variable spaces. But the BGL_INTERPOLATE command can only work with one local variable base offset. Therefore, if we are currently using the base offset to the local vars, then we have to compute the relative offset from the local vars to the interpolation table in order to provide the offset to the table that the BGL_INTERPOLATE command needs. In effect, by using the offset operator and subtracting the local var base offset from the interpolation table base offset, we can address the interpolation table by reference to the base offset of a different local variable space. Have I understood it correctly?

Thanks for all the explanations.

Taylor

 

[arno]

Hi Taylor,

Does it matter which RIFF section it goes in? In your animation examples, you put the variable declarations at the beginning of the ANIP section and did not JUMP over the declarations. My code does not involve any animations and therefore has no ANIP section. I found that I had to put my variable declarations in the BGL RIFF section to make my BGL_INTERPOLATE command work. Also, it only worked if I used a JUMP to skip over the declarations. I don't understand how this works, but as long as it does I guess I'm okay with it.

It can be anywhere, as long as you can refer to the label. But if you do not have a section it is hard to put it there of course .

For the CAT tool I put the local variables in the BGL section as well, so I also needed the jump there.

I think I get it now. The local vars and the interpolation table are stored in two different local variable spaces. But the BGL_INTERPOLATE command can only work with one local variable base offset. Therefore, if we are currently using the base offset to the local vars, then we have to compute the relative offset from the local vars to the interpolation table in order to provide the offset to the table that the BGL_INTERPOLATE command needs. In effect, by using the offset operator and subtracting the local var base offset from the interpolation table base offset, we can address the interpolation table by reference to the base offset of a different local variable space. Have I understood it correctly?

Yep, that's it.

 

[trfsd]

Arno,

I have discovered a bit of a glitch with my timed airport lights. If you are not facing the ref point of the light object when you momentarily tune the radio to the target frequency, then the light is not on when you move your viewpoint to be able to see the light object. Likewise, if the light object moves out of your view before the timer runs out, then the timer stops running and the light doesn't turn off. I finally realized that the reason for this is that FS9 does not draw the object if it is out of view. If the object is not drawn, then none of the conditional testing code for the object runs until the object comes back into view. This seriously messes up the timed lighting effect.

I found that I could force the object to be "visible" from any direction in the vicinity of the airport by increasing the bounding box of the object to a 10km cube. With this giant bounding box, the timed light works no matter which direction I am facing (as long as I am within 5km of the airport). The problem with this approach is that it suppresses all autogen with 5km of the airport. Not a useful result.

Is there any way to force FS9 to draw/process an object 100% of the time, even when the object is out of view? Is there any portion of the RIFF code that continues to run when the object is not visible?

Taylor

 

[arno]

Hi Taylor,

True, I did not think of the problem. When the object is out of view it is not drawn. When it comes into view again it is probably loaded again, so all the local variables are reset to their initial values.

The bounding box is my only idea at the moment to make it visible for longer (at a small performance cost), but that kills the autogen.

The only alternative I can think of is to use the FS2002 gamepack instead. You can then tweak the v1 and v2 parameters of the reference point to make sure it remains loaded.

 

[trfsd]

The only alternative I can think of is to use the FS2002 gamepack instead. You can then tweak the v1 and v2 parameters of the reference point to make sure it remains loaded.

I still need to do more testing, but this appears to work. I set v1 to 10000 and v2 to 5000. As long as the plane is within 5km of the airport, the timing code for the lights runs no matter which way the plane is facing. And unlike with the FS2004 bounding box, the autogen is still visible.

I will look at updating the wiki page once I have code that I am confident is working properly.

Thanks for the suggestion, Arno.

Taylor