taguilo

Bill, this is very simple:(@c:FlightPlanActiveWaypoint) s0 (>@c:FlightPlanWaypointIndex)...Show needed data for Active Waypointl0 ++ (@c:FlightPlanWaypointsNumber) 1 - min (>@c:FlightPlanWaypointIndex)...Show needed data for NEXT Waypoint (Active +1)That's it! No need to test remaining distance, etc. You should decide what to show for next wp when active becomes the last...Tom

Ed, TICK18 still updates with the sim paused, but NOT when FS is in any menu system.Tom

Nice example Bill :( However, I would like to point out this is one case where macros are not necessary to be used (in fact shouldn't be used :( if part of a big project).Let me explain:Say you have 100+ messages that display from multiple conditions. Probably the EICAS gauge would be duplicated in main panel/VC and maybe some subpanels; then the macro code and conditionals would be duplicated as well. The best in this case is to "build" the message via a local variable placed in the own gauge that manages the failure and refer to that variable in the CAS <FormattedText>For example, %@(L:ACBus Off,bool)%{if}AC BUS OFF\n%{end} where (L:ACBus Off,bool) condition is updated in another gauge, say ELECTRICS gauge.Notice that neither I use @Message(n) macros, but instead their direct meaning, is more clear to the user and saves some "extra" loading time.All this stated as my two cents in terms of code optimization :( Tom

Hi Bill, I checked the Wiki and seems OK. BTW, thank you for taking the effort to maintain the Wikis ( I understand you post on more than one) :( Tom

Bill, forget about that complicated code :( As Ed stated, it's a simple bitwise operationSo:decimal codes for BIT0 to 7128 BIT7: 0= VOR 1= Localizer 64 BIT6: 1= glideslope available 32 BIT5: 1= no localizer backcourse 16 BIT4: 1= DME transmitter at glide slope transmitter 8 BIT3: 1= no nav signal available 4 BIT2: 1= voice available 2 BIT1: 1 = TACAN available 1 BIT0: 1= DME availableThen for example, to test if a VOR has not localizer backcourse:(A:NAV CODES:1, flags) 32 & 32 == To test for glideslope available(A:NAV CODES:1, flags) 64 & 64 == etc etcTom

There is no list of @g macros :-)@g is just one macro used to simplify the reference to GPS variables.So what you need to do is search for those variables in the SDK.Tom

Hi Roman,Here you have an example on how to use Azimuth calcs. http://forums.avsim.net/dcboard.php?az=sho...ing_type=searchIn short it is used to find the coordinates of a given point that is n miles and with a d bearing from your aircraft (or any other point with known position)You could try this formula as well:slant (hypotenuse) = (Geocalcdistance,nmiles) sqr (Altitude,nmiles) sqr + sqrtAnd AFAIK this value should be similar to the DME reading in your NAV radio.Tom

Something like this?(value) (>L:MyArray:@1,unit)@Assign(1) @Assign(2) @Assign(3) etc Many things can be done with these pseudoarrays; if you need a selectable condition for each array member, the best option is to use a "goto" operator within a script, like(start value) s0:0(Evaluate the macro) (l0 ++ s0 (bound) <= if{ g0 }etcTom

Hi Paul,So, you just need the vars to be initialized at startup? Could you give me an example?Tom

Hi Bob,If you still want to use the gps functions to retrieve NAV coordinates and altitude, it's very simple :-)1) Do an ICAOSearch using Avar nav info: 0 (>L:ICAO Found,number) 0 (>L:ICAO NoMatch,bool)'V' (>@c:IcaoSearchStartCursor)31 (>@g:enteringInput)0 (>@c:IcaoSearchMatchedIcao)(A:NAV1 Ident,string) (>C:fs9gps:IcaoSearchEnterChar)(@c:IcaoSearchMatchedIcaosNumber) 0 > if{ (@c:IcaoSearchCurrentIcao) (>@c:FacilityICAO) 1 (>L:ICAO Found,number) } els{ 0 (>L:ICAO Found,number) } (@c:FacilityICAO) (>@c:WaypointVorICAO)(@c:WaypointVorLatitude,degrees) (>L:YOurLat,degrees)(@c:WaypointVorLongitude,degrees) (>L:YOurLon,degrees)(@c:WaypointVorElevation,feet) (>L:YourAlt,feet)Then, somewhere on the code ..NAV1 changedif{ @SearchICAO }(L:ICAO Found,number) 1 == if{ 2 (>L:ICAO Found,number) }(L:ICAO Found,number) 2 == if{ @RetrieveVOR }etc etcNow you can use those Lat/Lon/Alt vars combined with Plane Lat, Plane Lon and Plane alt via geocalc functions to find the proper distance to the VOR at any moment.Good luck! :-)Tom

Well, I believe the Lear45 could be a good approach for a simple CAS, and the code is very understandable (You wouldn't want to read the one I used in my gauge :7, which needs to handle 80+msgs, multiple pages,etc)Anyway, I for you would choose the C++ option if possible; I've done a similar multiline CDU with the C++/XML mix and is far more simpler and supportable.Tom

>What would be the most flexible way of scripting this? Please>>Bill, is XML mandatory here? Because as you know doing it in C++ or C++/XML mix is a piece of cake.:-)Anyway, in XML is simple as well but the script being rather complex if you want efficiency -forget about tons of nested if{}els{}s :-eek; you REALLY need efficiency in this case!.I'll try to translate to pseudocode an example from what I've done in a proprietary project, so I can post it here.Tom

>>You indicate that Option 2) is feasible. That

Hi,Options 1) and 2) are feasible for sure.But, like I stated in this thread before, the simplest solution is to model a "swaping" radio between two frequencies based on a single COM.Again,there is no need for a NAV3 whatsoever.A *very rough* pseudocode would be something like: (LNAVcontrol) 6 == if{ (ANAV(1/2)Bearing) (>LMyNav3Bearing) (ANAV(1/2)Distance) (>LMyNav3Distance) 1 (>LNAVcontrol) }(LNAVcontrol) 5 == if{ 6 (>LNAVcontrol) }(LNAVcontrol) 4 == if{ Freq (>K:NAV(1/2)_SET) 5 (>LNAVcontrol) }(LNAVcontrol) 3 == if{ (ANAV(1/2)Bearing) (>LMyNav2Bearing) (ANAV(1/2)Distance) (>LMyNav2Distance) 4 (>LNAVcontrol) }(LNAVcontrol) 2 == if{ 3 (>LNAVcontrol) }(LNAVcontrol) 1 == if{ Freq (>K:NAV(1/2)_SET) 2 (>LNAVcontrol) }Then instead of using Avars in your RMI/VOR/ILS course/rose/dme indicators, use your own LVars (like (LMyNav3Bearing)).The real update will happen at least 6 times/second per each NAV, I believe an acceptable rate. Tom

>>Anybody any ideas on this ??>Yes, you must use instead of .To insert a newline, use n like in your own example.Tom

>>The answer to "does it exist" is "no way," isn't it? ;-)>Yes, and I'm afraid it will always be "no way" in any script-dependant "language", using XML, LUA or other platform alike.You need a true function to acomplish that, and that's what C/C++ was invented for !! ;-)Tom

Bill, the behavior you describe is really weird.(A:Autopilot Master,bool) MUST return 0 or 1 - no other option possible. Maybe the problem was elsewhere? The only Avar with bool unit that returns -1 is (A:HSI CDI NEEDLE VALID,bool) so far I've tested, which I assume as a code bug.Anyway, the very advantage of using bool unit is precisely that you don't need to make any comparison at all, just the Avar itself will put a 0 or 1 in the stack, as you've already noticed :-)And regarding Ed's comment on unit spelling, remember that variables, units and events are NOT case sensitive; they are translated to uppercase by the parser (then BOOL, Bool and bool are all ok)Tom

Hi Paul,Some gps events -like search and Facility update-are asynchronious; in these cases a bit of delay is unavoidable.Tom

>Well... This is a pity... The following will draw the initial>StartAngle correctly, but it will never update... :(>>This is the final thing I need to accomplish somehow...>>FillColor="#545454" Bright="Yes">I could never make work in FS9...How did you do that? Unfortunately, the use of scripts in drawing vectors (line, pie,rectangle,etc both in FS9 and FSX) is limited to the starting point only, so it's not very useful IMHO. BTW, you should use TURB ENG N1 instead of the corrected value in engine gauges :-)Tom

Kenny, Try with .Close always with and use caps for the tokens (Element,Text,Image,etc)Tom

Hi,You must split GaugeName into this:Otherwise the gauge won't load.To test whether a gauge loads or not, just open the XML file with Internet Explorer, if it's ok the complete code will show, otherwise a message should appear in the text pointing out the offending section of code.Tom

Hi,If you know a bit of C++, you can modify the source code to do/show whatever you need, as Arne made it public domain. Otherwise it is not possible to add anything within the XML appart from what Arne describes in the documentation.Tom

>I need to detect 3 states:>>Case Value=0> "Smile">Case Value=1> "Frown">OTHERWISE> "Bury face in hands">>I can't find any XML examples like this construct anywhere.>Does it exist?>>Or maybe I should be using the if{} construct ?>>Cal - CYXX>VE7LZZ>Obvious NewbieHi,The OTHERWISE can be implicit placing a default bmp in the -For example:SCRIPT"Smile""Frown"etcAny value returned by SCRIPT different from 1 or 2 will make the element show the default image.Tom

(...)Ed, please...I do respect you, really, but sometimes you should avoid posting like above :-). I gave a clear explanation on the meaning and working of MINIPANEL on my previous posts. I strongly recommend you to read them carefully.Tom

>Actually if makes no sense whatever and is completely contrary>to what is in the SDK...>It is not contrary at all Bill. You are departing from a wrong assumption that IDENT_MINI_CONTROLS_PANEL is the same as MINIPANEL, which is clearly not.Actually MINI_CONTROLS is a carry over from FS2K era where Minicontrol window and gauge did exist, with the only purpose to show that tiny white double scale with the word "Knots", remember that? :-)But MINIPANELS is another thing, associated with the idea of a main 2D default and fixed cycle of MAIN ON - HUD ON - MAIN OFF.I guess that't the reason for using IDENT_AIRCRAFT_HUD_3D_PANEL as a pnemonic define. This applies both for FS2004 (FS9) and FSX as well.Tom