Blender 2.71 official keep crashing on BGE

Sad song never end. With the same project file played smoothly in 2.70a keep crashing in 2.71. Not able to identify the culprits.

Besides, something is just not right e.g. my arrow cannot shoot properly. Tried a few times…gave up…sorrow is the only word left…

Look at the blender’s bug fixing page, out of hundreds bug-fix, we only spared ‘five bucks’ to spend. No complaints,
but this 2.71 is not acceptable.

Anyone has this problem can voice over here.

The problem stems from the multi-threaded animation addition which was added between 2.70 and 2.71. The large patch has had a lot of teething problems since its merge with master, about five hard crashes have been fixed related to it however more remain on the tracker with likely more to be discovered as the bge becomes useable after 2.71 and at least doesn’t hard crash so people can test for more silent bugs with animations. As ive noticed not just crashes related to animations but oddity’s with them related to layers when compared to a blender build just before the multi-threaded addition.

This sadly is to expected from big features that most people want for the bge so try not to hate to much on 2.71 as I don’t think it would have been easy to implement a toggle for the multi threaded system and likely would have cluttered things up im sure to.

Im sure a 2.71a down the line will be available best thing for now is to stick with 2.70 or pre but try and narrow down your problem as much as possible in 2.71 and then report.

Then I don’t agree with the way new features are implemented. Before merging, whoever is responsible should make sure the feature is tested thoroughly so virtually no bugs would be left to fix. I’m volunteering to work side by side with developers to do such testing. And maybe even the community would gladly want to volunteer. Maybe it will take twice as much time for a feature to get merged, but I’m sure it would take much longer for bugs to get fixed if no thorough testing would precede.

Features as large as multi threading a part of the bge cant be tested by the dev for every single use case, especially with animations there’s so many ways they can be used with types of objects.

If I remember correctly this did have a branch separate from master with which it was worked on, but what blender user let alone the majority of very young bge users would have been able to find that branch let alone build it and test it. So adding to master when its working and stable to the dev which im sure it was before the merge is the only way of getting it into a larger user base for testing.

Then that leaves the bge users that one read the tracker about stuff added for the bge and then knowing about build-bot to test with then even bothering to report the bug as many of the bug reports for the bge are consisting of one line of text and not even a blend to recreate the bug with.

I reported a few bugs for animations early on in the 2.71 cycle which got fixed, Other reports came in after release candidate 2 for 2.71 very close to release, showing that people don’t test until an rc build is put up onto blenders main page or with a final. But this isn’t something just akin to the bge, people do this with blender bugs in general which is why we have a and b versions after finals.

So this isn’t really good enough if you want bugs fixed in the bge that have no work around for crashes, make sure to get reports in early when you find them. Showstoppers in the bge will not halt a blender release sadly.

I can understand that it has been difficult to avoid having bugs in trunk. But that’s why I’m proposing to work differently and depend on the help of the community. Of course you can’t expect any common user to know where to find this or that patch, let alone how to build it. That’s why I believe there should be a testing site especially for this purpose. Is it common practice for developers to build a Blender version with the patch after it’s completed? Well, let this Blender version be available for download on a web page especially designed for testing purposes. Let the community do their part in helping developers to keep the code optimized, before merging it.

I’m saying this also because maintenance is not something you get for free. Once a feature is added, you can’t go back, and someone will have to pick up the pieces if things turn out to be broken. I’m sure a lot of such pieces are laying around as a result of merging prematurely. This could be avoided if one would decide only to merge after the work is done.

I’ll test,

The issue with bugs in the BGE can be traced to things like unorganized code in the BGE source and unorganized and improperly presented bug reports from users.

If you want to help the process of fixes for one thing, I’ve seen plenty of cases in the BGE tracker where Moguri or another developer struggle to figure out what the report is trying to say, this by itself would be helping to impede progress.

Moguri and LordLoki have both written up articles on the wiki on what they think needs to be done in the source to clean it up and make future fixes much easier to do (the individual logic brick code for example are in two completely different files, one of the proposals is to have them all in the same directory). Meanwhile, Brita_ on the developer website is busy triaging and assessing bug report threads to definitively figure out which reports are valid and to the point.

By the way, was this the bug you were talking about?

Moguri has concluded that it may have been a fix that was improperly backported to the 2.71 release branch, as BGE armatures work without crashing in Master.

Wherever I can I’m already doing this. I even offered Moguri my help to clarify those bug reports. I didn’t get any response though. I don’t know if anyone else is bug fixing for the Game Engine. But who is can contact me anytime for this job. Please, don’t hesitate!

But that’s not the real problem (imo). Yes, there may be a lot of reports that are invalid or incomplete, but most are not (I think). I’ll see what I can do to complete those that are.

This is great. Could I join Brita_ in this work?

The fact that I have another opinion about implementation doesn’t mean I’m opposed to new features nor the people working so hard to get them working. I just want to help avoid the problems that come with adding new features, and preferably before they get into trunk.

I don’t know if trying to catch bugs before they’re committed is something that’s realistic. Bugs will always be present, and they’ll always be found after the fact. Something that the community can do is regularly update their version of Blender with the version from the BuildBot, or build it themselves if they’re so inclined.

If someone wants to make builds of prospective patches to be committed, that’s great, but it’s also a lot of work (since not all people have the same OS, or even the same bit-depth across the same OS).

Is there any documentation on how to make builds? I would like to do this in order to test new patches.

Here’sa wiki article on it. My build “path” boils down to using TortoiseGit to get the source, TortoiseSVN to get the libs, CMake to make the Visual Studio solution, and Visual Studio to build Blender. You don’t have to use those tools, and it’ll vary according to OS, of course.

“Is there any documentation on how to make builds?”

My environment configuration: Tortoise SVN, Cmake, Microsoft Visual Studio 2013 professionnal (I’ve never succeeded in building 64bits blender versions with visual studio express), git… And to apply patches on Blender Git sources, Tortoise Git.

A tuto I made in french (for windows) (I’m not experimented):

First build takes a lot of time but after, it is easier.

EDIT: I use GIT to get the sources, but apparently (as SolarLune said) you can use tortoise git instead…

TortoiseGit and TortoiseSVN are just graphical frontends for Git and SVN - you can use those if you want to. I just don’t want to use the command line prompt if I don’t have to.

yes :yes: you’re right

(but i don’t know if this code:

cd lib\win64_vc12
svn update
cd …\blender
git pull --rebase
git submodule foreach git pull --rebase origin master

in a .bat file will work if you have not installed git for command prompt) (I don’t know whether tortoise git provides a command prompt to do that or not…)

Thanks, SolarLune and youle.

Hopefully that it is. Thanks!

Thanks Raco!

Tested in blender-2.71-ac6b5f2-win64. Now all the animations are not working properly but bge did not crash.

This bug was reported recently. I can only imagine it will get fixed soon because it’s quite important that armature deformation works in the BGE.

same armature broken bug raco?(my report?)