Sign in to follow this  
Guest Karl R Pettersen

1690 and xx90 above, numbers causing weird problems (xml)

Recommended Posts

Hi,When I have a L:Variable set at 1690, I'm not able to get the same results in xml as I do with the normal calculator. 1691, 1689, 1590, 1490, works fine, but 1690, 1790 and 1890 etc gives really strange results.What I'm trying to do is do a tenth increment on an adf without carrier, setting up a standby frequency.The code goes as follows (inc by ten):(L:Adf1 standby frequency,number) 100 / d int - 100 * int90 >=if{(L:Adf1 standby frequency,number) 90 - (>L:Adf1 standby frequency,number)}els{(L:Adf1 standby frequency,number) 10 + (>L:Adf1 standby frequency,number)}Changing the 90 >= to 89 &gt seems to work, but it seems highly nonlogic?Doing the following clicks in calculator: 1690 / 100 = - int = * 100 = int = gives 90, my expected value. Even Excel seems to "fail" on this, as long as I take integer of a previous integered value, but not if I setup the calculation setting up 0.9 manually ('INTEGER' replaced since I'm using a localized version of Excel):Cell A1 =1690/100Cell B1, can even refer to cell A1 in beginning.=((1690/100)-INTEGER(A1))*100, gives 90, correctCell C1=INTEGER(B1), hehe, gives 89!!!This is silly? How can integer of 90 become 89? What maths class should I take again? :) Does anyone know a way around this problem?Edit: I've also tried using ceil instead of int, and deleting the last int or ceil. Still no go though.

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Unfortunately things like that can happen. It looks very much like a rounding problem. Often it 0.9 (or any other float) is represented internally as 0.899999999999 and *10 and int gives int(8.999999) and that is 8. Try to work with 'flr','ceil','near' not with 'int' (depends on the actual purpose).BTW in XML we have 'near' to round properly in C we haven't, but (int)floor(number+0.5) does the same trick.Arne Bartels

Share this post


Link to post
Share on other sites

Karl,Of course not a solution for your strange math's but, though not very real, if one wants an adf standby frequency, you can use G:Var's to change and read the numbers.Here is my code (tested):Logic: (G:Var4) 10 / (G:Var3) + (G:Var2) 10 * + (G:Var1) 100 * + (>G:Var5) Read:%((A:Adf1 active frequency, KHz))%!06.1f!%((G:Var5))%!06.1f!Click: (G:Var1) 1 - 0 max (>G:Var4) (G:Var1) 1 + 17 min (>G:Var4) (G:Var2) 1 - 0 max (>G:Var7) (G:Var2) 1 + 9 min (>G:Var7) (G:Var3) 1 - 0 max (>G:Var7) (G:Var3) 1 + 9 min (>G:Var7) (G:Var4) 1 - 0 max (>G:Var7) (G:Var4) 1 + 9 min (>G:Var7)Swap: (G:Var5) d 10 * 10000 % int d 10 % r 10 / int d 10 % r 10 / int d 10 % r 10 / int 16 * + 16 * + 16 * + r 1000 < if{ (>K:ADF_LOWRANGE_SET) } els{ (>K:ADF_HIGHRANGE_SET) }Works very good, and it is a "fill in" for the adf stby freq window.Jan"Procul Negotiis"

Share this post


Link to post
Share on other sites

thanks for the explanation Arne. I suspected it had to do with rounding errors. It sure made me a miserable day yesterday though. I got around the problem using "normal" modulo functions though. Moral: It is never too late to return to proven methods :DAs for the standby, I use the dc3 method, excect I have put it in as a macro, which uses the COMPLETE_SET. I've tried getting around those high and lowrange stuff, but I've always ended up in troubles of all sorts (mainly due to readability issues). Looks like this:10000 * s010 % (>L:ADFConversionTemp,number)l0 10 / flr 10 % 16 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number)l0 100 / flr 10 % 256 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number)l0 1000 / flr 10 % 4096 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number)l0 10000 / flr 10 % 65536 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number)l0 100000 / flr 10 % 1048576 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number)l0 1000000 / flr 10 % 16777216 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number)l0 10000000 / flr 10 % 268435456 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number)(L:ADFConversionTemp,number) (>K:ADF_COMPLETE_SET)Anywhere in code, simply call with 1347.2 (*any freq on stack*) @ADF_SETI love this macrostuff :)

Share this post


Link to post
Share on other sites

Karl,What do you use for clicks to choose the frequency and the to swap?A L:number or a G:Var?Jan"Procul Negotiis"

Share this post


Link to post
Share on other sites

I'm very consistent of using L:Variables over G:Var's since I have had problems with G:Var's when a gauge is called on several panels, or on both 2d and vc panels. It doesn't always fail, but sometimes.Here is btw a couple of very useful "macros" (procedures, gosub routines) if you use the new xmlsound system. VERY similar to the adf set above: 200 + 10000 * s0 10 % (>L:ADFConversionTemp,number) l0 10 / flr 10 % 16 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number) l0 100 / flr 10 % 256 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number) l0 1000 / flr 10 % 4096 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number) l0 10000 / flr 10 % 65536 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number) l0 100000 / flr 10 % 1048576 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number) l0 1000000 / flr 10 % 16777216 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number) l0 10000000 / flr 10 % 268435456 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number) (L:ADFConversionTemp,number) (>K:ADF2_COMPLETE_SET) 300 + 10000 * s0 10 % (>L:ADFConversionTemp,number) l0 10 / flr 10 % 16 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number) l0 100 / flr 10 % 256 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number) l0 1000 / flr 10 % 4096 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number) l0 10000 / flr 10 % 65536 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number) l0 100000 / flr 10 % 1048576 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number) l0 1000000 / flr 10 % 16777216 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number) l0 10000000 / flr 10 % 268435456 * (L:ADFConversionTemp,number) + (>L:ADFConversionTemp,number) (L:ADFConversionTemp,number) (>K:ADF2_COMPLETE_SET)Use like this:2 @PlayS to play sound "dsd_xml_02.wav" once.2 @PlayL to play sound "dsd_xml_02.wav" in loop.If the author of this gauge reads this, I'd like to ask for a couple of changes, hopefully improvements:Firstly, the default searchpath should always be the aircraft's sound directory, or the xml code directory. That way there would never be a conflict between aircrafts using different soundsets. Or, using the yyy.gau filename as an indicator on what prefix the sounds should use. I.e. Naming your gauge yyy.gau would make it go look in sound dir for files named yyy_01.wav when played.Secondly, now there is two types of playback, once and looped. The looped one doesn't always behave correctly. The following types should be possible, since there are many more frequencies to "exploit": once, loop toggle, loop start, and loop stop. Heh, maybe even loop fadein and loop fadeout with various fade times (controlled?). A "silence all" command would also be welcome.Just a couple of suggestions if you are low on workload, hehe :D I really dig that gauge now - excellent work.

Share this post


Link to post
Share on other sites

I am now totally addicted to the xml-sound.gau of Doug Dawson, which uses also the adf2 complete set code.Now having more than 40 sounds and "loops operable without any problem.Jan"Procul Negotiis"

Share this post


Link to post
Share on other sites

Karl,Thanks for the feedback. I'm glad to hear you are enjoying the gauge. Renaming the gauge is a no go. The registration key it supplies to FSUIPC is dependent on the external gauge name. Renaming the gauge will cause this registration to fail and the gauge will then be dependent on a registered copy of FSUIPC.If I learn a little more about programming in C, I should be able to come up with some of the enhancements you are looking for. The fade in and fade out functions would require my dumping the EasyGauge gaugesound.dll in favour of DirectX calls.If you have a specific project in mind, let me know. It would be easy enough to re-compile the gauge with different sound names and paths. At that point it could in fact be renamed (with a new reg key being obtained for FSUIPC access.)Doug Dawson

Share this post


Link to post
Share on other sites

Thanks for the offer, but since I'm mainly "designing" stuff for personal use, merging into other peoples (and default) aircraft, I don't think that would be necessary. A general purpose gauge that causes everybody to be happy would be better (using gauge filename or aircraft sound directory, maybe a sound directory named sound.xmlsounds or something.I "hexed" the .gau file, and if no protection is put in, I might even be able to "hack it" :) to use different filenames for my different aircrafts. Although, 100 files for my own use should probably be enough. I was able to hack Bill Morad's gauge in this manner and it worked fined. Never released anything with it though.As for DirectX calls, uhmm. I've actually had _really_ weird soundproblems after using WeatherSet in fsuipc. Sounds are really destroyed and a restart necessary. Other games have had this problem too (Freelancer being the most notorious), but only when run on WinXP. All products made by you know who, MS :D

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this