- User Since
- Jan 28 2010, 4:59 PM (476 w, 4 d)
Sat, Mar 2
Jan 1 2019
@Toshe Andonov (ANDhitecture) its not really fixed, it just shifts the functionality from one to the other, with this change we lose the shift+numpad functionality which is not good.
I will try to do a proper fix so both is working but it will take me some time due to my inexperience. i think this should stay open for the time since the issue has not been fixed.
I think i opend pandoras box of keyboard trickery:O
Im reading up on how the keyboard modifiers work and so far it looks like the keys can be identified with the raw input and the pressed state so the unknown key should not be needed. I will try to come up with something but it will take me some time.
Dec 27 2018
it seems that its back, well no wonder since i basically removed the "fix" for that. thanks for pointing that out, i will see if i can find a different solution that works with both scenarios.
@Bastien Montagne (mont29) its done i think:D
i added the diff as a revision, i hope that is how this should be done? otherwise please let me know so i can do it correct in the future.
@Bastien Montagne (mont29) ive seen you active on some older ticket related to this so i thought you would be the correct person to assign, guess i was wrong. sorry for that.
thanks for mentioning the diff creation, its really a lot easier than the patch.
i have made a fix in the code of blender, but since my knowledge is limited i might have not understood some of the magic that was done with the shift buttons.
Dec 26 2018
Dec 16 2018
can this be brought to the 3d view grid as well? the behavior currently is really strange.
Apr 26 2016
seemed for some reason the git submodule foreach git pull --rebase origin master was only doing its job when i got a coder here to ask him what i do wrong... so ticket can be closed, thanks for support.
hmm how can it be that i only get version 2.3.0 when i pull from head? in 2.3.1 everything looks good
hm strange, im using 2.77 2016-04-22 and obj version 2.3.0
Sep 10 2015
is there some timeline when these issues will get worked on? or maybe something we could contribute to get this fixed?
Aug 20 2015
expected behavior from who's perspective? a coder or a user? from "my" user perspective this can be defined as a bug since the expectation is that everything is either shown in the same range.
thanks a lot for adding the functionality! i also dont think this will happen with recent files and probably not possible to reproduce this without messing with very old blender versions.
Aug 13 2015
Jul 31 2015
Jul 28 2015
i think it was manually, i cant remember ever using a script for stencils.
so i looked into the scene to see how this came to be, and it has a long history. Models in the scene have been made in the age of 2.49 and were at some point ported to 2.5+, there was a lot of stuff like multiple uvmaps, drivers, and deformation setups with lattices and such that have been removed over the years and also stencil layers.
my best guess is that we manually assigned a uvmap to a stencil layer which later got removed and somehow created this special case.
Jul 27 2015
@antony kaua (antony): i will see if i can figure out what happened there
@perfection cat: it is the same blend file, i just stripped it down because i can not upload the full scene. but since it also happens when the modifiers are removed i dont think they are relevant to the problem.
Jul 23 2015
this can probably be closed since it was "user error" the frame was set to 0 where its assumed that its a image sequence or something like that setting the frame to 1 or enabling "still frame" and setting still frame to 1 solves this problem.
Jul 22 2015
Jul 21 2015
Jun 29 2015
May 3 2015
Apr 29 2015
@Sergey Sharybin (sergey), can you tell me what i need to do to get the backtrace from IDE?
and yes if i disable the austosave then i can not get it to crash (at least in the ~30-40 times i tried)
Apr 28 2015
was this fix done in a branch? i still get the crash with the latest build but now the crashlog contains no more information except this
Apr 16 2015
Apr 15 2015
i added an other bug report because of thee crash T44404 it seems this is caused by the freestyle addon.
Apr 14 2015
yes it only prints the error. i added a crash when rendering a animation which only seems to happen if the frame step is set to 1. but not sure its related to the addon or if its caused by something else.
Apr 9 2015
Feb 20 2015
i tested in the daily build (win64_cmake_vc2013.zip 104M Fri Feb 20 04:12:42 2015) and the extreem artifacts are gone, but there are still problems with the bleeding
Feb 17 2015
Oct 8 2014
we share the same location of the scripts folder over the network for multiple users and there is where the presets become very powerful. as soon as someone creates a preset everybody on the network has it available in his blender, without the need to update a file or link it from a blend file.
correct me if im wrong but i dont think this is possible with a ID datablock
Sep 23 2014
Sep 11 2014
Jun 4 2014
we are working on it but its hard to tell what is reproducable on your machines when the issue can be reproduced every time on the file we provide but you tell us you can not reproduce it....
i did some further testing and the problem happens when i link an object in with a relative path. with absolute path it works fine but as soon as the path is relative i get these funky paths.
May 20 2014
tried on a different machine with a quadro 2000 and driver 335.23 (also a windows 64 bit system) and have the same problem.
tested an other system with a nvidia 660ti and 332.21 driver (also windows) and there it does not happen. so it looks like this is a quadro driver issue:O
i understand and i will see if i can allocate some more time or give time to my intern to try and reproduce this somehow.
my coworker has the same issue on his system, he also uses a quadro k4000 with the 335.23 driver. im using 332.88 at the moment an also have it.
Edit: upgraded to driver version 335.23 and still have it.
im pretty sure i did not move any files around because im fully aware that this messes up the relative paths. i will have a look today if maybe a coworker did something which could cause such an issue but i was the only one working on these projects so its unlikely...
i replaced a drive recently but the drive letter and the location of the files is the same again so i dont see how this would break the relative paths.
May 19 2014
i dont know how blender refers to such a path, thats why im creating this report.
my savings are exactly in the same file structure as in the files i attached.
if you make such a claim, maybe you can explain to me how i would save a file with a so called "broken" path. because i dont know how to save a file with a path i can not define and doesnt even exist...
May 9 2014
May 8 2014
finally got time to take the scenes apart so i can submit them here. you will find 2 blend files in the packed file with the same folder structure that i use.
Apr 29 2014
Apr 17 2014
hm doesnt make any sense that its intentional different from the other tools. maybe you reconsider youre quick decision because i dont think anyone would expect/want it to work like this.
finally got some time to track down this issue and it was caused by a
import uuid https://docs.python.org/3.3/library/uuid.html seems to be a legit python module so no idea why this happens.
Mar 28 2014
oh sorry, the addon link took me directly here so i assumed it was the right place
Mar 27 2014
maybe this can be reconsidered as design change and opened again?
i just wanted to let you know that we tracked down the issue and it seems it is caused by a in-house addon. i will continue to investigate and report back if i know why the addon causes this.
Jan 27 2014
i would like to see some better solutions for the operator shelf, i think it causes a lot of scrolling because it shares the space with the tool shelf.
Dec 19 2013
ok i confirm that it is working now, for some reason my build was not updated:/ thanks for fixing this problem
hm strange, seems im not fully understanding how to update git yet, will let you know once i figured it out and can test the latest version
im sorry but i still get the same problem with Hash: 6f4515b
- go into uv editor
- create a new image
- save image as tiff
- then save image again with "save image"
no its not, thats a new one which i just created in blender, then saved as tiff and then directly used save image again which resulted in this disguised png
oh and when i want to "save image" with step 4 it seems you just built in a error message so it doesnt work and one is forced to use the "save image as" option instead...
well photoshop gives the same error message as before so i assume its still a png in disguise. and if i change the file name to png it loads without problems.
Dec 18 2013
well i just saved directly again whithout switching to generate first, but i guess that shouldnt change the format either.
i just built the latest version (Hash: 6f4515b) and the issue is not resolved. direct save still saves as default png with the old extension in this case .tif.
Dec 16 2013
for 1) here is a blend file for the first problem, just bake from highres to lowres with uv - islands that are diagonal in the uv space.
Dec 13 2013
yeah it seems that whenever the direct save is used the image gets saved with the default settings (png, rgba 8bit)