Qoole is (C) 1997-1998 by Lithium Software. All rights reserved.  Quake is a trademark of id Software and not affiliated with Lithium Software

The Qoole Webring PreviousSite Next Site List of Site in Qoole Webring

  The Qoole Users Wish List will be recieving a "facelift" in the near future. 
Please be patient 

The simple intention of this web page is to provide a medium through which the users of the product Qoole can give feedback to the authors in respects to the bug reporting and features requests.  It is also the intention of this web page to centrally track the wishes of those in the mailing list (ml@qoole.com).  Compiling the wishlist here should alleviate the congestion in the mailing list of festure requests.

While this is the manifest for the creation of this web page - I do not wish to cause harm of any form or difficulty for any persons whether involved with Lithium Software or not.  If any part of this web page is found to be justifiably inappropriate then I will remove it.  Images used here are the property of Lithium Software and are used with permission on this page.  Batteries are not included.

The Qoole Users Wish List is managed by myself, Robert Kennedy (rob@riv.com) - I am usually found in Tripod chat under the alias Scaramanga - and I also read the ml@qoole.com mailing-list mentioned above.  Feel free to contact me with your suggestions and comments.

Use the Qoole Wish List Guestbook. to add your ideas and comments!!!

The following is a summary of the wishlist.  clicking on a wish will link you to the complete text in the section below this one.
 

  * entries above with no link established do not have full descriptions.  I will be adding more full descriptinos as time permits.
 

By far this is the most requested feature for Qoole.  A great number of other level editors include a leak detection system in one form or another.  Leaks are simply openings in the level which lead to an area with no defined limits.  Typically a leak is caused by misaligned brushes leaving a gap which if not covered is the actual leak.

It would be totally excellent if the leak detector could be inline with the editing.  Imeaning a little indicator on the status bar to let you know if there is a leak in the level at any time.  Plugging leaks would be a snap!  Credits to James Matthews but this piece!

Current Workarounds
When compiling a level, the QBSP or QBSP3 program will give a signal that a leak has been detected with the message *** LEAKED ***. There are multiple methods for tracking down a leak.  Please check the tutorial at the rust site on Planetquake (http://www.planetquake.com/rust) for detailed instructions on locating and fixing leaks. Suffice to say the most common method is to use QERadient (another editor (boo-hiss!)).

Integrated Compilers

It would be really cool if Qoole would simply compile the BSP file completely.  Of course this has drawbacks since often people like to use 3rd part compilers.  But the advantage of internal compilers would be that Qoole could setup unique compiler features and also it may be possible to integrate the compilers together and potentially speed up the overall process of creating and lighting a level.  This may also provide a method for avoiding the rounding problems that so frequently haunt level editing in Qoole.. QBSP, QVIS, LIGHT, QBSP3, QVIS3 and QRAD3 all have source code which is publically available.  It's written in C++ and should be portable to any program.

Multitask Compilers to continue Editing in Qoole

Allow continued editing of a level even after the compiler has begun execution.  On a typical Pentium 166MMX it can take as much as 30 minutes to perform an average compile.  If Qoole is frozen for the duration of this compile the user is left with little ability to do further work.  I have developed a batch file that can be run (in conjunction with 4DOS from Jp Software all you need is to copy the following text and place it in a batch file called "COMPILE" and then enter "COMPILE" on the QBSP3 line - see below.
 

 
To use this program create it as COMPILE.BAT in your QOOLE\BIN directory and then setup your Export BSP dialog box like this:

If someone would like to rewrite this for use with other compilers and programs I would be happy to post a copy on this page as an attachment.

Minimize Qoole during Compiles

Since Qoole currently does not execute the compilers under s seperated task why should it remain fully opened and maximized.  It would be best if Qoole would minimize to the taskbar or perhaps remove itself entirely from memory and only operate the compilers from a system tray footprint of itself.  The footprint would again load Qoole once the compilers had finished.  The convienence of this is simply because Qoole is locked in it's current mode and cannot be minimized during compiles.  A nuisence if you want access to the desktop underneath!

There have been some requests for the shapes to become smarter.  A prime example has been for the cylinder to be of any number of sides.  The current limit as of QOOLE 2.50 is any of 3,4,5,6,8,10,12,14 or 16 sides.  While these values may work for smaller dimensions often people have needs that are beyond these limitations.  Similar reqests have been made for other objects.

 
It is well known that some properties of a brush affect one face and some can affect the entire brush volume.  It would be easier and probably faster to reference brush volume properties together in one dialog box and face and texture properties in another dialog box.  the current setup works and does not really cause any problems.  This is entirely a suggestion for better layout and control.  Using the current all-in-one box system is a little unmanageable

Also Jaimi has mentioned that it would be nice to have all texture properties apply to all.  For example a 50% reduction in size ofa texture to be reflected on all the faces of a brush - helpful to creating boxes of various sizes.

This should really be divided into many catagories since brush manipulations are the main focus of the level development process.  Hence I will reference these in subsections

Exact Measurements

It would be a good idea to be able to use a dialog box to control the position and size of an object.  Using the mouse, trying to visually guess at precise position, orientation and size measurements is tedious and difficult work.  Qoole needs a control box for precise measurements.  The box would need to control the rotations (2-dimensions: rotation and tilt) and the position (3-dimensions: dX,dY and dZ) as well as the size (3-dimensions, vX, vY and vZ).  Measures could either be absolute map coordinates or relative to the current location of the object.  Units should be Qoole units, but could also be percentages and/or radians.

Point, Edge, Face Movement

It has been noticed by many people that when editing the position of a point, edge or face of a brush the point will jump around in an unpredictable manner.  This can be caused by these reasons:

1. Trying to edit the brush when a great number of backround brushes are on the screen.  The update of all present brushes causes a slowdown in response, hence the jumpy nature.
2. Snapping is turned on and set to an unexpectedly high value.  The point jumps between these values.
3. When released Qoole interprets the new location as invalid (sometimes incorrectly - depends on Qoole version) and will snap the point back.  (Potentially with an error message).

This jumpyness isn't so much an error or bug as simply a matter of fact. The feature I wish to request is in regards to the third reason given above.  It would be nice to have a fast indicator informing the user while moving the point that QOOLE doesn't agree with the new position.  Something like changing the points colour from yello to orange or flashing yellow/red would be appropriate.

Point Realign to Grid

It seems that "Realign to Grid" attempts to align the centre of the object or some single part of the object to the grid.  It would be more helpful if while editing a point, edge or face to be able to realign the point to the grid.  Adjacent brushes would then be guarenteed contact.

Resizing Objects & Object Groups - When Using The Mouse

Given that objects can be adjusted in size it would be a saving grace to know the total dimensions of the adjustments.  Qoole currently indicates the center of the adjusted object which is not very helpful since it is the dimensions of the object that are being changed not the position.  It would also be nice to be able to edit the size of a group of brushes from these maximum and minimum points.

Another size adjustment would be to include equal dimension change.  Meaning the entire object adjusts in size instead of just one dimension at a time.  Sort of a ZOOM object feature.  Perhaps the face textures of the object could also be zoomed or shrunk equally with the object - thus keeping the object's appearance intact.

New Brush Shape Adjustments

Requests for "Mirror Image" brush manipulation have been quite common.  The simple ability to invert a brush or a set of brushes would make editing complicated symmertic objects much simpler.  The ultimate of this would be creating a Capture The Flag level by simply designing one side and using mirror image to create the entire other side.

Allowing Resizing of Hollow Rooms without Changing the Wall Thickness

I agree with the idea but I do think it may cause some unforseen problems.  Well actually everything can cause problems.  You can even have too much Vitamine C.  Still it would be nice to treat a room as a BOX and just move and resize it as needed without worrying about internal objects becoming badly morphed.  This may require a locking ability for the size of brushes.

---------
Well enough about brushes for one day... 

QOOLE is great - it already supports 3 games from within a continuous environment.  Moving from level editing in QUAKE to QUAKE2 or to HEXEN2.  Users only need to aquaint themselves with new entities and new textures.  In fact it is quite easy to create a single level and port it to multiple games.

There are about 8-10 games that use the Quake engine and BSP formatted levels.  And countless others that use similar engines.  It would certainly be a boon too have QOOLE support the other games.  Admittedly QUAKE and QUAKE2 are the industry leaders - however if it's really not that much additional work to extract from and write for these games - I'm sure some users will appreciate it! 

Since the invention of language mankind has ascended into a state of .... oh nevermind!  It's become apparent to many that QOOLE is a dream and a nightmare depending on where you stand.  If it were possible for other programmers and developers to create add-ons and enhancements to QOOLE much like QUAKE itself then this program would be truly marvelous!  In fact Matt may never have to work another day on QOOLE after a QOOLE Script language is created.  Of course this is a tremendous task.  If it were accomplished, then QOOLE would rank as the best Quake Engine Editor forever!

QOOLE-C would be something like VBA or QuakeC or any other application scripting language.  3rd party developers could create toolkits and additional funky features for QOOLE.  If the Script language were simple enough then even the most basic of users could try their hand at creating miniscripts to handle repetitive tasks.  Some simplistic tasks made complex by the current menu and toolbar options could perhaps be solved quickly and simply by a script program.

With a properly developed scripting language it is even possible for the 3rd party developers to create internal compilers and leak detectors, making this "Features Wishlist" obsolete!  (that would be really nice!) 

Being able to select and group faces in the 3D view window would be much like the grouping of brushes.  The user could change the properties
of many faces at once.  For instance, the user could define a group of faces that will all use the same ceiling texture, or will all have the same
surface properties.  Face groups should have the ability to scope up and down like the brush groups allow, so the user can make vast changes or small
adjustments.  Manual and auto-grouping should be supported.  If the user wishes, QOOLE should be able to auto-group adjacent faces that exist on the
same plane. 

CSG subtraction is a handy tool, but sometimes it can leave behind a group of horribly fragmented brushes.  Putting together a complex set of grouped brushes manually can also be messy sometimes.  The user should be able to merge brushes together if doing so will create a convex brush.  The user should also be able to tell QOOLE to systematically merge all possible brushes in a selected group.  How differing texture and brush properties are handled while merging should be options configurable by the user. 

All 3D transformations (rotation, scaling, mirroring, translation, shearing
and more?) can be representated with a 4x4 matrix, looking something like
this:
[r11, r12, r13, t1]
[r21, r22, r23, t2]
[r31, r32, r33, t3]
[  0,   0,   0,  1]

What I'd like the function to do is making a client window here you can
enter the data for the matrix. (preferably it would open up with a
[1,0,0,0]
[0,1,0,0]
[0,0,1,0]
[0,0,0,1]
matrix, just to save us the hassle of writeing these values there. This
matrix doesn't do anything, so it's good as default)

Another aspect of this function would be the ability to predefine some of
the matrices and maybe add hotkeys to them. Like flip around X:
[-1, 0, 0, 0]
[ 0, 1, 0, 0]
[ 0, 0, 1, 0]
[ 0, 0, 0, 1]
 
Hmm.. maybe someone wonders why I want to have a 4x4 matrix, instead for
3x3? The advantage with 4x4 is that we can have translations (movement)
also. The fields t1, t2 and t3 in one of the matrices above represents the
movement in respectively x, y and z axis. 

Automatic Brush Naming

Allow each brush, group and entity, within a map, to be named automatically and then be able to be renamed by the user if he so chooses. For example a user place down his first brush which then becomes “Brush_1”. He then places an additional brush on the map which becomes “Brush_2”. Next he selects Brush_1 and chooses to hollow it. Brush_1 has now actually been removed from the map and has been replaced by Group_1 which contains “Brush_3”, “Brush_4”, “Brush_5”, etc… The user then renames Group_1 to “Starting Room”. Next the user applies a Func_Door and the Brush is automaticly renamed “Door_1” and given a targetname of Door_1 by default. With this feature added it would be possible to also add the ability to select a brush or group by name as well as by
highlighting it on the map.

Project Management Window

Additionally, this would allow a project window to be created. This would simply be a window with a data tree within it showing all of the brushes, entities, and groups within it. This would allow many functions to be added to the program. First, the user would be able to perform all of the functions, presently included in version 2.5’s brush pop-up menu, by simply right clicking on the selected object on within the project manager. Second, grouping objects would be greatly simplified. The user would be able to use drag and drop  functions to add and remove objects from a group as well as select individual objects within a group without disturbing any other contents within the group. Another feature this would be able to add, would be the ability to hide and show objects, eliminating the often times frustrating task of editing single object within a large map.

Master Objects

The ability to create and use prefabs is a great benefit to level designers.However, when making a prefab, it can easily become a monotonous task, anytime he decides to modify the prefab, to find all instances of a prefab and replace them with the latest, up to date version of it. As a solution to this, I suggest the creation of “Master Objects”. A master object would be similar to a prefab, however, it would allow the user to modify the master object and at the same time the instances of the master object within the map would be modified as well. To do this, the master object would be saved to either a separate file or within the map file and then each instance of it would simply mark its location with  x, y, z coordinates, to represent its center and its axis rotation, to represent its facing. If the master object was saved to a separate file there would be multiple ways of handling the updating of it within a map. It could be loaded at the same time a map was being loaded and since the map file would not include the actual object, only its location it would immediately refresh these objects within the programs main display. Another option would be to place a function, within the program, that would be accessible to the user to refresh the main screen of the program. It would also be possible to have the program monitor each master object file that the user
includes within his map. However, the last of these would take CPU time and would slow the performance of the rest of the program.

Expanded list of Entity Properties

The Entity Properties feature of Qoole2.xx is an excellent feature. I would like to suggest that it be expanded to include all of the properties for every object. For example, a user clicks on a simple cubed brush; within the Object Properties window, he would see the objects name, height, width, depth, x, y and z coordinates. In addition, he would still have the ability to apply an entity to the brush and then be able to see each entity properties or add a new property much like the present version.

Room Centre Referencing Point

An additional feature, I would like to suggest adding is giving each group a center point. By adding this to each group one would be able to switch the grid’s numbering to be centered within each selected room and cut down on much of the math that goes into the creation of a map. In addition, if any form of scripting were implemented into the program, creating a room, using a script, would become a much easier task. The user would be able to tell the program to create an object, and place it a certain distance from the room’s center without having to do any math to figure where that point would be on the worldspawn map. It would also allow objects to be placed into the center of a room quickly and remove much of the time used to move an object to the correct position.

Yet another feature that would be nice to have is an enhanced texture manager. While the bookmark feature within version 2.xx is nice it is a bit limited. What I suggest is allow the texture browser to split the textures into groups that are accessible through a combo box at the top of it. With it the user would be able to see the textures within each group (e1u1, e1u2, etc..) separately without having to load and unload each group. In addition the user would be able to create groups for creating texture themes for use while designing a level. The easiest way I can think of doing this, within the user interface, would be to have an option within the menu system that would allow the user to create a group. Next, he could add textures to the new group by simply right clicking on a texture within the master list and selecting “Add to Group…”

(Another concept for the manager would be simply to use something similar to Windows Explorer - where each icon is a texture and can be sorted into multiple directories and subdirectories.  I suggest this only to reduce the learning curve.  Lithium has always seemed intent to keep Qoole easy to get start with! - Rob.)

To alter the terain I must move 4 vertices and align them again. It would be great to lock these 4 vertices together so if one is moved,  all are moved If a concave brush is made the operation fails.  Using this it would be very quick to make sweeping changes to a map area without a lot of fiddling. A room can be distorted with one mouse drag of one vertex or edge because atatched vertices are locked to the one you have moved.

This is akin to grouping vertices which you can then scope down  to and move independantly (The vertices are locked relative to each other in scoped up operations)

 

I have no idea whether this page will end up being helpful to anyone.  Basically I have the feeling I'll be rewriting this page many time to make the ceoncepts more robust and more precise.  Perhaps this page will also expand to include other quake engine level editing software.  I do tend to run on about things that excite me.  And when you cross my two favorite pastimes - Architecture and Action/Adventure Computer Games - You get QOOLE and all it's rivals.

The reason this page is dedicated to making QOOLE better is because I feel it's already well ahead of the competition.  It's easy to use and is constantly being worked upon.  With the release of version 2.50 at the end of May 1998 QOOLE has truly become a stable platform for developing QUAKE, QUAKE2 and HEXEN2 Levels.

All the best,
Rob.

Written by Robert Kennedy
First Created 01-Jun-1998
Last Updated 01-Oct-1998