That is great to hear! It sort of reminds me of the experimental process. d

Glad the issue was worked out, and this is a great connection to Ben’s post.

A workaround might be sensible in current iteration of XP life. Maybe on next XP version you will be able to fix this issue, since incompatibilities should be acceptable.

I think so, yeah. If you want your object lazy-loaded, you should do so at the plugin level; since the next thing you can do with an OBJ is -draw- it, lazy loading by the SDK would imply blocks -during- drawing for loading objects. So we assume that if you want the OBJ now, you mean it. Note that you can also schedule an object to load async, which is often the best compromise.

No.
– This bug is new to 10.50, so applying the fix to 10.45 makes no sense.
– We aren’t going to patch 10.45 at all – 10.50 -is- where bug fixes will go.

Is lazy-loading .obj conditionals’ dependencies out of the question?

cheers,
sh

In the project I am currently emplyed in, just until a couple of weeks ago, we had one automated test that was failing “sometimes”. There was no clear cause for the test to fail, but myself and some other members of the team that took some time to investigate postulated that it was due to timing issues (always a nasty thing with asynchronous code execution). Eventually I was tasked with actually fixing the issue. So, my initial reaction was to refactor the code in such a manner that the timing would not be an issue. Once I did that, the test started to fail *always*.

Many junior software developers would think that this was a turn for worse, but I was positively thrilled. Instead of a test that was randomly failing, I now had a test that was always failing – so … this brought the realisation that the random failures were *not* the problem … the problem was that most of the time the test was “randomly” passing – even though it should have failed. So … I was thrilled because I had made the test behave deterministically and this was the first step in getting the feature actually work the way it was supposed to.

What to take home from all of this? a) Automated tests are developer’s friend, not an enemy. b) If/when your tests fail – even randomly, look into it; there is possibly a bug involved. c) If you make a change that causes a test that sometimes fails to fail always – that is not necessarily a bad thing.

…oh, and in case it is of interest to anyone, I did manage to fix the actual root cause of the failure in our tests. Since then the test (unmodified since the initial modification that caused it to always fail) has passed without problems. That is always nice thing to take home after work 🙂

No. If you have the current installer (3.40r3) you don’t need a new installer.

If you are experiencing crashes on startup you may have to -manually- check for updates using that installer; some of the crashes in beta 1 crash before the auto-update check happens.

Is is going to be necessary to download a new installer once b2 goes live?