At this point I am only aware of one document describing BGL opcodes which is BGLFP.doc of the FS2002 BGL SDK.However when I look at the BGLC.EXE or BGLC_9.EXE (of which I don't remember where I got it, but which came with a list of codes in BGLC_9_Source.htm) I noticed a lot more opcodes which aren't described anywhere. Is there a full description somewhere ?All I really need is a bit shift and a binary AND with bgl user variables. I don't really want to switch to MASM or get any more complicated than that.Thanks for your help,Matthias

Hello Matthias,another source is the FS2002 Scenery SDK with some more bglc macros.You could also open bglc.exe in the notepad editor and extract the asm-include files.BTW: BGLC is MASM in disguise. So you might use assembler commands...Regards,Edgar

I think you mean the Fs2000 scenery SDK here. It describes most of the older opcodes. The newer FP commands are described in the SDK mentioned before. There will still be some commands that are not documented anywhere (for Fs2004 opcodes there is no document for example).

Hi Edgar,yes, assembler commands seem to work in terms of compiling. But it stops drawing the model. For example if I just addpush axpop axinto the drawing code,right before MATERIAL 0,0 ; <255,255,255,255> CRATE_SIDES.BMP;;; DRAW_TRI_BEGIN 0, 8 ...it won't draw anything. The same even happens with a single 'nop' (no operation). I have no idea why that is.MatthiasHere is the code:crate_MasterScale_1 label BGLCODE nop MATERIAL 0,0 ; <255,255,255,255> CRATE_SIDES.BMP;;; DRAW_TRI_BEGIN 0, 8 DRAW_TRI 7, 5, 2 ; poly=2 part=1 DRAW_TRI 0, 1, 4 ; poly=3 part=1 DRAW_TRI 4, 3, 0 ; poly=4 part=1 DRAW_TRI 2, 6, 7 ; poly=1 part=1 DRAW_TRI_END MATERIAL 0,1 ; <255,255,255,255> CRATE_TOP.BMP;;; DRAW_TRI_BEGIN 8, 16 DRAW_TRI 2, 0, 6 ; poly=5 part=1 DRAW_TRI 6, 9, 2 ; poly=6 part=1 DRAW_TRI 5, 14, 12 ; poly=7 part=1 DRAW_TRI 12, 4, 5 ; poly=8 part=1 DRAW_TRI 10, 8, 13 ; poly=9 part=1 DRAW_TRI 13, 15, 10 ; poly=10 part=1 DRAW_TRI 7, 1, 3 ; poly=11 part=1 DRAW_TRI 3, 11, 7 ; poly=12 part=1 DRAW_TRI_END BGL_RETURNbgl_riff_end_crate label BGLCODEWith the 'nop' it will not draw anything. Remove it and it draws the crate as always.

Hi Matthias,While BGLC is MASM in disguise, it doesn't mean you should use it for assembly programming! The reason MS decided to use MASM is because they wrote a set of macros to turn into a binary format. The beauty of MASM is that you can just add macros as you go. So, if you add a 'nop' into your code, you are changing the binary outcome (bgl file) and FS won't be able to interprete it anymore...To answer your question: You find a set of explanations from the FS98 to FS2002 SDKs. The older SDKs describe older macros that probably aren't used anymore.If you use Visual Studio or any Resource 'reader' program, you can find some textfiles embedded into BGLC (those textfiles are essentially the difference between MASM and BGLC). These textfiles contain the complete list of macros (including FS2004).Cheers, Christian

Hi Christian, thanks for the clarification.So if I understand this correctly the BGL code is not interpreted as assembler code but purely as a way to call predefined BGL macros, which means I am bound to the defined set of macros.I am using Visual Studio and I am familiar with resources but I'm not sure what you mean in terms of reading the EXE as a resource. I can look at the codes by looking at the bglc_9.exe in binary in VS. I also have a list called BGLC_9_Source.htm which seems to contain all opcodes with parameters.But in terms of use it seems I can only guess or experiment. When I look through the list I would think "IFMSK macro dest,var,mask" might be helpful in terms of what I want to do but, as Arno stated, there is no documentation anywhere.So I guess 'IFMSK macro dest,var,mask' could mean it would jump to dest if "var AND mask is not 0", but who knows...Matthias

Hi Matthias.You're right as far as what the role of BGLC is...The sim has terrain and scenery "engines" and the compiled code is just the way of communicating with them. All the coding has "headers" which clues the sim as to what type of coding is to follow.Code could be written in C++, Delphi, ASM, Basic... anything that can write the bits, bytes, words, etc., in the formatting required by the sim, and described in the Scenery and Terrain SDKs.Adding a NOP will still compile. But when the scenery engine gets the code, it's unknown how it will react. In this case, it simply stopped the display of the object. In other cases, it might crash the sim or even the computer. The NOP didn't belong in that datastream of code.The FS2002 series of SDKs is fairly complete if you want to persue any type of hand coding for FS2002 scenery. It's pretty tedious stuff. SCASM is also available as a language unique to the flight sim series. The BGLC_9 executable is for scenery experimenters hacking FS9's MakeMDL output. It has very limited use, and isn't to be used for FS2002 MakeMDL output ( might produce strange results ). The BGLC_9 source is the format of the commands available, in MASM ( suitable for FS9 ). It just shows the command formatting, 95% of which is just like the FS2002 BGLC. The source doesn't tell us the usage or order of those commands... that's left for us to figure out.MS seems to indicate they don't really want us to hack the ASM code of the new scenery objects, but there is still some need for that when wanting to use conditional displays. That's why BGLC_9 came into existence. BGLC_9 was "liberated" from FS9's MakeMDL.Arno's website has a forum that deals with many BGLC and ASM issues:http://www.scenerydesign.org/modules.php?n...rums&file=indexDick

Thanks for the detailed info, Dick. Now I also remember where I got BGLC_9 from. ;) I like your May 1st ultimatum to M$. :DI think I have an ok workaround for now. Maybe if there is more info in the future I can make it as sophisticated as I hoped for it to be.Thanks everyone for the friendly and detailed help on this topic.Matthias

Maybe if you use the SCASM documentation as well you will understand more of the commands. A lot of the names are similar and in general better documented.

>Maybe if you use the SCASM documentation as well you will>understand more of the commands. A lot of the names are>similar and in general better documented.Cool, thanks Arno. I never used SCASM but when I look at the docs it sure looks like a direct translation of the BGL commands. I may even have been correct regarding the IFMSK command...Matthias