From: Bryce Barry Baril To: ml@qoole.com In-Reply-To: Reply-To: ml@qoole.com Date: Sat, 28 Feb 1998 23:46:02 -0800 (PST) Subject: Re: Some things I'd like to see improved about Qoole (long) Simple solution to multiple window openings: when qvis opens, click on the MSdos window properties button and select the "close on exit" choice. then it will close the windows automatically for you and you don't have to close them. Bryce "vaticide" Baril On Sat, 28 Feb 1998, Bill Gammel wrote: Yes, I know that a new version is supposed to be out this weekend and maybe some of this will be addressed. But, I could remain silent no longer. In lieu of a developer's page or having a support e-mail to send this to, I'm posting it here in hopes the programmers will see this and at least hear my thoughts. Some background. I'm a registered Qoole user and have done a Q2 map with it. I use winqoole and glqoole interchangably on WNT and W95. I compile with the Q2utils I got from the Qoole web page. Caveat, I say below a number of opinions on how I expected qoole to behave. I include this here realizing that some could say, "well, it just does it this way, learn it and move on". While this is true, I think all programmers (I'm one) like to have feedback on what users thought was intuitive. If others don't agree, fair enough, but at least one person thought this way and its input for future consideration. OK...here goes. 1. Improve all aspects of moving/resizing/rotating brushes. 1A) Mouse movement - While not so bad on W95, its almost unusable on WNT. I move the mouse a tiny fraction and it either shifts the line not at all or too much. Also, there seems lag in that if I let go too soon, there is more movement after I think I've got the line where I want. 1B) The "handles" for moving edges/vertices/etc. You would think that the more you're zoomed in on a brush, the easier it would be to "grab" one. Not true. Sometimes I have to zoom out, just so I can grab a handle. I find myself anxiously looking at the other "handles" to see if they disappear so I can tell if I've grabbed it. If not, then I have to make sure I move the mouse so as not to accidentally select another brush. I zoom in on brushes to adjust things for better accuracy (or at least that's what I want to do), but it doesn't work that way in qoole. 1C) make snap work correctly. Ok, what do I mean by correctly. Minimum grid size is 4 units. If I've got snap set to 1, then I should only be able to set an edge (whatever) in 1 of 5 places in that grid: on either line, in the middle, and between the half and each grid line. That's it. Not so in Qoole. I won't say its infinite, but I can get an edge fractionally off a grid line and spend the next several minutes trying to get it back on grid (don't even talk to me about the realign to grid function). In conjunction with the problems in 1A above, I end up moving the mouse in large increments away from my target in hopes that I will realign with the grid and then can reset the snap to something bigger. Why do I have a snap of 1, you ask? Because I'm doing some ramps and non orthogonal brushes. Also, it seems that sometimes cloning (ctl move) seems to put the cloned brush off the grid line. Finally, I would expect that if the line was just a screen pixel off the line, it would still "map" to that line. I found time after time, that I would be a unit off in the compiled map in these situations. Most cases, I ended up deleting the brush and starting again. 1D) Rotation - I assumed originally that if a brush was selected and I was in rotate mode and I held the mouse down and moved the mouse in a circular direction, it would rotate the shape in that direction. Again, not so. I finally realized that you MUST start the rotation with the cursor inside the brush and then move the mouse in a horizontal direction which started the rotation. Unintuitive even on direction of the rotation vs. the direction of the mouse move. Also, I would expect the snap to control how much rotation there was. It didn't SEEM to. I didn't get anywhere near as much accuracy of the rotation as I wanted. In the end, I started moving edges/vertices by hand and using that as a crude rotation (unless its orthogonal). 1E) Resizing - I used this mode at first to resize objects till I realized that it increased the width of the walls in a hollowed out cube. In otherwords, the resize resizes everything. Now, I can see how you could say, well yes, you're really just applying a "zoom" to the object, of course it works this way. I can not imagine ever wanting this to work this way except for basic brush shapes and even then, I usually want to expand the the brush in a sinlge direction. Which is what the edge (plane?) mode is for. Yes, I use this ALL the time. Its my savior. But guess what, it doesn't work on anything but basic brush shapes. I know, I know, how would you make it work rationally. Which objects in the group should move where? All I know is, I spend a LOT of time, scoping down so I can move, edge move, the components of a group (even something as simple as a hollowed out box). It seems like there should be something that would help here. 1F) Keyboard shortcuts - If I missed this one, then nevermind. I'd like a way to move the cursor a single unit (based on snap) from the keyboard. When aligning to grids or just moving brushes slightly, I'd love to be able to select my vertex/edge/plane and then hit the up arrow (for example) to move it a single snap unit up (or whatever direction). You don't have to worry about micro controlling your mouse all the time. The mouse is the obvious control for most movement, but there are times when you have to shift things around to precise locations. 1G) Panel to show/enter coords for object/brush. I'd love to be able to pop up a panel that I can either scroll, page through the coords of the object (they exist in the map output, why not export it to the GUI?). Maybe it would be easier in some situations to manipulate the numeric values of the brush, instead of with the mouse. 1H) Put up rulers (or make it configurable). QERadiant has them, and I didn't realize how much they would help until I looked at QER. I found myself counting out major grids to find out where to move/size something. A nice ruler would help a lot. 1I) Realign to grid - I have no idea what this is supposed to do. I thought that it would take the edge/vertex/plane that was selected (by handles) and align them to the nearest grids. Every time I used it it moved everything, edges and vertexes away from any grid lines. Thank you UNDO. OK...enough about moving...let's move on. 2. Compiling - I like the ability to select the path/utility for each stage and the option to wait between stages. However, in W95, a command shell is spawned for each stage which must be exited before the next stage can begin. At one point a full compile of my map took 2.5 hours. I would like to just kick it off before I go to bed and look at the results in the morning. However, that meant I had to wait for the vis to finish (so I could begin the rad). Not good. Now, I don't know if this is a W95 problem, or if even there is anything you can do. But, I'd like the stages of the compile to be continuous unless I ask for a pause (i.e., make it work like it does in WNT). 3. Fix the memory leaks! I'm assuming on W95, there are leaks there as well (I just can't measure it as easily), but on WNT, I can see a memory loss at every compile. Exiting Qoole and restarting helps, but even then there's a "permanent" (till next boot) loss of usuable memory. A co-worker of mine said he just coulnd't use qoole, cause of the leak problem and his limited resources. 4. Selecting another object for edge/vertex/plane manipulation - You make it so you can't select an object that is grouped for these manipulations. Unfortunately, many of us put a hollow cube to encase our maps (preventing leaks) or in general group outside structures in to a single object through which we "look" at the rest of the objects. As a result, I find myself shifting to move mode so I can cycle into the object I want (from one of the e/v/p modes) only to switch back to the e/v/p mode of the object once I've got it selected. Perhaps you could make it so we could select objects in e/v/p mode even though we can't manipulate them (because they're grouped). That way we could cycle through them without having to change modes. Or, perhaps you could ignore objects for selection purposes that aren't permitted to be selected in that mode. There might be a little confusion as someone wanted to selected a brush and couldn't (because he was in the wrong mode), but the power would make up for it. Its a joy to scope down on a group just so I can e/v/p between the brushes without changing modes. Its just not feasable to constantly group and ungroup just so you can select modes easier. 5. Map bugs: I've run across a couple of instances where the map that I displayed did not generate the map that I tested. Once I got into a state where I acutally wrote out the map as a map (instead of compiling to BSP) and then read the map back in. The map I read back in was different from the one written out. I dont' know if internal states were messed up or what. Fortunately, when I reloaded the qle after that, it matched what the map had said (I saved my grouping info that way). I also had a situation where I placed objects (over and over) on a spot only to find them compiled in some different spot. For a while, I actually had a laser offset from where it was supposed to be so it would compile correctly. Later (for no reason i could tell), it finally fixed itself (and I had to change it back). 6. Do something about the modes? - Frankly, they're a pain. I know they help clearly define the actions you take, but I would love to have the ability to use other mouse buttons or shift/ctl clicks to effect a different mode. I spend a lot of time switching modes and I would think it would be a savings if I could just shift click to select in plane mode for example. or shift right click to rotate, or make it configuratble which combination of keys and clicking effected which mode. Some of us have 3 (actually 4 button mice). Let us use those buttons (QER does). 7. Tutorials - I'd like to see some for Q2. The one's at the rust web page are great, but I watched all of your tutorials off the CD and had to remember, that "oh, that feature is Q1 only", or how do I do this Q2 thing? While I'm sure there's still a lot of Q1 work going on, I think that Qoole is getting a lot of use right now because you've managed to get Q2 functionality working (people are giving up on WC 1.6). 8. In your grouping, use the info_group feature of Q2. That way, the grouping information ends up in the map. If someone else builds a map in another editor with grouping info, you could then read this in and retain the grouping. This mail is already getting long, so I won't go into all the things I think could imporve Qoole. Although many of them are showing up in QERadiant (like info boxes on level statistics, leak detection, finding brushes by map number (to match up with compiler errors), expanded explanations of key/value pairs, clipping, labeling of objects, showing dependancies between triggered objects, etc.). Maybe I'll save it for another mail. Now, before I end this and because I don't want you to think I hate qoole, I want to list some things I think you did right. I still like this better than any of the other editors, I just want to see some things improved. - Love the grouping/drill into a group to isolate specific areas - face/edge/vertex movement - texture panel that allows me to shift a texture and see results on 3d view (in texture mode) - shifting textures subject to snap - easy key/value pair addition - panel to compile allows specification of utility and easy entry of parameters - snap increments on tool bar - up-down/left-right/all movement restrictions on toolbar - support for prefabs - much more. Enough for now. Thank you for your time. Bill Gammel "The above is my opinion only. If it is deserving of flaming, then send away. I'm right here: bgammel@megsinet.net"