[Gtkradiant] GTKRadiant Bug Report

Sun, 14 Dec 2003 08:57:39 -0800

Fuck. It's only a matter of time before this guy discovers Bugzilla.

Ladies, move your children inside.

y

P.S.
Some links for the uneducated:

http://www.cygwin.com/ml/cygwin/2002-07/msg02530.html
http://www.google.com/search?hl=en&lr=&ie=UTF-8&safe=off&q=+site:www.cygwin.com+Paul+Derbyshire
http://web.archive.org/web/19970525014643/www.ncf.carleton.ca/~aa349/
http://groups.google.com/groups?q=Paul+Derbyshire&hl=en&lr=&ie=UTF-8&safe=off&selm=4vop05%24ru8%40bertrand.ccs.carleton.ca&rnum=3
http://web.archive.org/web/19970525082910/http://www.ncf.carleton.ca:80/~aa349/HomePage.Saga.html
http://members.rogers.com/derbyshire2/
http://www.cygwin.com/ml/cygwin/2002-08/msg00481.html
http://groups.google.com/groups?q=Paul+Derbyshire&hl=en&lr=&ie=UTF-8&safe=off&selm=4tavle%24lnq%40bertrand.ccs.carleton.ca&rnum=1

66.185.84.73 wrote:

>This bug report was submitted from 66.185.84.73 using the Bug Report Submission Form on the QERadiant Website at 05:05:35 CST Dec 14, 2003.
>
>---
>
>BUG REPORT
>
>CPU/RAM/Operating System: Athlon 1.53GHz/512M/XP home
>Hard Drive Space: over 10GB
>Video Card/OpenGL Drivers: NVidia GeForce2, recent drivers
>Version of GTKRadiant: 1.3.13
>
>Error:
>Multiple problems as follows:
>* Loading a map saved from 1.2.13 with Brush Primitives produces all manner of weirdness. Textures are misaligned even loading in BP mode; sometimes simple editing actions such as cloning a brush generate a prompt about map conversion. Effectively, it's not possible to use 1.3.x and later to edit BP maps without retexturing everything, which makes mappers maintaining maps made with BP on in older versions unable to upgrade unless they keep multiple installs running.
>
>* T and N don't dismiss texture browser and entity inspector, respectively, when they have focus. This is reportedly fixed in 1.4.x but I haven't tried that branch.
>
>* Undo sometimes undoes something older than your most recent change, instead of the most recent change. Especially common when this was a texture or entity related change, not a geometry one. This problem goes back at least as far as version 1.2.13.
>
>* On one occasion, I attempted to cut a bunch of brushes to the clipboard and Radiant simply died, without any error message or whatnot. Fortunately no data was lost as it'd been saved recently.
>
>* There are occasional crashes on exit after working on larger maps.
>
>* Working on a large map (around 10000 brushes, several thousand u in x-y and over 2000 in z extent, over 5 meg .map file) the Radiant process will frequently top 130megs size, which seems excessive.
>
>* In earlier versions where BP support is nominally working, moving and rotating brushes  often alters texture alignment although the manual states it won't.
>
>* Sometimes a 2d view "goes nuts" during drag operations and flies off to a realm of large coordinates seemingly at random; it can be a pain to move it painstakingly back to your map. Worse, sometimes it simply becomes blank and unusable until Radiant is restarted!
>
>* When drag-editing an axial brush moving one face north in the XY view, and dragging to the top causing the window to scroll, the opposite face of the brush moves. It shouldn't.
>
>* Dragging near window borders causes scrolling that is frequently too fast to control usefully.
>
>* Numerous inconsistencies between Radiant and other Windows applications that cause annoyance include:
>  - Oddball clipboard handling -- selecting text in some circumstances, such as the descriptions in the entity inspector, and then hitting ctrl-C fails to copy it for example.
>   - Inconsistent menu handling -- menus sometimes hang around long after you've clicked elsewhere when normally menus disappear if you click outside them. Menus stay on screen if you open one and minimize Radiant. Alt shortcuts don't work, or don't work consistently, often just beeping when you e.g. hit alt, f, s to save.
>  - Texture browser doesn't correctly remember size and position, not only between sessions but within one session, sometimes randomly reverting to the default location and size. Which, notably, is useless -- too small and covering the menu bar.
>  - Default size of entity inspector window likewise is smaller than ideal. It has to be centered and made a lot bigger to get any use whatsoever out of the aforementioned entity description text field, for instance.
>  - Edit controls sometimes act odd. The Simple Patch Mesh ... one is a particular culprit: if you type a number at the insertion point in the edit field, the editor window (in the background) goes nuts while the foreground dialog doesn't respond. It looks like the keystrokes are incorrectly not being handled by the window with focus.
>
>* Editing patch vertices and brush edges and vertices using 'e' or 'v' and then the mouse in a 2d view no longer functions correctly. At small grid sizes, it's often outright impossible to alter the middle of three collinear and closely-spaced control points -- clicking anywhere near any of them selects the center control point even if one of the end points is closer! This means that e.g. making a 4ux128u rectangular flat mesh to edit into arch trim or suchlike leads to a useless mesh, as the green vertices cannot be moved at all, only the pink ones. Clicking near a green one will select a pink one whether or not the green one is closer to the mouse or even *between the mouse and the pink one*! This worked much better, though still not perfectly, in 1.2.13.
>
>Feature suggestions while we're at it:
>
>* When faces of a single brush are selected the surface inspector should give the brush number. When a single world brush is selected the entity inspector should give the brush number. When a single entity is selected the entity inspector should give the entity number. This would aid in finding brush and entity defs in situations involving hand-hacking of .map files.
>
>* Cubic clipping of distant patches and details (without clipping structural) would be nice as an added view option.
>
>* Wireframing structural material outside cubic clip range would be another useful option.
>
>* Brush cleanup should remove degenerate patches, or whatever circumstance makes q3map2 complain "BOGUS BOGUS".
>
>* Brushes should not randomly disappear when editing them. If the edit would make the brush invalid the edit should be rejected with a beep instead IMO.
>
>* Camera move speed should maybe scale with the gridsize -- currently it's excruciatingly slow for navigating larger maps while still the jumps in position are awkwardly large during detail work. Usually though the grid is set large in the one case and tiny in the other...
>
>* Moving and rotating brushes should preserve texture alignment. How hard can it be, honestly? It's just a little trigonometry to find the correct new texture coordinates. At least moving, axial flipping, and rotating in steps of 90 degrees...
>
>* Some options are missing from the bobtoolz menu although they're available via toolbar. Is this intentional? It may confuse users migrating from 1.2.x.
>
>* The tooltips for the lock axis buttons incorrectly say they scale axis. They are useful for that mind you, though -- click two and click scale to scale along the third.
>
>* A function that finds and caulks all unseen faces would be useful.
>
>* The ability to use a selected brush surface to set the clipper plane for the next time you use the clipper would be nice. The zone around clip points that responds to the mouse should be made larger -- currently it's too easy to "miss" and lose carefully placed clipping points.
>
>* "Clipper uses caulk" seems to operate inconsistently at best. Often the new face(s) are not caulked, though usually they are. Is this intended?
>
>* Forcing the common textures to the top of the texture browser would be useful. Currently if you load e.g. a base_foo directory the common textures get buried further down the browser window. They should probably be treated as a special case.
>
>* CSG subtract could be made more intelligent. If it first made axial cuts around the soon-to-be hole and then made the non-axial cuts, the results would be less messy and serious mappers might actually start using it. :)
>
>* Changing the texture alignment on a patch with texture A applied using shift-arrows while texture B is selected correctly moves texture A across the patch. Changing the same alignment by using e.g. surface inspector -> cap changes the texture to texture B in this case, and usually doesn't align it correctly to boot, as evidenced by the alignment changing if without doing anything else you hit the same surface inspector button again.
>
>* Fitting a texture to an angled, rectangular brush face doesn't always work as you'd expect. The texture's four corners should end up at the face's four corners, however it's angled.
>
>* Lights display poorly in the texture browser, and here's why. Groups of lights with identical and small editor images tend to occur, and these tend to have long names; finding the one you want depends on reading a number near the end of the name typically, but because the browser uses the image width alone and not max (image width, text width) to place the next texture, that number is liable to be overlapping the beginning of the next texture's name, which makes it unreadable, forcing you to try them all one by one and look at the status line. Which, in turn, messily marks textures as "in use" (green border) when they might not really be in use, cluttering up the browser unnecessarily later when you browse with only "in use" textures displayed.
>
>* Radiant startup fails on some machines due to a statically linked call to a function used for handling multiple display monitors that isn't in all versions of Windows. This function call should be dynamically linked and only used if multiple display options are enabled in Preferences, to enable Radiant to run on these machines. The people using these machines should not be forced to either pay Microsoft through the nose for yet another step on the upgrade treadmill or else break the law just to be able to edit Quake 3 maps.
>
>* The new surface inspector is confusing to users of earlier versions.
>
>* Opening documentation from the Help menu unnecessarily creates Internet connections when only local files are being viewed. No other Windows app I use opens a socket to launch something in a browser window. Although if it's an offsite link the browser will open a socket shortly thereafter. This can be made more streamlined, which given how shoddily Windows handles everything to do with the network, will make it faster and quite probably more secure too.
>
>* Radiant should never exit without an error message, save when the user elects to exit; and then it should request confirmation. Currently it sometimes does spontaneously exit, particularly when clipboard operations are attempted, and does not always request confirmation, only when the document's been changed. Since it's slow to start up again this can be a nuisance if you accidentally close Radiant.
>
>* An option in Preferences to disable the splash screen would be nice. Given the aforementioned slow startup I'd like to browse the web or do something else constructive while waiting, but currently my view of my work will be obscured by the splash screen which, of course, has "always on top" set. Please remember that people that use your app don't ONLY use your app, and don't sit there gazing in adoration at the splash screen for upwards of a minute rather than get impatient when it decides to be especially slow loading. I know slow loading is unavoidable with software this complex, but not letting the user multitask is quite avoidable.
>
>* If texture directories x and foo_x both exist, and you load directory x, foo_x also loads which it seems to me it shouldn't.
>
>* A separate "texturelist.txt" to go with the current "shaderlist.txt" would be nice. Currently if you use "shaderlist.txt only" in the editor, and want to see a directory of textures that has no shader file with a matching name, it has to go in shaderlist.txt which makes the compilers complain with warnings that the shader file cannot be found. (The compile works fine, of course, but the warnings are annoying and may even alarm less savvy users.)
>
>Well I think that's it for now. :)
>
>Cause of Error:
>See above.
>
>User Email: derbyshire2@rogers.com
>
>_______________________________________________
>Gtkradiant mailing list
>Gtkradiant@zerowing.idsoftware.com
>http://zerowing.idsoftware.com/mailman/listinfo/gtkradiant
>
>
>  
>