New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: RMBClick while in VEF modes #120
Comments
I cannot reproduce this. When I do it, everything is deselected and the editor leaves VEF mode. If I right drag while in VEF mode, the editor leaves VEF mode and I can create a brush as usual. |
This is the exact steps:
Results in something like this. You can see the 8x8x8 "brush" that is left over. You can select all normal brushes and perform operations on them as normal (including going into VEF modes). |
Alright, I can reproduce this on Windows, too. |
This should be fixed in TrenchBroom_Win32_20120812_1311, please confirm. |
Edit: I spoke too soon, sometimes when creating a brush, the program will just quit silently. Also, repeating the steps in this post results in the program quitting with no errors. |
Strange - I had that happen last week and I thought I fixed it. Unfortunately it's very hard to debug because it only happens in the Release build on Windows. I'll work on that now. |
It seems to happen when, during the RMBClick, you drag the mouse enough that the single unit brush would become more than 1 unit. |
Yeah I know. It is somehow related to the rendering of the size helper graphic while right dragging. |
Could you please try TrenchBroom_Win32_20120812_1929 and report back? That version definitely does not crash for me when creating a brush by right-dragging. The Vertex-Mode problem you described earlier doesn't exist either. |
I believe this thread's specific bug is fixed. If you carefully Rightclick in VEF mode, a new brush is created and VEF mode is disabled. It was just the RMBDrag crash causing the initial bug (which is still happening in build 1929). |
I don't understand it. It's working fine for me now. I'll see if I can reproduce this. |
Feel free to send me some executables to test changes. |
I'm trying to reproduce it like this:
Does it crash when you do that? |
Also, which version of Windows are you using? |
Windows 7 Professional, SP1. I usually install all critical updates and most of the optional ones if they seem relevant. reply to this |
Hmm, I have tested it on both Windows 7 64 bit and Windows XP 32 bit. I'm currently out of ideas... I had the bug a couple of days ago and tracked it down to a specific location, and then it disappeared. Something fishy is going on... I'll try it on another machine and see if I can reproduce it there. |
Please try TrenchBroom_Win32_20120812_2313. |
Okay, I have an idea how to track this down, but this will be quite annoying for you. If you could try each version in dropbox in reverse order and tell which is the latest version that does not exhibit this error, this might help me find the problem... |
The last version that worked correctly for me was TrenchBroom_Win32_20120804_1047.zip |
Aha, that should help me find it. I'll compare the versions tomorrow. |
Of all the versions (1831, 2135, 1213) uploaded today, TrenchBroom_Win32_20120809_1831 no longer crashes when creating brushes and also has the VEF mode fix. |
What about the later versions? They crash again? |
Later versions?
on the 13th. (they have newer data created time stamps) |
It must have been dropbox, because I will never reuse a build number. |
Please try TrenchBroom_Win32_20120814_2111. |
TrenchBroom_Win32_20120814_2111: Sorry man, still there. :( |
I think I missed something. Did you upload earlier versions on dropbox yesterday? Because in this post I mentioned that TrenchBroom_Win32_20120804_1047was the latest version that stopped working. But with the 3 files that were uploaded yesterday, this is now how it looks:
I'm not sure if I got mixed up with all the versions (It would be nice if the build number always incremented) or if dropbox didn't upload some files until later. |
It's possible that dropbox got mixed up on the latest version. The build number is always different: TrenchBroom_Win32_YYYYMMDD_HHmm.zip where YYYY = year, MM = month, DD = day of month, HH = hour in 24-hour format, mm = minutes. |
Hi, I have added lots of debugging output to TrenchBroom_Win32_20120815_1357. Please try it and send me the log file. If you have skype or some other instant messenger, we could debug this much more quickly though. |
Strange, TrenchBroom_Win32_20120815_1357 no longer crashes when making brushes. Log |
Jesus, I bet the next build will crash again.
I would prefer skype for instant messenging, too. |
I have found a bug in the part of the code which I think may be responsible for the crash. It's in the code that generates vector data for the strings to be rendered on screen. I have fixed that bug and uploaded a new version: TrenchBroom_Win32_20120815_2010. If the bug happens again, please post the log file here so that we can start pinpointing it. |
I can confirm TrenchBroom_Win32_20120815_2010 does not crash, at least! :) |
So I take it that this one is gone now? hoping |
If you are referring to the brush creation crash, then yes, it seems to be fixed. I tested a bit yesterday and made quite a few brushes without any problems. :) |
Good. I'll close this, but if it happens again, be sure to post the log file here. |
If you right-click while in one of the VEF manip modes a new brush seems to be created at the click point 1 unit in dimensions, however this new brush cannot be interacted with at all.
Further, it appears to be selected but clicking on other brushes does not deselect it.
RMBClicking again will clear this 'ghost' brush.
The text was updated successfully, but these errors were encountered: