 |
Can you give me a screenshot where I can see the toolbar, I need to know the settings you're working with when trying to reproduce the issue. LMB-resizing the brushes works fine in my SVN build here. As many others are using 1.7.0 and surely would've reported something major like this immediately after release, I suspect there must be a preference or mode setting in your way. |
 |
http://spawnhost.files.wordpress.com/2012/02/darkr.png |
 |
it seems your shift key is stuck on. in status bar its trying to use shift + |
|
|
That's weird, I definitely do not press my shift key while trying to resize brushes, and the shift key works just fine elsewhere. |
 |
I just tried DR 1.5 - 1.7 and also SVN build compiled this morning, and none of them have this issue. |
|
|
I tried to compile the SVN version on my Ubuntu machine, to check if it might work, but the build failed with CXX darkradiant-QuerySidesDialog.o CXX darkradiant-OverlayDialog.o CXX darkradiant-Overlay.o CXX darkradiant-Splash.o ui/overlay/OverlayDialog.cpp: In member function ‘Gtk::Widget& ui::OverlayDialog::createWidgets()’: ui/overlay/OverlayDialog.cpp:89: error: ‘class Gtk::Adjustment’ has no member named ‘property_value’ ui/overlay/OverlayDialog.cpp:101: error: ‘class Gtk::Adjustment’ has no member named ‘property_value’ ui/overlay/OverlayDialog.cpp:113: error: ‘class Gtk::Adjustment’ has no member named ‘property_value’ ui/overlay/OverlayDialog.cpp:125: error: ‘class Gtk::Adjustment’ has no member named ‘property_value’ make[2]: *** [darkradiant-OverlayDialog.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/home/jonas/darkradiant/radiant' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jonas/darkradiant' make: *** [all] Error 2 unfortunately :-/ |
|
|
What Ubuntu version are you using? The Glibmm interface seems to be an old one (I also had to upgrade the Windows build dependencies because of that property). |
|
|
10.04 LTS, Lucid Lynx. I do regularly run the update thingy though, this version of Ubuntu should get official updates until 2013. I'll see if there is a more recent version of Glibmm available and report back. |
|
|
Version: 2.24.2-0ubuntu1 (libglibmm-2.4-1c2a) Version: 1:2.20.3-0ubuntu1 (libgtkmm-2.4-1c2a) Version: 2.20.1-0ubuntu2.1 (libgtk2.0-0) This is what I have. There seems to be no newer versions available, I even did apt-get update / apt-get upgrade and let the update manager run through as well. |
 |
This affects me as well,but I'm on Ubuntu 10.10, DR 1.7.0 from the repo. I tried compiling from SVN and got stuck at the same point. Would be nice to see a working update in the repo. (Then again, maverick's life cycle has just a few weeks left anyway...) |
|
|
Update: On Ubuntu 12.04 Precise Pangolin, with DR 1.7.2 from the PPA, the issue is gone in the 2D viewport, but persists in the 3D view. I can't work like this, I absolutely need brush resize in the 3D view. Going back to Netradiant. - gb |
|
|
Can anybody reproduce the behaviour in 12.04? I'm not running Ubuntu natively, just in a VirtualBox VM where most 3D features are not working anyway. I'm not really motivated to set up a new dual boot system just to debug this. |
|
|
Resizing only works along the normals of *some* faces of the brush, not all of them at the same time. The "working" faces are marked by a blue point in the middle. It is to a certain degree possible to add more faces with ctrl-shift-LMB. This gives them a blue point as well, but: not permanently. The next resize operation seems to randomly delete blue points, i.e. unselect subselected faces. While resizing, the mouse-drag texture function is active. The above is all in 3D-view, resize mode, texture lock on, whole brush selected. It is also possible to resize a brush along the normal of a selected face in translate mode, select faces active. I would have thought this was supposed to only mouse-drag textures. So from my end it looks like a NEW bug. Something like brushes losing subselections in 3D-view or an interference issue with mouse-dragging textures. Or both. Tested on 12.04 64-bit, DR from the PPA, TDM or Doom not installed (yet). |
|
|
After using it for a while (because of the Light editor that netradiant lacks, I now use both alternatingly), the behaviour seems to be pretty erratic. Sometimes I can drag the vertices of a light in the 2D view, sometimes not (and sometimes I'm not even able to select a vertex at all, in vertex mode of course), and often dragging one face of an omni light volume results in another face actually moving. I'm making a full size Doom 3 SP atm. I am considering to volunteer for some Dark Mod mapping in the future, but without a working editor (and all of my workflow is in Linux) that's not going to ever happen. If the maintainer is unmotivated to setup an actual Linux system to debug the editor, then that looks pretty unprofessional to me, by the way. I'm willing to help debug this; my email is j.nicolaisen .AT. gmx.net. |
|
|
>> If the maintainer is unmotivated to setup an actual Linux system to debug the >> editor, then that looks pretty unprofessional to me, by the way. WTF? I mean, are you serious? It might come across as "unprofessional" to you, but I tend to decide myself how to spend my personal spare time, thank you very much. Last time I checked DarkRadiant was open source, so don't hold back solving the issue at hand, instead of insulting the few people left working on the project. |
 |
I'm stuck on 10.04 here, and have the same issue. So if the update to 12.04 or 12.10 doesn't solve it, then it might be better that I don't even attempt to update my system just to solve the issue with DR. Currently I am using the vertex mode to resize brushes - very cumbersome, but at least it works at all. |
|
|
greebo; I already stated that I'm willing to help if you need me to e.g. run any tests to solve this issue. You said you were unmotivated to fix the serious issue on a project you're maintaining (inability to create brushwork in a BSP editor is pretty serious), which came across as dismissive. I mean, why even report bugs then. I don't see an insult in my comment btw. Anyway, might this be a GTK / Linux mouse input related bug? If so, it might help to know that netradiant doesn't exhibit the same problem under the same OS. |
|
|
To be clear: I'm not the Linux maintainer of this project. I've never been, even though I looked into some Linux issues in the past. I've spent more than 6 years working on this project, and I understand that there is a problem in the 3D view. I've been moving away from TDM coding over the past year and as stated above I don't want to invest much time setting up a new native OS on my system to debug it. That was obviously enough to earn the "unprofessional" label from somebody I haven't seen around here before - if you can't see that this behaviour might come across as slightly impolite, then we just have a different understaning of how the user-developer relationship should work in a free time project like this. If you're unsatisfied with the maintenance state of this project, then we're on the same page. I've waited months and years for somebody to take over the torch, but people aren't exactly standing in line for this job. |
|
|
There's yet to be someone to step forward who is as talented as you. People like you are few and far between and I'm ashamed to say that The Dark Mod has chewed you up and spit you out. |
|
|
Has anybody been experiencing this behaviour in Linux lately? If not, I'm going to close this entry due to its age. |
- Anonymous
