Thanks for explaining that changing the default for removing Scenes was a necessity to match most common behavior. A choice had to be made.

In the release notes I read:

bpy.data.foo.remove() functions have been cleaned up and unified in behavior, now you need to pass do_unlink=True explicitly to unlink the datablock from Blender before deleting it. Previously, some were silently unlinking, while others errored if the datablock was still in use.

Still broken (Blender 2.75a).

I can confirm the bug.

I can confirm that the file doesn't crash with Blender 2.72b on Windows 7 64-bit. So probably it's a Windows 8 issue.

Could this be closed then?

Related to T27322. Some diffs presented there.

Sorry guys, it's still broken. Press Return to add object, wait a second until Blender crashes when its removed from the scene.

Thanks lordloki. It seems to be fixed in 2.72RC.

Looking at your blend more carefully made me realize I didn't reproduce it exactly as was explained. Sorry about that. I could reproduce it and my conclusion is that adding an object in an overlay scene through the controller of an object in the background scene causes Blender to crash.

Hmm... This probably shouldn't be called: 'Armature Modifier broken' because Mesh deformation does work! Only you have to activate the action. I'm closing this. If someone has an objection to this, please do reopen it, but just keep in mind the bug shown in the blend is more of a Viewport type of thing.

@solarlune: Could you maybe have a look at this blend file. I had to update yours a bit to make it work in 2.71 (texture lost some info). But it works, I think. Could you make sure I'm not missing anything? And if not, this could be closed then?

Duplicate of T33462?

Workaround is to Clear Parent and Keep Transformation, then Vertex Parent again.

Not really a duplicate of T19377 but this fix should also solve the issue with removeParent() (and the Remove Parent Actuator).

Not really a duplicate of T35917 but this fix should also solve the issue with restoreDynamics().

A workaround is to load your own font (*.ttf). The same font will be displayed in both Blender as the BGE. But then still there's the issue that in the BGE the size or the spacing is different. It sure would be nice if there would be no difference at all.

Could not reproduce with 2.71 on Windows 7 64. Pressing 3 will do as expected: mpa cube scales up, ecology cube fades out. So can this be closed?

As Mitchell said. Tested without issue with 2.71 also. So could this be closed?

Can't reproduce this with 2.71 on Windows 7 64. It seems to be fixed. So could this be closed?

Made a simpler blend file which tests Set State Actuator with Action Actuator. Play 'Scene' and see that it works as it should. Then play 'Scene_Sensors_reused' and see that it doesn't work, while it should.

I think we have working examples of what mad-overlord was trying to do here. Could this be closed? As sergof mentioned this isn't a Physics bug anyway (but a collision shape visualization bug).

This is a duplicate of T40955. Could this be closed?

This probably relates to T33212.

This probably relates to T40955.

And couldn't reproduce crash with 2.71 with Windows 7 64. Can this be closed? It's a duplicate of T31101 anyway...

To get an extra picture of what's happening to the normal map, I adjusted the example in T32383 (the duplicate) a bit:

Also confirmed with 2.71 on Windows 7 64.

Have you tested with the newest build of 2.71, because a couple of weeks ago I downloaded Hash 80d3eb6, and with this version everything seems to work fine. (on Windows 7 64-bit).

No. First of all the bug in the link couldn't be reproduced on systems including a video card. Secondly, the bug ascribed here doesn't involve a crash. Thirdly, hitting the P key hasn't anything to do with it. The attached blend shows a mesh being deformed by an armature. Press P to see how this doesn't work in the BGE.

Any chance these patches will be committed soon?

I can confirm this. First thing that came to mind is that this was already reported, but couldn't find it in the tracker. So I'm glad it is reported anyhow.

I can confirm this.

@Inês Almeida (brita_) This seems to be fixed. I tested in 2.71.2. Starting the path with '//' solves the problem. I made a proper test file for this. I'm not sure if I could close this so I'll leave that up to you (or someone else). Here's the test file. When starting the game two cubes will be LibLoaded, one with packed textures, one without. After two seconds 'Start Game From File' will activate. In all cases the textures show up as they should:

To be more specific it's the first 'created' material, not just the material on the first material block.

I also can reproduce the error. What's more is that if both objects have the same two materials, no polygons disappear, instead they exchange materials. Here's an example of that:

Bug confirmed with Blender 2.71 hash 80d3eb6 (2014-07-18).

Maybe this could be changed from type 'Bug' to 'To do' or 'Design'. I think we all agree that changing to seconds is the best solution.

I had to know... So, thanks. And sorry for the trouble.

@Satoshi Yamasaki (yamyam) not offended at all ;)

I think I'm free to assume that path D610 is committed now, but the bug is still not fixed. @Inês Almeida (brita_) please correct me if I'm wrong.

@Satoshi Yamasaki (yamyam) I'm not saying that there's a problem with the Keyboard Sensor, only that it could be related, because with an Always Sensor there's no problem at all.

Very strange bug. Point, Hemi and Area work, but Sun and Spot won't. You could wonder how this is related to PingPong action mode or the Keyboard Sensor, because with an Always Sensor set to a frequency it works too.

bump

@rouane yasir (rouane) Don't wait to long with completing a report. If after some time the author still wouldn't have shown interest in completing it, it most likely will be considered as an invalid report.

I see. But I'm wondering if automating the video refreshing would actually make a (noticeable) difference. If you think about it, to playback video, the bge has to convert every frame. It's not like we have a real player in the bge. And I think this is what is taking so much processing power/time. But I don't know for sure. It's an interesting topic so I hope some else could tell us more about this. Maybe you could start a new thread on the BA forum to ask around? Just an idea.

Thanks, Giulio, for this valuable information. Since I'm not an expert on this, I hope someone else could confirm if this CPU usage is due to a bug in the BGE. Maybe brita_ can redirect this to someone who's familiar with these type of things.

@Inês Almeida (brita_) Maybe could you have a look?

I use Open Hardware Monitor to monitor my CPU levels.

To make it easier for everyone, here's a complete example:

Thanks for the link, Giulio, I tested with this *.ogg, but like before no CPU core is peaking (not more than 20%). However I had no sound, but that's another issue probably.

It would be better to provide a complete example file so you're not giving developers more work than necessary.

Please provide a fully functional, but small example. The blend you provided is incomplete.

@Inês Almeida (brita_) If patch D610 is closed, does this also mean that it was committed two weeks ago? Should I then reopen this task, because latest builds still have the bug?

The link is broken, so here's the full link: https://www.wuala.com/MESY/public_data/inside_eies_animation2-final%2016t9-packed.7z

@MrLarodos (mrlarodos) I've checked this and I can confirm that this is a bug. Maybe this simple blend will be more useful. Normally the Cube would be sliding faster until it reaches the grass material. Change the friction of the grass material to 0 or something low and you'll notice that indeed the friction value of the first material will affect the second material too.

@solarlune

@Inês Almeida (brita_) I created a new task related to just the third bug. The first two are already solved. So this could be merged with T40955.

@solarlune: Could we maybe open a new task for this third issue (LibNew doesn't update Physics Mesh) so this can be closed? Or change the title?

I'm all for changing to seconds. You can read about opinions on BA: Your opinion about fixing the addObject 'time' parameter?

Obstacle simulation works with World properties not set to None. Closing this. If by any chance there would still be an issue then you can always reopen this task.

@Inês Almeida (brita_): Not that there's any haste to it, but since I assumed this is merged now, I downloaded the latest build, but the bug's still there. So I'm assuming this isn't merged yet, is it?

I know that object instances shouldn't be removed when freeing the library, but I'm not sure if a crash is normal behavior. So just in case I reported this.

Split into T40923 and T40924

I agree it would get too messy, but I don't think this work-around is perfect enough, let alone fitted to add as a function to the API. I don't think you can't even call it a work-around, because the result is far from perfect. There's still the collision mesh of the added 'parent' object to consider. Even if this would be cube as small as a grain, its vertexes would still interfere with collision. Here's a blend to illustrate this:

I think this would be useful indeed. But are there circumstances in which it would be profitable to have armatures disabled in game? If not, I don't see why there even should be an option to disable it. But else, I think it's good this could be done with logic bricks as well as with python script.

I can only assume this can be closed. Glad it worked out for you, Hochnebel.

I totally missed that. Sorry. I just tested this and can confirm that these constraints are working in 2.70a but not anymore.

Also notice in LibNew_material_bug.blend that regardless of the material freeing a LibNew library will not remove the object completely. The physics mesh remains. To see this remove line 33.

Had another look at this. This may be related to T40924 because Blender only crashes if the LibLoaded object has a material.

Newest build (bd777ff) doesn't crash.

@Alexander (Hochnebel): Did you run your game on the newest build at http://builder.blender.org/download/ ? I can confirm after 20 seconds or so Blender crashed with the official release, but I tried three times with the newest build and it works fine.

@Wesley Blijlevens (happylifes): If possible, could I have a look at your scene, so I can help figure out what the problem is exactly and make a small example blend? Also, it probably would be better not to file a report without such a blend. What I do sometimes is start a thread at BlenderArtists.org if I have trouble finding the real problem.

@ BPR: Maybe you could change the title to something more accurate. Like for example: "IK not working in BGE".

I can confirm that IK is not working since 2.7a Hash be980b9, probably even before that, but I can't check this. Works in official release 2.7a. Good you noticed this, BPR. It would be unfortunate if this bug would remain in next releases.

Oops, I'm sorry. I didn't notice that latest build is of the 24th. I only assume the one that has the fix hasn't been uploaded yet.

@ brita_: I just checked if this was resolved with the latest build at http://builder.blender.org/download/ (Win64 - f37ec65) and it's not. Are you sure you didn't mix something up?

I can only imagine this won't be looked at due to its complicity. Please provide a simple blend file so it's much easier to confirm whether this is a bug or not.

It seems the crash occurs only when freeing objects that were loaded and freed once or more.
I can confirm that this also happens with LibNews of (inactive) objects, LibLoaded or not.

It seems this one got fixed somehow. So I'm closing it. Thanks, Moguri, it was probably thanks to you.

Hi moguri,