Closed by commit rBACc8ed86374865.
@Severin made a fix, I'll commit soon.
Exact steps for others to reproduce error:
Open .blend file, if you use button and head of Xbox joystyck in blender 2.72 the empty (and cube associate) move well.
But if you use blender 2.73 or 2.74 testbuild the joystick sensors button and hat is not working properly.
Closed by commit rB02685aca5238.
Could you also tell us which version of Windows you're using? In the bug report you just mention "64 bit".
I still think this lets you work in a faster and more organized way (especially in heavy scenes) -- it just hides away things that are not in interest atm...
I also think improved performance in heavy scenes is quite something.
So, calling this useful "only in a very minor way" seems subjective [it doesnt hold for me - and apparently others]
Generally looks good,
version 2.73 (sub 9), branch b'master', commit date b'2015-03-03' b'13:48', hash b'ed5df50', b'Release'
build date: b'2015-03-03', b'15:58:44'
binary path: 'C:\\Program Files\\Blender Foundation\\test 2.73\\blender-app.exe'
build cflags: b'-DWITH_FREESTYLE /nologo /J /W3 /Gd /w34062 /wd4018 /wd4065 /wd4127 /wd4181 /wd4200 /wd4244 /wd4267 /wd4305 /wd4800 /we4013 /we4431 /D_WIN32_WINNT=0x600 /DOIIO_STATIC_BUILD /openmp -O2 /Ob2 -DWIN32 -D_CONSOLE -D_LIB -D_CRT_SECURE_NO_DEPRECATE -DOPJ_STATIC -DWIN64 -DWITH_MOD_FLUID -DWITH_MOD_OCEANSIM -DLITTLE_ENDIAN -DWITH_AUDASPACE -DWITH_AVI -DWITH_OPENNL'
build cxxflags: b'/nologo /J /W3 /Gd /w34062 /wd4018 /wd4065 /wd4127 /wd4181 /wd4200 /wd4244 /wd4267 /wd4305 /wd4800 /we4013 /we4431 /D_WIN32_WINNT=0x600 /DOIIO_STATIC_BUILD /openmp /EHsc -O2 /Ob2 -DWIN32 -D_CONSOLE -D_LIB -D_CRT_SECURE_NO_DEPRECATE -DOPJ_STATIC -DWIN64 -DWITH_MOD_FLUID -DWITH_MOD_OCEANSIM -DLITTLE_ENDIAN -DWITH_AUDASPACE -DWITH_AVI -DWITH_OPENNL'
build linkflags: b'/SUBSYSTEM:CONSOLE /MACHINE:X64 /STACK:2097152 /OPT:NOREF /INCREMENTAL:NO /NODEFAULTLIB:msvcrt.lib /NODEFAULTLIB:msvcmrt.lib /NODEFAULTLIB:msvcurt.lib /NODEFAULTLIB:msvcrtd.lib'
build system: b'SCons'
Should this restore the active scene after?
Its crappy, but not sure of a better way to get around this. :S
It's just to see the zone used to render shadow texture, can help to optimize.
Hmm, but stickies will come after 2.74 and conflicting shortcuts are high prio! @meta-androcto, we should either change it (e.g. to Q as suggested in the report) or I'm afraid we have to remove it. AFAIK Unmaintained Add-ons with major issues aren't allowed to stay in the official release :/
I added more information to the "System Info" text, so we can debug SDL issues (like this) a bit easier.
I don't think it's totally useful feature to add. I can see why drawing the cone helps -- basically spot lamps does not highlight stuff outside of the code, but sun, area and other lamps do. So it's rather misleading thing IMO.
Could you explain the use-case for this patch, why is it needed?
There are a couple of major problems with the proposal.
Some details, I just noticed.
It happens only when I mix different UV channels
(T43876 might be similar/duplicate)
before spending too much more effort on this patch it'd be good to get functionality approval from the UI module owners.
I'm missing motivation for this change. Who would use this, and in what kind of situation? How will this change impact performance? As far as I see, all messages (so bodies + headers) are copied, even when a game doesn't use this new feature.
I tried using this patch on a simple file with a bone called Bone.L and it duplicated in place.
Did you manage to test this patch? I can't imagine it would have been usable.
I don't really think it's the way to go. it just adds hell of a lot of extra complexity and weirdeness to the code. I would just disable smart ownership pass for cases when there are any references in the custom data. It wouldn't cancel the original purpose of the path which was to reduce memory footprint when having dense constructive modifiers. Would also be really small and tiny and nice change.
I would actually be quite skeptical about accepting 2x memory usage. For my knowledge ghash could be used for quite heavy meshes, in which case it's really problematic to increase memory consumption. It also feels a bit weird to have hash in the entry itself. It feels after all the changes you did there should be no so much hash/values comparisons and if it's still an issue i guess we need to look into particular hash/comparison functions and optimize them instead. If it's not possible and storing value will really help we can store the hash for those particular ghashes in user key?
@sergey ah, so you were on it too…
Hi, I gave the test build a go and have a few notes :)
those fixes supposed to be in 2.74 testbuild? at least bug is still there
current selection is interfering with new selection. You can not select a bone (it should deselect all others)
This is caused by the take_ownership change in DM_to_mesh. Seems we need to forbid passing ownership and do it all in a copy if DM depends on mesh, but not sure how to check on that yet. Can look later after smashing the current bug i'm looking into.
Looks OK here...am I missing something?
We need to be able to redo the bug. What you describe sounds like a fairly typical Linux installation,
one more thing , please do not consider this sentence....'but do not select 'locrotate' of cube'
Lots of people use Blender on laptops, on Linux without this bug, so its likely this is an error specific to your configuration.
Closed by commit rBb1e48ab4e483.
What happened to this patch?
A result seems to vary according to a form of color depth of the png file so that you say.
This just makes it so Alt+RMB selecting always selects the entire interior loop.
Using UpdateMesh() for changing triangle mesh shapes now, even in unshared case (instead of SetMesh()), because of possible ignoring the RAS_MeshDeformer. Thanks to @panzergame for pointing this out.
Also fixed a crash with bvhTriangleMesh (happened even before replaceMesh()), there the new unshared case was not treated correctly.
Closed by commit rB7f25da650943.
Yes, it happens with factory settings too.
Here's the blender -d output, although I don't see any screams of pain in it: log.txt
To reiterate: we just load the blend, select the texture, tick "Normal", and it crashes. We've investigated with several files and various images, and crash is inconsistent: some files work fine, while others crash.
AFAIK this issue is fixed already, could you test using our latest build from buildbot?