EXPERIMENTAL USE ONLY!!! -- [What?] -- Login to add public annotations [How? >>YouTube].

I probably should have said this earlier.

Please do not release 64-bit add-ons.

If you want to beta test your add-on in 64-bits, great!  If you have gotten 64 bits working, that’s totally cool!

But, please don’t ship 64-bit code.  The problem is: we are still in beta and there are still open issues with 64-bit plugins that have not been resolved.  If we make changes to the plugin system during beta to make 64-bits work right and your add-on is broken, you won’t be able to react to it if it is already released.

So wait – make sure to test against the RC.  Like new features and scenery file formats, while the new features is in beta, it is unstable and we’re not going to try to ‘protect’ you from change.  Once we go final, things will be set in stone but we are not there yet.

(In beta 3 we changed our address space layout on Mac…that should give you an idea of how new this stuff is.)

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

16 comments on “Please DO NOT release 64-bit add-ons”

  1. Is the 32 bit version of 10.20b5 an update whose operation you are very interested in getting checked out? As a Windows user, given the comments about 64bit support, it seems like there is very little incentive to switch to 64bit at the present time. If I understand correctly, even though I have 16GB of storage on my system, and a 3 core processor, X-Plane can and does use only 4GB for Windows users in either mode. The main advantage is that Apple users move from using only 3GB to 4 GB when the switch is made. Am I correct in this statement?

    For Chris’s benefit, another comment. I have just finished the taxi Routes for 5 GA airports in the Keys and central Florida. The tutorial was really helpful, especially because it showed how to form groups in the right WED pane to consolidate the display of airports with substantial collections of objects and layout data. The ATC operation is now quite nice and the paths taken by aircraft look really good. My only complaint is that any waiting X-plane aircraft at a runway hold always causes an ATC waveoff of previously tower-approved landings on the runway, and the resultant ATC managed go-around can often be a course of 40 NM with a great chance that the whole situation will repeat itself (and with only 2 GA auto-aircraft operational yet!).

    Should I put the 32bit 10.20 beta on my system..would that be of any good use to your operations at this time?… or to mine?

    1. We are interested in regression bugs from 10.11 32 bit to 10.20 32 bit. But 10.20 has a lot of open bugs right now, so I don’t think I would suggest it for personal use.

    2. I’ve had some success moving the runway hold point in the taxi flow (critical area – red) farther from the runway. So if your matching your taxi flows to the paint you put down, you might be too close to the runway for ATC to handle it.

    1. A viewable bug tracker would be very useful — it would sure save me the time (and the headache) of having to report a bug that someone else may have already submitted.

      1. Let me say this about a bug tracker: the bug report form has a small number of very clear instructions, things like “include a log.txt” and “don’t email this form for tech support” and the overwhelming majority of bug reports do not follow procedures. (Some users are very good about following instructions and I appreciate the effort that everyone puts in, even when the report instructions are not followed, and you, who is reading this may be in the minority of “I read the instructions first” but…statistically, most people aren’t paying attention.)

        So while we have discussed internally a number of ways to do some kind of better sharing of bug information, we have not yet come up with anything satisfactory. In particular, we think that if we make the instructions _more_ complicated (which is almost guaranteed to be necessary to have a ‘full bug base’ approach) the results are going to be a wreck due to the number of bug reports that don’t follow procedure.

        If you are an ambitious user who wants better bug tracking, I can see only one way to get the benefits of a bug base given our (LR’s) unwillingness to open up our internal bug DB while the level of bug report instruction following is so low (and I think this scheme isn’t terrible):

        – A group of users who wants to have the advantage of a bug base maintains a public bug DB of ‘user submitted bugs’.
        – Someone in that group submits the bugs to LR.
        – Someone in that group ‘gardens’ the public bug base to keep junk out.

        There is one more aspect of this scheme (and a public bug base in general) that I do not like:

        Duplicate bugs contain information!!!

        In other words, the number of users reporting a bug is really important for us to understand the configuration, frequency, and severity of a bug. It is useful for us that when something is _really_ broken, we hear about it 3 times, because there are a lot of “bugs” that we hear about only once, from one user, that turns out to be some local piece of crap-ware on their PC or a graphics card with a bad heat sync or magically goes away with a driver upgrade.

        So my concern is that IF everyone stops reporting every duplicate bug, we won’t be able to tell the ‘real’ bugs from the ‘configuration problems’.

        And one more note on duplicates: you guys (users) are not in a position to judge what is truly a duplicate bug, because often _two_ bugs in the system have _different_ root causes – particularly when the repro steps are non-obvious. And often one bug has multiple different manifestations, making it appear like two. So the ‘duplicate detection’ value of a public bug base may be limited – it will cause users to spend time reading bugs instead of filing (time not saved because to do the procedure right, you as a user must read the ENTIRE bug base to find whether you are reporting a dupe) and we get bugs filtered out, but not the ones we want filtered out.

        I think there are two real issues going on with 10.20:

        1. The speed at which I jump on the “obvious” bugs has been quite slow due to all of the plugin-related goo and other junk I’ve been working on, plus a beta during the Thanksgiving long weekend. Our normal approach is to fix anything that gets 5+ reports ASAP so that people stop re-reporting, and this “fast fix” approach is good for everyone.

        2. I haven’t done a very good job of keeping up with the ‘known issues’ list, something that I can do a better job.

        In fact, I think my summary is that the simplest thing for us to do is for me to post ‘known issues’ more aggressively.

        1. Hi Ben,

          I was not suggesting having people actually adding bugs to the DB – I was suggesting share the bug DB you have with the rest of the world, at least in a semi-RO mode. You guys would be the ones actually filing bugs…

          Re: The duplicates, it’s perfectly fine to have 2 bugs opened for the same issue (so you keep all the information), as long as you mark the old one as “Dup” of the first one. We can discuss offline if you’re interested some approaches I usually do for managing a huge number of bugs without it becoming a nightmare.

        3. Hi Ben, Thank for a very informative post. I have a question about your XP10 Crash_Reporter. What info does it actually collect and send to you? I allways add my e-mail address, is there anything we (the users) could add to the comments field that would be especially useful to you or do you get all that you need from the .rpt file itself?
          cessna729.

          1. If you open one of those .rpt files in a text editor you will see 99% of what we report – only two items are not plain-text encoded. Basically:

            – Your log file and the actual back-trace of the crash are encoded into the .rpt.
            – A bunch of fields are added that you can see for yourself – mostly OS, driver and sim version info so that our database can filter on things like Mac vs Windows.
            – Your comment (if you add one) and email (if you add one).
            – That UUID is a hash of some system specific info – the goal is just to get a string that’s unique and consistent for YOU so that if a user reports a crash, we can say “let’s see EVERYTHING that’s crashed for this user.” Sometimes a user will have different crashes with one root cause (“look, that guy has a play-station blue-tooth joystick on Mac”). We can’t reverse a UUID to its input info.

            Really the most important thing in the report form is the email, so that if we need more info we can contact you. If you file a bug with ‘the sim crashed’ the rpt file is all we need.

  3. “I probably should have said this earlier. Please do not release 64-bit add-ons.”
    In fact you did 😉 September you stated clear:
    [quote] Never, ever, ever release an airplane against a version of the sim that hasn’t gone final [/quote]
    and I suppose the same would apply for a plugin (especially when keeping in mind, that an airplane nowadays ships mostly with plugins)
    Therefore its only logical, to wait for a plugin release. But nice you remind about it again.

    As a 64-Bit testing guy so far I am happy with the first steps that you made.
    Ron

  4. I know 64bit wasn’t supposed to improve performance but for me I did a controlled test and went from 18fps to 24fps with the new version. In general I also noticed a much smoother performance, had lots of slow spikes but now it’s smooth as butter.

  5. Before there will be a complete UI, it could be helpful to use command-line-arguments.
    For example “firefox –help” uses “-P “, “-ProfileManager”, “-preferences” etc.
    It would be helpful, to use a VersionControl like http://git-scm.com/ to have different profiles with its own history.
    They Plugins, Joystick-Settings and more are directly bundled together and many user may use the same settings with just there own modifications.

  6. I’m only posting this here because so I know it will be noticed:

    Last night, I installed the latest beta for the first time. Ben and friends gave me a lot of help over email when I bought X-plane because I kept experiencing total system crashes. It turns out that these were a result of over cranking the rendering settings.

    I can happily report that, using the 64 bit beta, I played the sim for about half an hour with no crashes, even with the settings turned up to a degree which my computer is doesn’t have the power for. Sure, the fps dropped to about 7, so I wouldn’t seriously attempt to play the game in that configuration, but at least now I can play with the settings without fear of a crash and 5 minute restart each time.

    So, well done to Ben and team, and thanks for all the hard work. I can report at least one pay-off for the 64 bit conversion!

Comments are closed.