Herbie63

Members
  • Content Count

    115
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Herbie63

  • Rank
    Member

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    Germany
  1. LOL !- accepted -:-)Do I need to add, that I wrote and tested it in FS9 ?Anyways, I'll probably furtheron will use the :X index methode. It's as good as the other and who knows what FS 11 might require...Thanks for your input Bill & Roman, it's allways very much appreciated!
  2. I ALLWAYS read the SDK befor asking a question here. But in this case I only read through the 2004 version. Sorry.And of course I tried to specify it to NAV1, but tried(A:NAV1 RAW GLIDE SLOPE,degrees), and also(A:NAV 1 RAW GLIDE SLOPE,degrees) - which should be the same as(A:NAV RAW GLIDE SLOPE:1,degrees)at least it was the same in all gauges I built up to now...What confused me was that I got a value (1.00) which usually means that the syntax is correct...Anyways, it's working now, so thanks a lot!!Herbert
  3. Besides what Bill said, there are two flags controlling the night appearance. 'Luminous' refers to the luminous colour described in the panel.cfg and makes those elements illuminated when the panel lights are on. 'Bright' will let those elements (bitmaps, strings etc.) allways appear as if it was daytime. This fits very well to digital LED or LCD displays.In your code you used for the string 'Bright = Yes' which will be fine if it represents a LED or LCD font (but then Arial?). For this you'll indeed nedd some code to switch it off - the visible statement is the best - but in case the string represents somehow the old style rolling numbers, they will be visible but dark when the battery is off. So instead of 'Bright' 'Luminous' would be better here.
  4. 1. It will be best to place the yoke on a separate pop up panel. Then when there are no 0,0,0 and/or 1,1,1 colours (which will be transparent) used for its visible parts it should work fine.2. That depends on the FS version. In FSX you can use a second set of bitmaps (for the panel as well as for the gauges) having the same name plus an added '_night'.In FS-9 you'll have to use some tricks to get that working - but it's possible.Maybe you'll also need to set the luminous flags used for the gauge's bitmap to meet your requirements. The SDK will tell you more about this.Good luck!
  5. Hi everybody,I found in the SDK the variable NAV RAW GLIDE SLOPEwhich I suppose will give the glide scope angle of the available NAV.But whatever I dom I cant get it working - the best result is 1.00, when using number as unit.Any ideas?
  6. Thanks for the answers! That works quite well inside ONE gauge. But how can I get it displayed in an other gauge? As much as I know, these macros are for use in that gauge only where they are defined.Or am I missing something...I want to build a gauge which reads out the NAV AID IDs and stores them in this L:variables / macros so that I can use this information in a different gauge. So I can display the ID belonging to a special frequency without having tuned that frequency.It's still a bit experimental and I'm not shure what the gauge will be for in the end... but if I can not get this working, obviously it will be for nothing...
  7. Hi,Is it possible to store a text in a (L:something) variable likeMy Text (>L:something,string) for use in other gauges (displaying that "My Text" there)?I can't get it working, tried several units, worked with macros... I'm aware of an old thread here in the forum where it is said it's not possible at all - is that really true?If so, I'll probably have to transform every single charakter to an integer (and back) using the XML string operators symb, ord and chr. But to say the truth, I'm a bit lazy to write that routine - if there is a simplier solution.Any help more than welcome!Herbert
  8. Ed, Heaven no! That only was my way to tell Keith that I'd prefer to help him via direct contact (mail pm) rather than using the forum.Keith: I'm glad to hear you got things sorted out! You can send me a pm (private message) using one of the buttons at the top right of this answer.Herbert
  9. Just to hang in once again...Ben74, I have to appologize, It's been late at night after a bad day. I think my words were rougher than they should be. I'm sorry for this.Just one more idea how I'd solve the problemI'd build a gauge to display and to inc / dec the simrate.This gauge would also have a third button or mouse-click area to return to normal simrate from where ever you are: Clicking this will set an internal variable to 1.Mouse click event:(1 (>L:SR reset,bool)Now you need an element, which permanently checks this (L:SR reset,bool) and starts to reset the simrate as soon as it detects it to be 1. This simply can be done by a if-then syntax which either increases or decreases the simrate until (A:SIMRATE,number) equals 0. Something like this should work:reset if sim rate is higher than 1:(L:SR reset,bool) 1 == (A:SIMULTION RATE,number) 0 > && if{ (A:SIMULATION RATE,number) 0 == if{ 0 (L:SR reset,bool) els{ (>K:SIM_RATE_DECR) } }And in case it is lower than 1(L:SR reset,bool) 1 == (A:SIMULTION RATE,number) 0 < && if{ (A:SIMULATION RATE,number) 0 == if{ 0 (L:SR reset,bool) els{ (>K:SIM_RATE_INCR) } }This changes the simrate as long as it doesn't equal 0 and when it equals 0 it sets the (L:SR reset) back to 0 - job is done.I neither have tried this nor may the syntax be correct in all points, but the idea (in general) will work.Herbert
  10. you don't really want me to comment this, do you? Yes, you do.OK, here we go:No, that isn't too much - in case you tried to find a solution on your own - within a reasonable time. I think about 2 or 3 days (meaning 16 - 24 hours) of investigations, trial and errors are a reasonable time. If after that you haven't found a solution, you'll be moe than welcome - and you'll probably get a qualified answer. (if not from me than maybe from someone else...)But - without diving into this subject too deeply - I'm quite sure that there will be a solution that doesn't require too much investigations.
  11. yes, it would be nice to have my coffee boiled in the morning, but I have to do it on my own...
  12. the SIM_RATE_INCR and SIM_RATE_DECR mouse click events still work.
  13. Keith,First of all, I'd like to say: NEVER GIVE UP!I'm in the mid 40's and allready realized that I could get things working faster when I wore a younger man's cloth... I wish, I had that "drive" you have when I'll (if ever) be 70.Then concerning the XML syntax: Maybe this very basic information might shed some more light on your problems:XML code is executed from top to bottom and within a line from left to right. So conditions that get true at the beginning of an element will have an influence of everything else beeing coded in that context.And it is not only the knowledge about the syntax that makes the diference between those beeing able to produce good gauges and those that eren't. Sometimes - if not even rather often - you'll need something like "inspiration" or at least a good sense to see things in a very, very logical context. And these aren't things that can be written in a tutorial.So, once again good luck with whatever you'll try to get managed but let's cut this thread at this point. If you need more help on specific things, feel free to contact me via pm.Herbert
  14. Keith,I must say, you're confusing me... you say you allready made several other XML gauges, you use an XML editor and still you don't know the basics of the XML syntax?Well, I'm not the one to judge this here.As for that mentioned elevator up-/down-feature:That's indee a bit tricky, as now time comes into the game.Working with time controlled events is possible, but not that easy to explain - and to keep code simple, I'd let do that by using macros. But that would start a new thread, I'm afraid...But here is an idea, which should also work:As you will have to move the elevator down and then up again within a certain time, you might use the time the flaps need to get extended.So check when the flaps are starting to extend with something like(A:TRAILING EDGE FLAPS LEFT PERCENT,percent) s0 l0 5 > l0 50 < && if{ (>K:ELEVATOR_UP) }This will move the elevator as long as the flaps are > 5% and < 50%. To move the elevators down again use this:(A:TRAILING EDGE FLAPS LEFT PERCENT,percent) s1 l1 50 > l1 95 < && if{ (>K:ELEVATOR_DOWN) }But those commands above aren't one time events, so they will happen as long as the condition meets. You could controll this by the gauge update frequency, but probably it would be better to use something like(A:ELEVATOR POSITION,percent) X.X - 163,83 * (>K:ELEVATOR_SET)By using an appropriate value for X.X (start with 0.1) you can controll how fast the elevator position will change per update cycle. You may also try different values for the start points when this movements begin / end (the obove flaps positions 5 / 50 / 95 %).OK, these are the quick ideas of I would try to do these things. I'm sure it can be done, but will probably need a lot of try and error and a lot of time to find the fittings values.Good luck!Herbert