Payware quality review

[dragonflightdesign 98]

Hi Ed>>it was a decision by MSWell, if I want to be really, really picky, :) :) it was actually a decision by BAO. Due to legal restrictions even FSX still has FS3 (yes!) code in it and quite a few of FS' apparently stupid restrictions date back to the subLogic/Microsoft court case of (about) 1987. Ever wondered why no ADF2 in FS? The code stub is in the core engine but M$ aren't allowed to make use of it.You are absolutely right on the definition of a bug.-Dai

[n4gix 4,947]

>Ever wondered>why no ADF2 in FS? The code stub is in the core engine but M$>aren't allowed to make use of it.LOL! Folks would be amazed if they realized that core is still in pure assembly language too!Oops... more catching up to do, Dai... ;) FS9 does offer ADF2 now......kinda, sorta...There are C key_events to control ADF2, as well as Tooltips... but, there is no read variable for C gauges.Full support is offered via XML though, so we can read the A:ADF:2 variable using the execute_calculator_code function.That legal settlement might explain why there's no C variable though... :-bang

[n4gix 4,947]

>Just as an aside Fly! II radios operate just the way the>author is asking for so It can be done.No one has said that "it can't be done." That's not the point! >The point in question is NOT a programming bug. ie. it doesn't crash the program BUT it is a LOGIC bug in that it doesn't represent reality.Roger, that's not correct either. All digital avionics that I'm aware of DO in fact feature higher-digit rollover by design. Having spent a significant part of my fifty-seven years working with electronics (including avionics), I'm pretty well versed on the subject.Granted, older style avionics with mechanical tuning and/or displays don't normally have higher-digit rollover, but many of them did have a 'calculator style' rolling digit display that did allow for the higher-digit rollover feature.I suppose it all depends on just WHO'S reality takes precedence!No matter how you parse it though, a deliberate design decision that works consistently as intended is not a "bug" by any definition of the term...

[dragonflightdesign 98]

Hi Bill>LOL! Folks would be amazed if they realized that core is>still in pure assembly language too!Yes. As I understand it, Microsoft are legally bound to not look at or use any information present in the core engine that was not in use as of the date of the court case. Many years ago (FS5 days) Simon Hradecky (AS2) was one of the guys that poked around in there with a hex editor. Simon passed me the results of what was then an 'underground' document and what Bruce Artwick had forward-planned for was absolutely amazing. Individual instrument lighting was another core-stub event. Incidently, Microsoft had a similar core-stub in place for FS98 but never implemented it.>Oops... more catching up to do, Dai... ;) FS9 does offer ADF2>now...>...kinda, sorta...I'm likely to be sticking with C unless pushed. Actually, now I come to think of it, my dayjob with The Other Big IDE Company will probably let me learn XML anyway.Yah, well off-topic. Never mind.-Dai

[Guest JeanLuc_]

If I'm not mistaken (memory sometimes fails), I think the SDK includes two sets of KEY_ events: one set increments WITH rollover, and the other set increments WITHOUT. Actually I think I've used the one WITHOUT consistently in my gauges. (again, saturday morning with a cofee and a not 100% working memory here).

[Roger Mazengarb 0]

G'day Bill,>Roger, that's not correct either. All digital avionics that >I'm aware of DO in fact feature higher-digit rollover by design. >Having spent a significant part of my fifty-seven years working with >electronics (including avionics), I'm pretty well versed on the >subject.>Granted, older style avionics with mechanical tuning and/or displays >don't normally have higher-digit rollover, but many of them did have >a 'calculator style' rolling digit display that did allow for the >higher-digit rollover feature. Hey what's with this older style stuff! :-)That's the trouble with the young'uns of today. They think every aircraft has a digital glass cockpit.The point I think the originator of the thread was trying to make was that the designers of aircraft are not making the aircraft as true to life as they could/should, using the roll over of radio frequencing tuning purely as an example. The point of whether the digits roll over or not was exactly the issue he was trying to raise. Many designers, perhaps being aware that they do know how something works on one aircraft type simply transpose that to the aircraft they are modelling, when such may not be the case. The average beta tester would in all probability fail to notice the discrepency. I got the impression he was advocating a group of people with specialized knowledge that designers could call on to beta test their creations as to how faithfully they approach reality. All in all I thought it a fairly good idea (with implementation difficulties) but I would think it be better done at the research/design stage rather than at the beta testing stage. Keep beta testing for programing erros/glitches/crashes/hardware incompatibilities etc.Being a staunch supporter of freeware it would have to be a free service even if it was a payware developer seeking assistance. >I suppose it all depends on just WHO'S reality takes precedence!No I disagree! There is only one reality. The programer either faithfully follows the aircraft type he is making or he doesn't, period. Is there a B747 that has the flight controls modelled anywhere near the real life aircraft I'd be curious to hear about it. I don't think so, ( I'll eat humble pie if there is) and that includes payware. The basic problem is that the advertising hype is way in advance of the product, which only promotes disillusionment.Roger

[n4gix 4,947]

>If I'm not mistaken (memory sometimes fails), I think the SDK>includes two sets of KEY_ events: one set increments WITH>rollover, and the other set increments WITHOUT. Actually I>think I've used the one WITHOUT consistently in my gauges.>(again, saturday morning with a cofee and a not 100% working>memory here).For COM and NAV only the fractional tuning has a choice of rollover or non-rollover, for example:#define KEY_COM2_RADIO_FRACT_DEC (KEY_ID_MIN + 902)#define KEY_COM2_RADIO_FRACT_DEC_CARRY (KEY_ID_MIN + 903)The _CARRY event will increment the 1's digit each time .9 is passed, and vice-versa.The _WHOLE key events will auto-rollover the next higher digits, always.Whenever I've needed to simulate mechanical tuning of individual digits, I've had to use custom variables in conjunction with the _SET key event.

[Guest JeanLuc_]

that is it! the WHOLE and the CARRY versions!

[marcom 139]

Roger - thankyou!That is exactly the point I was trying to make in this thread! I'm a little surprised the whole rollover issue exploded while it was only an example of ONE thing many developers disregarded.And I agree - should this service ever become reality, it will be free of charge and available to freeware designers aswell (as long as they didn't just alter panel bitmaps...) - I'd think the TinMouse project is a very good example of how good freeware can be!Regards,Mark

[n4gix 4,947]

Mark, the whole "rolling digits thing" was to illustrate that a little ignorance can go a long ways towards coming to erroneous conclusions... ;)Those who seek realistic operations will invest the time and MONEY necessary to obtain the actual operations manuals for systems and sub-systems.The "average" modeler or gauge programmer isn't all that concerned with "realistic functions," but simply use the sim defaults.

[WarpD 824]

>Roger - thankyou!>>That is exactly the point I was trying to make in this thread!>I'm a little surprised the whole rollover issue exploded while>it was only an example of ONE thing many developers>disregarded.>Yet again, you're incorrect. It's not disregarded. To code around it literally breaks such hardware as designed by GoFlight. That is NOT a thought taken lightly. It is extremely clear that you literally do not grasp the impact of what you demand and/or expect. Not everything can be simply bypassed.>And I agree - should this service ever become reality, it will>be free of charge and available to freeware designers aswell>(as long as they didn't just alter panel bitmaps...) - I'd>think the TinMouse project is a very good example of how good>freeware can be!Until there is a group that literally understands every aspect of FS and what it can and can not support as well as why something should or should not be coded around... this idea is about as brilliant as a hot water heater in the Sahara desert.>>Regards,>>Mark

[Guest iholrf]

>Until there is a group that literally understands every aspect>of FS and what it can and can not support as well as why>something should or should not be coded around... this idea is>about as brilliant as a hot water heater in the Sahara>desert.>Yer a "cup is half empty" kind of guy, eh? Where is your sense of adventure? ;)I agree with Roger and I think the OP has a valid idea that will be a challenge to impliment. Semantic arguments like "what 'real as it gets' means" and credentialism asside, the only thing that would cause it to fail is if the organization does not demonstrate a willingness to do significant research into the actual flight and operational characteristics of a type (not just spec data).I think such an organization could well succeed, but not if its free. You will find that impossible. But as a paid service (remember there is also "non profit"), you can do a whole lot more and generate (hire) the needed experties for your client if required.Here is a further idea... I was in contact with the author of a recent addition to the library who mentioned prior to the release that the beta testing got a little difficult to manage at times.It seems to me there is an opportunity within those words: What you might be able to offer is some sort of "beta testing central" that does not just look at things like "real as it gets" but also things like "it works as author intended". IE A multi-tiered approach.You could provide streamlined access to beta testing as well as streamline the beta testing procedures. As you can see from this and other examples in this thread, some other developers have struggled with the process (to the point that often the real "beta testing" is the actual release version) and it might prove a valuable service.Like any business venture, it comes down to how well you can generate the appropriate relationships (people - contacts). In that area anybody might have trouble as those take time to cultivate (years), and the quality of which is so very often based on personality. Thats where science becomes art.CheersShad