Several users requested the recovery as the removal of the two parameters was considered over-simplification for advanced users.
As in the Python Scripting mode, the two parameters are in the "advanced edge detection options" section and disabled by default.
Also the lower limit of Kr derivative epsilon was changed from 0 to -1000 so as to permit a negative value.
This commit reshapes a bit runtime button info getter, by adding a new uiButGetStrInfo() which accepts a variable number of uiStringInfo parameters, and tries to fill them with the requested strings, for the given button (label, tip, context, RNA identifier, keymap, etc.). Currently used mostly by existing ui_tooltip_create(), and new UI_OT_edittranslation_init operator.
It also adds a few getters (to get RNA i18n context, and current language iso code).
Finally, it adds to C operators needed for the py ui_translation addon:
*UI_OT_edittranslation_init, which gathers requested data and launch the py operator.
*UI_OT_reloadtranslation, which forces a full reload of the whole UI translation (including rechecking the directory containing mo files).
For the first operator to work, it also adds a new user preferences path: i18n_branches_directory, to point to the /branch part of a bf-translation checkout.
1. first pass only fast nodes are calculated and only to the active
viewer node
2. second pass all nodes to all outputs
Temp disabled highlights because of random crashes.
* Elbeem exporter code now overrides user settings to No Slip in case the object is animated;
* UI of fluid obstacles now disables slip settings when export animated is enabled;
* Added in this later option's tooltip a mention that it enforces No Slip!
The transform operators in nodes will now use the unselected nodes to generate snapping points. Unlike object snapping, node snapping works for the x/y axes separately and snaps node borders to same borders of unselected nodes. The sensitive area for node borders extends over the whole view2D range, to enable simple alignment of nodes in both x and y direction.
For snap points in the node editor an additional enum value is stored to indicate the type of node border (left/right/top/bottom). This works as a constraint on possible node alignments: only same border types align with each other.
The tool works OK, except it was messing vertices' order of polys, often giving ugly results! Now only using sorted list of vertices indices to find matching polys.
Snapping actually was working already, but grid spacing was set to 1.0, which is basically pixel size in the node editor. Increased this to 1x grid step for fine snapping and 5x grid step for rough snapping.
Grid drawing in node editor now draws 2 levels in slightly different shades to indicate the different snapping modes better.
Node editor also supports the general use_snap tool setting to enable automatic snapping during transform. For now only the incremental snapping is supported, in future could be extended to enable alignment between nodes in a number of ways.
Problem was py code of main texture panel was not doing any check on the pinned id, assuming it managed the textures itself - but this is not the case of the Object datablock...
All work actually done by Sergey, was just missing the Lamp specific case. Checked both in code and with tests, quite sure all cases are now correctly handled!
Near sensors only pick up "actors," but objects with character physics did not have the actor option displayed. By setting the character physics object to actor, it can be picked up by the near sensor. However, it collides with the near sensor, which sounds like bug [#31701]
Issue was caused by some stuff happenign in wm_operator_finish() which uses
to somehow restore changes made by transformation invoke function.
Solved by not calling translation operator directly from duplication operator
(which is in fact really tricky) and use macros instead. This macros calls
duplication operator which simply duplicates strip, and then calls translation
operator.
Patch by Philipp Oeser (lichtwerk), just did style change (better to not define a value twice, so only affecting the three color components, not the alpha, also using the slice syntax makes things much more compact ;) ), thanks!
In contrast to start_frame (which affects on where footage actually
starts to play and also affects on all data associated with a clip
such as motion tracking, reconstruction and so on) this slider only
affects on a way how frame number is mapping to a filename, without
touching any kind of tracking data.
The formula is:
file_name = clip_file_name + frame_offset - (start_frame - 1)
- Display track's reprojection error in dopesheet
- Make sure track is selected when clicking on dopesheet channel
- Attempt to make headers a bit cleaner without long labels which
doesn't actually make sense.
It was a bit confusing to synchronize settings used in pre-calculated
dopesheet channels which was storing in tracking data with settings
used for display which is in space data.
This was initially done by converting one flags to other and checking
if space's settings matches pre-calculated one, but that had several
issues if two different dopesheet are using different settings:
- Channels would be re-calculated on every redraw for each of spaces
- Dopesheet operators could fail due to the could be using channels
calculated for other space.
That was also quite nasty code checking if requested settings matches
pre-calculated one.
