I don't want to leave this task finally :) I transformed spotRectSizeX/Y functions into spotRectSize as demanded by sybren (It changes the bge api, now we have to define spotRectSize in a list with the x and y sizes (spotLamp.spotRectSize = [30., 2.0] > we can't simply do spotLamp.spotRectSize -= 0.1 (I don't know if it's possible to fix it - see KX_light.cpp))). I tried to remove trailing whitespaces. About the subject of size, and rectangle size, I think we can compare the lamp with a camera. Size represents focal length. In the case we use a rectangle spot, spotrectsize represents the resolution of the camera. I can't see how we can use "size" ("angle of the spotlight beam") variable to do what I'm trying to do (anyway, we'd have to use either a ratio variable or two more variables to scale on X and Y axis). Furthermore, from the users point of view, I think it's much more convenient to scale only the bottom rectangle of the cone without modifying the "angle of the spotlight beam". About the names of the variables, I'm opened to any suggestion. Same for the tooltip text. Same for the API.
Is there not the possibility that an installer cannot update registry?
@Sergey Sharybin (sergey):
I think that the correction does not work definitely in new nependency graph.
version 2.75 (sub 2), branch b'master', commit date b'2015-07-01' b'19:48', hash b'b05cf04', b'Release'
Hey @Patrizio Melis (cobe571), afaik this isn't really an issue on blenders side, windows has to be configured to know which program and which version to use.
Open up an attached file.
Start a game.
A property should be displayed.
If you push the arrow key of UP/DOWN, a red object moves.
The property that is displayed when the object comes in contact with a different object changes.
I confirmed this in the following versions.
version 2.75 (sub 1), branch b'master', commit date b'2015-06-30' b'21:41', hash b'cf1bac3', b'Release'
I confirmed that this worked in the following versions definitely.
version 2.74 (sub 0), branch b'master', commit date b'2015-03-31' b'13:39', hash b'000dfc0', b'Release'
Do you have an idea of the goal of this code part ?
Because it interested me I just counted a bit: We have 756 color and 119 other theme options :S For now that should be enough :S
Thanks for reporting, had a quick look into fixing, but we either had to be inconsistent by using theme colors from other editors (currently graph and dopesheet view both use clip editor theme colors and nothing from real graph/dopesheet editors), or we had to add extra theme option(s) for this.
We're really careful at adding new theme options as we already have much to much (several hundred approximately). We've gone a bit too far with the "everything themable" idea.
Closing this since initial bugs were fixed.
No problem, closing this for now :)
I refer to the native OS X fullscreen function, rather than the one available inside Blender.
Works fine for me. However, you seem to use a heavily modified Blender since the shortcuts differ from default. I'm also not sure which green window icon you mean and which fullscreen mode it calls (we've multiple fullscreen modes).
I created a proper patch for this task:
Apologies for not including additional computer information (forgot, e_e)
Seems like I managed to fix the issue with tooltips/node-dragging. It was caused by the approach I was using to auto-register keymaps at the addon start-up.
I have replaced the old modal operator running in background with scene_update_post callback, and the bug disappeared.
GPU:AMD HD 5450
double-precision constant is
represented as single-precision constant because double is not enabled
in many lines.
Same as @josh (joshr)
@Sergey Sharybin (sergey) I agree that this looks a lot like an upstream issue, although I think it's premature to conclude so.
Nevermind. It seems to be a scale issue. Apologies for taking up dev time.
Checked this, but think we should consider this a limitation. It only applies to border rendering and happens because we make partial redraws for performance reasons while using border rendering. Result of this is that we redraw the info box, but not the area widgets.
Patch offers incorrect solution as Ton noted, closing.
Quick review, copied from irc.
Well, that's already something.
At least a start. ;-)
please post a .blend file that shows the issue
The command prompt saves V-Ram Ram and CPU because it does not have to draw the interface and such.
Ok, read the replies and it seems guys have more sophisticated tasks then making minecraft levels (absolute snapping) :)
A revision just fixed this, you can probably close it,
if you have any solution, please let me know as soon as possible before the coming friday, Thanks!
I have been wanting this for 3rd person actor controls for some time :D
sorry for the late reply:
I don't like how our ghost system work, where we need to manually provide a fallback for every single setting we would like to see supported (I ran into that issue with multiview, where in Linux the stereo quadbuffer mode was not supported in some machines, and the fallback was just a broken context ghost).
Overlooked a float4 pointer, didn't matter for functionality, but it's still wrong.
Old dependency graph doesn't really know which actions needs to force particles to re-distribute. It's probably possible to make some cases working, but it;s quite tricky in the old system, also assuming particles are really fragile.
What are the exact steps reproducing the crash with your file? Are you able to reproduce the crash on iMac with this exact file?
Quick experiment test render:
I understand. Please understand tthat I cannot upload my model because it is over 400MB and it's internal company know-how...NVIDIA Titan with 6GB...
There is no problem to render it with Blender 2.7. But with Blender 2.75RC it does not render but crashed when Building BHV is at 94%.
This is also the case for CPU rendering (here at 92%).
From Command-line it seems to work (than you, Aaron). Strange...
Support mathutils Color type.
I am sorry.
But when you ask to me examples to disonsider the problem I clearly expose while you are refusing to expose examples where current behaviour could make sense; I feel it like a lack of respect.
Tested with more than 1 substep : all works.
@ronan ducluzeau (zeauro), there is no need for sarcastic/snarky comments.
I confirm the issue is fixed in daily builds. Thank you all for the replies :)