Evan, > Just because developers understand a problem with an application, it > doesn't necessarily mean it's not a bug with the application, > does it?
A bug is defined as _unexpected_ behavior, the semi-transparent rendering problems are completely expected based on our particular z-sorting algorithm. If instead we were of the opinion that it shouldn't happen but it does, thus making this unexpected behavior, then it would be logged as a bug. Our sorting algorithms are working just as expected, the problem here is that they are not working just as you (or others) desire and that is the critical difference between this being a bug versus a feature request. NOTE: being as most folks don't know our sorting algorithms the first and most natural instinct is to say "bug!", but I do have the additional knowledge necessary and felt I'd share the fact that this is an implementation limitation and not a bug. > Sure his algorithm is working as expected: it's losing money. > And it's still incorrect for your broker to use an algorithm. Yes, it's incorrect for the broker to use the algorithm but you wouldn't say the algorithm is behaving unexpectedly would you? In fact you state that it's working as expected yourself (buying high and selling low just like it was made to do) so the algorithm itself is fine, the choice to use it is the problem for you (and me too if that's my broker!). In our case our z-sorting algorithms are working as expected (z-sorting on a model level), you disagree with our choice to use it thus I label it as a feature request: change your z-sorting algorithm, it's working as expected (now that Tom told me how you z-sort - on a model level) but just not how would like it to. Two final points: 1. Bug vs. feature request is not a factor in determining the importance of fixing such an "issue", we'd look at the user impact and move from there, the classification is largely a semantics issue. 2. My use of the word "incorrect" in my summary was coming from _your_ perspective, the end user doesn't care whether it's expected or not, it's just that polys that are behind other polys render in front and that's "incorrect" based on your eyeball level experience without knowing the code. I'll refrain from summarizing a bug or feature request from your point of view to avoid further confusion. ;) Cheers, Tom [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
