-Compilation instructions\r
-------------------------\r
-\r
-See latest information for compiling and installation\r
-on the developer pages:\r
-\r
-http://www.qeradiant.com/wikifaq/index.php?GtkRadiant%20Hacker\r
+Compilation instructions
+------------------------
+
+See latest information for compiling and installation
+on the developer pages:
+
+http://www.qeradiant.com/wikifaq/index.php?GtkRadiant%20Hacker
-; bkgrnd2d.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "BKGRND2D"\r
-DESCRIPTION 'BKGRND2D Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; bkgrnd2d.def : Declares the module parameters for the DLL.
+
+LIBRARY "BKGRND2D"
+DESCRIPTION 'BKGRND2D Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-November 25 2003\r
-bkgrnd2d v 0.25 beta for radiant 1.3.13\r
-by SCDS_reyalP (email hellsownpuppy@yahoo.com)\r
-\r
-WARNING:\r
-This is an beta release. It is provided with absolutely NO WARRANTY.\r
-If it turns your data to mush and melts your CPU, don't blame me.\r
-\r
-Overview:\r
-This little plugin allows you to display an image in the the gtkradiant 2d\r
-windows. This is useful for layout sketches, maps made from\r
-existing plans, building geometry based on photgraphs, viewing terrain\r
-alphamaps in relation to your terrain, and so on.\r
-\r
-Installation:\r
-extract the .dll and bitmaps into your gtkradiant/plugins directory, and\r
-restart radiant. Be sure to use directory names, to ensure the bitmaps go\r
-in your plugins/bitmaps directory.\r
-\r
-Uninstallation:\r
-Close radiant, delete the bkgrnd2d.dll from the plugins directory, and \r
-delete the bkgrnd2*.bmp files from the plugins/bitmaps directory.\r
-\r
-User Interface:\r
-- The plugin adds 4 buttons to the radiant plugin toolbar. The first 3\r
- toggle the display of a background image in the specified view. The fourth\r
- brings up a configuration dialog. The configuration dialog can also be\r
- opened from the plugins menu.\r
-\r
-- If an image has not been loaded, or it's display size and location have\r
- not been set, pushing one of the toggle buttons will bring up the dialog\r
- with the corresponding page selected.\r
-\r
-- The configuration dialog is non-modal, meaning that you can leave it open\r
- while you work in radiant. If it gets lost behind another window, clicking\r
- on the configuration button will bring it to the forground.\r
-\r
-Usage:\r
-- bring up the configuration dialog.\r
-\r
-- Choose the "Browse..." button. This will prompt you for an image file.\r
- The file *MUST* be inside your basegame directory (baseq3, main, etmain or\r
- whatever your chosen game uses). The image must be in a format supported by\r
- the game in use. For q3 based games this is truecolor .jpg, .tga and\r
- sometimes .png. For q2 this is .wal\r
-\r
-- Use one of the following methods to set the size (in game units) that the\r
- file is displayed. \r
- 1) select 1 or more brushes or entities and choose "from selection"\r
- This will use the total dimensions off all selected brushes and entities\r
- to size the image. \r
- 2) For the X/Y view only, choose 'Size to min/max keys' This will look in\r
- the worldspawn entity for the keys mapcoordsmins and mapcoordsmaxs (also\r
- used for ET tracemap generation and command map sizing) and use those\r
- dimensions to size the image.\r
-\r
-- Use the toggle buttons to show or hide the loaded images. The buttons will\r
- press or unpress whenever you click them, but an image will only be\r
- displayed once you have successfully loaded a file and set its size/postion.\r
-\r
-- Set the opacity of the image using the slider in the configuration dialog.\r
- \r
-- If any of these commands do not produce the expected results, there may be\r
- an information in the radiant console. Please include this when reporting\r
- bugs.\r
-\r
-\r
-Notes and limitations:\r
-- This plugin is compiled for GtkRadiant 1.3.13. It may or may not work with\r
- later versions. It will *NOT* work with version 1.3.12 and below. If you\r
- build from source (see below) you can build it for other versions.\r
-\r
-- As mentioned above, the image *MUST* be inside your basegame directory, or \r
- another directory in which radiant looks for game files.\r
-\r
-- To prevent the image from being distorted, you should size it to the\r
- original images aspect ratio. mapcoordsmaxs/mapcoordsmins and command maps\r
- should always be square.\r
-\r
-- If you want a specific pixel to world unit relationship, you must arrange\r
- that yourself.\r
-\r
-- On load, the image is converted to a texture whose dimensions are powers\r
- of 2. If the original image dimensions are not powers of 2, some detail will\r
- be lost due to resampling. If it is too large to fit on a single texture,\r
- resolution is reduced.\r
-\r
-- radiants gamma and mipmap options are applied to the image.\r
-\r
-- If the image has an alpha channel, it will be included in the blending\r
- process. 0 is transparent, 255 is opaque. .tga images are recommended if\r
- you want to have an alpha channel.\r
-\r
-- since the plugin will only use true color files, you cannot use a terrain\r
- indexmap (aka alphamap) or heightmap directly. You can of course, save a\r
- copy of your indexmap in a 32 bit format.\r
-\r
-- There is no unload command.\r
-\r
-- You put the plugin in a game specific plugin directory, rather than the\r
- radiant plugin directory. \r
-\r
-- You cannot set the image size with sub-unit precision.\r
-\r
-- Only win32 binaries are included. The source is available from:\r
- http://www.cyberonic.net/~gdevault/rfm/mapstuff/bkgrnd2d-b0.25-src.zip\r
- If you want to use it on another platform you will need a buildable gtkradiant\r
- source tree to build it. For any non-windows platform you will also have to\r
- figure out the compile options. I suggest ripping those off from some other\r
- plugin.\r
-\r
-TODO:\r
-- make file selection paterns match supported filetypes\r
-- large images without downsampling\r
-- bitmap and pcx support for indexmaps\r
-- automatic size from indexmapped entities\r
-- render under the grid instead of blending\r
-- mac/*nix support\r
-- remember/save/restore settings\r
-- texture options independant of radiant prefs\r
-- clean up icky code\r
-\r
-Changes from 0.1\r
-- all 2d views supported\r
-- new ui\r
-- file selection patterns, default directory improved\r
-\r
-Changes from 0.2\r
-- tooltips in dialog\r
-- various code cleanup\r
-\r
+November 25 2003
+bkgrnd2d v 0.25 beta for radiant 1.3.13
+by SCDS_reyalP (email hellsownpuppy@yahoo.com)
+
+WARNING:
+This is an beta release. It is provided with absolutely NO WARRANTY.
+If it turns your data to mush and melts your CPU, don't blame me.
+
+Overview:
+This little plugin allows you to display an image in the the gtkradiant 2d
+windows. This is useful for layout sketches, maps made from
+existing plans, building geometry based on photgraphs, viewing terrain
+alphamaps in relation to your terrain, and so on.
+
+Installation:
+extract the .dll and bitmaps into your gtkradiant/plugins directory, and
+restart radiant. Be sure to use directory names, to ensure the bitmaps go
+in your plugins/bitmaps directory.
+
+Uninstallation:
+Close radiant, delete the bkgrnd2d.dll from the plugins directory, and
+delete the bkgrnd2*.bmp files from the plugins/bitmaps directory.
+
+User Interface:
+- The plugin adds 4 buttons to the radiant plugin toolbar. The first 3
+ toggle the display of a background image in the specified view. The fourth
+ brings up a configuration dialog. The configuration dialog can also be
+ opened from the plugins menu.
+
+- If an image has not been loaded, or it's display size and location have
+ not been set, pushing one of the toggle buttons will bring up the dialog
+ with the corresponding page selected.
+
+- The configuration dialog is non-modal, meaning that you can leave it open
+ while you work in radiant. If it gets lost behind another window, clicking
+ on the configuration button will bring it to the forground.
+
+Usage:
+- bring up the configuration dialog.
+
+- Choose the "Browse..." button. This will prompt you for an image file.
+ The file *MUST* be inside your basegame directory (baseq3, main, etmain or
+ whatever your chosen game uses). The image must be in a format supported by
+ the game in use. For q3 based games this is truecolor .jpg, .tga and
+ sometimes .png. For q2 this is .wal
+
+- Use one of the following methods to set the size (in game units) that the
+ file is displayed.
+ 1) select 1 or more brushes or entities and choose "from selection"
+ This will use the total dimensions off all selected brushes and entities
+ to size the image.
+ 2) For the X/Y view only, choose 'Size to min/max keys' This will look in
+ the worldspawn entity for the keys mapcoordsmins and mapcoordsmaxs (also
+ used for ET tracemap generation and command map sizing) and use those
+ dimensions to size the image.
+
+- Use the toggle buttons to show or hide the loaded images. The buttons will
+ press or unpress whenever you click them, but an image will only be
+ displayed once you have successfully loaded a file and set its size/postion.
+
+- Set the opacity of the image using the slider in the configuration dialog.
+
+- If any of these commands do not produce the expected results, there may be
+ an information in the radiant console. Please include this when reporting
+ bugs.
+
+
+Notes and limitations:
+- This plugin is compiled for GtkRadiant 1.3.13. It may or may not work with
+ later versions. It will *NOT* work with version 1.3.12 and below. If you
+ build from source (see below) you can build it for other versions.
+
+- As mentioned above, the image *MUST* be inside your basegame directory, or
+ another directory in which radiant looks for game files.
+
+- To prevent the image from being distorted, you should size it to the
+ original images aspect ratio. mapcoordsmaxs/mapcoordsmins and command maps
+ should always be square.
+
+- If you want a specific pixel to world unit relationship, you must arrange
+ that yourself.
+
+- On load, the image is converted to a texture whose dimensions are powers
+ of 2. If the original image dimensions are not powers of 2, some detail will
+ be lost due to resampling. If it is too large to fit on a single texture,
+ resolution is reduced.
+
+- radiants gamma and mipmap options are applied to the image.
+
+- If the image has an alpha channel, it will be included in the blending
+ process. 0 is transparent, 255 is opaque. .tga images are recommended if
+ you want to have an alpha channel.
+
+- since the plugin will only use true color files, you cannot use a terrain
+ indexmap (aka alphamap) or heightmap directly. You can of course, save a
+ copy of your indexmap in a 32 bit format.
+
+- There is no unload command.
+
+- You put the plugin in a game specific plugin directory, rather than the
+ radiant plugin directory.
+
+- You cannot set the image size with sub-unit precision.
+
+- Only win32 binaries are included. The source is available from:
+ http://www.cyberonic.net/~gdevault/rfm/mapstuff/bkgrnd2d-b0.25-src.zip
+ If you want to use it on another platform you will need a buildable gtkradiant
+ source tree to build it. For any non-windows platform you will also have to
+ figure out the compile options. I suggest ripping those off from some other
+ plugin.
+
+TODO:
+- make file selection paterns match supported filetypes
+- large images without downsampling
+- bitmap and pcx support for indexmaps
+- automatic size from indexmapped entities
+- render under the grid instead of blending
+- mac/*nix support
+- remember/save/restore settings
+- texture options independant of radiant prefs
+- clean up icky code
+
+Changes from 0.1
+- all 2d views supported
+- new ui
+- file selection patterns, default directory improved
+
+Changes from 0.2
+- tooltips in dialog
+- various code cleanup
+
-; plugin.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "bobToolz"\r
-; DESCRIPTION 'bobToolz Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; plugin.def : Declares the module parameters for the DLL.
+
+LIBRARY "bobToolz"
+; DESCRIPTION 'bobToolz Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-common/areaportal\r
-common/clip\r
-common/clusterportal\r
-common/cushion\r
-common/donotenter\r
-common/full_clip\r
-common/hint\r
-common/missileclip\r
-common/nodraw\r
-common/nodrawnonsolid\r
-common/nodrop\r
-common/noimpact\r
-common/origin\r
-common/trigger\r
-common/weapclip\r
-liquid\r
+common/areaportal
+common/clip
+common/clusterportal
+common/cushion
+common/donotenter
+common/full_clip
+common/hint
+common/missileclip
+common/nodraw
+common/nodrawnonsolid
+common/nodrop
+common/noimpact
+common/origin
+common/trigger
+common/weapclip
+liquid
fog
\ No newline at end of file
-base_light/light1blue_2000\r
-base_light/light1blue_5000\r
-ctf/blue_telep\r
-ctf/ctf_blueflag\r
-ctf/ctf_tower_bluefin_shiny\r
-gothic_door/door02_eblue2_shiny\r
-gothic_light/ironcrossltblue_10000\r
-gothic_light/ironcrossltblue_2000\r
-gothic_light/ironcrossltblue_20000\r
-gothic_light/ironcrossltblue_3000\r
-gothic_light/ironcrossltblue_30000\r
-gothic_light/ironcrossltblue_4000\r
-gothic_light/ironcrossltblue_5000\r
-sfx/beam_blue\r
-sfx/flameanim_blue\r
-sfx/flameanim_blue_nolight\r
-sfx/flameanim_blue_pj\r
-sfx/mkc_fog_ctfblue\r
-sfx/xbluefog\r
-base_wall2/blue_metal\r
-base_wall2/jumppad_blue_kc\r
-base_wall2/blue_line\r
-base_wall2/double_line_blue\r
-base_wall2/blue_arrow_small\r
-base_wall2/blue_circle\r
-base_wall2/bluearrows\r
-base_wall2/blue_solid\r
-ctf2/blueteam01\r
-ctf2/blueteam02\r
-ctf2/xblueteam01\r
-ctf2/blue_banner02\r
-proto2/blueflag\r
-proto2/blueob\r
-proto2/marbledoor_blue\r
-proto2/concrete_bluenfx\r
-proto2/bluelight_on\r
-proto2/bsbluelight_on\r
-proto2/rsbluelight_off\r
-proto2/bsbluelight_off\r
-proto2/rsbluelight_on\r
-proto2/bluetrim01\r
-proto2/blue_zot\r
-proto2/blue_zot2\r
-proto2/bluea_dcl\r
-proto2/concrete_blue\r
-proto2/teamwerkz_blue1\r
-proto2/blueflare2\r
-proto2/blueflare\r
-sfx2/flameanim_blue_lowlite\r
-sfx2/blue_jumpad05\r
-sfx2/blue_launchpad\r
-sfx2/blue_jumpad\r
-sfx2/blue_jumpad2\r
-sfx2/blue_jumpad3\r
-sfx2/bluegoal2\r
-tim/blue_flagbase\r
-team_icon/the fallen_blue\r
-team_icon/intruders_blue\r
-team_icon/crusaders_blue\r
-team_icon/pagans_blue\r
+base_light/light1blue_2000
+base_light/light1blue_5000
+ctf/blue_telep
+ctf/ctf_blueflag
+ctf/ctf_tower_bluefin_shiny
+gothic_door/door02_eblue2_shiny
+gothic_light/ironcrossltblue_10000
+gothic_light/ironcrossltblue_2000
+gothic_light/ironcrossltblue_20000
+gothic_light/ironcrossltblue_3000
+gothic_light/ironcrossltblue_30000
+gothic_light/ironcrossltblue_4000
+gothic_light/ironcrossltblue_5000
+sfx/beam_blue
+sfx/flameanim_blue
+sfx/flameanim_blue_nolight
+sfx/flameanim_blue_pj
+sfx/mkc_fog_ctfblue
+sfx/xbluefog
+base_wall2/blue_metal
+base_wall2/jumppad_blue_kc
+base_wall2/blue_line
+base_wall2/double_line_blue
+base_wall2/blue_arrow_small
+base_wall2/blue_circle
+base_wall2/bluearrows
+base_wall2/blue_solid
+ctf2/blueteam01
+ctf2/blueteam02
+ctf2/xblueteam01
+ctf2/blue_banner02
+proto2/blueflag
+proto2/blueob
+proto2/marbledoor_blue
+proto2/concrete_bluenfx
+proto2/bluelight_on
+proto2/bsbluelight_on
+proto2/rsbluelight_off
+proto2/bsbluelight_off
+proto2/rsbluelight_on
+proto2/bluetrim01
+proto2/blue_zot
+proto2/blue_zot2
+proto2/bluea_dcl
+proto2/concrete_blue
+proto2/teamwerkz_blue1
+proto2/blueflare2
+proto2/blueflare
+sfx2/flameanim_blue_lowlite
+sfx2/blue_jumpad05
+sfx2/blue_launchpad
+sfx2/blue_jumpad
+sfx2/blue_jumpad2
+sfx2/blue_jumpad3
+sfx2/bluegoal2
+tim/blue_flagbase
+team_icon/the fallen_blue
+team_icon/intruders_blue
+team_icon/crusaders_blue
+team_icon/pagans_blue
team_icon/stroggs_blue
\ No newline at end of file
-base_light/light1red_2000\r
-base_light/light1red_5000\r
-ctf/red_telep\r
-ctf/ctf_redflag\r
-ctf/ctf_tower_redfin_shiny\r
-gothic_door/door02_bred2_shiny\r
-gothic_light/ironcrossltred_10000\r
-gothic_light/ironcrossltred_2000\r
-gothic_light/ironcrossltred_20000\r
-gothic_light/ironcrossltred_3000\r
-gothic_light/ironcrossltred_30000\r
-gothic_light/ironcrossltred_4000\r
-gothic_light/ironcrossltred_5000\r
-sfx/beam_red\r
-sfx/flameanim_red\r
-sfx/flameanim_red_nolight\r
-sfx/flameanim_red_pj\r
-sfx/mkc_fog_ctfred\r
-sfx/xredfog\r
-base_wall2/red_metal\r
-base_wall2/jumppad_red_kc\r
-base_wall2/red_line\r
-base_wall2/double_line_red\r
-base_wall2/red_arrow_small\r
-base_wall2/red_circle\r
-base_wall2/redarrows\r
-base_wall2/red_solid\r
-ctf2/redteam01\r
-ctf2/redteam02\r
-ctf2/xredteam01x\r
-ctf2/red_banner02\r
-proto2/redflag\r
-proto2/redob\r
-proto2/marbledoor_red\r
-proto2/concrete_rednfx\r
-proto2/redlight_on\r
-proto2/bsredlight_on\r
-proto2/rsredlight_off\r
-proto2/bsredlight_off\r
-proto2/rsredlight_on\r
-proto2/redtrim01\r
-proto2/red_zot\r
-proto2/red_zot2\r
-proto2/reda_dcl\r
-proto2/concrete_red\r
-proto2/teamwerkz_red1\r
-proto2/redflare2\r
-proto2/redflare\r
-sfx2/flameanim_red_lowlite\r
-sfx2/red_jumpad05\r
-sfx2/red_launchpad\r
-sfx2/red_jumpad\r
-sfx2/red_jumpad2\r
-sfx2/red_jumpad3\r
-sfx2/redgoal2\r
-tim/red_flagbase\r
-team_icon/the fallen_red\r
-team_icon/intruders_red\r
-team_icon/crusaders_red\r
-team_icon/pagans_red\r
+base_light/light1red_2000
+base_light/light1red_5000
+ctf/red_telep
+ctf/ctf_redflag
+ctf/ctf_tower_redfin_shiny
+gothic_door/door02_bred2_shiny
+gothic_light/ironcrossltred_10000
+gothic_light/ironcrossltred_2000
+gothic_light/ironcrossltred_20000
+gothic_light/ironcrossltred_3000
+gothic_light/ironcrossltred_30000
+gothic_light/ironcrossltred_4000
+gothic_light/ironcrossltred_5000
+sfx/beam_red
+sfx/flameanim_red
+sfx/flameanim_red_nolight
+sfx/flameanim_red_pj
+sfx/mkc_fog_ctfred
+sfx/xredfog
+base_wall2/red_metal
+base_wall2/jumppad_red_kc
+base_wall2/red_line
+base_wall2/double_line_red
+base_wall2/red_arrow_small
+base_wall2/red_circle
+base_wall2/redarrows
+base_wall2/red_solid
+ctf2/redteam01
+ctf2/redteam02
+ctf2/xredteam01x
+ctf2/red_banner02
+proto2/redflag
+proto2/redob
+proto2/marbledoor_red
+proto2/concrete_rednfx
+proto2/redlight_on
+proto2/bsredlight_on
+proto2/rsredlight_off
+proto2/bsredlight_off
+proto2/rsredlight_on
+proto2/redtrim01
+proto2/red_zot
+proto2/red_zot2
+proto2/reda_dcl
+proto2/concrete_red
+proto2/teamwerkz_red1
+proto2/redflare2
+proto2/redflare
+sfx2/flameanim_red_lowlite
+sfx2/red_jumpad05
+sfx2/red_launchpad
+sfx2/red_jumpad
+sfx2/red_jumpad2
+sfx2/red_jumpad3
+sfx2/redgoal2
+tim/red_flagbase
+team_icon/the fallen_red
+team_icon/intruders_red
+team_icon/crusaders_red
+team_icon/pagans_red
team_icon/stroggs_red
\ No newline at end of file
-base_support/support1rust\r
-base_support/support1shiny\r
-base_support/support2rust\r
-base_support/wplat1_1\r
+base_support/support1rust
+base_support/support1shiny
+base_support/support2rust
+base_support/wplat1_1
base_support/plate2_5
\ No newline at end of file
-base_door/shinymetaldoor\r
-base_door/shinymetaldoor_outside\r
-gothic_door/door02_bred\r
-gothic_door/door02_bred2_shiny\r
-gothic_door/door02_eblue2_shiny\r
-gothic_door/door02_i_ornate5_fin\r
-gothic_door/door02_j\r
-gothic_door/door02_j3\r
-gothic_door/door02_j4\r
+base_door/shinymetaldoor
+base_door/shinymetaldoor_outside
+gothic_door/door02_bred
+gothic_door/door02_bred2_shiny
+gothic_door/door02_eblue2_shiny
+gothic_door/door02_i_ornate5_fin
+gothic_door/door02_j
+gothic_door/door02_j3
+gothic_door/door02_j4
gothic_door/door02_k2b
\ No newline at end of file
-{\r
- "entity" "misc_model"\r
-\r
- "offset" "-16"\r
-\r
- "model" "models/mapobjects/trees_sd/tree_a.md3"\r
- "model" "models/mapobjects/trees_sd/tree_b.md3"\r
- "model" "models/mapobjects/trees_sd/tree_c.md3"\r
- "model" "models/mapobjects/trees_sd/tree_d.md3"\r
-\r
- "pitch" "-5" "5"\r
- "yaw" "0" "360"\r
- "scale" "1" "1.3"\r
+{
+ "entity" "misc_model"
+
+ "offset" "-16"
+
+ "model" "models/mapobjects/trees_sd/tree_a.md3"
+ "model" "models/mapobjects/trees_sd/tree_b.md3"
+ "model" "models/mapobjects/trees_sd/tree_c.md3"
+ "model" "models/mapobjects/trees_sd/tree_d.md3"
+
+ "pitch" "-5" "5"
+ "yaw" "0" "360"
+ "scale" "1" "1.3"
}
\ No newline at end of file
-; plugin.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "ctfToolz"\r
-DESCRIPTION 'ctfToolz Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- QERPlug_Init @1\r
- QERPlug_GetName @2\r
- QERPlug_GetCommandList @3\r
- QERPlug_Dispatch @4\r
- QERPlug_GetFuncTable @5\r
+; plugin.def : Declares the module parameters for the DLL.
+
+LIBRARY "ctfToolz"
+DESCRIPTION 'ctfToolz Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ QERPlug_Init @1
+ QERPlug_GetName @2
+ QERPlug_GetCommandList @3
+ QERPlug_Dispatch @4
+ QERPlug_GetFuncTable @5
-BobToolz Changelog:\r
-[=================]\r
-\r
-Changes in v1110 (GTK):\r
-[=====================]\r
-\r
-djbob\r
-\r
-Added:\r
-(16.05.01)\r
- Impemented a little feature that highligths the q3map bug that is causing problems for autocaulk, (see readme)\r
-(01.04.01)\r
- Added DPatch class to implement patches, however radiant does not (currently) support adding patches to an entity via a plugin, so, its actually redundant atm, i was adding this to fix the patches being removed from entities probelm with dealing with entities outside of the worldspawn.\r
- \r
-Changes:\r
-(02.04.01)\r
- EPair keys and values can now be 128 characters long, not 64, happy now hydra?\r
- Texture reseter works on patches now too.\r
-\r
-Removed:\r
-(29.03.01)\r
- Removed CTF colour changer, it is now in the ctftoolz.\r
-\r
-Fixed:\r
-(02.04.01)\r
- Worldspawn brushes are rebuilt per brush, rather than per entity in texture reseter.\r
-(03.04.01)\r
- Worldspawn brushes are rebuilt per brush, rather than per entity in brush cleanup.\r
-\r
-Changes in v1100 (GTK):\r
-[=====================]\r
-\r
-djbob\r
-\r
-Added:\r
-(24.03.01)\r
- Added CTF colour changer for worldspawn+func_group.\r
-\r
-Changes:\r
-(25.03.01)\r
- Brought some functions over to using DMap class, allowing them to run on multiple entities, patches are still a no-no atm.\r
- This includes:\r
- \r
- a) brush cleanup, will now fix problems on brushes that are not in the worldspawn, and rebuild the entitiy afterwards.\r
- b) texture reseter will change textures on all brushes now, not just those in the worldspawn.\r
- c) CTF colour changer will also work on brushes outside of the worldspawn entity.\r
-\r
-This introduces one prolem, patches in entities will no longer be part of the new entity, sorry for any trouble this causes, i will fix it soon hopefully.\r
-\r
-Fixes:\r
-(25.03.01)\r
- Fixed bug in DMap class that prevented it destroying brushes... thus enabling the class to work!!!!\r
-\r
-Changes in v1090 (GTK):\r
-[=====================]\r
-\r
-djbob\r
-\r
-Added:\r
-(22.03.01)\r
- Added PitOMatic Function.\r
-\r
-Changes in v1080b (GTK):\r
-[======================]\r
-\r
-djbob\r
-\r
-Fixes:\r
- Removed some previously unnoticed porting introduced bugs.\r
-\r
-Added:\r
- Polygon stuff now passes through my internal validation routines, no more phantom brushes will be made, or squiffy planes.\r
-\r
-Changes in v1080 (GTK):\r
-[=====================]\r
-\r
-djbob\r
-\r
-Fixes:\r
-(05.03.01)\r
- Fixed line removed by rr2 in autocaulk.\r
- Fixed Autocaulk not working with maps larger than the old grid.\r
-\r
-Added:\r
-(04.03.01)\r
- Added Changelog.\r
- Added ability to align polygons so that top edge will be flat. (Request By Casey)\r
-(05.03.01)\r
- Added ability to change main texture for stairs.\r
-\r
-rr2do2\r
-\r
-Changes:\r
-(??.??.01)\r
- Removed all traces of MFC from GTK version, the evil that it is ;]\r
-\r
+BobToolz Changelog:
+[=================]
+
+Changes in v1110 (GTK):
+[=====================]
+
+djbob
+
+Added:
+(16.05.01)
+ Impemented a little feature that highligths the q3map bug that is causing problems for autocaulk, (see readme)
+(01.04.01)
+ Added DPatch class to implement patches, however radiant does not (currently) support adding patches to an entity via a plugin, so, its actually redundant atm, i was adding this to fix the patches being removed from entities probelm with dealing with entities outside of the worldspawn.
+
+Changes:
+(02.04.01)
+ EPair keys and values can now be 128 characters long, not 64, happy now hydra?
+ Texture reseter works on patches now too.
+
+Removed:
+(29.03.01)
+ Removed CTF colour changer, it is now in the ctftoolz.
+
+Fixed:
+(02.04.01)
+ Worldspawn brushes are rebuilt per brush, rather than per entity in texture reseter.
+(03.04.01)
+ Worldspawn brushes are rebuilt per brush, rather than per entity in brush cleanup.
+
+Changes in v1100 (GTK):
+[=====================]
+
+djbob
+
+Added:
+(24.03.01)
+ Added CTF colour changer for worldspawn+func_group.
+
+Changes:
+(25.03.01)
+ Brought some functions over to using DMap class, allowing them to run on multiple entities, patches are still a no-no atm.
+ This includes:
+
+ a) brush cleanup, will now fix problems on brushes that are not in the worldspawn, and rebuild the entitiy afterwards.
+ b) texture reseter will change textures on all brushes now, not just those in the worldspawn.
+ c) CTF colour changer will also work on brushes outside of the worldspawn entity.
+
+This introduces one prolem, patches in entities will no longer be part of the new entity, sorry for any trouble this causes, i will fix it soon hopefully.
+
+Fixes:
+(25.03.01)
+ Fixed bug in DMap class that prevented it destroying brushes... thus enabling the class to work!!!!
+
+Changes in v1090 (GTK):
+[=====================]
+
+djbob
+
+Added:
+(22.03.01)
+ Added PitOMatic Function.
+
+Changes in v1080b (GTK):
+[======================]
+
+djbob
+
+Fixes:
+ Removed some previously unnoticed porting introduced bugs.
+
+Added:
+ Polygon stuff now passes through my internal validation routines, no more phantom brushes will be made, or squiffy planes.
+
+Changes in v1080 (GTK):
+[=====================]
+
+djbob
+
+Fixes:
+(05.03.01)
+ Fixed line removed by rr2 in autocaulk.
+ Fixed Autocaulk not working with maps larger than the old grid.
+
+Added:
+(04.03.01)
+ Added Changelog.
+ Added ability to align polygons so that top edge will be flat. (Request By Casey)
+(05.03.01)
+ Added ability to change main texture for stairs.
+
+rr2do2
+
+Changes:
+(??.??.01)
+ Removed all traces of MFC from GTK version, the evil that it is ;]
+
-BobToolz GTK: v1100\r
-[=================]\r
-\r
-Date:\r
-[===]\r
-16.05.01\r
-\r
-The multipurpose Quake3 Mappers Tool\r
-[==================================]\r
-\r
-Author: djbob\r
-Other work: q3terra, ctftoolz, EECA mod\r
-\r
-eMail: gbiggans@uglab.eee.strath.ac.uk (NO SPAM thank u very much :P)\r
-\r
-www: www.planetquake.com/toolz\r
- www.planetquake.com/eeca\r
-\r
-IRC: #freepq irc.fdf.net\r
- #qeradiant irc.telefragged.com\r
-\r
-Files Contained In This Package:\r
-[==============================]\r
-\r
-Readme.txt --- This file.\r
-Changelog.txt --- Version information.\r
-bobToolz.dll --- The plugin itsself.\r
-bt/*.txt --- A few text files required by the plugin.\r
-\r
-\r
-What's a boy to do?\r
-[=================]\r
-\r
-Put The plugin in your GTKRadiant plugins folder:\r
-e.g. mine: c:\gamez\quake3\GTKRadiant\plugins\r
-\r
-Run Radiant, and select the toolz from the dropdown plugin menu.\r
-\r
-Help is available in the form of a manual on my site.\r
-\r
-\r
-\r
-For the new q3map bug highlighting feature, run autocaulk-build mini prt, then run autocaulk.\r
-identify an area which has been caulked incorrectly, then reopen the map, select the q3map bug highlight option, and wait.\r
-once the selected brushes appear, u have 2 choices, \r
-\r
-a) press i and remove all the original brushes, or \r
-b) keep going with both sets (slower, but more useful)\r
-\r
-navigate to the problem region, you should find that the set of inverse brushes that has been built is missing a brush\r
-at the problem area, i suppose the next problem is finding out why :]\r
-\r
-this function is mainly provided for other coders to show the problem, and is probably of little use to anyone else,\r
-but u never know.\r
-\r
-\r
-Coming Soon:\r
-[==========]\r
-Region area saving. perhaps, if i get the time to finish it.\r
-\r
-\r
-Testing, Feedback & Ideas:\r
-[========================]\r
-\r
- Akuma, Casey, Cartman2K, maverik, rayden, nephilim_goth and god knows who else.\r
- Thx to you all.\r
-\r
-Thanx:\r
-[====]\r
-\r
- ttimo, da man :]\r
- spog, for his often baffling advice.... and questions....\r
- Thx to rr2do2, for his linux conversion, and removing the "evil" (his words :]) MFC code.\r
- Thx to RKone, for improving my q3w sig.\r
- Azr for giving me ops in #qeradiant, k3wl :]\r
- Everyone at the Quake3World Forums, I think of you all as my little worshippers :P\r
+BobToolz GTK: v1100
+[=================]
+
+Date:
+[===]
+16.05.01
+
+The multipurpose Quake3 Mappers Tool
+[==================================]
+
+Author: djbob
+Other work: q3terra, ctftoolz, EECA mod
+
+eMail: gbiggans@uglab.eee.strath.ac.uk (NO SPAM thank u very much :P)
+
+www: www.planetquake.com/toolz
+ www.planetquake.com/eeca
+
+IRC: #freepq irc.fdf.net
+ #qeradiant irc.telefragged.com
+
+Files Contained In This Package:
+[==============================]
+
+Readme.txt --- This file.
+Changelog.txt --- Version information.
+bobToolz.dll --- The plugin itsself.
+bt/*.txt --- A few text files required by the plugin.
+
+
+What's a boy to do?
+[=================]
+
+Put The plugin in your GTKRadiant plugins folder:
+e.g. mine: c:\gamez\quake3\GTKRadiant\plugins
+
+Run Radiant, and select the toolz from the dropdown plugin menu.
+
+Help is available in the form of a manual on my site.
+
+
+
+For the new q3map bug highlighting feature, run autocaulk-build mini prt, then run autocaulk.
+identify an area which has been caulked incorrectly, then reopen the map, select the q3map bug highlight option, and wait.
+once the selected brushes appear, u have 2 choices,
+
+a) press i and remove all the original brushes, or
+b) keep going with both sets (slower, but more useful)
+
+navigate to the problem region, you should find that the set of inverse brushes that has been built is missing a brush
+at the problem area, i suppose the next problem is finding out why :]
+
+this function is mainly provided for other coders to show the problem, and is probably of little use to anyone else,
+but u never know.
+
+
+Coming Soon:
+[==========]
+Region area saving. perhaps, if i get the time to finish it.
+
+
+Testing, Feedback & Ideas:
+[========================]
+
+ Akuma, Casey, Cartman2K, maverik, rayden, nephilim_goth and god knows who else.
+ Thx to you all.
+
+Thanx:
+[====]
+
+ ttimo, da man :]
+ spog, for his often baffling advice.... and questions....
+ Thx to rr2do2, for his linux conversion, and removing the "evil" (his words :]) MFC code.
+ Thx to RKone, for improving my q3w sig.
+ Azr for giving me ops in #qeradiant, k3wl :]
+ Everyone at the Quake3World Forums, I think of you all as my little worshippers :P
id Software, of course.
\ No newline at end of file
-; camera.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "CAMERA"\r
-DESCRIPTION 'CAMERA Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; camera.def : Declares the module parameters for the DLL.
+
+LIBRARY "CAMERA"
+DESCRIPTION 'CAMERA Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-; gensurf.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "gensurf"\r
-DESCRIPTION 'gensurf Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; gensurf.def : Declares the module parameters for the DLL.
+
+LIBRARY "gensurf"
+DESCRIPTION 'gensurf Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-; fgd.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "HydraToolz"\r
-DESCRIPTION 'HydraToolz Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; fgd.def : Declares the module parameters for the DLL.
+
+LIBRARY "HydraToolz"
+DESCRIPTION 'HydraToolz Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-; PrtView.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "PrtView"\r
-; DESCRIPTION 'PrtView Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; PrtView.def : Declares the module parameters for the DLL.
+
+LIBRARY "PrtView"
+; DESCRIPTION 'PrtView Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-Put PrtView.dll in the Q3Radiant plugins directory.\r
-\r
-This program is pretty self explanitary, but point needs to\r
-be mentioned. In the configuration menu for 3D view options,\r
-the lines and polygons flags are tri-state. In the third state,\r
-the lines or polygons will only be drawn if the have the\r
-hint flag set. Older version of q3map will not set this flag\r
-and the hint shader may have to be modified to set it. As of\r
-this writing, I do not know all the details.\r
-\r
-Geoffrey DeWan\r
+Put PrtView.dll in the Q3Radiant plugins directory.
+
+This program is pretty self explanitary, but point needs to
+be mentioned. In the configuration menu for 3D view options,
+the lines and polygons flags are tri-state. In the third state,
+the lines or polygons will only be drawn if the have the
+hint flag set. Older version of q3map will not set this flag
+and the hint shader may have to be modified to set it. As of
+this writing, I do not know all the details.
+
+Geoffrey DeWan
gdewan@prairienet.org
\ No newline at end of file
-OK. Again I would have liked to get a design document before it being done. Main functionalities we\r
-need in the inspector:\r
-\r
-- Unifiy the inspector under a single dialog box, called with 'S'\r
-\r
-- Depending on what is currently selected, display several frames in the inspector:\r
-only brushes -> surface inspector\r
-only patches -> patch inspector\r
-brushes & patches -> both\r
-and later when brush primitives are mixed with regular brushes + plugin entities, raise whatever\r
-additional inspector stuff we need\r
-\r
-- The camera view must update realtime when we change some parameters.\r
-\r
-- Get rid of the Apply button, use the Undo code to store settings when surface inspector is\r
-raised. If user hits Cancel, call the undo stuff.\r
-\r
-- Use the message broadcasting stuff to keep the inspectors up to date when the user changes the\r
-current selection. Be careful to keep the undo stuff in sync with the select / deselect operations.\r
-\r
-- Use a 3-state scheme to display the params in the widgets. If two faces are selected that don't\r
-have the same shift increment, just grey out the shift box.\r
-\r
-Messaging:\r
-- a good chunk of the work is moving the selection/creation stuff to the messaging API\r
- we no longer use UpdateSurfaceDialog, we post messages instead ..\r
- the surface inspector has hooked one of it's listeners into the corresponding message\r
- we may need to reorganize the messages, maybe introduce a hierarchy? \r
- or pass a void * param with messages?\r
-\r
-- we don't post messages like "update surface inspector", we post messages that say "this and that\r
-have changed", then the surface inspector reacts if it needs to.\r
-Do we need marshalling in the messages? Very likely .. maybe using Gtk signal stuff would be interesting?\r
-\r
--> the messaging stuff is a big chunk of work and our surface inspector changes are not totally \r
-dependent on it. Better leave that for l8r\r
-\r
-the inspector works by states and transitions? Or we post messages to it?\r
-Use case:\r
-the user raises the inspector .. if we are up we'll ignore, if we are hidden we'll\r
-go through the whole process (initialise, look at what is selected, display)\r
-then we enter an active state (listening for select / deselects and applying stuff)\r
-\r
-all in all it seems to be too big a change for next release. will see later probably.\r
-Trying a few more days with it, see what happens. after all the interface is fairly restricted\r
-so there's a good chance our changes are fairly stable in the end. But rebuilding the whole interface\r
-part might be too much ...\r
-We need something state based? AND a set of messages ..\r
-but first, need to write the initialisation loop\r
-build the dialog, get the current surface information and display\r
-\r
-Undoing the changes on the selected stuff:\r
-at any point in time, one can get a snapshot of selected stuff and use it to store the surface\r
-properties settings for later on. But what happens if the user modifies the selected brush, pushing\r
-it in the undo stack? Then we would cancel the changes? (and just backup to the state right after\r
-the modif)\r
-We could has the 'Apply' button used for that .. grey it out when the current state is the one in\r
-the backup. This happens whenever we hit 'Apply' or change something in the selection.\r
-The selection has several items: entities, brushes and selected faces (possibly later generic plugin entities)\r
-Current undo stuff is aimed at entities and brushes.\r
-NOTE: you can't have selected faces and brushes/entities at the same time, that's a good point to\r
-keep that seperated to deal with undo and storage\r
-On what side should the implemetation be ? undo.cpp select.cpp or surfacedialog.cpp ?\r
-We are going to do it with the messaging API anyway..\r
-And hook in the undo stuff, to reset the snapshot each time something gets pushed in the undo?\r
-\r
-We have advanced stuff on the Inspector branch, doing basics on Alpha branch.\r
-Start writing the watch code in surfacedialog.cpp, see if we need some merging with Undo stuff l8r\r
-We need to track for the patch inspector as well..\r
-\r
-basic code for CSurfaceUndo written. need to add hooks for the snapshot stuff and undo stuff. and a\r
-debug flag to monitor the life cycle of the object.\r
-\r
-some use cases:\r
-- select a brush\r
-- bring up surface inspector\r
-- check we had the debug messages from CSurfaceUndo (initialise, activate, snapshot)\r
-- edit the surface settings\r
-- check the views are updating correctly\r
-- hit Ok\r
-- check we had a deactivate message\r
-OK\r
-\r
-- select a brush\r
-- bring up surface inspector\r
-- check we had the debug messages from CSurfaceUndo (initialise, activate, snapshot)\r
-- edit the surface settings\r
-- check the views are updating correctly\r
-- hit cancel / escape\r
-- check we have a undo and deactivate from CSurfaceUndo\r
-OK\r
-\r
-- select a brush\r
-- bring up the surface inspector\r
-- edit the surface settings\r
-- hit apply\r
-- edit them again\r
-- hit cancel / escape\r
-- check you get back to the apply state\r
-OK\r
-\r
-- make two brushes\r
-- select a brush\r
-- bring up surface inspector\r
-- change settings\r
-- select an additional brush\r
-- check the surface inspector, new snapshot\r
-- hit cancel\r
-- check brushes remained in the same state\r
-- use standard Undo\r
-- check the first brush got back to it's initial settings\r
-OK\r
-\r
-- select a brush\r
-- bring up surface inspector\r
-- change settings\r
-- select an additional brush\r
-- check the surface inspector, new snapshot\r
-- change more settings\r
-- hit cancel\r
-- check the first brush returned to intermediate state, and second to initial state (i.e. last snapshot)\r
-OK\r
-\r
-g_surfaceUndo acts as a layer on top of the core Undo code when the surface inspector is activated.\r
-We need it because the surface inspector can edit faces which are not handled by the undo?\r
-(or does the current code push the whole brush when editing a face?)\r
-\r
-not sure of the utility of the g_surfaceDialog hooks here ..\r
-default undo usage in the sruface inspector sends way too many undo messages.\r
-with the new scheme we store in undo only when select/deselect or user hits apply\r
-that way the 'Cancel' and later Ctrl+Z calls make sense\r
-but is it worth implementing a new class to achieve that?? .. yes because we intend a later cleanup\r
-of this part. (ahem is this reason good enough..)\r
-this part is actually much closer from the undo code than I had expected..\r
-'Cancel' call being an Undo call..\r
-\r
-going to Inspector3:\r
-don't create a new class, simply use the Undo more intelligently?\r
-i.e. don't create undo stuff when editing the brush\r
--> we add a flag to turn off the default undo behaviour and force Undo storage when we want\r
-we could also store the undo Id we are interested in and call undo several times to get it back\r
-\r
-NOTE: what happens if the user hits undo when the surface inspector is up?\r
--> we'll have to take his request into account?\r
-err .. performing which undo? The texture positioning or something else?\r
-seems the snapshot approach would still make sense then?\r
-\r
-more use cases, see with Undo calls and select/deselect events\r
-NOTE: this whole thing is probably a single call to select_settexture that needs to be turned on/off\r
-instead of working at the undo level. but we would like to move to messaging so maybe it still makes sense\r
-the undo call is in Select_SetTexture (which does not have that many callers, I was expecting more)\r
-\r
-the question about having the undo code keep working when surface inspector is around is still raised.\r
-but it makes it a lot harder, gotta have a real inspector mode in the undo?\r
-dunno, think about it again later\r
-\r
-two operations are mixed in a single one and should not be:\r
-reading the map to get the current data we'll manipulate\r
-feed it in the dialog box widgets\r
-WARNING: when putting stuff in the widgets, it raises a shitload of update messages and therefor completely\r
-fucks up our OnOK OnApply OnCancel scheme (specially OnApply!)\r
-\r
-NOTE: we want to switch between Surface inspector for brushes only and Patch inspector for patches only\r
-there's some crappy code in the surface inspector that we need to get rid of\r
-but need to check about that before with Spog or others\r
-\r
-Forcing the way into using the surface inspector is SCREWED?\r
-Doesn't seem to work the way we want to. Always get parasite Undo messages and stuff.\r
-We could use a seperate stack for Undo with the surface inspector?\r
-Just store the surface properties in a seperate stack?\r
-When user hits cancel you go back and apply whatever you had?\r
-Doesn't seem like a clean way either.\r
-\r
-Now dealing with both regular surface inspector and patch inspector:\r
-we have some stuff that needs to be on/off with the two inspectors\r
-what about catching the messages and issuing new snapshots?\r
-the main surface inspector is doing it?\r
-no!\r
-so what, we have several states?\r
-FUCKED UP\r
-\r
-INSPECTOR 5 ----------------------------------------------------------------\r
-restarted from scratch, made much more simple changes.\r
-trying another trick for undo (!)\r
-just let the undo work as usual, but call undo ourselves in SetTexMods if we have create the last do\r
-requires proper initialization/deinitialisation.. in SetTexMods and GetTexMods..\r
-\r
-getting rid of patch manipulation code in the regular surface inspector. The buttons will \r
-still work, but manip will require the patch inspector. (seems the patch inspector doesn't have that\r
-much success anyway)\r
-\r
-TODO:\r
-OK get rid of patch stuff\r
-OK get rid of the texture toolbar? (it's broken right now)\r
- (and doesn't have anything usefull..)\r
-OK (Partial) OnCancel? we need to cancel the texdef as well\r
- store an undo texdef each time we grab new texdef stuff\r
- this works in reverse than the Undo code? When we do the initial\r
- problem is, in some cases the settings that show up are not in sync with what's in the inspector??\r
- (we can't avoid that because if a brush is selected there's no single setting)\r
- prolly get it out as is and let Spog or others send feedback about what it's supposed to do..\r
- for now: store stuff in the cancel texdef when we initialize an undo loop\r
- revert to that if OnCancel is used\r
-OK message when spinning over a patch?\r
-DUPLICATE (.. see below ..) check the increments we store in the SI are used when shift + arrows etc.\r
- no it doesn't work .. the shifting on keyboard shortcuts is done with m_nTextureTweak\r
- seems m_nTextureTweak is nowhere available in the prefs (and it's not in MFC builds either)\r
- some cleanup to be done around that it seems\r
-OK (.. merged with below, maybe some special cases left ..) texture widget (catch the Enter key to force-call an OnApply)\r
-OK (.. see above ..) catch Enter key at dialog level to call OnDone\r
-NO (.. it's clean, but thats too many lines of code ..) move the code that blokes updates to use gtk_signal_handler_block_by_func and gtk_signal_handler_block_by_func\r
-OK shift + arrow must match the SI settings, \r
-OK (FIXME .. not using the right scale (using the scale step instead! + add a button in SI to 'Match grid')\r
-POSTPONED (.. m_nTextureTweak is used in the nudge commands ..\r
- .. and nudge shortcuts are broken right now ..) get rid of m_nTextureTweak\r
-+ SI and PI always on top!\r
-\r
-+ known issues: "Match Grid" is broken in BP mode\r
-\r
-now on the patch inspector (nightmare!):\r
-OK (.. put it as readonly .. don't bother ..) texture name widget is screwed?\r
-OK the spinners scheme doesn't work, the stuff in the dialog is the inc step and we just need arrows\r
-OK get rid of the 'Type' dialog box\r
-POSTPONED (.. can't do undo on PI without proper Undo module ..) add proper Done Apply Cancel with Undo\r
-NO (.. too much work for something that sucks ..) make the changes reflect in the views when manipulating the entries\r
-OK (.. using %g ..) cut down on the number of digits!\r
-OK increment steps to be stored in the registry\r
-\r
-putting the Cancel stuff in the surface inspector: only based on the Undo code, no cancel settings to store\r
-because we don't have actual storage of a current texdef (we only send alterations) BTW we should do that for \r
-brushes as well\r
-the patch inspector works by increments, Patch_SetTextureInfo to incrementally modify the patch.\r
-we can still do some undo by having a texdef storing the changes and working together with the undo\r
-if the undo is recognized, it means our current texdef increment is valid\r
-no, we can't represent the combination of several increments scale and rotate in a single texdef..\r
-get rid of the undo code for now .. only Apply and Done left\r
-\r
-it seems it's still vastly broken when you select something. or is it on linux only?\r
-need a LOT of testing and figuring it out!!\r
-selecting a brush breaks totally.. (the texture screws up it seems)\r
-does it attempt to change the texture of the selected object??\r
-also: it seems you can multiple select a same brush??\r
-\r
-the UNDO code of the SURFACE INSPECTOR IS STILL BROKEN ????\r
-(ok I'm really screwed, time to sleep)\r
--> can't reproduce now?? maybe it's linux specific problem, I can't tell\r
-\r
-FOUND A WAY TO REPRODUCE THE CRASH:\r
-+ select brush\r
-+ hit "Fit"\r
-+ hit the shift spinners two times\r
-OR:\r
-+ select single face on brush\r
-+ manually edit scale values\r
--> maybe we have a problem with current texture? (NO)\r
-it's some kind of infinite loop? we call UpdateSurfaceInspector from Select_Brush and bang!\r
-no, it's a texdef from a face that got deleted\r
-prolly that hooking the undo code in there screws up the selected faces stuff\r
-if you undo a selected face operation, you end up with the whole brush selected.\r
-but that does not necessarily explain why you remove the face at Undo_Start\r
-ho well .. removed the undo buffering when selected faces and everything's better\r
-would need to re-establish the right face selection after undo, might solve the problem\r
-(actually you'd still need to have the settings point to the right object)\r
-\r
-From PJ about the 'Match Grid' stuff: textures are moved in pixels, not units.\r
-We must rely on the current texture scale AND gridsize to compute the shift increment\r
+OK. Again I would have liked to get a design document before it being done. Main functionalities we
+need in the inspector:
+
+- Unifiy the inspector under a single dialog box, called with 'S'
+
+- Depending on what is currently selected, display several frames in the inspector:
+only brushes -> surface inspector
+only patches -> patch inspector
+brushes & patches -> both
+and later when brush primitives are mixed with regular brushes + plugin entities, raise whatever
+additional inspector stuff we need
+
+- The camera view must update realtime when we change some parameters.
+
+- Get rid of the Apply button, use the Undo code to store settings when surface inspector is
+raised. If user hits Cancel, call the undo stuff.
+
+- Use the message broadcasting stuff to keep the inspectors up to date when the user changes the
+current selection. Be careful to keep the undo stuff in sync with the select / deselect operations.
+
+- Use a 3-state scheme to display the params in the widgets. If two faces are selected that don't
+have the same shift increment, just grey out the shift box.
+
+Messaging:
+- a good chunk of the work is moving the selection/creation stuff to the messaging API
+ we no longer use UpdateSurfaceDialog, we post messages instead ..
+ the surface inspector has hooked one of it's listeners into the corresponding message
+ we may need to reorganize the messages, maybe introduce a hierarchy?
+ or pass a void * param with messages?
+
+- we don't post messages like "update surface inspector", we post messages that say "this and that
+have changed", then the surface inspector reacts if it needs to.
+Do we need marshalling in the messages? Very likely .. maybe using Gtk signal stuff would be interesting?
+
+-> the messaging stuff is a big chunk of work and our surface inspector changes are not totally
+dependent on it. Better leave that for l8r
+
+the inspector works by states and transitions? Or we post messages to it?
+Use case:
+the user raises the inspector .. if we are up we'll ignore, if we are hidden we'll
+go through the whole process (initialise, look at what is selected, display)
+then we enter an active state (listening for select / deselects and applying stuff)
+
+all in all it seems to be too big a change for next release. will see later probably.
+Trying a few more days with it, see what happens. after all the interface is fairly restricted
+so there's a good chance our changes are fairly stable in the end. But rebuilding the whole interface
+part might be too much ...
+We need something state based? AND a set of messages ..
+but first, need to write the initialisation loop
+build the dialog, get the current surface information and display
+
+Undoing the changes on the selected stuff:
+at any point in time, one can get a snapshot of selected stuff and use it to store the surface
+properties settings for later on. But what happens if the user modifies the selected brush, pushing
+it in the undo stack? Then we would cancel the changes? (and just backup to the state right after
+the modif)
+We could has the 'Apply' button used for that .. grey it out when the current state is the one in
+the backup. This happens whenever we hit 'Apply' or change something in the selection.
+The selection has several items: entities, brushes and selected faces (possibly later generic plugin entities)
+Current undo stuff is aimed at entities and brushes.
+NOTE: you can't have selected faces and brushes/entities at the same time, that's a good point to
+keep that seperated to deal with undo and storage
+On what side should the implemetation be ? undo.cpp select.cpp or surfacedialog.cpp ?
+We are going to do it with the messaging API anyway..
+And hook in the undo stuff, to reset the snapshot each time something gets pushed in the undo?
+
+We have advanced stuff on the Inspector branch, doing basics on Alpha branch.
+Start writing the watch code in surfacedialog.cpp, see if we need some merging with Undo stuff l8r
+We need to track for the patch inspector as well..
+
+basic code for CSurfaceUndo written. need to add hooks for the snapshot stuff and undo stuff. and a
+debug flag to monitor the life cycle of the object.
+
+some use cases:
+- select a brush
+- bring up surface inspector
+- check we had the debug messages from CSurfaceUndo (initialise, activate, snapshot)
+- edit the surface settings
+- check the views are updating correctly
+- hit Ok
+- check we had a deactivate message
+OK
+
+- select a brush
+- bring up surface inspector
+- check we had the debug messages from CSurfaceUndo (initialise, activate, snapshot)
+- edit the surface settings
+- check the views are updating correctly
+- hit cancel / escape
+- check we have a undo and deactivate from CSurfaceUndo
+OK
+
+- select a brush
+- bring up the surface inspector
+- edit the surface settings
+- hit apply
+- edit them again
+- hit cancel / escape
+- check you get back to the apply state
+OK
+
+- make two brushes
+- select a brush
+- bring up surface inspector
+- change settings
+- select an additional brush
+- check the surface inspector, new snapshot
+- hit cancel
+- check brushes remained in the same state
+- use standard Undo
+- check the first brush got back to it's initial settings
+OK
+
+- select a brush
+- bring up surface inspector
+- change settings
+- select an additional brush
+- check the surface inspector, new snapshot
+- change more settings
+- hit cancel
+- check the first brush returned to intermediate state, and second to initial state (i.e. last snapshot)
+OK
+
+g_surfaceUndo acts as a layer on top of the core Undo code when the surface inspector is activated.
+We need it because the surface inspector can edit faces which are not handled by the undo?
+(or does the current code push the whole brush when editing a face?)
+
+not sure of the utility of the g_surfaceDialog hooks here ..
+default undo usage in the sruface inspector sends way too many undo messages.
+with the new scheme we store in undo only when select/deselect or user hits apply
+that way the 'Cancel' and later Ctrl+Z calls make sense
+but is it worth implementing a new class to achieve that?? .. yes because we intend a later cleanup
+of this part. (ahem is this reason good enough..)
+this part is actually much closer from the undo code than I had expected..
+'Cancel' call being an Undo call..
+
+going to Inspector3:
+don't create a new class, simply use the Undo more intelligently?
+i.e. don't create undo stuff when editing the brush
+-> we add a flag to turn off the default undo behaviour and force Undo storage when we want
+we could also store the undo Id we are interested in and call undo several times to get it back
+
+NOTE: what happens if the user hits undo when the surface inspector is up?
+-> we'll have to take his request into account?
+err .. performing which undo? The texture positioning or something else?
+seems the snapshot approach would still make sense then?
+
+more use cases, see with Undo calls and select/deselect events
+NOTE: this whole thing is probably a single call to select_settexture that needs to be turned on/off
+instead of working at the undo level. but we would like to move to messaging so maybe it still makes sense
+the undo call is in Select_SetTexture (which does not have that many callers, I was expecting more)
+
+the question about having the undo code keep working when surface inspector is around is still raised.
+but it makes it a lot harder, gotta have a real inspector mode in the undo?
+dunno, think about it again later
+
+two operations are mixed in a single one and should not be:
+reading the map to get the current data we'll manipulate
+feed it in the dialog box widgets
+WARNING: when putting stuff in the widgets, it raises a shitload of update messages and therefor completely
+fucks up our OnOK OnApply OnCancel scheme (specially OnApply!)
+
+NOTE: we want to switch between Surface inspector for brushes only and Patch inspector for patches only
+there's some crappy code in the surface inspector that we need to get rid of
+but need to check about that before with Spog or others
+
+Forcing the way into using the surface inspector is SCREWED?
+Doesn't seem to work the way we want to. Always get parasite Undo messages and stuff.
+We could use a seperate stack for Undo with the surface inspector?
+Just store the surface properties in a seperate stack?
+When user hits cancel you go back and apply whatever you had?
+Doesn't seem like a clean way either.
+
+Now dealing with both regular surface inspector and patch inspector:
+we have some stuff that needs to be on/off with the two inspectors
+what about catching the messages and issuing new snapshots?
+the main surface inspector is doing it?
+no!
+so what, we have several states?
+FUCKED UP
+
+INSPECTOR 5 ----------------------------------------------------------------
+restarted from scratch, made much more simple changes.
+trying another trick for undo (!)
+just let the undo work as usual, but call undo ourselves in SetTexMods if we have create the last do
+requires proper initialization/deinitialisation.. in SetTexMods and GetTexMods..
+
+getting rid of patch manipulation code in the regular surface inspector. The buttons will
+still work, but manip will require the patch inspector. (seems the patch inspector doesn't have that
+much success anyway)
+
+TODO:
+OK get rid of patch stuff
+OK get rid of the texture toolbar? (it's broken right now)
+ (and doesn't have anything usefull..)
+OK (Partial) OnCancel? we need to cancel the texdef as well
+ store an undo texdef each time we grab new texdef stuff
+ this works in reverse than the Undo code? When we do the initial
+ problem is, in some cases the settings that show up are not in sync with what's in the inspector??
+ (we can't avoid that because if a brush is selected there's no single setting)
+ prolly get it out as is and let Spog or others send feedback about what it's supposed to do..
+ for now: store stuff in the cancel texdef when we initialize an undo loop
+ revert to that if OnCancel is used
+OK message when spinning over a patch?
+DUPLICATE (.. see below ..) check the increments we store in the SI are used when shift + arrows etc.
+ no it doesn't work .. the shifting on keyboard shortcuts is done with m_nTextureTweak
+ seems m_nTextureTweak is nowhere available in the prefs (and it's not in MFC builds either)
+ some cleanup to be done around that it seems
+OK (.. merged with below, maybe some special cases left ..) texture widget (catch the Enter key to force-call an OnApply)
+OK (.. see above ..) catch Enter key at dialog level to call OnDone
+NO (.. it's clean, but thats too many lines of code ..) move the code that blokes updates to use gtk_signal_handler_block_by_func and gtk_signal_handler_block_by_func
+OK shift + arrow must match the SI settings,
+OK (FIXME .. not using the right scale (using the scale step instead! + add a button in SI to 'Match grid')
+POSTPONED (.. m_nTextureTweak is used in the nudge commands ..
+ .. and nudge shortcuts are broken right now ..) get rid of m_nTextureTweak
++ SI and PI always on top!
+
++ known issues: "Match Grid" is broken in BP mode
+
+now on the patch inspector (nightmare!):
+OK (.. put it as readonly .. don't bother ..) texture name widget is screwed?
+OK the spinners scheme doesn't work, the stuff in the dialog is the inc step and we just need arrows
+OK get rid of the 'Type' dialog box
+POSTPONED (.. can't do undo on PI without proper Undo module ..) add proper Done Apply Cancel with Undo
+NO (.. too much work for something that sucks ..) make the changes reflect in the views when manipulating the entries
+OK (.. using %g ..) cut down on the number of digits!
+OK increment steps to be stored in the registry
+
+putting the Cancel stuff in the surface inspector: only based on the Undo code, no cancel settings to store
+because we don't have actual storage of a current texdef (we only send alterations) BTW we should do that for
+brushes as well
+the patch inspector works by increments, Patch_SetTextureInfo to incrementally modify the patch.
+we can still do some undo by having a texdef storing the changes and working together with the undo
+if the undo is recognized, it means our current texdef increment is valid
+no, we can't represent the combination of several increments scale and rotate in a single texdef..
+get rid of the undo code for now .. only Apply and Done left
+
+it seems it's still vastly broken when you select something. or is it on linux only?
+need a LOT of testing and figuring it out!!
+selecting a brush breaks totally.. (the texture screws up it seems)
+does it attempt to change the texture of the selected object??
+also: it seems you can multiple select a same brush??
+
+the UNDO code of the SURFACE INSPECTOR IS STILL BROKEN ????
+(ok I'm really screwed, time to sleep)
+-> can't reproduce now?? maybe it's linux specific problem, I can't tell
+
+FOUND A WAY TO REPRODUCE THE CRASH:
++ select brush
++ hit "Fit"
++ hit the shift spinners two times
+OR:
++ select single face on brush
++ manually edit scale values
+-> maybe we have a problem with current texture? (NO)
+it's some kind of infinite loop? we call UpdateSurfaceInspector from Select_Brush and bang!
+no, it's a texdef from a face that got deleted
+prolly that hooking the undo code in there screws up the selected faces stuff
+if you undo a selected face operation, you end up with the whole brush selected.
+but that does not necessarily explain why you remove the face at Undo_Start
+ho well .. removed the undo buffering when selected faces and everything's better
+would need to re-establish the right face selection after undo, might solve the problem
+(actually you'd still need to have the settings point to the right object)
+
+From PJ about the 'Match Grid' stuff: textures are moved in pixels, not units.
+We must rely on the current texture scale AND gridsize to compute the shift increment
-#!perl\r
-rename("$ARGV[0]", "$ARGV[0].old");\r
-open(FILE, "$ARGV[0].old");\r
-open(OFILE, ">$ARGV[0]");\r
-while(<FILE>)\r
-{\r
-if($. != $ARGV[1])\r
-{\r
-print OFILE;\r
-next;\r
-}\r
-s/Sys_Printf \(/Sys_FPrintf \(SYS_VRB,/;\r
-s/Sys_Printf\(/Sys_FPrintf \(SYS_VRB,/;\r
-print OFILE;\r
-}\r
-close(OFILE);\r
+#!perl
+rename("$ARGV[0]", "$ARGV[0].old");
+open(FILE, "$ARGV[0].old");
+open(OFILE, ">$ARGV[0]");
+while(<FILE>)
+{
+if($. != $ARGV[1])
+{
+print OFILE;
+next;
+}
+s/Sys_Printf \(/Sys_FPrintf \(SYS_VRB,/;
+s/Sys_Printf\(/Sys_FPrintf \(SYS_VRB,/;
+print OFILE;
+}
+close(OFILE);
close(FILE);
\ No newline at end of file
-#!perl\r
-rename("brush.c", "brush.c.old");\r
-open(FILE, "brush.c.old");\r
-open(OFILE, ">brush.c");\r
-while(<FILE>)\r
-{\r
-if($. != 150)\r
-{\r
-print OFILE;\r
-next;\r
-}\r
-s/Sys_Printf \(/Sys_FPrintf \(SYS_VRB,/;\r
-s/Sys_Printf\(/Sys_FPrintf \(SYS_VRB,/;\r
-print OFILE;\r
-}\r
-close(OFILE);\r
+#!perl
+rename("brush.c", "brush.c.old");
+open(FILE, "brush.c.old");
+open(OFILE, ">brush.c");
+while(<FILE>)
+{
+if($. != 150)
+{
+print OFILE;
+next;
+}
+s/Sys_Printf \(/Sys_FPrintf \(SYS_VRB,/;
+s/Sys_Printf\(/Sys_FPrintf \(SYS_VRB,/;
+print OFILE;
+}
+close(OFILE);
close(FILE);
\ No newline at end of file
-printf mess in q3map\r
-(and in the libs)\r
-\r
-q3map: several breeds .. qprintf _printf printf\r
-should all resolve to use a single Sys_Printf thing\r
-and put #define printf ..\r
-\r
-for the static libs? need to use function pointers..\r
-\r
-q3map uses common/cmdlib.c\r
-Radiant links against cmdlib.lib based on libs/cmdlib/cmdlib.cpp\r
-\r
-but eventually we'll want to use the same Sys_Printf scheme in q3map AND Radiant?\r
-qprintf and _printf are defined in common/cmdlib.c\r
-BUT: modifying cmdlib would probably break bspc and other stuff that relies on it?\r
-\r
-moving q3map to use a custom version of cmdlib.c in q3map/cmdlib.c\r
-removing the qprintf and _printf stuff, moving to a seperate printout.c file\r
-\r
-compiling libxml on win32: need to turn off a bunch of stuff.\r
-problem: we got two xmlversion.h files??\r
-we can't get rid of using libxml/xmlversion.h, so the solution is to get rid of xmlversion.h\r
-(add ../libxml to the paths)\r
-\r
-fuck!\r
-we also compile some .c files from common/ !\r
--> create a common2/ dir .. \r
+printf mess in q3map
+(and in the libs)
+
+q3map: several breeds .. qprintf _printf printf
+should all resolve to use a single Sys_Printf thing
+and put #define printf ..
+
+for the static libs? need to use function pointers..
+
+q3map uses common/cmdlib.c
+Radiant links against cmdlib.lib based on libs/cmdlib/cmdlib.cpp
+
+but eventually we'll want to use the same Sys_Printf scheme in q3map AND Radiant?
+qprintf and _printf are defined in common/cmdlib.c
+BUT: modifying cmdlib would probably break bspc and other stuff that relies on it?
+
+moving q3map to use a custom version of cmdlib.c in q3map/cmdlib.c
+removing the qprintf and _printf stuff, moving to a seperate printout.c file
+
+compiling libxml on win32: need to turn off a bunch of stuff.
+problem: we got two xmlversion.h files??
+we can't get rid of using libxml/xmlversion.h, so the solution is to get rid of xmlversion.h
+(add ../libxml to the paths)
+
+fuck!
+we also compile some .c files from common/ !
+-> create a common2/ dir ..
-========================================================================\r
- CONSOLE APPLICATION : XMLPush\r
-========================================================================\r
-\r
-\r
-AppWizard has created this XMLPush application for you. \r
-\r
-This file contains a summary of what you will find in each of the files that\r
-make up your XMLPush application.\r
-\r
-XMLPush.dsp\r
- This file (the project file) contains information at the project level and\r
- is used to build a single project or subproject. Other users can share the\r
- project (.dsp) file, but they should export the makefiles locally.\r
-\r
-XMLPush.cpp\r
- This is the main application source file.\r
-\r
-\r
-/////////////////////////////////////////////////////////////////////////////\r
-Other standard files:\r
-\r
-StdAfx.h, StdAfx.cpp\r
- These files are used to build a precompiled header (PCH) file\r
- named XMLPush.pch and a precompiled types file named StdAfx.obj.\r
-\r
-\r
-/////////////////////////////////////////////////////////////////////////////\r
-Other notes:\r
-\r
-AppWizard uses "TODO:" to indicate parts of the source code you\r
-should add to or customize.\r
-\r
-/////////////////////////////////////////////////////////////////////////////\r
+========================================================================
+ CONSOLE APPLICATION : XMLPush
+========================================================================
+
+
+AppWizard has created this XMLPush application for you.
+
+This file contains a summary of what you will find in each of the files that
+make up your XMLPush application.
+
+XMLPush.dsp
+ This file (the project file) contains information at the project level and
+ is used to build a single project or subproject. Other users can share the
+ project (.dsp) file, but they should export the makefiles locally.
+
+XMLPush.cpp
+ This is the main application source file.
+
+
+/////////////////////////////////////////////////////////////////////////////
+Other standard files:
+
+StdAfx.h, StdAfx.cpp
+ These files are used to build a precompiled header (PCH) file
+ named XMLPush.pch and a precompiled types file named StdAfx.obj.
+
+
+/////////////////////////////////////////////////////////////////////////////
+Other notes:
+
+AppWizard uses "TODO:" to indicate parts of the source code you
+should add to or customize.
+
+/////////////////////////////////////////////////////////////////////////////
-XMLmap branch:\r
-\r
-need to move the map loading / saving code out in a module\r
-what are the main dependencies?\r
-\r
-main functions to move out:\r
-Map_LoadFile\r
-Map_SaveFile\r
-(and all their direct dependencies/call graph)\r
-ex Entity_Parse Brush_Parse Entity_Write Brush_Write\r
-\r
-but? even changing to XML format we would need those functions too?\r
-is it worth having the .map and .xmlmap through a same interface?\r
-\r
-what dependencies?\r
--> active_brushes\r
--> GetToken etc.\r
--> LoadFile (load into a buffer) .. that's VFS right?\r
-\r
-first step: move some code out in map module and try to compile it..\r
-Map_LoadFile for example\r
-or the whole map.cpp?\r
-\r
-first problem: entity_t is declared in entity.h, currently not available to\r
-the plugin API. Clean way would be to create a wrapper, but speed says we\r
-should move entity_t to qertypes.h..\r
-\r
+XMLmap branch:
+
+need to move the map loading / saving code out in a module
+what are the main dependencies?
+
+main functions to move out:
+Map_LoadFile
+Map_SaveFile
+(and all their direct dependencies/call graph)
+ex Entity_Parse Brush_Parse Entity_Write Brush_Write
+
+but? even changing to XML format we would need those functions too?
+is it worth having the .map and .xmlmap through a same interface?
+
+what dependencies?
+-> active_brushes
+-> GetToken etc.
+-> LoadFile (load into a buffer) .. that's VFS right?
+
+first step: move some code out in map module and try to compile it..
+Map_LoadFile for example
+or the whole map.cpp?
+
+first problem: entity_t is declared in entity.h, currently not available to
+the plugin API. Clean way would be to create a wrapper, but speed says we
+should move entity_t to qertypes.h..
+
-Listing of required modules and interfaces as an XML file\r
-=========================================================\r
-\r
-Purpose:\r
---------\r
-\r
-Make the editor more data driven. Be able to specify during\r
-startup the full running configuration of the editor:\r
-- what modules to load\r
-- general execution paths (i.e. what's in the project settings)\r
-- configuration for the loaded modules\r
-- user preferences\r
-\r
-Feature Requirements:\r
----------------------\r
-\r
-This is primarily intended for multiple games support. A restart\r
-of the editor may be required when going from one game to the\r
-other, but otherwise it should read the XML file and initialize\r
-the right modules and APIs from there.\r
-\r
-Don't have a clear view of what multiple games support is gonna\r
-be like. Can list a few things:\r
-\r
-- some interfaces are required for startup in a given game mode.\r
-That's primarily what the XML config file is there for.\r
-For instance in Q3 you will require Q3 map format module\r
-and Q1 will require Q1 map format module\r
-\r
-- some modules are to be ignored? that's primary intended to \r
-avoid loading unneeded modules.\r
-\r
-- some plugins are loaded for all games?\r
-- some plugins are only relevant for some games?\r
-(those two suggest various installation paths for modules\r
-and directory-based scan?)\r
-\r
-- a plugin might require some other APIs to complete it's loading\r
-process (i.e. sending it's own XML description of required\r
-interfaces).\r
-\r
-Constaints:\r
------------\r
-\r
-We have a nasty collision between preferences / project settings\r
-and XML requirements. All three things need to be unified in some way.\r
-The long term target being to have a central installation location \r
-for the editor, and independant packages for each game.\r
-\r
-What kind of difference is there between project settings and prefs?\r
-Prefs would be user settings that survive throughout all games, \r
-whereas project settings are per-game / per-mod configuration. Turns\r
-out it's all a matter of loading the right configuration chunks at the\r
-right time.\r
-\r
-Proposed implementation:\r
-------------------------\r
-\r
-Use key/values (== property bags) based on XML format for everything.\r
-Use them on project settings, and user prefs. The only difference\r
-between what would be project settings and what would be user pref\r
-is in which game configuration they are loaded, and how they are used.\r
-\r
-Project templates: We have a particular syntax to build settings from \r
-a 'template' version. Instead of loading a project template, we should\r
-be selecting a template from a list.\r
-\r
-Default startup: If we are configured to load last project on startup,\r
-load it .. otherwise display a list of games and templates?\r
-\r
-Module library:\r
----------------\r
-\r
-The dynamic loading / interfaces sharing / pure virtual classes needs\r
-to be implemented in a generic module. It should be the basis of the\r
-editor startup process.\r
+Listing of required modules and interfaces as an XML file
+=========================================================
+
+Purpose:
+--------
+
+Make the editor more data driven. Be able to specify during
+startup the full running configuration of the editor:
+- what modules to load
+- general execution paths (i.e. what's in the project settings)
+- configuration for the loaded modules
+- user preferences
+
+Feature Requirements:
+---------------------
+
+This is primarily intended for multiple games support. A restart
+of the editor may be required when going from one game to the
+other, but otherwise it should read the XML file and initialize
+the right modules and APIs from there.
+
+Don't have a clear view of what multiple games support is gonna
+be like. Can list a few things:
+
+- some interfaces are required for startup in a given game mode.
+That's primarily what the XML config file is there for.
+For instance in Q3 you will require Q3 map format module
+and Q1 will require Q1 map format module
+
+- some modules are to be ignored? that's primary intended to
+avoid loading unneeded modules.
+
+- some plugins are loaded for all games?
+- some plugins are only relevant for some games?
+(those two suggest various installation paths for modules
+and directory-based scan?)
+
+- a plugin might require some other APIs to complete it's loading
+process (i.e. sending it's own XML description of required
+interfaces).
+
+Constaints:
+-----------
+
+We have a nasty collision between preferences / project settings
+and XML requirements. All three things need to be unified in some way.
+The long term target being to have a central installation location
+for the editor, and independant packages for each game.
+
+What kind of difference is there between project settings and prefs?
+Prefs would be user settings that survive throughout all games,
+whereas project settings are per-game / per-mod configuration. Turns
+out it's all a matter of loading the right configuration chunks at the
+right time.
+
+Proposed implementation:
+------------------------
+
+Use key/values (== property bags) based on XML format for everything.
+Use them on project settings, and user prefs. The only difference
+between what would be project settings and what would be user pref
+is in which game configuration they are loaded, and how they are used.
+
+Project templates: We have a particular syntax to build settings from
+a 'template' version. Instead of loading a project template, we should
+be selecting a template from a list.
+
+Default startup: If we are configured to load last project on startup,
+load it .. otherwise display a list of games and templates?
+
+Module library:
+---------------
+
+The dynamic loading / interfaces sharing / pure virtual classes needs
+to be implemented in a generic module. It should be the basis of the
+editor startup process.
-** currently supported debug messages:\r
-\r
-* map leaked / pointfile information\r
-+ tested\r
-\r
-* duplicate plane\r
-+ tested\r
-\r
-* degenerate plane, mirrored plane\r
-+ testing may not be necessary, exact same code as duplicate plane\r
-\r
-* mixed CONTENTS_DETAIL and CONTENTS_STRUCTURAL\r
-- not tested!\r
-\r
-* fog brush has multiple visible sides\r
-+ tested\r
-\r
-* WindingFromDrawSurf failed: MAX_POINTS_ON_WINDING exceeded\r
-+ tested, only outputs a single point, would need much improvement\r
- (TstMaps/western.map)\r
-\r
-* MAX_BUILD_SIDES\r
-uses xml_Select as other warnings, switched xml_Select to error or warn\r
-+ tested\r
-\r
-** to-be-added list (and associated test map file if any)\r
-\r
-* Node without a volume\r
-* leaf with too many portals\r
--> both in Desktop_p_leaf.map, contributed by y_lavanant@vistech.ie\r
-\r
-Mesh lightmap miscount\r
+** currently supported debug messages:
+
+* map leaked / pointfile information
++ tested
+
+* duplicate plane
++ tested
+
+* degenerate plane, mirrored plane
++ testing may not be necessary, exact same code as duplicate plane
+
+* mixed CONTENTS_DETAIL and CONTENTS_STRUCTURAL
+- not tested!
+
+* fog brush has multiple visible sides
++ tested
+
+* WindingFromDrawSurf failed: MAX_POINTS_ON_WINDING exceeded
++ tested, only outputs a single point, would need much improvement
+ (TstMaps/western.map)
+
+* MAX_BUILD_SIDES
+uses xml_Select as other warnings, switched xml_Select to error or warn
++ tested
+
+** to-be-added list (and associated test map file if any)
+
+* Node without a volume
+* leaf with too many portals
+-> both in Desktop_p_leaf.map, contributed by y_lavanant@vistech.ie
+
+Mesh lightmap miscount
(no test map)
\ No newline at end of file
-\r
-\r
-Title: BSP Converter\r
-Version: 2.1h\r
-Date: 2001-03-28\r
-Author: Mr. Elusive\r
-\r
-\r
-Description\r
------------\r
-\r
-The BSPC tool is used to create AAS files from BSP files.\r
-An AAS file is a file with areas used by the Quake III Arena bot in order\r
-to navigate and understand a map. The Quake III Arena maps are stored in\r
-BSP files.\r
-\r
-\r
-Usage\r
------\r
-\r
-bspc [-<switch> [-<switch> ...]]\r
-\r
-Example 1: bspc -bsp2aas d:\quake3\baseq3\maps\mymap?.bsp\r
-Example 2: bspc -bsp2aas d:\quake3\baseq3\pak0.pk3\maps/q3dm*.bsp\r
-\r
-Switches:\r
- bsp2aas <[pakfilter/]filter.bsp> = convert BSP to AAS\r
- reach <filter.bsp> = compute reachability & clusters\r
- cluster <filter.aas> = compute clusters\r
- aasopt <filter.aas> = optimize aas file\r
- output <output path> = set output path\r
- threads <X> = set number of threads to X\r
- cfg <filename> = use this cfg file\r
- optimize = enable optimization\r
- noverbose = disable verbose output\r
- breadthfirst = breadth first bsp building\r
- nobrushmerge = don't merge brushes\r
- freetree = free the bsp tree\r
- nocsg = disables brush chopping\r
- forcesidesvisible = force all sides to be visible\r
- grapplereach = calculate grapple reachabilities\r
-\r
-\r
-Several metacharacter may be used in the filter and pakfilter.\r
-\r
-* match any string of zero or more characters\r
-? match any single character\r
-[abc...] match any of the enclosed characters; a hyphen can\r
- be used to specify a range (e.g. a-z, A-Z, 0-9)\r
-\r
-.pk3 files are accessed as if they are normal folders. For instance\r
-use "d:\quake3\baseq3\pak0.pk3\maps/q3dm1.bsp" to access the\r
-map q3dm1.bsp from the pak0.pk3 file. \r
-\r
-Multiple files may be listed after the switches bsp2map, bsp2aas, reach,\r
-cluster and aasopt.\r
-\r
-If a BSP file is being converted to an AAS file and no output path\r
-is entered on the command-line then the AAS file will automatically\r
-be stored in the same folder as the BSP file. However if the BSP file\r
-was stored in a .pk3 file then the AAS file will be stored in a folder\r
-with the name 'maps' outside the .pk3 file.\r
-\r
-\r
-Updating entity lump\r
---------------------\r
-\r
-If an AAS file is already available for a BSP file and you ONLY change\r
-the entities inside this BSP file then you only have to recalculate the\r
-reachabilities. This way you can move items, platforms etc. around\r
-without the need to recalculate the whole AAS file which can save quite\r
-some compile time. You can recalculate the reachabilities as follows:\r
-\r
-bspc -reach mymap.bsp\r
-\r
-Where mymap.bsp is the BSP file. The mymap.aas file has to be in the\r
-same folder as mymap.bsp or should be in the output folder specified\r
-with the -output option.\r
-\r
-Keep in mind that as soon as ANY geometry in the map changes the whole\r
-AAS file HAS to be recalculated in order to play with bots.\r
-\r
-NOTE: -reach does not work on optimized .AAS files!\r
-NOTE: don't use -reach when moving the position of doors.\r
-\r
-\r
-Leaks\r
------\r
-\r
-Just like there can be vis leaks in a map there can also be clipping\r
-leaks. Two things can be wrong when the BSPC tool outputs that a map\r
-leaks.\r
-\r
-1. There are no entities in the map at all, or all entities that are\r
-actually in the map are placed in solid. In this case the BSPC tool\r
-outputs "WARNING: no entities inside". (At least a player start entity\r
-is needed to load a map.)\r
-\r
-2. There is a spot in the map where players can go outside the map\r
-into the void. This is bad, players should never be able to fall out\r
-of a level. In this case the BSPC tool outputs "WARNING: entity\r
-reached from outside". The BSPC tool also writes a mymap.lin file\r
-that can be loaded in the Q3Radiant editor to show lines that go\r
-through the actual leak.\r
-\r
-Make sure the .lin file is stored in the same folder as where q3radiant\r
-stores the .bsp file. Load the map in q3radiant and use the\r
-menu -> File -> Pointfile... to load the .lin file. A thick red line\r
-will be shown in the map. Follow this line to find the leak.\r
-\r
-\r
-Map bounds\r
-----------\r
-\r
-Currently a map should be within the bounds (-65536, -65536, -65536) -\r
-(65536, 65536, 65536) for the bspc tool to compile. These are the same\r
-limits the q3map tool has.\r
-\r
-\r
-Physics\r
--------\r
-\r
-The player bounding box is a 30 units by 30 units square with a height\r
-of 56 units. If we assume 1.75 meters being the average height of a human\r
-and a player in Quake III Arena being 56 units high we get 32 units = 1 meter.\r
-\r
-Maximum step height of a player is 18 units (just keep steps 16 units or\r
-lower).\r
-\r
-The maximum water jump height for bots has been set to 18 units. (height\r
-difference between water surface and the floor jumping onto). If the\r
-waterjump height is made higher human players will have a hard time getting\r
-out of the water.\r
-\r
-With normal gravity and without the quad the maximum rocket jump height is\r
-around 280 units (you can sometimes jump a few units higher but this is a\r
-safe value for reference).\r
-\r
-The maximum height for barriers the bots will jump on is 32 units.\r
-\r
-Some math to calculate some other values of interest:\r
-\r
-gravity = 800;\r
-jump velocity = 270;\r
-max vertical rocketjump velocity = 670;\r
-max run velocity = 320;\r
-max step height = 18;\r
-\r
-max jump height = 0.5 * gravity * (jumpvelocity/gravity)*(jumpvelocity/gravity);\r
-max jump height = 45 units;\r
-NOTE: even though this is the mathematical maximum jump height always keep\r
-the the 32 units maximum barrier height for bots in mind when building maps.\r
-\r
-maximum horizontal jump distance over a gap from one spot to another both\r
-at the same height:\r
-\r
-t = sqrt((maxjumpheight + maxstep) / (0.5 * gravity));\r
-t = 0.3986 seconds;\r
-dist = maxrunvelocity * (t + jumpvelocity / gravity);\r
-dist = 235 units;\r
-Because players use a bounding box we can jump a full bounding box width\r
-furter in the ideal case. (15 units at the jump start and 15 at the\r
-landing place).\r
-235 + 15 + 15 = 265 units.\r
-Again this is the mathematical maximum which players can only reach under\r
-ideal circumstances.\r
-\r
-\r
-Optimizing a map for bspc\r
--------------------------\r
-\r
-Hint brushes have no effect on the bspc tool. Only solid, clip, liquid,\r
-cluster portal and do not enter brushes are used by the bspc tool.\r
-\r
-The bspc tool outputs how many areas are created for a map. Less areas\r
-is better. Often the number of areas can be reduced by adding additional\r
-clip brushes. By adding these additional clip brushes the complexity\r
-of the geometry used for collision can be reduced. Do not add clip\r
-brushes in front of the complex geometry but get the complex shaped\r
-geometry contained within these clip brushes. Things that should be\r
-contained within clip brushes are small or complex shaped (often detail)\r
-brushes and complex and twisted curves, but also more regular curves\r
-can be placed within a clip brush. When containing a curve within a\r
-clip brush it's preferred to place the whole curve within the clip\r
-brush (not just part of the curve).\r
-Note: you can make brushes or curves non-solid when they are contained\r
-within *full* clip or *weap* clip brushes to speed up bspc calculations.\r
-\r
-Always try to align your geometry to the grids. Always use the largest\r
-grid possible for alignment of your geometry. Also try to align the\r
-back sides of brushes which may not be visible. The more brush sides\r
-are aligned the better. This will also speed up bspc calculations.\r
-\r
-Align adjacent brushes as much as possible. Make sure no tiny faces are\r
-created due to badly aligned brushes.\r
-\r
-Quite often there are places in a map that are visible to players\r
-but that players can never get to. Players would be able to walk around there\r
-but since players can never reach such places they will never actually\r
-move around there. If players are never able to get to such places\r
-it's better to put a large clip brush which encloses that whole space.\r
-This will also speed up bspc calculations and reduce the number of areas\r
-created by the bspc tool.\r
-\r
-Note: the number of areas relative to the map size tells something about\r
-the navigation complexity for players in general (also human players).\r
-Reducing the collision complexity for bots also makes the map easier to\r
-navigate for human players\r
-\r
-\r
-func_plat and func_bobbing\r
---------------------------\r
-\r
-When func_plat or func_bobbing entities are placed in a map the bots will\r
-use them if possible. The bots assume they can stand on top of the bounding\r
-box of the model used for the func_plat or func_bobbing entity. As a result\r
-creating complex shaped func_plat or func_bobbing models is mostly a bad\r
-idea. You have to make sure the bots (and players) can actually stand\r
-everywhere ontop of the bounding box of the model.\r
-\r
-\r
-Cluster Portals\r
----------------\r
-\r
-A map is divided into areas. Several of these areas can be grouped together\r
-to create a cluster. The clusters are seperated by cluster portals which are\r
-areas themselves. One of the things the bot uses these clusters for is a\r
-multi-level routing algorithm. When a map is efficiently divided up into\r
-clusters bot calculations will be faster.\r
-\r
-several things to take into account:\r
-\r
-- The BSPC tool tries to create cluster portals automatically but additional\r
- cluster portals can be created by placing "clusterportal" brushes.\r
-- Cluster portals are manually created by placing "clusterportal" brushes\r
- inside the map.\r
-- Cluster portal brushes are a tool to optimize a map for CPU usage by the\r
- bots. They are not needed for the bots to operate correctly.\r
-- The "clusterportal" brushes should not be used outside the world hull.\r
-- The cluster portals do not have any effect on vis.\r
-- If a door is already sealed with an areaportal brush, a clusterportal is\r
- not necessary there. (area portals are also used as cluster portals).\r
-- Just like the area portals, the cluster portals must seal a space off\r
- entirely from other areas.\r
-- The cluster portal areas should seal off a cluster in a way that the only\r
- path towards another cluster is through a cluster portal area.\r
-- Only create cluster portals where people can walk or swim through.\r
-- Don't create cluster portals in gaps in the floor. (people would fall through)\r
-- If you have two sealed off clusters and you add a teleporter between them\r
- then the two clusters will be merged again because of the teleporter.\r
-- Cluster portals must seperate no more and no less than two (2) clusters.\r
-- Try to create clusters with all the same number of 'reachability' areas.\r
- for instance if the map has 5400 areas try to create 10 clusters with 540\r
- areas each, or 12 clusters with 450 areas each, etc. The BSPC tool lists\r
- the number of reachability areas in each cluster.\r
- With Q3A version 1.25 and up you can use /set bot_testclusters 1 on the\r
- console and the area number and cluster number you're in will be printed\r
- on the screen. These cluster number correspond to the cluster numbers\r
- the BSPC tool prints.\r
-- Minimize the number of clusters with only a few (less than 10) areas.\r
-- When adding "cluster portal" brushes try to place them in places with\r
- minimal geometric complexity. For instance place them inside convex door\r
- openings or small hallways (not infront of door openings). Ideally the shape\r
- of the face through which a player walks or swims into the cluster portal\r
- is the same as the shape of the face through which a player leaves the\r
- cluster portal. Also ideally the open space inside the cluster portal\r
- brush is convex.\r
-- Make cluster portals about 16 or 32 units thick or align them with\r
- adjacent geometry. Don't make them too thick though.\r
-- Minimize the total number of cluster portal areas at all times. The more\r
- cluster portal areas you have the more CPU the bots need.\r
-- Items have no effect at all on the creation of areas or clusters.\r
- The same goes for item_botroam.\r
-\r
-\r
-Do Not Enter areas\r
-------------------\r
-\r
-When bot navigation problems show up or you want to make sure a bot never tries\r
-to go to a certain place "do not enter" brushes can be used.\r
-\r
-several things to take into account:\r
-\r
-- The "do not enter" brushes should not be used outside the world hull.\r
-- The "do not enter" brush is Not a clip brush for the bot.\r
-- The "do not enter" brush is a tool of last resort. Do not use it unless\r
- there are serious navigation problems.\r
-- The number of "do not enter" brushes should be minimized because these\r
- brushes create additional areas for the bots.\r
-- The "do not enter" brush will create a New area that the bot will try to\r
- avoid. However if the bot somehow ends up in a "do not enter" area or there\r
- is a valid goal inside the "do not enter" area then the bot is allowed to\r
- go into and out of that area. So if the bot somehow gets in a "do not enter"\r
- area the bot will be able to get out.\r
-\r
-\r
-Bot roaming\r
------------\r
-\r
-The item_botroam entity can be used when a bot does not roam the whole level\r
-or prefers to go to only specific areas. This (invisible) item can be placed\r
-in a map just like regular items. Nobody can actually pick up the item it's\r
-only used to attract bots to certain places of the map. The item_botroam has\r
-a key "origin". The value is set by Q3Radiant automatically. The item_botroam\r
-also has a key "weight". The value is the weight of the roam item and is\r
-relative to the weight of other items in the map. The bot character specific\r
-item weights are stored with the bot characters in the botfiles/bots/ sub-folder\r
-in the .pk3 file. The value of the weight is a non-zero floating point value,\r
-most often in the range 0 to 400. (Higher values are allowed but keep in mind\r
-that the bot should also still go for normal items, so don't make the\r
-item_botroam weight to high.)\r
-\r
-When a bot should never go for a specific item the key "notbot" with value "1"\r
-can be used for that item. This key with value can be used for every available\r
-item in Quake III Arena.\r
-\r
-The suspended flag can be used on all items (item_botroam included).\r
-However keep in mind that when a suspended item is not anywhere near the\r
-ground the bot will ONLY try to go for this suspended item using jump pads.\r
-\r
-\r
-Team based entities\r
--------------------\r
-\r
-You can use the "bot_notteam" entity key with value "1" or "2" on teleporters\r
-(trigger_teleport or trigger_multiple pointing at a target_teleporter),\r
-elevators (func_plat), cyclic movers (func_bobbing), jumppads (trigger_push)\r
-and areas that hurt the player (trigger_hurt).\r
-When "notteam" is set to "1" only bots using the travel flag TFL_NOTTEAM1 will\r
-use the entity or move through the area. When "bot_notteam" is set to "2" only\r
-bots using the travel flag TFL_NOTTEAM2 will use the entity or move through the\r
-area. These travel flags can be used in the game source code. Using this entity\r
-key also only has effect if the mod the map is being made for supports team based\r
-navigation for bots.\r
-\r
-\r
-Testing AAS files\r
------------------\r
-\r
-One of the easiest ways to test the AAS file is to load the map in\r
-Quake3 in teamplay mode (type /set g_gametype 3 on the console before\r
-loading the map). Enter a team and add a bot to your team. Use the\r
-team order menu (by default bound to the key F3) to command the bot\r
-to follow you. Walk around the map and see if the bot is able to\r
-follow you everywhere.\r
-\r
-Map bugs can sometimes cause certain places in the map to show up\r
-'solid' in the AAS file. The bots cannot travel through these 'solid'\r
-areas. To test for these 'solid' places set the cvar bot_testsolid\r
-to 1 on the console. (type /set bot_testsolid 1) The map has to be\r
-started with devmap instead of map before the cvar bot_testsolid can\r
-be set. When the cvar is set to 1 then either "empty area" or\r
-"SOLID area" will be printed on the screen while traveling through a map.\r
-Several map bugs can cause these 'solid' places in the AAS file.\r
-- Sometimes microscopic brushes are left over after a brush CSG. Search\r
- for such brushes in the problem area and delete them.\r
-- Tiny brush faces (not curves) can also cause problems. Due to vertex\r
- snapping in the q3map tool those tiny brush faces can be snapped out\r
- of existence. Such faces will not show up in Quake3 and you'll see\r
- tiny peek holes or slits where you can view through the geometry.\r
- Allign vertexes of and edges of adjacent brushes to remove and avoid\r
- such tiny faces. Placing a clip brush in front of the face that is\r
- snapped out of existence will also remove the 'solid' area but ofcourse\r
- it's much better to remove the peek holes and slits.\r
-- Another cause could be a brush with a collapsed side. Check how many\r
- sides a brush has and how many sides actually have a surface. Rebuild\r
- brushes with collapsed sides.\r
-- All faces contained within liquid brushes using a shader without\r
- "surfaceparm trans" set will be removed. Those contained surfaces will\r
- not be visible and can cause the liquid to appear "solid" in the AAS file.\r
-\r
-If you insist creating an AAS file for a map with bugs then the option\r
--forcesidesvisible can be used. This should fix all the problems with areas\r
-showing up solid in the AAS file. However creating an AAS file with this\r
-option takes a lot longer (often more than twice the normal compile time).\r
-\r
-Clusters can be tested with the cvar bot_testclusters.\r
-(type "/set bot_testclusters 1" on the console)\r
-\r
-Jumppads can also be tested. Type the following on the Quake3 console\r
-before loading your map:\r
-\r
-/set bot_maxdebugpolys 1024\r
-/set bot_visualizejumppads 1\r
-/set bot_forcereachability 1\r
-\r
-Now load the map. A counter will be shown and goes from 0% to 100%.\r
-When the counter has reached 100% type /set bot_debug 1 and\r
-/set r_debugSurface 2 on the console. For every jumppad the\r
-default arch of travel (without using air control) will be visualized.\r
-This only works if your .aas file is not optimized.\r
-\r
-\r
-Error messages\r
---------------\r
-\r
-Level designers should not worry too much about the following messages and/or warnings. The things reported are non fatal and won't cause any major problems. Some of the messages are just debug left overs.\r
-\r
-"AAS_CheckArea: area %d face %d is flipped\n"\r
-"AAS_CheckArea: area %d center is %f %f %f\n"\r
-"AAS_CheckFaceWindingPlane: face %d winding plane unequal to face plane\r\n"\r
-"AAS_CheckFaceWindingPlane: face %d winding reversed\r\n"\r
-"area %d face %d flipped: front area %d, back area %d\n"\r
-"area %d face %d is tiny\r\n"\r
-"face %d and %d, same front and back area but flipped planes\r\n"\r
-"AAS_SplitFace: tiny back face\r\n"\r
-"AAS_SplitFace: tiny back face\r\n"\r
-"AAS_SplitArea: front area without faces\n"\r
-"AAS_SplitArea: back area without faces\n"\r
-"gsubdiv: area %d has a tiny winding\r\n"\r
-"AAS_TestSplitPlane: tried face plane as splitter\n"\r
-"found %d epsilon faces trying to split area %d\r\n"\r
-"AAS_SplitArea: front area without faces\n"\r
-"AAS_GetFace: face %d had degenerate edge %d-%d\r\n"\r
-"AAS_GetFace: face %d was tiny\r\n"\r
-"WARNING: huge winding\n"\r
-"bogus brush after clip"\r
-"split removed brush"\r
-"split not on both sides"\r
-"two tiny brushes\r\n"\r
-"possible portal: %d\r\n"\r
-"portal %d: area %d\r\n"\r
-"WARNING: CM_GridPlane unresolvable\n"\r
-"WARNING: CM_AddFacetBevels... invalid bevel\n"\r
-"WARNING: CM_SetBorderInward: mixed plane sides\n"\r
-"WARNING: bevel plane already used\n"\r
-"trigger_multiple model = \"%s\"\n"\r
-"trigger_teleport model = \"%s\"\n"\r
-"found a trigger_push with velocity %f %f %f\n"\r
-"AAS_TraceBoundingBox: stack overflow\n"\r
-"AAS_TraceAreas: stack overflow\n"\r
-"AAS_LinkEntity: stack overflow\n"\r
-"MergeWindings: degenerate edge on winding %f %f %f\n"\r
-"Warning: MergeWindings: front to back found twice\n"\r
-"FindPlaneSeperatingWindings: winding1 non-convex\r\n"\r
-"FindPlaneSeperatingWindings: winding2 non-convex\r\n"\r
-\r
-\r
-When one of the following messages, errors or warnings is found then there is often something to be fixed.\r
-\r
-"WARNING! HashVec: point %f %f %f outside valid range\n"\r
-"This should never happen!\n"\r
- While storing the AAS file some vertex was found outside the valid map bounds. When this happens some part of the map is likely to have badly aligned brushes or weird shaped curves. Clipping off or rebuilding complex shapes often helps.\r
-"trigger_push start solid\n"\r
- The trigger_push start point is in solid. Try making the trigger_push brush a bit larger or move it around a bit.\r
-"trigger_push without target entity %s\n"\r
- Could not find the target entity of the trigger_push with the target field %s.\r
-"trigger_push without time\n"\r
- trigger_push entity found without "time" field.\r
-"trigger_multiple not in any jump pad area\n"\r
-"trigger_push not in any jump pad area\n"\r
- A trigger_push entity was found not to be in any valid jumppad area. (the message states trigger_multiple but it should have been trigger_push) Try making the trigger_push brush a bit larger or move it around a bit.\r
-"trigger_multiple at %1.0f %1.0f %1.0f without target\n"\r
- A trigger multiple was found at the given coordinates without a "target" field.\r
-"target_teleporter without target\n"\r
- A target_teleporter entity was found without target field.\r
-"trigger_teleport at %1.0f %1.0f %1.0f without target\n"\r
- A trigger_teleport entity was found at the given coordinates without "target" field.\r
-"teleporter without misc_teleporter_dest (%s)\n"\r
- The destination of a teleporter with target field %s could not be found.\r
-"teleporter destination (%s) without origin\n"\r
- A teleporter destination with the target name %s was found without origin field.\r
-"teleporter destination (%s) in solid\n"\r
- A teleporter destination with the targetname %s was found to be in solid.\r
-"teleported into slime or lava at dest %s\n"\r
- A player would be pushed into slime or lave at the teleporter destination with the targetname %s.\r
-"trigger_multiple not in any area\n"\r
- A teleporter trigger was found not to be in any valid area. Try moving the trigger around a bit.\r
-"func_plat without model\n"\r
- A func_plat entity was found without model field.\r
-"func_plat with invalid model number\n"\r
- A func_plat entity was found with the model field set to some invalid number.\r
-"func_bobbing without model\n"\r
- A func_bobbing entity was found without model field.\r
-"func_bobbing with invalid model number\n"\r
- A func_bobbing entity was found with the model field set to some invalid number.\r
-"%s in solid at (%1.1f %1.1f %1.1f)\n"\r
- An item with classname %s was found to be in solid at the given coordinates.\r
-"empty aas link heap\n"\r
- Some part of the map has some rather complex clipping. Reduce the geometric complexity or use clip brushes to reduce the clipping complexity.\r
-"too many entities in BSP file\n"\r
- There are too many entities in the bsp file.\r
-"error opening %s\n"\r
- Could not create a new AAS file. Hard disk might be full.\r
-"error writing lump %s\n"\r
- Could not write an AAS lump to file. Hard disk might be full.\r
-\r
-\r
-\r
-Version Changes\r
----------------\r
-\r
-2.1h (2001-03-28)\r
-\r
-- fixed crash bug\r
-\r
-2.1g (2001-02-18)\r
-\r
-- added bot_notteam support on trigger_hurt entities\r
-\r
-\r
-2.1f (2001-02-06)\r
-\r
-- added some AAS statistics\r
-- don't flood through faces when creating clusters\r
-\r
-\r
-2.1e (2001-01-10)\r
-\r
-- fix map size limitation\r
-\r
-\r
-2.1d (2000-12-17)\r
-\r
-- renamed "notteam" to "bot_notteam"\r
-\r
-\r
-2.1c (2000-11-02)\r
-\r
-- added fs_maxfallheight\r
-- compiled with larger map size bounds\r
-\r
-\r
-2.1b (2000-09-15)\r
-\r
-- fixed cfg file loading\r
-\r
-\r
-2.1 (2000-06-28)\r
-\r
-- added model numbers for AREACONTENTS_MOVER\r
-- added team based func_plat, func_bobbing, trigger_teleport and trigger_push reachabilities\r
-\r
-\r
-2.0 (2000-06-21)\r
-\r
-- fixed swim reachabilities\r
-- fixed some reachabilities through cluster portals\r
-- fixed jump reachabilities\r
-- changed some start travel times\r
-- added travel time settings to cfg\r
-\r
-\r
-1.9 (2000-03-27)\r
-\r
-- fixed func_bobbing entities with origin brush\r
-\r
-\r
-1.8 (2000-01-14)\r
-\r
-- fixed trigger_teleport bug.\r
-- increased max map bounds to (-8192, -8192, -8192)-(8192, 8192, 8192)\r
-- increased max points on winding\r
-- made "HashVec: point x y z outside valid range" non-fatal\r
-- fixed rocket jump reachabilities\r
-- added force sides visible option\r
-- increased simulated stack size for area traces\r
-\r
-\r
-1.7 (1999-12-22)\r
-\r
-- fixed ducked bounding box size\r
-- fixed sv_maxsteepness being zero in aas configuration\r
-- AAS files are now automatically stored in BSP file folder\r
-- fixed crash bug caused by overflow of a simulated stack\r
+
+
+Title: BSP Converter
+Version: 2.1h
+Date: 2001-03-28
+Author: Mr. Elusive
+
+
+Description
+-----------
+
+The BSPC tool is used to create AAS files from BSP files.
+An AAS file is a file with areas used by the Quake III Arena bot in order
+to navigate and understand a map. The Quake III Arena maps are stored in
+BSP files.
+
+
+Usage
+-----
+
+bspc [-<switch> [-<switch> ...]]
+
+Example 1: bspc -bsp2aas d:\quake3\baseq3\maps\mymap?.bsp
+Example 2: bspc -bsp2aas d:\quake3\baseq3\pak0.pk3\maps/q3dm*.bsp
+
+Switches:
+ bsp2aas <[pakfilter/]filter.bsp> = convert BSP to AAS
+ reach <filter.bsp> = compute reachability & clusters
+ cluster <filter.aas> = compute clusters
+ aasopt <filter.aas> = optimize aas file
+ output <output path> = set output path
+ threads <X> = set number of threads to X
+ cfg <filename> = use this cfg file
+ optimize = enable optimization
+ noverbose = disable verbose output
+ breadthfirst = breadth first bsp building
+ nobrushmerge = don't merge brushes
+ freetree = free the bsp tree
+ nocsg = disables brush chopping
+ forcesidesvisible = force all sides to be visible
+ grapplereach = calculate grapple reachabilities
+
+
+Several metacharacter may be used in the filter and pakfilter.
+
+* match any string of zero or more characters
+? match any single character
+[abc...] match any of the enclosed characters; a hyphen can
+ be used to specify a range (e.g. a-z, A-Z, 0-9)
+
+.pk3 files are accessed as if they are normal folders. For instance
+use "d:\quake3\baseq3\pak0.pk3\maps/q3dm1.bsp" to access the
+map q3dm1.bsp from the pak0.pk3 file.
+
+Multiple files may be listed after the switches bsp2map, bsp2aas, reach,
+cluster and aasopt.
+
+If a BSP file is being converted to an AAS file and no output path
+is entered on the command-line then the AAS file will automatically
+be stored in the same folder as the BSP file. However if the BSP file
+was stored in a .pk3 file then the AAS file will be stored in a folder
+with the name 'maps' outside the .pk3 file.
+
+
+Updating entity lump
+--------------------
+
+If an AAS file is already available for a BSP file and you ONLY change
+the entities inside this BSP file then you only have to recalculate the
+reachabilities. This way you can move items, platforms etc. around
+without the need to recalculate the whole AAS file which can save quite
+some compile time. You can recalculate the reachabilities as follows:
+
+bspc -reach mymap.bsp
+
+Where mymap.bsp is the BSP file. The mymap.aas file has to be in the
+same folder as mymap.bsp or should be in the output folder specified
+with the -output option.
+
+Keep in mind that as soon as ANY geometry in the map changes the whole
+AAS file HAS to be recalculated in order to play with bots.
+
+NOTE: -reach does not work on optimized .AAS files!
+NOTE: don't use -reach when moving the position of doors.
+
+
+Leaks
+-----
+
+Just like there can be vis leaks in a map there can also be clipping
+leaks. Two things can be wrong when the BSPC tool outputs that a map
+leaks.
+
+1. There are no entities in the map at all, or all entities that are
+actually in the map are placed in solid. In this case the BSPC tool
+outputs "WARNING: no entities inside". (At least a player start entity
+is needed to load a map.)
+
+2. There is a spot in the map where players can go outside the map
+into the void. This is bad, players should never be able to fall out
+of a level. In this case the BSPC tool outputs "WARNING: entity
+reached from outside". The BSPC tool also writes a mymap.lin file
+that can be loaded in the Q3Radiant editor to show lines that go
+through the actual leak.
+
+Make sure the .lin file is stored in the same folder as where q3radiant
+stores the .bsp file. Load the map in q3radiant and use the
+menu -> File -> Pointfile... to load the .lin file. A thick red line
+will be shown in the map. Follow this line to find the leak.
+
+
+Map bounds
+----------
+
+Currently a map should be within the bounds (-65536, -65536, -65536) -
+(65536, 65536, 65536) for the bspc tool to compile. These are the same
+limits the q3map tool has.
+
+
+Physics
+-------
+
+The player bounding box is a 30 units by 30 units square with a height
+of 56 units. If we assume 1.75 meters being the average height of a human
+and a player in Quake III Arena being 56 units high we get 32 units = 1 meter.
+
+Maximum step height of a player is 18 units (just keep steps 16 units or
+lower).
+
+The maximum water jump height for bots has been set to 18 units. (height
+difference between water surface and the floor jumping onto). If the
+waterjump height is made higher human players will have a hard time getting
+out of the water.
+
+With normal gravity and without the quad the maximum rocket jump height is
+around 280 units (you can sometimes jump a few units higher but this is a
+safe value for reference).
+
+The maximum height for barriers the bots will jump on is 32 units.
+
+Some math to calculate some other values of interest:
+
+gravity = 800;
+jump velocity = 270;
+max vertical rocketjump velocity = 670;
+max run velocity = 320;
+max step height = 18;
+
+max jump height = 0.5 * gravity * (jumpvelocity/gravity)*(jumpvelocity/gravity);
+max jump height = 45 units;
+NOTE: even though this is the mathematical maximum jump height always keep
+the the 32 units maximum barrier height for bots in mind when building maps.
+
+maximum horizontal jump distance over a gap from one spot to another both
+at the same height:
+
+t = sqrt((maxjumpheight + maxstep) / (0.5 * gravity));
+t = 0.3986 seconds;
+dist = maxrunvelocity * (t + jumpvelocity / gravity);
+dist = 235 units;
+Because players use a bounding box we can jump a full bounding box width
+furter in the ideal case. (15 units at the jump start and 15 at the
+landing place).
+235 + 15 + 15 = 265 units.
+Again this is the mathematical maximum which players can only reach under
+ideal circumstances.
+
+
+Optimizing a map for bspc
+-------------------------
+
+Hint brushes have no effect on the bspc tool. Only solid, clip, liquid,
+cluster portal and do not enter brushes are used by the bspc tool.
+
+The bspc tool outputs how many areas are created for a map. Less areas
+is better. Often the number of areas can be reduced by adding additional
+clip brushes. By adding these additional clip brushes the complexity
+of the geometry used for collision can be reduced. Do not add clip
+brushes in front of the complex geometry but get the complex shaped
+geometry contained within these clip brushes. Things that should be
+contained within clip brushes are small or complex shaped (often detail)
+brushes and complex and twisted curves, but also more regular curves
+can be placed within a clip brush. When containing a curve within a
+clip brush it's preferred to place the whole curve within the clip
+brush (not just part of the curve).
+Note: you can make brushes or curves non-solid when they are contained
+within *full* clip or *weap* clip brushes to speed up bspc calculations.
+
+Always try to align your geometry to the grids. Always use the largest
+grid possible for alignment of your geometry. Also try to align the
+back sides of brushes which may not be visible. The more brush sides
+are aligned the better. This will also speed up bspc calculations.
+
+Align adjacent brushes as much as possible. Make sure no tiny faces are
+created due to badly aligned brushes.
+
+Quite often there are places in a map that are visible to players
+but that players can never get to. Players would be able to walk around there
+but since players can never reach such places they will never actually
+move around there. If players are never able to get to such places
+it's better to put a large clip brush which encloses that whole space.
+This will also speed up bspc calculations and reduce the number of areas
+created by the bspc tool.
+
+Note: the number of areas relative to the map size tells something about
+the navigation complexity for players in general (also human players).
+Reducing the collision complexity for bots also makes the map easier to
+navigate for human players
+
+
+func_plat and func_bobbing
+--------------------------
+
+When func_plat or func_bobbing entities are placed in a map the bots will
+use them if possible. The bots assume they can stand on top of the bounding
+box of the model used for the func_plat or func_bobbing entity. As a result
+creating complex shaped func_plat or func_bobbing models is mostly a bad
+idea. You have to make sure the bots (and players) can actually stand
+everywhere ontop of the bounding box of the model.
+
+
+Cluster Portals
+---------------
+
+A map is divided into areas. Several of these areas can be grouped together
+to create a cluster. The clusters are seperated by cluster portals which are
+areas themselves. One of the things the bot uses these clusters for is a
+multi-level routing algorithm. When a map is efficiently divided up into
+clusters bot calculations will be faster.
+
+several things to take into account:
+
+- The BSPC tool tries to create cluster portals automatically but additional
+ cluster portals can be created by placing "clusterportal" brushes.
+- Cluster portals are manually created by placing "clusterportal" brushes
+ inside the map.
+- Cluster portal brushes are a tool to optimize a map for CPU usage by the
+ bots. They are not needed for the bots to operate correctly.
+- The "clusterportal" brushes should not be used outside the world hull.
+- The cluster portals do not have any effect on vis.
+- If a door is already sealed with an areaportal brush, a clusterportal is
+ not necessary there. (area portals are also used as cluster portals).
+- Just like the area portals, the cluster portals must seal a space off
+ entirely from other areas.
+- The cluster portal areas should seal off a cluster in a way that the only
+ path towards another cluster is through a cluster portal area.
+- Only create cluster portals where people can walk or swim through.
+- Don't create cluster portals in gaps in the floor. (people would fall through)
+- If you have two sealed off clusters and you add a teleporter between them
+ then the two clusters will be merged again because of the teleporter.
+- Cluster portals must seperate no more and no less than two (2) clusters.
+- Try to create clusters with all the same number of 'reachability' areas.
+ for instance if the map has 5400 areas try to create 10 clusters with 540
+ areas each, or 12 clusters with 450 areas each, etc. The BSPC tool lists
+ the number of reachability areas in each cluster.
+ With Q3A version 1.25 and up you can use /set bot_testclusters 1 on the
+ console and the area number and cluster number you're in will be printed
+ on the screen. These cluster number correspond to the cluster numbers
+ the BSPC tool prints.
+- Minimize the number of clusters with only a few (less than 10) areas.
+- When adding "cluster portal" brushes try to place them in places with
+ minimal geometric complexity. For instance place them inside convex door
+ openings or small hallways (not infront of door openings). Ideally the shape
+ of the face through which a player walks or swims into the cluster portal
+ is the same as the shape of the face through which a player leaves the
+ cluster portal. Also ideally the open space inside the cluster portal
+ brush is convex.
+- Make cluster portals about 16 or 32 units thick or align them with
+ adjacent geometry. Don't make them too thick though.
+- Minimize the total number of cluster portal areas at all times. The more
+ cluster portal areas you have the more CPU the bots need.
+- Items have no effect at all on the creation of areas or clusters.
+ The same goes for item_botroam.
+
+
+Do Not Enter areas
+------------------
+
+When bot navigation problems show up or you want to make sure a bot never tries
+to go to a certain place "do not enter" brushes can be used.
+
+several things to take into account:
+
+- The "do not enter" brushes should not be used outside the world hull.
+- The "do not enter" brush is Not a clip brush for the bot.
+- The "do not enter" brush is a tool of last resort. Do not use it unless
+ there are serious navigation problems.
+- The number of "do not enter" brushes should be minimized because these
+ brushes create additional areas for the bots.
+- The "do not enter" brush will create a New area that the bot will try to
+ avoid. However if the bot somehow ends up in a "do not enter" area or there
+ is a valid goal inside the "do not enter" area then the bot is allowed to
+ go into and out of that area. So if the bot somehow gets in a "do not enter"
+ area the bot will be able to get out.
+
+
+Bot roaming
+-----------
+
+The item_botroam entity can be used when a bot does not roam the whole level
+or prefers to go to only specific areas. This (invisible) item can be placed
+in a map just like regular items. Nobody can actually pick up the item it's
+only used to attract bots to certain places of the map. The item_botroam has
+a key "origin". The value is set by Q3Radiant automatically. The item_botroam
+also has a key "weight". The value is the weight of the roam item and is
+relative to the weight of other items in the map. The bot character specific
+item weights are stored with the bot characters in the botfiles/bots/ sub-folder
+in the .pk3 file. The value of the weight is a non-zero floating point value,
+most often in the range 0 to 400. (Higher values are allowed but keep in mind
+that the bot should also still go for normal items, so don't make the
+item_botroam weight to high.)
+
+When a bot should never go for a specific item the key "notbot" with value "1"
+can be used for that item. This key with value can be used for every available
+item in Quake III Arena.
+
+The suspended flag can be used on all items (item_botroam included).
+However keep in mind that when a suspended item is not anywhere near the
+ground the bot will ONLY try to go for this suspended item using jump pads.
+
+
+Team based entities
+-------------------
+
+You can use the "bot_notteam" entity key with value "1" or "2" on teleporters
+(trigger_teleport or trigger_multiple pointing at a target_teleporter),
+elevators (func_plat), cyclic movers (func_bobbing), jumppads (trigger_push)
+and areas that hurt the player (trigger_hurt).
+When "notteam" is set to "1" only bots using the travel flag TFL_NOTTEAM1 will
+use the entity or move through the area. When "bot_notteam" is set to "2" only
+bots using the travel flag TFL_NOTTEAM2 will use the entity or move through the
+area. These travel flags can be used in the game source code. Using this entity
+key also only has effect if the mod the map is being made for supports team based
+navigation for bots.
+
+
+Testing AAS files
+-----------------
+
+One of the easiest ways to test the AAS file is to load the map in
+Quake3 in teamplay mode (type /set g_gametype 3 on the console before
+loading the map). Enter a team and add a bot to your team. Use the
+team order menu (by default bound to the key F3) to command the bot
+to follow you. Walk around the map and see if the bot is able to
+follow you everywhere.
+
+Map bugs can sometimes cause certain places in the map to show up
+'solid' in the AAS file. The bots cannot travel through these 'solid'
+areas. To test for these 'solid' places set the cvar bot_testsolid
+to 1 on the console. (type /set bot_testsolid 1) The map has to be
+started with devmap instead of map before the cvar bot_testsolid can
+be set. When the cvar is set to 1 then either "empty area" or
+"SOLID area" will be printed on the screen while traveling through a map.
+Several map bugs can cause these 'solid' places in the AAS file.
+- Sometimes microscopic brushes are left over after a brush CSG. Search
+ for such brushes in the problem area and delete them.
+- Tiny brush faces (not curves) can also cause problems. Due to vertex
+ snapping in the q3map tool those tiny brush faces can be snapped out
+ of existence. Such faces will not show up in Quake3 and you'll see
+ tiny peek holes or slits where you can view through the geometry.
+ Allign vertexes of and edges of adjacent brushes to remove and avoid
+ such tiny faces. Placing a clip brush in front of the face that is
+ snapped out of existence will also remove the 'solid' area but ofcourse
+ it's much better to remove the peek holes and slits.
+- Another cause could be a brush with a collapsed side. Check how many
+ sides a brush has and how many sides actually have a surface. Rebuild
+ brushes with collapsed sides.
+- All faces contained within liquid brushes using a shader without
+ "surfaceparm trans" set will be removed. Those contained surfaces will
+ not be visible and can cause the liquid to appear "solid" in the AAS file.
+
+If you insist creating an AAS file for a map with bugs then the option
+-forcesidesvisible can be used. This should fix all the problems with areas
+showing up solid in the AAS file. However creating an AAS file with this
+option takes a lot longer (often more than twice the normal compile time).
+
+Clusters can be tested with the cvar bot_testclusters.
+(type "/set bot_testclusters 1" on the console)
+
+Jumppads can also be tested. Type the following on the Quake3 console
+before loading your map:
+
+/set bot_maxdebugpolys 1024
+/set bot_visualizejumppads 1
+/set bot_forcereachability 1
+
+Now load the map. A counter will be shown and goes from 0% to 100%.
+When the counter has reached 100% type /set bot_debug 1 and
+/set r_debugSurface 2 on the console. For every jumppad the
+default arch of travel (without using air control) will be visualized.
+This only works if your .aas file is not optimized.
+
+
+Error messages
+--------------
+
+Level designers should not worry too much about the following messages and/or warnings. The things reported are non fatal and won't cause any major problems. Some of the messages are just debug left overs.
+
+"AAS_CheckArea: area %d face %d is flipped\n"
+"AAS_CheckArea: area %d center is %f %f %f\n"
+"AAS_CheckFaceWindingPlane: face %d winding plane unequal to face plane\r\n"
+"AAS_CheckFaceWindingPlane: face %d winding reversed\r\n"
+"area %d face %d flipped: front area %d, back area %d\n"
+"area %d face %d is tiny\r\n"
+"face %d and %d, same front and back area but flipped planes\r\n"
+"AAS_SplitFace: tiny back face\r\n"
+"AAS_SplitFace: tiny back face\r\n"
+"AAS_SplitArea: front area without faces\n"
+"AAS_SplitArea: back area without faces\n"
+"gsubdiv: area %d has a tiny winding\r\n"
+"AAS_TestSplitPlane: tried face plane as splitter\n"
+"found %d epsilon faces trying to split area %d\r\n"
+"AAS_SplitArea: front area without faces\n"
+"AAS_GetFace: face %d had degenerate edge %d-%d\r\n"
+"AAS_GetFace: face %d was tiny\r\n"
+"WARNING: huge winding\n"
+"bogus brush after clip"
+"split removed brush"
+"split not on both sides"
+"two tiny brushes\r\n"
+"possible portal: %d\r\n"
+"portal %d: area %d\r\n"
+"WARNING: CM_GridPlane unresolvable\n"
+"WARNING: CM_AddFacetBevels... invalid bevel\n"
+"WARNING: CM_SetBorderInward: mixed plane sides\n"
+"WARNING: bevel plane already used\n"
+"trigger_multiple model = \"%s\"\n"
+"trigger_teleport model = \"%s\"\n"
+"found a trigger_push with velocity %f %f %f\n"
+"AAS_TraceBoundingBox: stack overflow\n"
+"AAS_TraceAreas: stack overflow\n"
+"AAS_LinkEntity: stack overflow\n"
+"MergeWindings: degenerate edge on winding %f %f %f\n"
+"Warning: MergeWindings: front to back found twice\n"
+"FindPlaneSeperatingWindings: winding1 non-convex\r\n"
+"FindPlaneSeperatingWindings: winding2 non-convex\r\n"
+
+
+When one of the following messages, errors or warnings is found then there is often something to be fixed.
+
+"WARNING! HashVec: point %f %f %f outside valid range\n"
+"This should never happen!\n"
+ While storing the AAS file some vertex was found outside the valid map bounds. When this happens some part of the map is likely to have badly aligned brushes or weird shaped curves. Clipping off or rebuilding complex shapes often helps.
+"trigger_push start solid\n"
+ The trigger_push start point is in solid. Try making the trigger_push brush a bit larger or move it around a bit.
+"trigger_push without target entity %s\n"
+ Could not find the target entity of the trigger_push with the target field %s.
+"trigger_push without time\n"
+ trigger_push entity found without "time" field.
+"trigger_multiple not in any jump pad area\n"
+"trigger_push not in any jump pad area\n"
+ A trigger_push entity was found not to be in any valid jumppad area. (the message states trigger_multiple but it should have been trigger_push) Try making the trigger_push brush a bit larger or move it around a bit.
+"trigger_multiple at %1.0f %1.0f %1.0f without target\n"
+ A trigger multiple was found at the given coordinates without a "target" field.
+"target_teleporter without target\n"
+ A target_teleporter entity was found without target field.
+"trigger_teleport at %1.0f %1.0f %1.0f without target\n"
+ A trigger_teleport entity was found at the given coordinates without "target" field.
+"teleporter without misc_teleporter_dest (%s)\n"
+ The destination of a teleporter with target field %s could not be found.
+"teleporter destination (%s) without origin\n"
+ A teleporter destination with the target name %s was found without origin field.
+"teleporter destination (%s) in solid\n"
+ A teleporter destination with the targetname %s was found to be in solid.
+"teleported into slime or lava at dest %s\n"
+ A player would be pushed into slime or lave at the teleporter destination with the targetname %s.
+"trigger_multiple not in any area\n"
+ A teleporter trigger was found not to be in any valid area. Try moving the trigger around a bit.
+"func_plat without model\n"
+ A func_plat entity was found without model field.
+"func_plat with invalid model number\n"
+ A func_plat entity was found with the model field set to some invalid number.
+"func_bobbing without model\n"
+ A func_bobbing entity was found without model field.
+"func_bobbing with invalid model number\n"
+ A func_bobbing entity was found with the model field set to some invalid number.
+"%s in solid at (%1.1f %1.1f %1.1f)\n"
+ An item with classname %s was found to be in solid at the given coordinates.
+"empty aas link heap\n"
+ Some part of the map has some rather complex clipping. Reduce the geometric complexity or use clip brushes to reduce the clipping complexity.
+"too many entities in BSP file\n"
+ There are too many entities in the bsp file.
+"error opening %s\n"
+ Could not create a new AAS file. Hard disk might be full.
+"error writing lump %s\n"
+ Could not write an AAS lump to file. Hard disk might be full.
+
+
+
+Version Changes
+---------------
+
+2.1h (2001-03-28)
+
+- fixed crash bug
+
+2.1g (2001-02-18)
+
+- added bot_notteam support on trigger_hurt entities
+
+
+2.1f (2001-02-06)
+
+- added some AAS statistics
+- don't flood through faces when creating clusters
+
+
+2.1e (2001-01-10)
+
+- fix map size limitation
+
+
+2.1d (2000-12-17)
+
+- renamed "notteam" to "bot_notteam"
+
+
+2.1c (2000-11-02)
+
+- added fs_maxfallheight
+- compiled with larger map size bounds
+
+
+2.1b (2000-09-15)
+
+- fixed cfg file loading
+
+
+2.1 (2000-06-28)
+
+- added model numbers for AREACONTENTS_MOVER
+- added team based func_plat, func_bobbing, trigger_teleport and trigger_push reachabilities
+
+
+2.0 (2000-06-21)
+
+- fixed swim reachabilities
+- fixed some reachabilities through cluster portals
+- fixed jump reachabilities
+- changed some start travel times
+- added travel time settings to cfg
+
+
+1.9 (2000-03-27)
+
+- fixed func_bobbing entities with origin brush
+
+
+1.8 (2000-01-14)
+
+- fixed trigger_teleport bug.
+- increased max map bounds to (-8192, -8192, -8192)-(8192, 8192, 8192)
+- increased max points on winding
+- made "HashVec: point x y z outside valid range" non-fatal
+- fixed rocket jump reachabilities
+- added force sides visible option
+- increased simulated stack size for area traces
+
+
+1.7 (1999-12-22)
+
+- fixed ducked bounding box size
+- fixed sv_maxsteepness being zero in aas configuration
+- AAS files are now automatically stored in BSP file folder
+- fixed crash bug caused by overflow of a simulated stack
-search orders with different settings\r
-\r
-\r
-=====================\r
-NON-TEAMPLAY\r
-=====================\r
-\r
--------------------------------------------------\r
-headmodel = *callisto/lily\r
-\r
-models/players/heads/callisto/lily/head_default.skin\r
-models/players/heads/callisto/head_lily.skin\r
-\r
-\r
--------------------------------------------------\r
-headmodel = callisto/lily\r
-\r
-models/players/callisto/lily/head_default.skin\r
-models/players/callisto/head_lily.skin\r
-models/players/heads/callisto/lily/head_default.skin\r
-models/players/heads/callisto/head_lily.skin\r
-\r
-\r
-\r
-=====================\r
-Q3 TEAMPLAY\r
-=====================\r
-\r
--------------------------------------------------\r
-team_headmodel = *callisto/lily\r
-team = red\r
-\r
-models/players/heads/callisto/lily/head_red.skin\r
-models/players/heads/callisto/head_red.skin\r
-\r
-\r
--------------------------------------------------\r
-team_headmodel = callisto/lily\r
-team = red\r
-\r
-models/players/callisto/lily/head_red.skin\r
-models/players/callisto/head_red.skin\r
-models/players/heads/callisto/lily/head_red.skin\r
-models/players/heads/callisto/head_red.skin\r
-\r
-\r
-\r
-=====================\r
-TA TEAMPLAY\r
-=====================\r
-\r
--------------------------------------------------\r
-team_headmodel = *callisto/lily\r
-team = red\r
-teamName = Stroggs\r
-\r
-models/players/heads/callisto/lily/Stroggs/head_red.skin\r
-models/players/heads/callisto/Stroggs/head_red.skin\r
-models/players/heads/callisto/lily/head_red.skin\r
-models/players/heads/callisto/head_red.skin\r
-\r
-\r
--------------------------------------------------\r
-team_headmodel = callisto/lily\r
-team = red\r
-teamName = Stroggs\r
-\r
-models/players/callisto/lily/Stroggs/head_red.skin\r
-models/players/callisto/Stroggs/head_red.skin\r
-models/players/callisto/lily/head_red.skin\r
-models/players/callisto/head_red.skin\r
-models/players/heads/callisto/lily/Stroggs/head_red.skin\r
-models/players/heads/callisto/Stroggs/head_red.skin\r
-models/players/heads/callisto/lily/head_red.skin\r
-models/players/heads/callisto/head_red.skin\r
+search orders with different settings
+
+
+=====================
+NON-TEAMPLAY
+=====================
+
+-------------------------------------------------
+headmodel = *callisto/lily
+
+models/players/heads/callisto/lily/head_default.skin
+models/players/heads/callisto/head_lily.skin
+
+
+-------------------------------------------------
+headmodel = callisto/lily
+
+models/players/callisto/lily/head_default.skin
+models/players/callisto/head_lily.skin
+models/players/heads/callisto/lily/head_default.skin
+models/players/heads/callisto/head_lily.skin
+
+
+
+=====================
+Q3 TEAMPLAY
+=====================
+
+-------------------------------------------------
+team_headmodel = *callisto/lily
+team = red
+
+models/players/heads/callisto/lily/head_red.skin
+models/players/heads/callisto/head_red.skin
+
+
+-------------------------------------------------
+team_headmodel = callisto/lily
+team = red
+
+models/players/callisto/lily/head_red.skin
+models/players/callisto/head_red.skin
+models/players/heads/callisto/lily/head_red.skin
+models/players/heads/callisto/head_red.skin
+
+
+
+=====================
+TA TEAMPLAY
+=====================
+
+-------------------------------------------------
+team_headmodel = *callisto/lily
+team = red
+teamName = Stroggs
+
+models/players/heads/callisto/lily/Stroggs/head_red.skin
+models/players/heads/callisto/Stroggs/head_red.skin
+models/players/heads/callisto/lily/head_red.skin
+models/players/heads/callisto/head_red.skin
+
+
+-------------------------------------------------
+team_headmodel = callisto/lily
+team = red
+teamName = Stroggs
+
+models/players/callisto/lily/Stroggs/head_red.skin
+models/players/callisto/Stroggs/head_red.skin
+models/players/callisto/lily/head_red.skin
+models/players/callisto/head_red.skin
+models/players/heads/callisto/lily/Stroggs/head_red.skin
+models/players/heads/callisto/Stroggs/head_red.skin
+models/players/heads/callisto/lily/head_red.skin
+models/players/heads/callisto/head_red.skin
-search orders with different settings\r
-\r
-\r
-=====================\r
-NON-TEAMPLAY\r
-=====================\r
-\r
--------------------------------------------------\r
-model = hunter/harpy\r
-\r
-\r
-legs:\r
- models/players/hunter/lower_harpy_default.skin\r
- models/players/hunter/lower_harpy.skin\r
- models/players/characters/james/lower_harpy_default.skin\r
- models/players/characters/james/lower_harpy.skin\r
-torso:\r
- models/players/hunter/upper_harpy_default.skin\r
- models/players/hunter/upper_harpy.skin\r
- models/players/characters/hunter/upper_harpy_default.skin\r
- models/players/characters/hunter/upper_harpy.skin\r
-\r
-\r
-=====================\r
-Q3 TEAMPLAY\r
-=====================\r
-\r
--------------------------------------------------\r
-team_model = hunter/harpy\r
-team = red\r
-\r
-legs:\r
- models/players/hunter/lower_harpy_red.skin\r
- models/players/hunter/lower_red.skin\r
- models/players/characters/hunter/lower_harpy_red.skin\r
- models/players/characters/hunter/lower_red.skin\r
-torso:\r
- models/players/hunter/upper_harpy_red.skin\r
- models/players/hunter/upper_red.skin\r
- models/players/characters/hunter/upper_harpy_red.skin\r
- models/players/characters/hunter/upper_red.skin\r
-\r
-\r
-=====================\r
-TA TEAMPLAY\r
-=====================\r
-\r
--------------------------------------------------\r
-team_model = james/badass\r
-team = red\r
-teamName = Stroggs\r
-\r
-legs:\r
- models/players/james/Stroggs/lower_badass_red.skin\r
- models/players/james/Stroggs/lower_red.skin\r
- models/players/james/lower_badass_red.skin\r
- models/players/james/lower_red.skin\r
- models/players/characters/james/Stroggs/lower_badass_red.skin\r
- models/players/characters/james/Stroggs/lower_red.skin\r
- models/players/characters/james/lower_badass_red.skin\r
- models/players/characters/james/lower_red.skin\r
-torso:\r
- models/players/james/Stroggs/upper_badass_red.skin\r
- models/players/james/Stroggs/upper_red.skin\r
- models/players/james/upper_badass_red.skin\r
- models/players/james/upper_red.skin\r
- models/players/characters/james/Stroggs/upper_badass_red.skin\r
- models/players/characters/james/Stroggs/upper_red.skin\r
- models/players/characters/james/upper_badass_red.skin\r
- models/players/characters/james/upper_red.skin\r
-\r
-\r
-\r
+search orders with different settings
+
+
+=====================
+NON-TEAMPLAY
+=====================
+
+-------------------------------------------------
+model = hunter/harpy
+
+
+legs:
+ models/players/hunter/lower_harpy_default.skin
+ models/players/hunter/lower_harpy.skin
+ models/players/characters/james/lower_harpy_default.skin
+ models/players/characters/james/lower_harpy.skin
+torso:
+ models/players/hunter/upper_harpy_default.skin
+ models/players/hunter/upper_harpy.skin
+ models/players/characters/hunter/upper_harpy_default.skin
+ models/players/characters/hunter/upper_harpy.skin
+
+
+=====================
+Q3 TEAMPLAY
+=====================
+
+-------------------------------------------------
+team_model = hunter/harpy
+team = red
+
+legs:
+ models/players/hunter/lower_harpy_red.skin
+ models/players/hunter/lower_red.skin
+ models/players/characters/hunter/lower_harpy_red.skin
+ models/players/characters/hunter/lower_red.skin
+torso:
+ models/players/hunter/upper_harpy_red.skin
+ models/players/hunter/upper_red.skin
+ models/players/characters/hunter/upper_harpy_red.skin
+ models/players/characters/hunter/upper_red.skin
+
+
+=====================
+TA TEAMPLAY
+=====================
+
+-------------------------------------------------
+team_model = james/badass
+team = red
+teamName = Stroggs
+
+legs:
+ models/players/james/Stroggs/lower_badass_red.skin
+ models/players/james/Stroggs/lower_red.skin
+ models/players/james/lower_badass_red.skin
+ models/players/james/lower_red.skin
+ models/players/characters/james/Stroggs/lower_badass_red.skin
+ models/players/characters/james/Stroggs/lower_red.skin
+ models/players/characters/james/lower_badass_red.skin
+ models/players/characters/james/lower_red.skin
+torso:
+ models/players/james/Stroggs/upper_badass_red.skin
+ models/players/james/Stroggs/upper_red.skin
+ models/players/james/upper_badass_red.skin
+ models/players/james/upper_red.skin
+ models/players/characters/james/Stroggs/upper_badass_red.skin
+ models/players/characters/james/Stroggs/upper_red.skin
+ models/players/characters/james/upper_badass_red.skin
+ models/players/characters/james/upper_red.skin
+
+
+
-#!/usr/bin/env python\r
-\r
-import os.path, sys, shutil\r
-\r
-def install_file( path, src_path, f ):\r
- src = os.path.join( src_path, f )\r
- dst = os.path.join( path, f )\r
- print '%s -> %s' % ( src, dst )\r
- shutil.copyfile( src, dst )\r
-\r
-def install( path, src_path ):\r
- for f in [ 'radiant.exe', 'radiant.pdb' ]:\r
- install_file( path, src_path, f )\r
- \r
- modules_path = os.path.join( path, 'modules' )\r
- try:\r
- os.makedirs( modules_path )\r
- except:\r
- pass\r
- assert( os.path.exists( modules_path ) )\r
-\r
- modules_src = os.path.join( src_path, 'modules' )\r
- assert( os.path.exists( modules_src ) )\r
-\r
- for e in os.listdir( modules_src ):\r
- if ( e[-4:] == '.dll' or e[-4:] == '.pdb' ):\r
- install_file( modules_path, modules_src, e )\r
- \r
- plugins_path = os.path.join( path, 'plugins' )\r
- try:\r
- os.makedirs( plugins_path )\r
- except:\r
- pass\r
- assert( os.path.exists( plugins_path ) )\r
- \r
- plugins_src = os.path.join( src_path, 'plugins' )\r
- assert( os.path.exists( plugins_src ) )\r
-\r
- for e in os.listdir( plugins_src ):\r
- if ( e[-4:] == '.dll' or e[-4:] == '.pdb' ):\r
- install_file( plugins_path, plugins_src, e )\r
-\r
-if __name__ == '__main__':\r
- if ( len( sys.argv ) <= 2 or not os.path.exists( sys.argv[1] ) or not os.path.exists( sys.argv[2] ) ):\r
- print 'usage: install [target directory] [source directory]'\r
- sys.exit(1) \r
- print 'Install %s into %s' % ( sys.argv[2], sys.argv[1] )\r
- install( sys.argv[1], sys.argv[2] )\r
+#!/usr/bin/env python
+
+import os.path, sys, shutil
+
+def install_file( path, src_path, f ):
+ src = os.path.join( src_path, f )
+ dst = os.path.join( path, f )
+ print '%s -> %s' % ( src, dst )
+ shutil.copyfile( src, dst )
+
+def install( path, src_path ):
+ for f in [ 'radiant.exe', 'radiant.pdb' ]:
+ install_file( path, src_path, f )
+
+ modules_path = os.path.join( path, 'modules' )
+ try:
+ os.makedirs( modules_path )
+ except:
+ pass
+ assert( os.path.exists( modules_path ) )
+
+ modules_src = os.path.join( src_path, 'modules' )
+ assert( os.path.exists( modules_src ) )
+
+ for e in os.listdir( modules_src ):
+ if ( e[-4:] == '.dll' or e[-4:] == '.pdb' ):
+ install_file( modules_path, modules_src, e )
+
+ plugins_path = os.path.join( path, 'plugins' )
+ try:
+ os.makedirs( plugins_path )
+ except:
+ pass
+ assert( os.path.exists( plugins_path ) )
+
+ plugins_src = os.path.join( src_path, 'plugins' )
+ assert( os.path.exists( plugins_src ) )
+
+ for e in os.listdir( plugins_src ):
+ if ( e[-4:] == '.dll' or e[-4:] == '.pdb' ):
+ install_file( plugins_path, plugins_src, e )
+
+if __name__ == '__main__':
+ if ( len( sys.argv ) <= 2 or not os.path.exists( sys.argv[1] ) or not os.path.exists( sys.argv[2] ) ):
+ print 'usage: install [target directory] [source directory]'
+ sys.exit(1)
+ print 'Install %s into %s' % ( sys.argv[2], sys.argv[1] )
+ install( sys.argv[1], sys.argv[2] )
-synapse code design documentation\r
-=================================\r
-\r
-Objective:\r
-----------\r
-\r
-Provide a simple cross platform layer to use dynamically loaded code\r
-inside a core application. Portability intended to win32 / linux / MacOS (?)\r
-\r
-Main features are:\r
-\r
-- designed for single process only, no remote clients, no asynchronous processes\r
-- a client/server architecture, based on configuration files: a main binary,\r
- loading a set of shared objects\r
- \r
-Constraints:\r
-------------\r
-\r
-- large existing plugin code in Radiant!\r
- must be compatible with minimal changes, specially for plugins (i.e. clients)\r
-\r
-- make things as much transparent as possible\r
- (ideally, no real difference between a static linkage and dynamic linkage,\r
- cf usage of #define macros to wrap a function call onto a code pointer)\r
- \r
-Features:\r
----------\r
-\r
-Gather as much generic code as possible in a static .lib with minimal dependencies\r
-(only dependency should be configuration files parser)\r
-\r
-NOTE: current effective dependency is STL / glib / xml\r
-\r
-Main executable implemented as a server, all others as clients. What has to\r
-be done for a server / what has to be done for a client needs to be documented.\r
-Provide as much scripts and tools and guidelines as needed (scripted generation of\r
-some .h files?)\r
-\r
-Proposed implementation:\r
-------------------------\r
-\r
-- have linux/ and win32/ subdirectories with OS-specific implementations\r
-(such as dynamically loading shared objects, and doing the initial query?)\r
-\r
-- reduce the API of a client to the minimum: one exported function?\r
-provide a squeleton to make new clients easily?\r
-\r
-Server use case:\r
-1) build information about location of the modules (from code and config files)\r
-2) load all modules and query information about their APIs\r
-NOTE: could read the APIs from some XML description files instead of\r
-querying it from the modules?\r
-3) build information about the required function tables\r
-i.e.: setup a list with the function tables to be filled in, and what they\r
-need to be filled in with.\r
-4) resolve the function table\r
-NOTE: is this iterative? will some plugins request more APIs as they get filled\r
-up?\r
-NOTE: do we have optional tables?\r
-5) unload unreferences modules\r
-NOTE: we don't expect to be unloading a LOT of modules, otherwise we would\r
-setup a solution that allows exploring of the APIs a given module provides\r
-from a file description. Or you could 'cache' that (md5-checksum the file, and \r
-maintain an XML list).\r
-\r
-Client use case:\r
-1) dynamically loaded\r
-2) prompted for the interfaces it provides\r
-2) prompted for the interfaces it requires\r
-3) either unloaded, or told what interfaces have been filled in\r
-\r
-The client module exports an Synapse_EnumerateInterfaces entry point\r
-This returns an ISynapseClient, which lists what the plugin provides, and what it requires\r
-\r
-The APIs:\r
-\r
-An interface is a function table, GUID / major string / minor string\r
-GUID is a shortcut to reference a major string (i.e. the human readable thing)\r
-the GUID / major string is unique for a given interface\r
-minor string is used to reference a particular version of an API\r
- (for instance when talking about image loading functionality, tga and jpg etc.)\r
- \r
-The GUID scheme is handy because it provides easy tests. They are not strictly\r
-necessary but we will probably want to keep them. Should we extend to GUIDs\r
-for minor too?\r
-\r
-Roadmap:\r
---------\r
-\r
-Need to convert the core (as server) and the required modules. Will have\r
-clearer view of what's to be done along the way.\r
-\r
-Implementation design:\r
-----------------------\r
-\r
-There is a client and server side to synapse. Typically server is in Radiant or q3map,\r
-client is in any module. For implementation, we have one server class and one client class.\r
-It would be possible to have two seperate libraries, synapse-client and synapse-server. But \r
-that only brings down the statically linked stuff to make things more complicated build-sysem\r
-wise.\r
-\r
-Initial implementation has been using isynapse.h and synapse.h, to provide a pure virtual\r
-base class for server and client. But that doesn't bring any major functionality, it's easier\r
-if both sides see the full API of the client and server classes.\r
-\r
-A side problem is the diagnostic printing functionality. For easy debugging we require that \r
-the synapse code can have access to a Sys_Printf or similar function at all times (that is for \r
-client and server implementation). On client we will pipe through the main API to the server \r
-as soon as we can in most cases. Using Sys_Printf would bring us to a dead end situation, since\r
-when synapse is used as the server, the main code implements it's own Sys_Printf stuff.\r
-Instead we introduce a local Syn_Printf implementation, which can be overriden in the server\r
-to point to the appropriate print functions.\r
-\r
-Runtime config:\r
----------------\r
-\r
-Something that has not been looked upon a lot yet, runtime configuration. What interfaces\r
-are loaded etc. Ideally, from an XML config file. A client explicitely requests the\r
-server to load all the interfaces it requires (in this case, the client is radiant or\r
-q3map).\r
-\r
-Plugins are somewhat out of the 'required interfaces' frame, since they are loaded \r
-whenever they are found. It is possible however that some plugins would not want to be \r
-loaded in if the game doesn't match etc. in case they would need to access the global \r
-config?\r
-\r
-In most cases a given API is only required once for editor functionality. (VFS for \r
-instance), so our #define strategy for easy mapping of the functions should still work.\r
-\r
-Version checks, reference counting:\r
-------------------------------------\r
-\r
-Need version checking at several levels. A version string (major/minor) on the main API\r
-entry point (straight in the exported function to save as much as possible for \r
-compatibility). For individual APIs, we have been feeding the struct size into the first\r
-int of the struct so far, and it has worked very well.\r
-\r
-Reference counting: we introduced class based APIs to solve the ref counting issues,\r
-which are not easy to solve on C function tables. That problem would arise in plugin\r
-situations where we might want to 'reload' or 'unload' some plugins. The server could\r
-keep track of the ref count.\r
-\r
-Caching?\r
---------\r
-\r
-We are going to load every shared object we find and query it for it's interfaces. Then\r
-we will unload the stuff we don't want. This is going to slow down the startup process.\r
-We could extract the API information in a cache to avoid the loading step.\r
-\r
-Interfaces with multiple minors against I* objects?\r
----------------------------------------------------\r
-\r
-Looking at the iimage.h API, why not having instead something that enumerates C++ objects \r
-directly? Mainly because we want to be able to spread several minors accross multiple modules\r
-and still use them together. And straight laid out function tables in C structs are only\r
-one indirection when the table is static.\r
-\r
-This raises a broader topic, instead of requesting APIs, we could request objects directly.\r
-Would that be of any use?\r
-\r
-Loading interfaces / resolving interdependencies strategy\r
----------------------------------------------------------\r
-\r
-Some notes about how we load the modules and resolve interdependencies:\r
-\r
-We want to avoid requesting a module for an API it provides before all the APIs it requires\r
-have been filled in (mostly stability concerns, a module may be doing whatever internally \r
-when we request something from it). The exception being the module we are trying to resolve\r
-for (since we need a start point for resolution). But in all likelyness we resolve for radiant\r
-or q3map for instance.\r
-\r
-With this approach, it is possible that some situations could not be resolved, for instance:\r
-Radiant\r
- requires A\r
- provides B\r
-module 1\r
- requires C\r
- provides A\r
-module 2\r
- requires A\r
- provides C\r
-if we start by resolving Radiant, we will get stuck\r
-if we are ready to ask module to provide the API even though the required is not meant, it would work\r
-but that kind of situation is very unlikely, so sticking to safer strategy\r
- \r
-Configuration\r
--------------\r
-\r
-the config info needs to go down to the clients too\r
+synapse code design documentation
+=================================
+
+Objective:
+----------
+
+Provide a simple cross platform layer to use dynamically loaded code
+inside a core application. Portability intended to win32 / linux / MacOS (?)
+
+Main features are:
+
+- designed for single process only, no remote clients, no asynchronous processes
+- a client/server architecture, based on configuration files: a main binary,
+ loading a set of shared objects
+
+Constraints:
+------------
+
+- large existing plugin code in Radiant!
+ must be compatible with minimal changes, specially for plugins (i.e. clients)
+
+- make things as much transparent as possible
+ (ideally, no real difference between a static linkage and dynamic linkage,
+ cf usage of #define macros to wrap a function call onto a code pointer)
+
+Features:
+---------
+
+Gather as much generic code as possible in a static .lib with minimal dependencies
+(only dependency should be configuration files parser)
+
+NOTE: current effective dependency is STL / glib / xml
+
+Main executable implemented as a server, all others as clients. What has to
+be done for a server / what has to be done for a client needs to be documented.
+Provide as much scripts and tools and guidelines as needed (scripted generation of
+some .h files?)
+
+Proposed implementation:
+------------------------
+
+- have linux/ and win32/ subdirectories with OS-specific implementations
+(such as dynamically loading shared objects, and doing the initial query?)
+
+- reduce the API of a client to the minimum: one exported function?
+provide a squeleton to make new clients easily?
+
+Server use case:
+1) build information about location of the modules (from code and config files)
+2) load all modules and query information about their APIs
+NOTE: could read the APIs from some XML description files instead of
+querying it from the modules?
+3) build information about the required function tables
+i.e.: setup a list with the function tables to be filled in, and what they
+need to be filled in with.
+4) resolve the function table
+NOTE: is this iterative? will some plugins request more APIs as they get filled
+up?
+NOTE: do we have optional tables?
+5) unload unreferences modules
+NOTE: we don't expect to be unloading a LOT of modules, otherwise we would
+setup a solution that allows exploring of the APIs a given module provides
+from a file description. Or you could 'cache' that (md5-checksum the file, and
+maintain an XML list).
+
+Client use case:
+1) dynamically loaded
+2) prompted for the interfaces it provides
+2) prompted for the interfaces it requires
+3) either unloaded, or told what interfaces have been filled in
+
+The client module exports an Synapse_EnumerateInterfaces entry point
+This returns an ISynapseClient, which lists what the plugin provides, and what it requires
+
+The APIs:
+
+An interface is a function table, GUID / major string / minor string
+GUID is a shortcut to reference a major string (i.e. the human readable thing)
+the GUID / major string is unique for a given interface
+minor string is used to reference a particular version of an API
+ (for instance when talking about image loading functionality, tga and jpg etc.)
+
+The GUID scheme is handy because it provides easy tests. They are not strictly
+necessary but we will probably want to keep them. Should we extend to GUIDs
+for minor too?
+
+Roadmap:
+--------
+
+Need to convert the core (as server) and the required modules. Will have
+clearer view of what's to be done along the way.
+
+Implementation design:
+----------------------
+
+There is a client and server side to synapse. Typically server is in Radiant or q3map,
+client is in any module. For implementation, we have one server class and one client class.
+It would be possible to have two seperate libraries, synapse-client and synapse-server. But
+that only brings down the statically linked stuff to make things more complicated build-sysem
+wise.
+
+Initial implementation has been using isynapse.h and synapse.h, to provide a pure virtual
+base class for server and client. But that doesn't bring any major functionality, it's easier
+if both sides see the full API of the client and server classes.
+
+A side problem is the diagnostic printing functionality. For easy debugging we require that
+the synapse code can have access to a Sys_Printf or similar function at all times (that is for
+client and server implementation). On client we will pipe through the main API to the server
+as soon as we can in most cases. Using Sys_Printf would bring us to a dead end situation, since
+when synapse is used as the server, the main code implements it's own Sys_Printf stuff.
+Instead we introduce a local Syn_Printf implementation, which can be overriden in the server
+to point to the appropriate print functions.
+
+Runtime config:
+---------------
+
+Something that has not been looked upon a lot yet, runtime configuration. What interfaces
+are loaded etc. Ideally, from an XML config file. A client explicitely requests the
+server to load all the interfaces it requires (in this case, the client is radiant or
+q3map).
+
+Plugins are somewhat out of the 'required interfaces' frame, since they are loaded
+whenever they are found. It is possible however that some plugins would not want to be
+loaded in if the game doesn't match etc. in case they would need to access the global
+config?
+
+In most cases a given API is only required once for editor functionality. (VFS for
+instance), so our #define strategy for easy mapping of the functions should still work.
+
+Version checks, reference counting:
+------------------------------------
+
+Need version checking at several levels. A version string (major/minor) on the main API
+entry point (straight in the exported function to save as much as possible for
+compatibility). For individual APIs, we have been feeding the struct size into the first
+int of the struct so far, and it has worked very well.
+
+Reference counting: we introduced class based APIs to solve the ref counting issues,
+which are not easy to solve on C function tables. That problem would arise in plugin
+situations where we might want to 'reload' or 'unload' some plugins. The server could
+keep track of the ref count.
+
+Caching?
+--------
+
+We are going to load every shared object we find and query it for it's interfaces. Then
+we will unload the stuff we don't want. This is going to slow down the startup process.
+We could extract the API information in a cache to avoid the loading step.
+
+Interfaces with multiple minors against I* objects?
+---------------------------------------------------
+
+Looking at the iimage.h API, why not having instead something that enumerates C++ objects
+directly? Mainly because we want to be able to spread several minors accross multiple modules
+and still use them together. And straight laid out function tables in C structs are only
+one indirection when the table is static.
+
+This raises a broader topic, instead of requesting APIs, we could request objects directly.
+Would that be of any use?
+
+Loading interfaces / resolving interdependencies strategy
+---------------------------------------------------------
+
+Some notes about how we load the modules and resolve interdependencies:
+
+We want to avoid requesting a module for an API it provides before all the APIs it requires
+have been filled in (mostly stability concerns, a module may be doing whatever internally
+when we request something from it). The exception being the module we are trying to resolve
+for (since we need a start point for resolution). But in all likelyness we resolve for radiant
+or q3map for instance.
+
+With this approach, it is possible that some situations could not be resolved, for instance:
+Radiant
+ requires A
+ provides B
+module 1
+ requires C
+ provides A
+module 2
+ requires A
+ provides C
+if we start by resolving Radiant, we will get stuck
+if we are ready to ask module to provide the API even though the required is not meant, it would work
+but that kind of situation is very unlikely, so sticking to safer strategy
+
+Configuration
+-------------
+
+the config info needs to go down to the clients too
for instance, mapxml loaded for q3map or radiant, doesn't rely on the same major?
\ No newline at end of file
-XML config files for customized synapse initialization at runtime\r
------------------------------------------------------------------\r
-\r
-Objective:\r
-----------\r
-\r
-We have to assign the minors of the APIs to function tables \r
-(and possibly to the API managers) at runtime from some config files.\r
-\r
-For instance in Q3 or RTCW mode, we will want to fill in \r
-g_FileSystemTable and g_ShadersTable with the "quake3" minor. Whereas\r
-those tables will be filled in with a different minor for HL mode.\r
-\r
-This affects SYN_REQUIRE for all the clients of the system, so that\r
-config will need to be global and passed around to the clients.\r
-\r
-Implementation:\r
----------------\r
-\r
-an XML hierarchy to describe the APIs:\r
-<client name="CORE">\r
- <api name="vfs">\r
- quake3\r
- </api>\r
- <api name="shaders">\r
- quake3\r
- </api>\r
- ..\r
-</client>\r
-<client name="SHADERS">\r
- \r
-</client>\r
-\r
-Each client will have to be identified by a specific name, if a name in the\r
-config is not found in the client list, the init should fail. A client can\r
-still be hardcoded and not appear in this list though.\r
-(a GetName() function to synapse client)\r
-\r
-SYN_REQUIRE_ANY support will work for strict API lists. Just the same way \r
-we do the simple SYN_REQUIRE\r
-\r
-Discussion:\r
------------\r
-\r
-We only deal with SYN_REQUIRE. It is possible that at some point we will want\r
-to customize the SYN_PROVIDE too. For instance depending on the game mode, a\r
-same module could provide two different minors. Couldn't provide the two minors\r
-at the same time though, only one.\r
-\r
-Implementation:\r
----------------\r
-\r
-Default config file will be synapse.config in the gametools path. We can override\r
-this later with a custom line in the .game file. Should Synapse be able to operate\r
-without this config file though, as it is looked up by the main program and handed\r
-over to synapse before init? Possibly .. we'll just pass a NULL config node ptr\r
-\r
-Add the config file path to CSynpaseServer::Initialize, pass the loaded XML file to\r
+XML config files for customized synapse initialization at runtime
+-----------------------------------------------------------------
+
+Objective:
+----------
+
+We have to assign the minors of the APIs to function tables
+(and possibly to the API managers) at runtime from some config files.
+
+For instance in Q3 or RTCW mode, we will want to fill in
+g_FileSystemTable and g_ShadersTable with the "quake3" minor. Whereas
+those tables will be filled in with a different minor for HL mode.
+
+This affects SYN_REQUIRE for all the clients of the system, so that
+config will need to be global and passed around to the clients.
+
+Implementation:
+---------------
+
+an XML hierarchy to describe the APIs:
+<client name="CORE">
+ <api name="vfs">
+ quake3
+ </api>
+ <api name="shaders">
+ quake3
+ </api>
+ ..
+</client>
+<client name="SHADERS">
+
+</client>
+
+Each client will have to be identified by a specific name, if a name in the
+config is not found in the client list, the init should fail. A client can
+still be hardcoded and not appear in this list though.
+(a GetName() function to synapse client)
+
+SYN_REQUIRE_ANY support will work for strict API lists. Just the same way
+we do the simple SYN_REQUIRE
+
+Discussion:
+-----------
+
+We only deal with SYN_REQUIRE. It is possible that at some point we will want
+to customize the SYN_PROVIDE too. For instance depending on the game mode, a
+same module could provide two different minors. Couldn't provide the two minors
+at the same time though, only one.
+
+Implementation:
+---------------
+
+Default config file will be synapse.config in the gametools path. We can override
+this later with a custom line in the .game file. Should Synapse be able to operate
+without this config file though, as it is looked up by the main program and handed
+over to synapse before init? Possibly .. we'll just pass a NULL config node ptr
+
+Add the config file path to CSynpaseServer::Initialize, pass the loaded XML file to
the clients. Do we need to wrap in an object with some convenience functions?
\ No newline at end of file
-Release / Reload of modules\r
----------------------------\r
-\r
-The 'not active' modules are unloaded after startup\r
-Plugins should be allowed to be unloaded and reloaded on the fly\r
-Modules too, when possible?\r
-\r
-Don't want to 'force' all plugins to have unload capabilities\r
-Just has to be something specified at compile time wether or not they can unload 'cleanly'\r
-\r
-Dependency implications. When you release a module, you need to remove a number of interfaces.\r
-If those interfaces are being used, can you explicitely ask for them to be unloaded?\r
-\r
-Also, problem with plugins breaking the startup process:\r
-http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=441\r
-\r
-The most important is to provide a clean shutdown method\r
-What's the != between unload and shutdown?\r
-\r
-Means that the server proceeds to the shutdown, and nothing else is supposed to be making\r
-calls through APIs post shutdown.\r
-\r
-Should be done in 3 steps:\r
-#1 prepare shutdown, all APIs are active, just release and save all the stuff you want\r
-#2 tell the modules to shutdown, i.e. release the APIs they point to? (at this point they can't call through anymore)\r
-#3 force all things to be unloaded, warn about reference count problems\r
-\r
-What is different when we unload a module, and we want to keep the editor up?\r
-All the interfaces obtained from this plugin need to be released\r
-If some pure virtual classes have been obtained from this plugin, we need a mecanism to have them removed\r
-Do we need a first path to check if the unload procedure is going to be allowed?\r
-\r
-For instance, a plugin that provides custom entities rendering etc.\r
-Need to unload first, then need to reload (scan the map again, rebuild)\r
-\r
-Summing up, when doing a reload we need to keep track of the modules and let them know after the\r
-module has been reloaded, so that the links can be rebuilt. When doing unload we need to do a\r
-'check' pass prior to anything to know if the release is possible. Because it does not depend\r
-on the module we unload, it depends on the other clients that use it.\r
-\r
-Objectives:\r
------------\r
-\r
-- 'release check' of a module\r
- walk through the interfaces this module has provided, and make sure the release will be possible\r
-- 'release' of a module\r
- actually drop all the interfaces. this should be done only after a 'release check'\r
- if something fails here, we are in an unstable state and need to abort\r
-- 'client shutdown' unused modules after initial startup\r
- actual DLL unload / complete shutdown of the client interface \r
- this comes after 'release check' and 'release'\r
-- 'refresh' modules\r
- 'release check', 'release', 'shutdown' and then, reload and build the links again\r
-- 'core shutdown'\r
- 'release' and force 'shutdown' of all clients\r
- even if we encounter some interfaces that we are not able to release cleanly\r
- force things and shutdown all clients\r
- then the core process is ready to exit..\r
-\r
-Constraints:\r
-------------\r
-\r
-- refresh and shutdown are sharing some code\r
-- the 'release' part of a module refresh may not be always possible (that's what 'release check' is there for)\r
-- 'core shutdown' has to be forced to happen, in the safest way possible obviously\r
-\r
-Implementation:\r
----------------\r
-\r
-- 'client shutdown' comes first\r
- this is used after initial startup, since we don't have to do a prior 'release' on those\r
- this will be used in the 'core shutdown' and 'refresh' too \r
-- then 'core shutdown' procedure?\r
- that's the most urgent thing we need\r
- but 'release check' and 'release' have to be written in and used during 'core shutdown'\r
-- 'refresh' takes an essential part of the design, but that's not something we need to have written right now?\r
- (it mostly relies on 'release check' 'release' 'client shutdown', and then reload and rebuild the links)\r
- \r
-'client shutdown':\r
-this is server side code though, you tell the server 'shutdown this client'\r
-we don't have to exchange anything with the client while we do that\r
-(written initially for unload of unused modules after startup)\r
-\r
-'core shutdown':\r
-is a shutdown of all clients\r
+Release / Reload of modules
+---------------------------
+
+The 'not active' modules are unloaded after startup
+Plugins should be allowed to be unloaded and reloaded on the fly
+Modules too, when possible?
+
+Don't want to 'force' all plugins to have unload capabilities
+Just has to be something specified at compile time wether or not they can unload 'cleanly'
+
+Dependency implications. When you release a module, you need to remove a number of interfaces.
+If those interfaces are being used, can you explicitely ask for them to be unloaded?
+
+Also, problem with plugins breaking the startup process:
+http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=441
+
+The most important is to provide a clean shutdown method
+What's the != between unload and shutdown?
+
+Means that the server proceeds to the shutdown, and nothing else is supposed to be making
+calls through APIs post shutdown.
+
+Should be done in 3 steps:
+#1 prepare shutdown, all APIs are active, just release and save all the stuff you want
+#2 tell the modules to shutdown, i.e. release the APIs they point to? (at this point they can't call through anymore)
+#3 force all things to be unloaded, warn about reference count problems
+
+What is different when we unload a module, and we want to keep the editor up?
+All the interfaces obtained from this plugin need to be released
+If some pure virtual classes have been obtained from this plugin, we need a mecanism to have them removed
+Do we need a first path to check if the unload procedure is going to be allowed?
+
+For instance, a plugin that provides custom entities rendering etc.
+Need to unload first, then need to reload (scan the map again, rebuild)
+
+Summing up, when doing a reload we need to keep track of the modules and let them know after the
+module has been reloaded, so that the links can be rebuilt. When doing unload we need to do a
+'check' pass prior to anything to know if the release is possible. Because it does not depend
+on the module we unload, it depends on the other clients that use it.
+
+Objectives:
+-----------
+
+- 'release check' of a module
+ walk through the interfaces this module has provided, and make sure the release will be possible
+- 'release' of a module
+ actually drop all the interfaces. this should be done only after a 'release check'
+ if something fails here, we are in an unstable state and need to abort
+- 'client shutdown' unused modules after initial startup
+ actual DLL unload / complete shutdown of the client interface
+ this comes after 'release check' and 'release'
+- 'refresh' modules
+ 'release check', 'release', 'shutdown' and then, reload and build the links again
+- 'core shutdown'
+ 'release' and force 'shutdown' of all clients
+ even if we encounter some interfaces that we are not able to release cleanly
+ force things and shutdown all clients
+ then the core process is ready to exit..
+
+Constraints:
+------------
+
+- refresh and shutdown are sharing some code
+- the 'release' part of a module refresh may not be always possible (that's what 'release check' is there for)
+- 'core shutdown' has to be forced to happen, in the safest way possible obviously
+
+Implementation:
+---------------
+
+- 'client shutdown' comes first
+ this is used after initial startup, since we don't have to do a prior 'release' on those
+ this will be used in the 'core shutdown' and 'refresh' too
+- then 'core shutdown' procedure?
+ that's the most urgent thing we need
+ but 'release check' and 'release' have to be written in and used during 'core shutdown'
+- 'refresh' takes an essential part of the design, but that's not something we need to have written right now?
+ (it mostly relies on 'release check' 'release' 'client shutdown', and then reload and rebuild the links)
+
+'client shutdown':
+this is server side code though, you tell the server 'shutdown this client'
+we don't have to exchange anything with the client while we do that
+(written initially for unload of unused modules after startup)
+
+'core shutdown':
+is a shutdown of all clients
-# version and about message management\r
-# NOTE: this module is meant to be used on all platforms, it is not SCons centric\r
-\r
-# version:\r
-# input:\r
-# include/version.default\r
-# output:\r
-# include/version.h include/RADIANT_MAJOR include/RADIANT_MINOR\r
-# the header is used by C/C++ code, the straight text file by setup\r
-\r
-# about message\r
-# for non-official builds, we have a default message\r
-# otherwise, use environment variable $RADIANT_ABOUTMSG\r
-# input:\r
-# include/aboutmsg.default\r
-# or file pointed to by $RADIANT_ABOUTMSG if exists\r
-# ouput:\r
-# include/aboutmsg.h\r
-\r
-import sys, re, string, os\r
-\r
-def get_version():\r
- # version\r
- f = open('include/version.default', 'r')\r
- buffer = f.read()\r
- line = string.split(buffer, '\n')[0]\r
- f.close()\r
- sys.stdout.write("version: %s\n" % line)\r
- exp = re.compile('^1\\.([^\\.]*)\\.([0-9]*)')\r
- (major, minor) = exp.findall(line)[0]\r
- sys.stdout.write("minor: %s major: %s\n" % (minor, major))\r
- return (line, major, minor) \r
-\r
-# you can pass an optional message to append to aboutmsg\r
-def radiant_makeversion(append_about):\r
- (line, major, minor) = get_version()\r
- f = open('include/version.h', 'w')\r
- f.write('// generated header, see makeversion.py\n')\r
- f.write('#define RADIANT_VERSION "%s"\n' % line)\r
- f.write('#define RADIANT_MINOR_VERSION "%s"\n' % minor)\r
- f.write('#define RADIANT_MAJOR_VERSION "%s"\n' % major)\r
- f.close()\r
- f = open('include/RADIANT_MINOR', 'w')\r
- f.write(minor)\r
- f.close()\r
- f = open('include/RADIANT_MAJOR', 'w')\r
- f.write(major)\r
- f.close()\r
- f = open('include/version', 'w')\r
- f.write(line)\r
- f.close()\r
- # aboutmsg\r
- aboutfile = 'include/aboutmsg.default'\r
- if ( os.environ.has_key('RADIANT_ABOUTMSG') ):\r
- aboutfile = os.environ['RADIANT_ABOUTMSG']\r
- sys.stdout.write("about message is in %s\n" % aboutfile)\r
- f = open(aboutfile, 'r')\r
- buffer = f.read()\r
- line = string.split(buffer, '\n')[0]\r
- f.close()\r
- # optional additional message\r
- if ( not append_about is None ):\r
- line += append_about\r
- sys.stdout.write("about: %s\n" % line)\r
- f = open('include/aboutmsg.h', 'w')\r
- f.write('// generated header, see makeversion.py\n')\r
- f.write('#define RADIANT_ABOUTMSG "%s"\n' % line)\r
- f.close()\r
-\r
-# can be used as module (scons build), or by direct call\r
-if __name__ == '__main__':\r
- radiant_makeversion(None)\r
+# version and about message management
+# NOTE: this module is meant to be used on all platforms, it is not SCons centric
+
+# version:
+# input:
+# include/version.default
+# output:
+# include/version.h include/RADIANT_MAJOR include/RADIANT_MINOR
+# the header is used by C/C++ code, the straight text file by setup
+
+# about message
+# for non-official builds, we have a default message
+# otherwise, use environment variable $RADIANT_ABOUTMSG
+# input:
+# include/aboutmsg.default
+# or file pointed to by $RADIANT_ABOUTMSG if exists
+# ouput:
+# include/aboutmsg.h
+
+import sys, re, string, os
+
+def get_version():
+ # version
+ f = open('include/version.default', 'r')
+ buffer = f.read()
+ line = string.split(buffer, '\n')[0]
+ f.close()
+ sys.stdout.write("version: %s\n" % line)
+ exp = re.compile('^1\\.([^\\.]*)\\.([0-9]*)')
+ (major, minor) = exp.findall(line)[0]
+ sys.stdout.write("minor: %s major: %s\n" % (minor, major))
+ return (line, major, minor)
+
+# you can pass an optional message to append to aboutmsg
+def radiant_makeversion(append_about):
+ (line, major, minor) = get_version()
+ f = open('include/version.h', 'w')
+ f.write('// generated header, see makeversion.py\n')
+ f.write('#define RADIANT_VERSION "%s"\n' % line)
+ f.write('#define RADIANT_MINOR_VERSION "%s"\n' % minor)
+ f.write('#define RADIANT_MAJOR_VERSION "%s"\n' % major)
+ f.close()
+ f = open('include/RADIANT_MINOR', 'w')
+ f.write(minor)
+ f.close()
+ f = open('include/RADIANT_MAJOR', 'w')
+ f.write(major)
+ f.close()
+ f = open('include/version', 'w')
+ f.write(line)
+ f.close()
+ # aboutmsg
+ aboutfile = 'include/aboutmsg.default'
+ if ( os.environ.has_key('RADIANT_ABOUTMSG') ):
+ aboutfile = os.environ['RADIANT_ABOUTMSG']
+ sys.stdout.write("about message is in %s\n" % aboutfile)
+ f = open(aboutfile, 'r')
+ buffer = f.read()
+ line = string.split(buffer, '\n')[0]
+ f.close()
+ # optional additional message
+ if ( not append_about is None ):
+ line += append_about
+ sys.stdout.write("about: %s\n" % line)
+ f = open('include/aboutmsg.h', 'w')
+ f.write('// generated header, see makeversion.py\n')
+ f.write('#define RADIANT_ABOUTMSG "%s"\n' % line)
+ f.close()
+
+# can be used as module (scons build), or by direct call
+if __name__ == '__main__':
+ radiant_makeversion(None)
-; fgd.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "FGD"\r
-DESCRIPTION 'FGD Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; fgd.def : Declares the module parameters for the DLL.
+
+LIBRARY "FGD"
+DESCRIPTION 'FGD Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-; entity.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "ENTITY"\r
-DESCRIPTION 'ENTITY Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; entity.def : Declares the module parameters for the DLL.
+
+LIBRARY "ENTITY"
+DESCRIPTION 'ENTITY Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-; image.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "Image"\r
-DESCRIPTION 'Image Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; image.def : Declares the module parameters for the DLL.
+
+LIBRARY "Image"
+DESCRIPTION 'Image Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-; hlimage.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "ImageHL"\r
-DESCRIPTION 'ImageHL Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; hlimage.def : Declares the module parameters for the DLL.
+
+LIBRARY "ImageHL"
+DESCRIPTION 'ImageHL Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-ImageHL\r
-=======\r
-\r
-Coding by Dominic Clifton - Hydra - hydra@hydras-world.com\r
-\r
-What is it ?\r
-------------\r
-\r
-This GTKRadiant 1.2+ plugin handles the loading of textures from .WAD files.\r
-I'll refer to these textures as .HLW files, even though they don't have any\r
-extension when they're stored in the .WAD file itself.\r
-\r
-You need a VFS plugin to go with this plugin that can open and read .WAD files\r
-My VFSWAD plugin does just this.\r
-\r
-Developer Notes\r
----------------\r
-\r
-The project file will copy the compiled DLL file and this .TXT file to\r
-"$(HLRADIANTDIR)modules" so make sure you have that environment variable\r
-defined.\r
-\r
-For my GTKRadiant 1.2 HalfLife game pack files I use the directory:\r
-"E:\games\HalfLife\Tools\GTKR12N". Under which there are the directories\r
-"modules" and "plugins"\r
-\r
-Credits\r
--------\r
-Thanks to the guys that made Wally for releasing an example WAD loader.\r
-without it this would not have been possible.\r
+ImageHL
+=======
+
+Coding by Dominic Clifton - Hydra - hydra@hydras-world.com
+
+What is it ?
+------------
+
+This GTKRadiant 1.2+ plugin handles the loading of textures from .WAD files.
+I'll refer to these textures as .HLW files, even though they don't have any
+extension when they're stored in the .WAD file itself.
+
+You need a VFS plugin to go with this plugin that can open and read .WAD files
+My VFSWAD plugin does just this.
+
+Developer Notes
+---------------
+
+The project file will copy the compiled DLL file and this .TXT file to
+"$(HLRADIANTDIR)modules" so make sure you have that environment variable
+defined.
+
+For my GTKRadiant 1.2 HalfLife game pack files I use the directory:
+"E:\games\HalfLife\Tools\GTKR12N". Under which there are the directories
+"modules" and "plugins"
+
+Credits
+-------
+Thanks to the guys that made Wally for releasing an example WAD loader.
+without it this would not have been possible.
-; imagem8.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "ImageM8"\r
-DESCRIPTION 'ImageM8 Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; imagem8.def : Declares the module parameters for the DLL.
+
+LIBRARY "ImageM8"
+DESCRIPTION 'ImageM8 Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-; imagepng.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "IMAGEPNG"\r
-DESCRIPTION 'IMAGEPNG Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; imagepng.def : Declares the module parameters for the DLL.
+
+LIBRARY "IMAGEPNG"
+DESCRIPTION 'IMAGEPNG Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-; mapq3.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "MAPQ3"\r
-DESCRIPTION 'MAPQ3 Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; mapq3.def : Declares the module parameters for the DLL.
+
+LIBRARY "MAPQ3"
+DESCRIPTION 'MAPQ3 Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-; mapxml.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "MAPXML"\r
-DESCRIPTION 'MAPXML Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; mapxml.def : Declares the module parameters for the DLL.
+
+LIBRARY "MAPXML"
+DESCRIPTION 'MAPXML Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-; model.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "MODEL"\r
-DESCRIPTION 'MODEL Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
+; model.def : Declares the module parameters for the DLL.
+
+LIBRARY "MODEL"
+DESCRIPTION 'MODEL Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
Synapse_EnumerateInterfaces @1
\ No newline at end of file
-; shaders.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "Shaders"\r
-DESCRIPTION 'Shaders Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; shaders.def : Declares the module parameters for the DLL.
+
+LIBRARY "Shaders"
+DESCRIPTION 'Shaders Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-; shaders.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "ShadersHL"\r
-DESCRIPTION 'ShadersHL Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; shaders.def : Declares the module parameters for the DLL.
+
+LIBRARY "ShadersHL"
+DESCRIPTION 'ShadersHL Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-; md3model.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "SPRITEMODEL"\r
-DESCRIPTION 'SPRITEMODEL Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; md3model.def : Declares the module parameters for the DLL.
+
+LIBRARY "SPRITEMODEL"
+DESCRIPTION 'SPRITEMODEL Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-; surface_heretic2.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "Surface_Heretic2"\r
-DESCRIPTION 'Surface_Heretic2 Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; surface_heretic2.def : Declares the module parameters for the DLL.
+
+LIBRARY "Surface_Heretic2"
+DESCRIPTION 'Surface_Heretic2 Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-; TexTool.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "TexTool"\r
-DESCRIPTION 'TexTool Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- QERPlug_Init @1\r
- QERPlug_GetName @2\r
- QERPlug_GetCommandList @3\r
- QERPlug_Dispatch @4\r
- QERPlug_GetFuncTable @5\r
+; TexTool.def : Declares the module parameters for the DLL.
+
+LIBRARY "TexTool"
+DESCRIPTION 'TexTool Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ QERPlug_Init @1
+ QERPlug_GetName @2
+ QERPlug_GetCommandList @3
+ QERPlug_Dispatch @4
+ QERPlug_GetFuncTable @5
-11/19/99\r
-first usable version\r
-here is the TODO-list for next release, ( most certainly a wish list )\r
-\r
-- TODO: add hooks with the selected face and selected patch data. tell the plugin when selected face\r
-or selected patch has changed.\r
-the hooks should use a generic interface inside Radiant for "observers"\r
+11/19/99
+first usable version
+here is the TODO-list for next release, ( most certainly a wish list )
+
+- TODO: add hooks with the selected face and selected patch data. tell the plugin when selected face
+or selected patch has changed.
+the hooks should use a generic interface inside Radiant for "observers"
- TODO: add other usefull texturing tools, if designers come up with good ideas
\ No newline at end of file
-; vfspk3.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "VFSPK3"\r
-DESCRIPTION 'VFSPK3 Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; vfspk3.def : Declares the module parameters for the DLL.
+
+LIBRARY "VFSPK3"
+DESCRIPTION 'VFSPK3 Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-; vfswad.def : Declares the module parameters for the DLL.\r
-\r
-LIBRARY "vfswad"\r
-DESCRIPTION 'vfswad Windows Dynamic Link Library'\r
-\r
-EXPORTS\r
- ; Explicit exports can go here\r
- Synapse_EnumerateInterfaces @1\r
+; vfswad.def : Declares the module parameters for the DLL.
+
+LIBRARY "vfswad"
+DESCRIPTION 'vfswad Windows Dynamic Link Library'
+
+EXPORTS
+ ; Explicit exports can go here
+ Synapse_EnumerateInterfaces @1
-VFSWAD\r
-======\r
-\r
-Coding by Dominic Clifton - Hydra - hydra@hydras-world.com\r
-\r
-What is it ?\r
-------------\r
-\r
-This GTKRadiant 1.2+ plugin handles the extracting of files from .WAD files.\r
-I'll refer to these files as .HLW files, even though they don't have any\r
-extension when they're stored in the .WAD file itself.\r
-\r
-You need an image plugin to go with this plugin that can read .HLW files\r
-My ImageHL plugin does just this.\r
-\r
-Developer Notes\r
----------------\r
-\r
-The project file will copy the compiled DLL file and this .TXT file to\r
-"$(HLRADIANTDIR)\modules" so make sure you have that environment variable\r
-defined.\r
-\r
-For my GTKRadiant 1.2 HalfLife game pack files I use the directory:\r
-"E:\games\HalfLife\Tools\GTKR12N\". Under which there are the directories\r
-"modules" and "plugins"\r
-\r
-Credits\r
--------\r
-Thanks to the guys that made Wally for releasing an example WAD loader.\r
-without it this would not have been possible.\r
+VFSWAD
+======
+
+Coding by Dominic Clifton - Hydra - hydra@hydras-world.com
+
+What is it ?
+------------
+
+This GTKRadiant 1.2+ plugin handles the extracting of files from .WAD files.
+I'll refer to these files as .HLW files, even though they don't have any
+extension when they're stored in the .WAD file itself.
+
+You need an image plugin to go with this plugin that can read .HLW files
+My ImageHL plugin does just this.
+
+Developer Notes
+---------------
+
+The project file will copy the compiled DLL file and this .TXT file to
+"$(HLRADIANTDIR)\modules" so make sure you have that environment variable
+defined.
+
+For my GTKRadiant 1.2 HalfLife game pack files I use the directory:
+"E:\games\HalfLife\Tools\GTKR12N\". Under which there are the directories
+"modules" and "plugins"
+
+Credits
+-------
+Thanks to the guys that made Wally for releasing an example WAD loader.
+without it this would not have been possible.
-Q3Map2 Version History + Changelog (Reverse Chronological Order)\r
-\r
-2.5.11 (2003-12-01)\r
-\r
-- New: added support for _skybox entities to generate "portal sky"\r
- surfaces in games w/o native support (Quake 3). _skybox entities have\r
- 3 keys: _scale (default 64), and angle/angles (for rotation of the\r
- skybox relative to the map)\r
-- New: added -skyfix switch to BSP phase as a workaround hack for\r
- the black GL_CLAMP border on skybox edges on ATI (and newer nvidia)\r
- video cards. Note: unnecessary in ET or JA\r
-- New: Added _anglescale to light entities for scaling angle attenuation.\r
- Use a small value (< 1.0) to lessen the angle attenuation, and a high\r
- value (> 1.0) for sharper, more faceted lighting\r
-- New: Added _lightmapscale support to misc_model entities\r
-- Custom shaders (external lightmaps, styles) will not be generated\r
- if the find/replace text cannot be found\r
-- Tightened up light culling epsilon from 1.0 to 0.125 to stop certain\r
- surface lights from being incorrectly culled (thanks RasputiN!)\r
-- Fixed bug where small 3 and 4 sided brush faces were getting fanned,\r
- adding triangle/vertex counts\r
-- Moved to Visual Studio .NET, with aggressive optimizations enabled\r
-- Cleaned up missing image warnings\r
-- Parsing images out of shader stages if not found explicit/implicitly\r
-- Loads Enemy Territory implicitMap images if editor/light image not found\r
-\r
-\r
-2.5.10 (2003-10-22)\r
-\r
-- New: Lightwave model support (beta) courtesy of RR2DO2\r
-- New: Heretic 2 FM model support courtesy of Nurail\r
-- Re-enabled vertex cache friendly triangle reordering with fix\r
-- Disabled triangle reordering on certain surfaces, including autosprite\r
- shaders due to visual errors\r
-- Fixed bug in radiosity where sorting of lights by style took forever.\r
- Thanks ReBoOT!\r
-- Fixed bug in sun lighting code where maps too far off the origin would\r
- not be properly it by sun or sky light. Thanks MindLink!\r
-- Entity causing a leak will be printed and selected in Radiant if BSP\r
- monitoring is enabled. Requested by heeen\r
-- Fixed odd bug causing 10x slowdown in lighting in some maps. Should\r
- be back to 2.5.7 performance. Also fixed a couple old bugs related to\r
- autosprite shader (point) lights and backsplash lights not being styled\r
- or setup correctly\r
-\r
-\r
-2.5.9 (2003-10-12)\r
-\r
-- Disabled triangle reordering for now (crashing on some maps)\r
-\r
-\r
-2.5.8 (2003-10-02)\r
-\r
-- New: Added two new sun parameters: angular deviation (width of the sun in\r
- degrees) and sampling count (jitters). This allows for decent approximation\r
- of penumbra "half-shadow" effects from sunlight with 16+ samples. These\r
- parameters are accessible for entity lights (including spots and suns) via\r
- these entity keys: _deviance and _samples. To use in shaders, use the new\r
- q3map_sunExt <r> <g> <b> <brightness> <angle> <elevation> <deviance> <samples>\r
-- New: q3map_lightmapFilterRadius <self> <other> for light-emitting shaders.\r
- Put *after* any q3map_sun directives or else your sun will be filtered. This\r
- is good for eliminating the "stadium lighting" effect from q3map_skyLight.\r
- Also usable as an entity key: _filterradius or _filter\r
-- New: Quake 2 MD2 model support in PicoModel for misc_model entities\r
- (thanks to Nurail!)\r
-- Re-enabled vertex-cache-aware triangle reordering. Will probably have a\r
- negligible effect on rendering performance, but can't hurt\r
-- Added short-circuit to raytracer: any empty nodes (including children) are\r
- ignored on sun traces\r
-- Added BSP file size printout\r
-- Filtering of any kind now disables adaptive supersampling on a per-light,\r
- per-ightmap basis\r
-- Fixed another _minlight <-> styled light interaction bug (thanks pjw!)\r
-\r
-\r
-2.5.7 (2003-08-31)\r
-\r
-- New: Jedi Academy support via -game ja\r
-- New: DDS (DXT1/3/5) texture support for future games\r
-- Re-enabled q3map_surfaceModel support, and the 'oriented' flag works as well\r
-- Re-enabled (fixed, really) large external lightmap support\r
-- Fixed a bug in the model code that would cause a crash if an uninvertable\r
- matrix was created\r
-- Fixed a bug in Mathlib m4x4_t code where the tolerance for a singular matrix\r
- was too low and crapping out on small (scaled down) matrices\r
-- Fixed bug in divide-by-zero on lightmap efficiency calculation\r
-- Added -force switch, allows unsupported BSP formats to (try) to be loaded\r
-\r
-\r
-2.5.6 (2003-08-15)\r
-\r
-- New: can convert BSP files to MAP files via -convert -format map. Note: not\r
- perfect by any means, as certain pieces of data are irretrievably lost, such\r
- as func_group entities (including terrain specifics), brush face texturing\r
- info, and light/misc_model entities with Q3Map2-generated BSPs\r
-\r
-\r
-2.5.5\r
-\r
-- New: -scale N.N mode to scale the BSP\r
-- New: -light -lomem switch to supress trace BSP optimization. This\r
- feature trades lighting performance for decreased memory usage\r
-- New: Added negative light support (note: will not darken below _minlight value)\r
- might screw up radiosity, haven't tested much. Should work with entity\r
- lights, shader lights, sun/sky lights and radiosity. Lightfilter shadows\r
- tint negative lights too, so the end effect is subtraction of the color\r
-- New: Lightstyle support for non-Raven (JK2/SOF2) games, including Quake 3,\r
- RTCW, ET, EF. Only works with lightmapped surfaces, use with care\r
-- Fixed long standing terrain texturing bug, should produce exact desired\r
- results all of the time now. May require fixing alphamaps that were\r
- kludged together to accomodate this bug on existing maps\r
-- Fixed bug (huh, wtf) causing misc_model surfaces to not be fogged\r
-- Fixed bug where fog brushes wouldn't fog surfaces if a global map fog\r
- shader was present\r
-- Fixed bug where -patchmeta surfaces were being ignored for raytracing\r
-- Fixed long-standing bug where twosided surfaces were not correctly\r
- bouncing light. You can now have a foggy glass window that re-emits\r
- bright light with q3map_bounce 3.0 or so\r
-- Fixed really stupid bug in radiosity with bouncing styled lights\r
-- Stripping .map and appending .bsp in -info mode\r
-- Fixed bug where tesselated brush face surfaces were not being fogged\r
-- Twosided surfaces (using cull disable/twosided/none) are now lit twosided\r
-- Added tighter tolerance for alphashadow/lightfilter shadowing to raytracer\r
- which fixed problem with double shadows from tracing near triangle seams\r
-- Brush entities should now be properly fogged. Really.\r
-- Styled lightmaps are no longer affected by _minlight (doh)\r
-\r
-\r
-2.5.4 (2003-04-01)\r
-\r
-- New: q3map_tessSize support for JK2/SOF2\r
-- New: -lightmapsize N argument\r
-- Fixed bug where switched styled lights weren't working correctly in SOF2/JK2\r
-- Fixed bug where external lightmaps with generated shaders were referencing\r
- the wrong lightmap\r
-- Fixed bug causing lightgrid brushes to be ignored\r
-- Added variable sphere around trace sample points to inhibit occluder geometry\r
-\r
-\r
-2.5.3 (2003-03-06)\r
-\r
-- New: SOF2/JK2 light styles now supported\r
-- New: q3map_lightStyle N to set shader lightstyles\r
-- New: Tenebrae 2 support via -game tenebrae\r
-- New: -light -deluxe and -debugdeluxe for Tenebrae "deluxemap" static\r
- lighting algorithm\r
-- Light envelopes now properly clipped to the PVS\r
-- q3map_vertexScale re-enabled (scales vertex lighting per-shader)\r
-- Minor bug in brush bevel code corrected\r
-- Brushes from func_group entities are correctly sorted on insertion\r
-- Fixed a couple misc warnings to print "percent" instead of "%"\r
-- Added -custinfoparms support to -light mode to suppress warnings\r
-- _minlight, _minvertexlight and _mingridlight order independent, and now\r
- allow for values of 0\r
-\r
-\r
-2.5.2 (2003-02-17)\r
-\r
-- Fixed crash bugs with global map fog\r
-- Model loading really only warns once now\r
-\r
-\r
-2.5.1 (2003-02-17) (Splash Damage internal release)\r
-\r
-- Added more Hella-Fast juice to light code. Overall should be 35% faster\r
-- Refactored surface portion of raytracer code for less memory usage\r
-- Changed UVW epsilon in raytracer to catch more edge cases\r
-- Removed bounds check on occluded luxel finding, was causing more problems\r
- than it was solving\r
-- Adaptive antialiasing code now ignores unmapped luxels for better shadow\r
- edges and higher performance\r
-- Brushes in the BSP are now sorted opaque first\r
-- Fixed Really Stupid bug causing MapRawLightmap to take about 4x as long\r
-- Added optimization to make MapRawLightmap 2x as fast\r
-- New non-sucky quadrilateral subdivision of patches for MapRawLightmap\r
-- Patches with < 90 degrees of curvature are now box-lightmapped\r
-- Patch vertex normals now correctly stored, fixing bug in 2.5.0\r
-- Prints warning if map with < 10% detail brushes is detected\r
-\r
-\r
-2.5.0 (2003-02-14) (Splash Damage internal release)\r
-\r
-RAYTRACING AND SHADOW CALCULATION\r
-- New raytracing code. Rewrote the raytracer to maximize efficiency on modern\r
- "caulk-hull" maps. Uses triangle intercept code written by SPoG, based on code\r
- by Tomas Moller and Ben Trumbore (Journal of Graphics Tools, 2(1):21-28, 1997)\r
- and a biased octree leaf subdivision scheme by Y.T.\r
-- Shadows (casting and receiving) are now controllable per-entity\r
- New entity keys: "_castShadows" or "_cs" and "_receiveShadows" or "_rc"\r
- Values: 0 = no shadows, 1 = worldspawn shadows, > 1 explicit shadow group,\r
- negative values imply no worldspawn shadow interation.\r
- *Entities, including model2 and RTCW misc_gamemodels can now cast shadows*\r
-\r
-RADIOSITY\r
-- Bumped up default and smallest radiosity patch size. Performance should be\r
- approximately 4x with a small quality tradeoff\r
-- Radiosity patches now trace to centroid of triangle, and not bounds center\r
-- Radiosity and surface lights are now nudged around a bit if in solid\r
-- Radiosity light generation code is now thread-safe\r
-- Radiosity -dump files now .map instead of .pfb\r
-- Poorly worded "q3map_bounce" renamed to "q3map_bounceScale" (old still works)\r
-- New -bounceonly switch to store only bounced light in the BSP (for Tenebrae)\r
-\r
-MISC LIGHTING\r
-- Optimized case where light and sample are coplanar\r
-- Forcing nudged luxels to stay within lightmap surfaces' bounds\r
-\r
-CURVED SURFACES\r
-- New -subdivisions N argument, works with -patchmeta and -light for setting\r
- patch level-of-detail. Default value is 8, use 4 to simulate default Q3\r
-- All patch tesselation code changed to create x-patterned tesselation for\r
- better lighting\r
-- Storing patch LOD info in the .srf file for better patch light/shadows\r
-\r
-FOG\r
-- Reworked fog code to fix bad interation with fog and clipped models\r
-\r
-MODELS\r
-- Entities with attached MD3/ASE misc_models now have their bounds correctly set\r
-- Attached misc_models now support q3map_clipModel for solidity\r
-- Missing models will only warn once, rather than spew errors\r
-\r
-MISC\r
-- Metasurface merging no longer folds nonplanar triangles into planar surfaces\r
- and vice-versa *\r
-- Fixed Really Stupid Bug where entity numbering was not loaded by lighting code\r
- resulting in lightmaps merging across entity boundaries *\r
-\r
-* Might result in slightly larger BSP. For maximum efficiency, ungroup\r
- func_group entities before doing a final compile\r
-\r
-TODO\r
-+ Document new shadow stuff\r
-+ Merge adjacent light-casting triangles into convex windings\r
-\r
-\r
-2.3.38 (2003-02-07)\r
-\r
-- New lighting code, return of Smoove-B. Intelligently antialises shadow edges\r
- when you use the new -samples N switch. Get -extra quality in 1/3 the time\r
-- New lightmap filtering code. Now using a proper 0.25/0.5/1.0 filter kernel.\r
- Also operates on individual lightsources, so per-lightsource filter/kernel\r
- settings are now possible\r
-- New -patchmeta fixes, now does stitching and adaptive subdivision.\r
- Thanks Sock!\r
-- Nonsolid patches will no longer be in the BSP when run with -patchmeta\r
-- Misc fog fixes, including q3map_noFog support in maps with global _fog\r
- support (SOF2/JK2)\r
-- Now stripping misc_model entities from the BSP\r
-- Fixed disappearing face bug that's been present since 2.3.36.\r
- Thanks Shadowspawn!\r
-\r
-\r
-2.3.37 (2003-01-24)\r
-\r
-- Building from GtkRadiant CVS trunk\r
-- Added new brush bevel code by MrElusive to fix lingering aas problems (sweet!)\r
-- Added -snap N arg to BSP phase for axial bevel plane snapping to reduce\r
- clipped model plane count (note: will muck with above, use with care)\r
-- Patches in terrain entities should now have proper vertex alpha set\r
-- Fixed bug in fur code where fur was being limited to 2 layers (thanks pazur)\r
-- Reduced vertexlight search area to a reasonable size to keep vertex lighting\r
- times down\r
-\r
-\r
-2.3.36 (2003-01-15)\r
-\r
-- Plane hashing re-enabled (I suck)\r
-- Plane hashing optimized (faster parsing of larger maps)\r
-- Plane finding accuracy code enabled\r
-- New ASE clipping code\r
- + With above should be 10-50% faster\r
- + Should generate 33% fewer planes\r
- + Generates mostly-axial 5-sided polyhedra instead of pyramids,\r
- for tighter 2-sided clipping\r
-- New -light args:\r
- + -scale N -- scales all lightsources (area, radiosity, point, sky)\r
- + -sky[scale] N -- scales sky lights (q3map_skylight, q3map_sunlight)\r
-- Changed fur code to scale fur offset based on original vertex alpha\r
-\r
-\r
-2.3.35 (2003-01-14)\r
-\r
-- PicoModel now inverts ASE T coordinate\r
-- BSP to ASE converter now inverts T coordinate\r
-- Disabling 2.3.34 triangle optimization code until I find out why it crashes\r
-- Fixed Conscript-q3map2 to use stack_size ld flags directly on Darwin/OS X\r
-- Added Conscript-q3map2 to q3map2.dsp for easier Win32 edit, *nix target\r
-\r
-\r
-2.3.34 (2003-01-08)\r
-\r
-- Building from merged GtkRadiant 1.2 -> 1.3 merged codebase\r
-- IMPORTANT NEW CHANGE: Light entities are now STRIPPED from the BSP file.\r
- They are re-read in by -light from the MAP file. This has two consequences:\r
- + It is no longer necessary to re-BSP & re-vis a map in order to change\r
- lighting. You can just change lights in the map file and run -light.\r
- + Slightly smaller BSP file, due to fewer entities\r
- + Faster loading time, as the game code doesn't have to deal with them\r
-- Added new -ne (normal epsilon) and -de (distance epsilon) for tuning precision\r
- of plane snapping to correct potential AAS/BSP issues\r
-- Using latest PicoModel, with support for RTCW MDC models\r
-- Surfaces per raw lightmap are now sorted by shader name, which should give\r
- slightly better lightmap efficiency and lower in-game shader counts\r
-- Adjusted model code to use correct m4x4_t code & angles key\r
-- Minor bugfix in patch color gradient calculation code\r
-- Silenced erroneous areaportal warning spew\r
-- q3map_tcGen now works on model surfaces\r
-- Using default radiosity subdivide of 256 again (should make radiosity faster)\r
-- Enabled byte-swapping code so Q3Map2 can be compiled/run on little-endian\r
- architectures (Mac OS X)\r
-\r
-\r
-2.3.33 (2002-12-08)\r
-\r
-- Added new -bouncescale argument for radiosity scaling\r
-- Added -pointscale and -areascale for consistent naming\r
-- Radiosity patch subdivision code enhanced\r
-- Hint portals split the BSP first (higher priority)\r
-- Antiportal and areaportal faces split the BSP last, to minimize errors\r
-- Areaportals work internally like hint and antiportals, so they no longer need\r
- to be full brushes (the other sides can be skip)\r
-- External lightmaps are now named "lm_NNNN.tga" in the maps/mapname dir\r
-- Cleaned up some of -light argument processing\r
-- Planar surfaces w/o lightmaps will no longer be tagged as MST_TRIANGLE_SOUP\r
- (this fixes problems with Particle Studio particles dropping out of view)\r
-\r
-\r
-2.3.32 (2002-11-30)\r
-\r
-- GtkRadiant (1.2.11) integration\r
-- Added epsilon to texture plane choose code to eliminate numerical\r
- inconsistencies on brush faces slanted at 45 degree angles (bug 637)\r
-- Fixed bug in lightmap export after lighting when map contains 0 BSP lightmaps\r
-- Adjusted some light tracing constants to fix certain brush/patch seam shadows\r
-- Tinkered with skylight code again\r
-- Fixed bug where lightgrid would be black if level was compiled with -nogrid\r
-- Fixed -approx code to work in floating-point space, using _minlight\r
-- Fixed bug where vertex light code was using invalid pvs data to create\r
- light list for surface, leading to incorrect vertex lighting\r
-- Fixed related bug in anti-light-leak code that was causing brush faces to go\r
- black (bug 694)\r
-- New: _minlight sets _minvertexlight and (new) _mingridlight automatically\r
-- New: _mingridlight key to set minimum grid lighting\r
-\r
-\r
-2.3.31 (2002-11-21)\r
-\r
-- Stitching the edges of lightmaps on patches that wrap around (cyls and cones)\r
- so the seam is no longer visible\r
-- The -patchmeta switch works better now, the patches are still stored in the\r
- BSP for collision, but are pre-tesselated into nonplanar meta surfaces for\r
- more efficient rendering\r
-- Better, more uniform lightmap sample position finding on patch meshes\r
-- Moved q3map_tcMod and q3map_alphaMod processing to the final phase\r
-- New: q3map_skylight AMOUNT ITERATIONS to replace surfacelight on sky surfaces\r
- for much faster and more uniform sky illumination\r
-\r
-\r
-2.3.30 (Splash Damage internal release)\r
-\r
-- Fixed bug in PicoModel ASE material parsing code\r
-- Fixed a few seam/lightmap precision/projection errors\r
-- Increased MAX_SHADER FILES to 1024 and fixed overrun error when more than that\r
- number of shaders was listed in shaderlist.txt\r
-- Increased a few compiler maximums for larger maps\r
-- New: -np N switch on BSP phase, works like -shadeangle, in that it forces all\r
- planar shaders to be nonplanar with the shading angle specified\r
-- New: -nohint switch on BSP phase, omits hint brushes from compile for testing\r
-- New: -debugaxis switch on light mode. Colors lightmaps based on their lightmap\r
- axis (which direction the lightmap was projected on)\r
-- New: -debugorigin switch on light mode. Colors lightmaps based on the luxel\r
- origin relative to the raw lightmap's bounding box\r
-- New: -debugcluster switch on light mode. Colors lightmaps based on the pvs\r
- cluster the luxel falls into\r
-- New: -convert switch to convert BSP to ASE file (experimental)\r
-- New: q3map_lightmapmergable directive to allow terrain to be mapped onto a\r
- single lightmap page for seamless terrain shadows\r
-\r
-\r
-2.3.29 (2002-11-03)\r
-\r
-- Merged with latest CVS, fixed minor issues with matrix order\r
-- Fixed minor Sys_FPrintf/Sys_Printf substitution typo in Q3Map2\r
-- Expanded debug colors to 12 for debugging surface meshes\r
-- PicoModel: fixed ASE loader to support > 1 texture coordinate per-vertex,\r
- so more models supported correctly, also loading vertex normals\r
-- PicoModel: md3 shader names are now cleaned. Suffixes (such as .tga or .jpg)\r
- are stripped, and \ path separators are changed to /\r
-- New: Add :q3map to the end of any shader name, and it will be interpreted as\r
- the named shader minus :q3map. Example:\r
- textures/shaderlab/concrete:q3map -> textures/shaderlab/concrete\r
- One potential use is the -approx feature to collapse lightmapped surfaces\r
- into vertexlit surfaces, saving lightmap space/memory\r
-- New: q3map_clipModel -- does what you think it does, sort of. This code ix\r
- really experimental, and should *only* be used on large models such as terrain\r
- (not small decorative models). This code will be evolving. Note: the shader's\r
- surfaceparms are inherited by the magic clip brush, so if you have nonsolid\r
- in your model's shader that uses q3map_clipModel, then the brush will also\r
- be nonsolid\r
-\r
-\r
-2.3.28 (2002-11-01)\r
-\r
-- Bug 654 (http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=654):\r
- Fixed problem where brush faces, drawsurfaces, and surfaceparms weren't living\r
- together in perfect harmony (terrain surfaceparms now inherited by brushes)\r
-- Nodraw fog works now, albeit when you're underneath, surfaces above don't get\r
- fogged properly. Could be good for foggy water where you want the above-water\r
- portions to only be occluded by the water surface\r
-- Bug 656 (http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=656):\r
- Number of lightgrid points displayed (byte size is currently out of proportion\r
- due to internal storage format) when Q3Map is called with the -info switch\r
-- Fixed wack surface merging bug where code would attempt to merge triangles not\r
- adjacent to the current set, causing bad lightmap projections on nonplanar\r
- surfaces\r
-- Fixed tiny 1-character bug in 2d lightmap texture allocator where adjacent\r
- luxels were being checked for occlusion rather than the actual source luxel\r
-\r
-\r
-2.3.27 (2002-10-31) Happy Halloween!\r
-\r
-- Fixed minor bug in scriplib bugfix where the last character in a file wasn't\r
- being read.\r
-- Fixed bug where 0-area or bogus triangles were causing crash in MapRawLightmap\r
- if they used a shader with a normalmap (thanks ShadowSpawn)\r
-- Fixed bug where lightmaps were getting hosed levelwide on a prerelease version\r
- of 2.3.27\r
-- Fixed bug where lightmaps were getting knackered on models and certain patches\r
-- Merged latest PicoModel version from seaw0lf, adding support for ASE and WF OBJ\r
- models (preliminary)\r
-- Increased MAX_MAP_PLANES to 0x40000 (~256k)\r
-\r
-Known issues:\r
-- Lightmap projection and surface merging on large ASE models sometimes flakes\r
-- Surface to brush surfaceparm propogation doesn't work properly with large\r
- metasurfaces: http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=654\r
-\r
-\r
-2.3.26 (2002-10-27)\r
-\r
-- Now using GtkRadiant's libpng and zlib config (linked as DLLs)\r
-- Fixed bug in script parser where repeat calls to GetToken() were causing\r
- memory corruption\r
-- Fixed SOF2 -rename bug\r
-- When using -game sof2 or -game jk2, the -flares argument is implied\r
-- Added -noflares argument to disable the above behavior\r
-- Added support for flares on entities. Use one of the following keys:\r
- "_flare" "1" -- use default flare (different for each game)\r
- "_flareshader" "path/to/flareshader" -- use a specific flare shader\r
- Note: This only matters in SOF2/JK2 now. Make a light targetted (a spotlight)\r
- to get it to aim the correct direction, otherwise it defaults to pointing \r
- downward. You cannot have omnidirectional flares\r
-- Lightgrid size is automatically increased to accomodate large maps. The\r
- MAX_MAP_LIGHTGRID error will never happen again\r
-\r
-\r
-2.3.25 (2002-10-22)\r
-\r
-- Go Giants!\r
-- Fixed bug where Q3Map would crash on writing the BSP after the light stage.\r
- Thanks to Rap7or (#q3map) and loon8 (Q3W forums) [bug 641]\r
-- Fixed bug where surface lights were not affecting the light grid properly.\r
- Thanks to Shadowspawn and djbob [bug 642]\r
-- NEW: Added -faster support to lightgrid calculations while fixing previous bug\r
-- NEW: Changed it so the BSP file is written to a temp file first, then renamed.\r
- This should prevent BSP file corruption on crashes during writes\r
-\r
-\r
-2.3.24 (2002-10-20)\r
-\r
-- Fixed numerous outstanding bugs and issues.\r
-- Normal interpolation is now improved. It's slightly slower, but more 'correct'\r
- in cases where you have 10 triangles in one plane and 1 triangle in another\r
- meeting up and the 10 triangles were over-affecting the average. Only new\r
- identical normals are averaged now. This change affects phong shading, meta\r
- surfaces, and PicoModel\r
-- PicoModel up to version 0.7.6, BSD license, better 3DS model support\r
-- PicoModel library now fixes broken normals on MD3 and 3DS models\r
-- Bumpmapping code is improved. The correct tangent vectors per-triangle are\r
- now calculated so the bumpmaps are consistent with regards to light direction\r
-- Metasurface merging code optimized. Should be about 100x as fast on complex\r
- maps or maps using models with high triangle counts\r
-- Vertexlight code tweaked a bit\r
-- Triangle/winding orders now more consistent. Tesselated surfaces will have\r
- a uniform triangle ordering (thanks RR2DO2)\r
-- NEW: "vertexDeform move" now parsed and surfaces are merged into the\r
- appropriate BSP leaves they may enter into (thanks to Bart Vrijkorte)\r
-- NEW: shader command: q3map_alphaMod. Currently takes a single form:\r
- q3map_alphaMod dotproduct ( NX NY NZ )\r
- where NX NY NZ are a unit normal (length of 1.0) specifying direction.\r
- An example use would be snow in a shader's 2nd pass, using alphaFunc or\r
- blendFunc:\r
- q3map_alphaMod dotproduct ( 0 0 1 ) // surfaces facing upwards have snow\r
- (idea contributed by RR2DO2)\r
-\r
-\r
-2.3.23 (2002-10-18)\r
-\r
-- In my haste to release the previous version, I neglected to give credit where\r
- it was due. Seaw0lf had as much (probably more) to do with the new model\r
- loading library (PicoModel). Because of his efforts, you can load 3DS models\r
- and use them in misc_model entities.\r
-- PicoModel model library up to version 0.7. Improved 3DS support, more stable.\r
-- Surface models still not reenabled. Soon. :)\r
-- You can now remap a misc_model's shaders like this:\r
- Key "_remapNN" "the/model/shader;the/real/shader"\r
- This works just like TA terrain vertexRemapShader key. You can also supply a\r
- * glob for the source shader if you want all your model's shaders to use the\r
- specified shader:\r
- "_remap" "*;models/mapobjects/tree/bark"\r
-\r
-\r
-2.3.22 (2002-10-16)\r
-\r
-- Moving to sensible Linux-style versioning.\r
-- The misc_model code has been completely rewritten, breaking surface models.\r
- Surface models will reappear in the next release, once the new model API has\r
- stablized.\r
-- New: MD3 and 3D Studio 3DS models now natively supported.\r
-- The misc_model "angles" key now supported. Values: "pitch yaw roll" in keeping\r
- with standard Quake 3 angles order.\r
-- Models scaled with "modelscale_vec" now have proper normal scaling/rotation\r
- (thanks SPOG).\r
-- Models can now be lightmapped.\r
-- Models can now have > 1000 vertexes per surface.\r
-- For best results for above, add the following to models' shaders:\r
- q3map_splotchfix\r
- q3map_nonplanar\r
-- 3DS models' MATERIAL NAMES ARE THE FINAL Q3 SHADER NAMES. YOU HAVE BEEN WARNED.\r
-- Models are generally 13373R. :)\r
-\r
-\r
-2.3.0-a21 (2002-10-02)\r
-\r
-- Fixed a stack of really stupid bugs in the lightgrid code. Should be faster\r
- and more predictable now.\r
-- SOF2/JK2 lightgrid now compiled. This is the first version of Q3Map2 that can\r
- compile full, release-worthy SOF2 and JK2 maps.\r
-- SOF2/JK2 damageshader and damagable brush faces should work correctly now.\r
-\r
-\r
-2.3.0-a20 (2002-09-26)\r
-\r
-- SOF2/JK2 worldspawn "fog" (and "_fog") shader key support for levelwide fog\r
-- SOF2/JK2 light "scale" key to scale light brightness\r
-- SOF2/JK2 -rename function for _bsp and _rmg_bsp shader renaming\r
-\r
-\r
-2.3.0-a19 (2002-09-24)\r
-\r
-- Shaders can now be subclassed (Q3Map relavant portions only, such as\r
- surfaceparms, lighting, texture projection, etc). To subclass an existing\r
- shader, add "q3map_baseshader X" where X is the name of the base shader.\r
-- Preliminary auto-model distribution over surfaces. You can now have things\r
- like grass and tree models automatically distributed across your terrain\r
- or other surfaces. To wit:\r
-\r
- q3map_surfacemodel models/mapobjects/tree2/tree2.md3 64 0.001 0.5 4.0 0 360 1\r
-\r
- q3map_surfacemodel <path to md3> <density in units> <odds of appearing>\r
- <min scale> <max scale> <min angle> <max angle> <oriented>\r
- \r
- The last flag is 1 or 0, and sets whether the model gets fitted to the\r
- orientation of the surface. Not functional yet. See screenshots page for\r
- shots of this in action.\r
-\r
-\r
-2.3.0-a18 (2002-09-21)\r
-\r
-- misc_models can now be attached to any brush model entity. Just target the\r
- brush entity with the misc_model (select model, then entity, hit Ctrl+K)\r
-- q3map_tcMod translate (or shift or offset) <s offset> <t offset>\r
-- q3map_tcMod rotate <degrees> (rotates around origin, not center)\r
-- q3map_tcMod scale <s scale> <t scale>\r
-- Metasurface merging now much, much better. Merges into roughly rectangular or\r
- square areas wherever possible\r
-- q3map_terrain no longer sets Z-axis lightmap projection. It must be set in\r
- the terrain layer shaders if you want previous behavior\r
-- Worlspawn _blocksize key now supports 3 elements for setting X Y and Z splits\r
- independently of each other (use a value of 0 for no splits on that axis)\r
-- Misc bugfixes\r
-\r
-\r
-2.3.0-a1 through 2.3.0-a17 (2002-07 through 2002-09-20)\r
-\r
-- Elite Force support (via -game ef)\r
-- SOF2 and JK2 support (via -game sof2 or -game jk2)\r
-- All new image handling with PNG support\r
-- q3map_lightimage specifies image for radiosity and lighting\r
-- External lightmaps, set using q3map_lightmapsize <width> <height>. Up to\r
- 1024 x 1024 supported.\r
-- q3map_lightmapGamma <value> sets the brightness scale of a lightmap\r
-- q3map_lightmapsampleoffset <distance> to fix glitches in lightmapped terrain\r
-- Tons more features and bugfixes. See the forum threads for details/screenshots\r
-- Two new surfaceparms, "antiportal" and "skip," and associated shaders, for\r
- allowing the mapper to more cleanly set up visibility data\r
-- Lightmaps will always have square texels now (no more stretching)\r
-- Vertex light improvements\r
-- Light grid improvements\r
-- q3map_lightrgb support for RTCW\r
-\r
-\r
-\r
-\r
-\r
-\r
+Q3Map2 Version History + Changelog (Reverse Chronological Order)
+
+2.5.11 (2003-12-01)
+
+- New: added support for _skybox entities to generate "portal sky"
+ surfaces in games w/o native support (Quake 3). _skybox entities have
+ 3 keys: _scale (default 64), and angle/angles (for rotation of the
+ skybox relative to the map)
+- New: added -skyfix switch to BSP phase as a workaround hack for
+ the black GL_CLAMP border on skybox edges on ATI (and newer nvidia)
+ video cards. Note: unnecessary in ET or JA
+- New: Added _anglescale to light entities for scaling angle attenuation.
+ Use a small value (< 1.0) to lessen the angle attenuation, and a high
+ value (> 1.0) for sharper, more faceted lighting
+- New: Added _lightmapscale support to misc_model entities
+- Custom shaders (external lightmaps, styles) will not be generated
+ if the find/replace text cannot be found
+- Tightened up light culling epsilon from 1.0 to 0.125 to stop certain
+ surface lights from being incorrectly culled (thanks RasputiN!)
+- Fixed bug where small 3 and 4 sided brush faces were getting fanned,
+ adding triangle/vertex counts
+- Moved to Visual Studio .NET, with aggressive optimizations enabled
+- Cleaned up missing image warnings
+- Parsing images out of shader stages if not found explicit/implicitly
+- Loads Enemy Territory implicitMap images if editor/light image not found
+
+
+2.5.10 (2003-10-22)
+
+- New: Lightwave model support (beta) courtesy of RR2DO2
+- New: Heretic 2 FM model support courtesy of Nurail
+- Re-enabled vertex cache friendly triangle reordering with fix
+- Disabled triangle reordering on certain surfaces, including autosprite
+ shaders due to visual errors
+- Fixed bug in radiosity where sorting of lights by style took forever.
+ Thanks ReBoOT!
+- Fixed bug in sun lighting code where maps too far off the origin would
+ not be properly it by sun or sky light. Thanks MindLink!
+- Entity causing a leak will be printed and selected in Radiant if BSP
+ monitoring is enabled. Requested by heeen
+- Fixed odd bug causing 10x slowdown in lighting in some maps. Should
+ be back to 2.5.7 performance. Also fixed a couple old bugs related to
+ autosprite shader (point) lights and backsplash lights not being styled
+ or setup correctly
+
+
+2.5.9 (2003-10-12)
+
+- Disabled triangle reordering for now (crashing on some maps)
+
+
+2.5.8 (2003-10-02)
+
+- New: Added two new sun parameters: angular deviation (width of the sun in
+ degrees) and sampling count (jitters). This allows for decent approximation
+ of penumbra "half-shadow" effects from sunlight with 16+ samples. These
+ parameters are accessible for entity lights (including spots and suns) via
+ these entity keys: _deviance and _samples. To use in shaders, use the new
+ q3map_sunExt <r> <g> <b> <brightness> <angle> <elevation> <deviance> <samples>
+- New: q3map_lightmapFilterRadius <self> <other> for light-emitting shaders.
+ Put *after* any q3map_sun directives or else your sun will be filtered. This
+ is good for eliminating the "stadium lighting" effect from q3map_skyLight.
+ Also usable as an entity key: _filterradius or _filter
+- New: Quake 2 MD2 model support in PicoModel for misc_model entities
+ (thanks to Nurail!)
+- Re-enabled vertex-cache-aware triangle reordering. Will probably have a
+ negligible effect on rendering performance, but can't hurt
+- Added short-circuit to raytracer: any empty nodes (including children) are
+ ignored on sun traces
+- Added BSP file size printout
+- Filtering of any kind now disables adaptive supersampling on a per-light,
+ per-ightmap basis
+- Fixed another _minlight <-> styled light interaction bug (thanks pjw!)
+
+
+2.5.7 (2003-08-31)
+
+- New: Jedi Academy support via -game ja
+- New: DDS (DXT1/3/5) texture support for future games
+- Re-enabled q3map_surfaceModel support, and the 'oriented' flag works as well
+- Re-enabled (fixed, really) large external lightmap support
+- Fixed a bug in the model code that would cause a crash if an uninvertable
+ matrix was created
+- Fixed a bug in Mathlib m4x4_t code where the tolerance for a singular matrix
+ was too low and crapping out on small (scaled down) matrices
+- Fixed bug in divide-by-zero on lightmap efficiency calculation
+- Added -force switch, allows unsupported BSP formats to (try) to be loaded
+
+
+2.5.6 (2003-08-15)
+
+- New: can convert BSP files to MAP files via -convert -format map. Note: not
+ perfect by any means, as certain pieces of data are irretrievably lost, such
+ as func_group entities (including terrain specifics), brush face texturing
+ info, and light/misc_model entities with Q3Map2-generated BSPs
+
+
+2.5.5
+
+- New: -scale N.N mode to scale the BSP
+- New: -light -lomem switch to supress trace BSP optimization. This
+ feature trades lighting performance for decreased memory usage
+- New: Added negative light support (note: will not darken below _minlight value)
+ might screw up radiosity, haven't tested much. Should work with entity
+ lights, shader lights, sun/sky lights and radiosity. Lightfilter shadows
+ tint negative lights too, so the end effect is subtraction of the color
+- New: Lightstyle support for non-Raven (JK2/SOF2) games, including Quake 3,
+ RTCW, ET, EF. Only works with lightmapped surfaces, use with care
+- Fixed long standing terrain texturing bug, should produce exact desired
+ results all of the time now. May require fixing alphamaps that were
+ kludged together to accomodate this bug on existing maps
+- Fixed bug (huh, wtf) causing misc_model surfaces to not be fogged
+- Fixed bug where fog brushes wouldn't fog surfaces if a global map fog
+ shader was present
+- Fixed bug where -patchmeta surfaces were being ignored for raytracing
+- Fixed long-standing bug where twosided surfaces were not correctly
+ bouncing light. You can now have a foggy glass window that re-emits
+ bright light with q3map_bounce 3.0 or so
+- Fixed really stupid bug in radiosity with bouncing styled lights
+- Stripping .map and appending .bsp in -info mode
+- Fixed bug where tesselated brush face surfaces were not being fogged
+- Twosided surfaces (using cull disable/twosided/none) are now lit twosided
+- Added tighter tolerance for alphashadow/lightfilter shadowing to raytracer
+ which fixed problem with double shadows from tracing near triangle seams
+- Brush entities should now be properly fogged. Really.
+- Styled lightmaps are no longer affected by _minlight (doh)
+
+
+2.5.4 (2003-04-01)
+
+- New: q3map_tessSize support for JK2/SOF2
+- New: -lightmapsize N argument
+- Fixed bug where switched styled lights weren't working correctly in SOF2/JK2
+- Fixed bug where external lightmaps with generated shaders were referencing
+ the wrong lightmap
+- Fixed bug causing lightgrid brushes to be ignored
+- Added variable sphere around trace sample points to inhibit occluder geometry
+
+
+2.5.3 (2003-03-06)
+
+- New: SOF2/JK2 light styles now supported
+- New: q3map_lightStyle N to set shader lightstyles
+- New: Tenebrae 2 support via -game tenebrae
+- New: -light -deluxe and -debugdeluxe for Tenebrae "deluxemap" static
+ lighting algorithm
+- Light envelopes now properly clipped to the PVS
+- q3map_vertexScale re-enabled (scales vertex lighting per-shader)
+- Minor bug in brush bevel code corrected
+- Brushes from func_group entities are correctly sorted on insertion
+- Fixed a couple misc warnings to print "percent" instead of "%"
+- Added -custinfoparms support to -light mode to suppress warnings
+- _minlight, _minvertexlight and _mingridlight order independent, and now
+ allow for values of 0
+
+
+2.5.2 (2003-02-17)
+
+- Fixed crash bugs with global map fog
+- Model loading really only warns once now
+
+
+2.5.1 (2003-02-17) (Splash Damage internal release)
+
+- Added more Hella-Fast juice to light code. Overall should be 35% faster
+- Refactored surface portion of raytracer code for less memory usage
+- Changed UVW epsilon in raytracer to catch more edge cases
+- Removed bounds check on occluded luxel finding, was causing more problems
+ than it was solving
+- Adaptive antialiasing code now ignores unmapped luxels for better shadow
+ edges and higher performance
+- Brushes in the BSP are now sorted opaque first
+- Fixed Really Stupid bug causing MapRawLightmap to take about 4x as long
+- Added optimization to make MapRawLightmap 2x as fast
+- New non-sucky quadrilateral subdivision of patches for MapRawLightmap
+- Patches with < 90 degrees of curvature are now box-lightmapped
+- Patch vertex normals now correctly stored, fixing bug in 2.5.0
+- Prints warning if map with < 10% detail brushes is detected
+
+
+2.5.0 (2003-02-14) (Splash Damage internal release)
+
+RAYTRACING AND SHADOW CALCULATION
+- New raytracing code. Rewrote the raytracer to maximize efficiency on modern
+ "caulk-hull" maps. Uses triangle intercept code written by SPoG, based on code
+ by Tomas Moller and Ben Trumbore (Journal of Graphics Tools, 2(1):21-28, 1997)
+ and a biased octree leaf subdivision scheme by Y.T.
+- Shadows (casting and receiving) are now controllable per-entity
+ New entity keys: "_castShadows" or "_cs" and "_receiveShadows" or "_rc"
+ Values: 0 = no shadows, 1 = worldspawn shadows, > 1 explicit shadow group,
+ negative values imply no worldspawn shadow interation.
+ *Entities, including model2 and RTCW misc_gamemodels can now cast shadows*
+
+RADIOSITY
+- Bumped up default and smallest radiosity patch size. Performance should be
+ approximately 4x with a small quality tradeoff
+- Radiosity patches now trace to centroid of triangle, and not bounds center
+- Radiosity and surface lights are now nudged around a bit if in solid
+- Radiosity light generation code is now thread-safe
+- Radiosity -dump files now .map instead of .pfb
+- Poorly worded "q3map_bounce" renamed to "q3map_bounceScale" (old still works)
+- New -bounceonly switch to store only bounced light in the BSP (for Tenebrae)
+
+MISC LIGHTING
+- Optimized case where light and sample are coplanar
+- Forcing nudged luxels to stay within lightmap surfaces' bounds
+
+CURVED SURFACES
+- New -subdivisions N argument, works with -patchmeta and -light for setting
+ patch level-of-detail. Default value is 8, use 4 to simulate default Q3
+- All patch tesselation code changed to create x-patterned tesselation for
+ better lighting
+- Storing patch LOD info in the .srf file for better patch light/shadows
+
+FOG
+- Reworked fog code to fix bad interation with fog and clipped models
+
+MODELS
+- Entities with attached MD3/ASE misc_models now have their bounds correctly set
+- Attached misc_models now support q3map_clipModel for solidity
+- Missing models will only warn once, rather than spew errors
+
+MISC
+- Metasurface merging no longer folds nonplanar triangles into planar surfaces
+ and vice-versa *
+- Fixed Really Stupid Bug where entity numbering was not loaded by lighting code
+ resulting in lightmaps merging across entity boundaries *
+
+* Might result in slightly larger BSP. For maximum efficiency, ungroup
+ func_group entities before doing a final compile
+
+TODO
++ Document new shadow stuff
++ Merge adjacent light-casting triangles into convex windings
+
+
+2.3.38 (2003-02-07)
+
+- New lighting code, return of Smoove-B. Intelligently antialises shadow edges
+ when you use the new -samples N switch. Get -extra quality in 1/3 the time
+- New lightmap filtering code. Now using a proper 0.25/0.5/1.0 filter kernel.
+ Also operates on individual lightsources, so per-lightsource filter/kernel
+ settings are now possible
+- New -patchmeta fixes, now does stitching and adaptive subdivision.
+ Thanks Sock!
+- Nonsolid patches will no longer be in the BSP when run with -patchmeta
+- Misc fog fixes, including q3map_noFog support in maps with global _fog
+ support (SOF2/JK2)
+- Now stripping misc_model entities from the BSP
+- Fixed disappearing face bug that's been present since 2.3.36.
+ Thanks Shadowspawn!
+
+
+2.3.37 (2003-01-24)
+
+- Building from GtkRadiant CVS trunk
+- Added new brush bevel code by MrElusive to fix lingering aas problems (sweet!)
+- Added -snap N arg to BSP phase for axial bevel plane snapping to reduce
+ clipped model plane count (note: will muck with above, use with care)
+- Patches in terrain entities should now have proper vertex alpha set
+- Fixed bug in fur code where fur was being limited to 2 layers (thanks pazur)
+- Reduced vertexlight search area to a reasonable size to keep vertex lighting
+ times down
+
+
+2.3.36 (2003-01-15)
+
+- Plane hashing re-enabled (I suck)
+- Plane hashing optimized (faster parsing of larger maps)
+- Plane finding accuracy code enabled
+- New ASE clipping code
+ + With above should be 10-50% faster
+ + Should generate 33% fewer planes
+ + Generates mostly-axial 5-sided polyhedra instead of pyramids,
+ for tighter 2-sided clipping
+- New -light args:
+ + -scale N -- scales all lightsources (area, radiosity, point, sky)
+ + -sky[scale] N -- scales sky lights (q3map_skylight, q3map_sunlight)
+- Changed fur code to scale fur offset based on original vertex alpha
+
+
+2.3.35 (2003-01-14)
+
+- PicoModel now inverts ASE T coordinate
+- BSP to ASE converter now inverts T coordinate
+- Disabling 2.3.34 triangle optimization code until I find out why it crashes
+- Fixed Conscript-q3map2 to use stack_size ld flags directly on Darwin/OS X
+- Added Conscript-q3map2 to q3map2.dsp for easier Win32 edit, *nix target
+
+
+2.3.34 (2003-01-08)
+
+- Building from merged GtkRadiant 1.2 -> 1.3 merged codebase
+- IMPORTANT NEW CHANGE: Light entities are now STRIPPED from the BSP file.
+ They are re-read in by -light from the MAP file. This has two consequences:
+ + It is no longer necessary to re-BSP & re-vis a map in order to change
+ lighting. You can just change lights in the map file and run -light.
+ + Slightly smaller BSP file, due to fewer entities
+ + Faster loading time, as the game code doesn't have to deal with them
+- Added new -ne (normal epsilon) and -de (distance epsilon) for tuning precision
+ of plane snapping to correct potential AAS/BSP issues
+- Using latest PicoModel, with support for RTCW MDC models
+- Surfaces per raw lightmap are now sorted by shader name, which should give
+ slightly better lightmap efficiency and lower in-game shader counts
+- Adjusted model code to use correct m4x4_t code & angles key
+- Minor bugfix in patch color gradient calculation code
+- Silenced erroneous areaportal warning spew
+- q3map_tcGen now works on model surfaces
+- Using default radiosity subdivide of 256 again (should make radiosity faster)
+- Enabled byte-swapping code so Q3Map2 can be compiled/run on little-endian
+ architectures (Mac OS X)
+
+
+2.3.33 (2002-12-08)
+
+- Added new -bouncescale argument for radiosity scaling
+- Added -pointscale and -areascale for consistent naming
+- Radiosity patch subdivision code enhanced
+- Hint portals split the BSP first (higher priority)
+- Antiportal and areaportal faces split the BSP last, to minimize errors
+- Areaportals work internally like hint and antiportals, so they no longer need
+ to be full brushes (the other sides can be skip)
+- External lightmaps are now named "lm_NNNN.tga" in the maps/mapname dir
+- Cleaned up some of -light argument processing
+- Planar surfaces w/o lightmaps will no longer be tagged as MST_TRIANGLE_SOUP
+ (this fixes problems with Particle Studio particles dropping out of view)
+
+
+2.3.32 (2002-11-30)
+
+- GtkRadiant (1.2.11) integration
+- Added epsilon to texture plane choose code to eliminate numerical
+ inconsistencies on brush faces slanted at 45 degree angles (bug 637)
+- Fixed bug in lightmap export after lighting when map contains 0 BSP lightmaps
+- Adjusted some light tracing constants to fix certain brush/patch seam shadows
+- Tinkered with skylight code again
+- Fixed bug where lightgrid would be black if level was compiled with -nogrid
+- Fixed -approx code to work in floating-point space, using _minlight
+- Fixed bug where vertex light code was using invalid pvs data to create
+ light list for surface, leading to incorrect vertex lighting
+- Fixed related bug in anti-light-leak code that was causing brush faces to go
+ black (bug 694)
+- New: _minlight sets _minvertexlight and (new) _mingridlight automatically
+- New: _mingridlight key to set minimum grid lighting
+
+
+2.3.31 (2002-11-21)
+
+- Stitching the edges of lightmaps on patches that wrap around (cyls and cones)
+ so the seam is no longer visible
+- The -patchmeta switch works better now, the patches are still stored in the
+ BSP for collision, but are pre-tesselated into nonplanar meta surfaces for
+ more efficient rendering
+- Better, more uniform lightmap sample position finding on patch meshes
+- Moved q3map_tcMod and q3map_alphaMod processing to the final phase
+- New: q3map_skylight AMOUNT ITERATIONS to replace surfacelight on sky surfaces
+ for much faster and more uniform sky illumination
+
+
+2.3.30 (Splash Damage internal release)
+
+- Fixed bug in PicoModel ASE material parsing code
+- Fixed a few seam/lightmap precision/projection errors
+- Increased MAX_SHADER FILES to 1024 and fixed overrun error when more than that
+ number of shaders was listed in shaderlist.txt
+- Increased a few compiler maximums for larger maps
+- New: -np N switch on BSP phase, works like -shadeangle, in that it forces all
+ planar shaders to be nonplanar with the shading angle specified
+- New: -nohint switch on BSP phase, omits hint brushes from compile for testing
+- New: -debugaxis switch on light mode. Colors lightmaps based on their lightmap
+ axis (which direction the lightmap was projected on)
+- New: -debugorigin switch on light mode. Colors lightmaps based on the luxel
+ origin relative to the raw lightmap's bounding box
+- New: -debugcluster switch on light mode. Colors lightmaps based on the pvs
+ cluster the luxel falls into
+- New: -convert switch to convert BSP to ASE file (experimental)
+- New: q3map_lightmapmergable directive to allow terrain to be mapped onto a
+ single lightmap page for seamless terrain shadows
+
+
+2.3.29 (2002-11-03)
+
+- Merged with latest CVS, fixed minor issues with matrix order
+- Fixed minor Sys_FPrintf/Sys_Printf substitution typo in Q3Map2
+- Expanded debug colors to 12 for debugging surface meshes
+- PicoModel: fixed ASE loader to support > 1 texture coordinate per-vertex,
+ so more models supported correctly, also loading vertex normals
+- PicoModel: md3 shader names are now cleaned. Suffixes (such as .tga or .jpg)
+ are stripped, and \ path separators are changed to /
+- New: Add :q3map to the end of any shader name, and it will be interpreted as
+ the named shader minus :q3map. Example:
+ textures/shaderlab/concrete:q3map -> textures/shaderlab/concrete
+ One potential use is the -approx feature to collapse lightmapped surfaces
+ into vertexlit surfaces, saving lightmap space/memory
+- New: q3map_clipModel -- does what you think it does, sort of. This code ix
+ really experimental, and should *only* be used on large models such as terrain
+ (not small decorative models). This code will be evolving. Note: the shader's
+ surfaceparms are inherited by the magic clip brush, so if you have nonsolid
+ in your model's shader that uses q3map_clipModel, then the brush will also
+ be nonsolid
+
+
+2.3.28 (2002-11-01)
+
+- Bug 654 (http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=654):
+ Fixed problem where brush faces, drawsurfaces, and surfaceparms weren't living
+ together in perfect harmony (terrain surfaceparms now inherited by brushes)
+- Nodraw fog works now, albeit when you're underneath, surfaces above don't get
+ fogged properly. Could be good for foggy water where you want the above-water
+ portions to only be occluded by the water surface
+- Bug 656 (http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=656):
+ Number of lightgrid points displayed (byte size is currently out of proportion
+ due to internal storage format) when Q3Map is called with the -info switch
+- Fixed wack surface merging bug where code would attempt to merge triangles not
+ adjacent to the current set, causing bad lightmap projections on nonplanar
+ surfaces
+- Fixed tiny 1-character bug in 2d lightmap texture allocator where adjacent
+ luxels were being checked for occlusion rather than the actual source luxel
+
+
+2.3.27 (2002-10-31) Happy Halloween!
+
+- Fixed minor bug in scriplib bugfix where the last character in a file wasn't
+ being read.
+- Fixed bug where 0-area or bogus triangles were causing crash in MapRawLightmap
+ if they used a shader with a normalmap (thanks ShadowSpawn)
+- Fixed bug where lightmaps were getting hosed levelwide on a prerelease version
+ of 2.3.27
+- Fixed bug where lightmaps were getting knackered on models and certain patches
+- Merged latest PicoModel version from seaw0lf, adding support for ASE and WF OBJ
+ models (preliminary)
+- Increased MAX_MAP_PLANES to 0x40000 (~256k)
+
+Known issues:
+- Lightmap projection and surface merging on large ASE models sometimes flakes
+- Surface to brush surfaceparm propogation doesn't work properly with large
+ metasurfaces: http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=654
+
+
+2.3.26 (2002-10-27)
+
+- Now using GtkRadiant's libpng and zlib config (linked as DLLs)
+- Fixed bug in script parser where repeat calls to GetToken() were causing
+ memory corruption
+- Fixed SOF2 -rename bug
+- When using -game sof2 or -game jk2, the -flares argument is implied
+- Added -noflares argument to disable the above behavior
+- Added support for flares on entities. Use one of the following keys:
+ "_flare" "1" -- use default flare (different for each game)
+ "_flareshader" "path/to/flareshader" -- use a specific flare shader
+ Note: This only matters in SOF2/JK2 now. Make a light targetted (a spotlight)
+ to get it to aim the correct direction, otherwise it defaults to pointing
+ downward. You cannot have omnidirectional flares
+- Lightgrid size is automatically increased to accomodate large maps. The
+ MAX_MAP_LIGHTGRID error will never happen again
+
+
+2.3.25 (2002-10-22)
+
+- Go Giants!
+- Fixed bug where Q3Map would crash on writing the BSP after the light stage.
+ Thanks to Rap7or (#q3map) and loon8 (Q3W forums) [bug 641]
+- Fixed bug where surface lights were not affecting the light grid properly.
+ Thanks to Shadowspawn and djbob [bug 642]
+- NEW: Added -faster support to lightgrid calculations while fixing previous bug
+- NEW: Changed it so the BSP file is written to a temp file first, then renamed.
+ This should prevent BSP file corruption on crashes during writes
+
+
+2.3.24 (2002-10-20)
+
+- Fixed numerous outstanding bugs and issues.
+- Normal interpolation is now improved. It's slightly slower, but more 'correct'
+ in cases where you have 10 triangles in one plane and 1 triangle in another
+ meeting up and the 10 triangles were over-affecting the average. Only new
+ identical normals are averaged now. This change affects phong shading, meta
+ surfaces, and PicoModel
+- PicoModel up to version 0.7.6, BSD license, better 3DS model support
+- PicoModel library now fixes broken normals on MD3 and 3DS models
+- Bumpmapping code is improved. The correct tangent vectors per-triangle are
+ now calculated so the bumpmaps are consistent with regards to light direction
+- Metasurface merging code optimized. Should be about 100x as fast on complex
+ maps or maps using models with high triangle counts
+- Vertexlight code tweaked a bit
+- Triangle/winding orders now more consistent. Tesselated surfaces will have
+ a uniform triangle ordering (thanks RR2DO2)
+- NEW: "vertexDeform move" now parsed and surfaces are merged into the
+ appropriate BSP leaves they may enter into (thanks to Bart Vrijkorte)
+- NEW: shader command: q3map_alphaMod. Currently takes a single form:
+ q3map_alphaMod dotproduct ( NX NY NZ )
+ where NX NY NZ are a unit normal (length of 1.0) specifying direction.
+ An example use would be snow in a shader's 2nd pass, using alphaFunc or
+ blendFunc:
+ q3map_alphaMod dotproduct ( 0 0 1 ) // surfaces facing upwards have snow
+ (idea contributed by RR2DO2)
+
+
+2.3.23 (2002-10-18)
+
+- In my haste to release the previous version, I neglected to give credit where
+ it was due. Seaw0lf had as much (probably more) to do with the new model
+ loading library (PicoModel). Because of his efforts, you can load 3DS models
+ and use them in misc_model entities.
+- PicoModel model library up to version 0.7. Improved 3DS support, more stable.
+- Surface models still not reenabled. Soon. :)
+- You can now remap a misc_model's shaders like this:
+ Key "_remapNN" "the/model/shader;the/real/shader"
+ This works just like TA terrain vertexRemapShader key. You can also supply a
+ * glob for the source shader if you want all your model's shaders to use the
+ specified shader:
+ "_remap" "*;models/mapobjects/tree/bark"
+
+
+2.3.22 (2002-10-16)
+
+- Moving to sensible Linux-style versioning.
+- The misc_model code has been completely rewritten, breaking surface models.
+ Surface models will reappear in the next release, once the new model API has
+ stablized.
+- New: MD3 and 3D Studio 3DS models now natively supported.
+- The misc_model "angles" key now supported. Values: "pitch yaw roll" in keeping
+ with standard Quake 3 angles order.
+- Models scaled with "modelscale_vec" now have proper normal scaling/rotation
+ (thanks SPOG).
+- Models can now be lightmapped.
+- Models can now have > 1000 vertexes per surface.
+- For best results for above, add the following to models' shaders:
+ q3map_splotchfix
+ q3map_nonplanar
+- 3DS models' MATERIAL NAMES ARE THE FINAL Q3 SHADER NAMES. YOU HAVE BEEN WARNED.
+- Models are generally 13373R. :)
+
+
+2.3.0-a21 (2002-10-02)
+
+- Fixed a stack of really stupid bugs in the lightgrid code. Should be faster
+ and more predictable now.
+- SOF2/JK2 lightgrid now compiled. This is the first version of Q3Map2 that can
+ compile full, release-worthy SOF2 and JK2 maps.
+- SOF2/JK2 damageshader and damagable brush faces should work correctly now.
+
+
+2.3.0-a20 (2002-09-26)
+
+- SOF2/JK2 worldspawn "fog" (and "_fog") shader key support for levelwide fog
+- SOF2/JK2 light "scale" key to scale light brightness
+- SOF2/JK2 -rename function for _bsp and _rmg_bsp shader renaming
+
+
+2.3.0-a19 (2002-09-24)
+
+- Shaders can now be subclassed (Q3Map relavant portions only, such as
+ surfaceparms, lighting, texture projection, etc). To subclass an existing
+ shader, add "q3map_baseshader X" where X is the name of the base shader.
+- Preliminary auto-model distribution over surfaces. You can now have things
+ like grass and tree models automatically distributed across your terrain
+ or other surfaces. To wit:
+
+ q3map_surfacemodel models/mapobjects/tree2/tree2.md3 64 0.001 0.5 4.0 0 360 1
+
+ q3map_surfacemodel <path to md3> <density in units> <odds of appearing>
+ <min scale> <max scale> <min angle> <max angle> <oriented>
+
+ The last flag is 1 or 0, and sets whether the model gets fitted to the
+ orientation of the surface. Not functional yet. See screenshots page for
+ shots of this in action.
+
+
+2.3.0-a18 (2002-09-21)
+
+- misc_models can now be attached to any brush model entity. Just target the
+ brush entity with the misc_model (select model, then entity, hit Ctrl+K)
+- q3map_tcMod translate (or shift or offset) <s offset> <t offset>
+- q3map_tcMod rotate <degrees> (rotates around origin, not center)
+- q3map_tcMod scale <s scale> <t scale>
+- Metasurface merging now much, much better. Merges into roughly rectangular or
+ square areas wherever possible
+- q3map_terrain no longer sets Z-axis lightmap projection. It must be set in
+ the terrain layer shaders if you want previous behavior
+- Worlspawn _blocksize key now supports 3 elements for setting X Y and Z splits
+ independently of each other (use a value of 0 for no splits on that axis)
+- Misc bugfixes
+
+
+2.3.0-a1 through 2.3.0-a17 (2002-07 through 2002-09-20)
+
+- Elite Force support (via -game ef)
+- SOF2 and JK2 support (via -game sof2 or -game jk2)
+- All new image handling with PNG support
+- q3map_lightimage specifies image for radiosity and lighting
+- External lightmaps, set using q3map_lightmapsize <width> <height>. Up to
+ 1024 x 1024 supported.
+- q3map_lightmapGamma <value> sets the brightness scale of a lightmap
+- q3map_lightmapsampleoffset <distance> to fix glitches in lightmapped terrain
+- Tons more features and bugfixes. See the forum threads for details/screenshots
+- Two new surfaceparms, "antiportal" and "skip," and associated shaders, for
+ allowing the mapper to more cleanly set up visibility data
+- Lightmaps will always have square texels now (no more stretching)
+- Vertex light improvements
+- Light grid improvements
+- q3map_lightrgb support for RTCW
+
+
+
+
+
+
-#!/usr/bin/perl -w \r
-\r
-use IO::Socket; \r
-use Net::hostent; \r
-\r
-my $port = shift || 13131; \r
-\r
-my $server = IO::Socket::INET->new(\r
- Proto => 'tcp', \r
- LocalPort => $port, \r
- Listen => SOMAXCONN, \r
- Reuse => 1 )\r
- || die "can't setup server"; \r
-print "[Q3Map2 listener $0 is now active on port $port]\n"; \r
-\r
-while( $client = $server->accept() )\r
-{ \r
-\r
- $client->autoflush( 1 ); \r
- \r
- $hostinfo = gethostbyaddr( $client->peeraddr );\r
- printf "[Connect from %s]\n\n", $hostinfo ? $hostinfo->name : $client->peerhost; \r
- \r
- #ask the client for a command \r
- print $client "[server]\$";\r
- my $text = "";\r
- while( <$client> )\r
- {\r
- $text .= $_;\r
- while( $text =~ s|<message[^>]*>([^<]+)</message>|| )\r
- {\r
- my $msg = $1;\r
- \r
- # fix xml ents\r
- $msg =~ s|<|<|g;\r
- $msg =~ s|>|>|g;\r
- $msg =~ s|"|"|g;#"\r
- $msg =~ s|'|'|g;#'\r
- \r
- print $msg;\r
- }\r
- }\r
- \r
- printf "\n[Disconnected: %s]\n\n", $hostinfo ? $hostinfo->name : $client->peerhost; \r
- close $client;\r
-} \r
+#!/usr/bin/perl -w
+
+use IO::Socket;
+use Net::hostent;
+
+my $port = shift || 13131;
+
+my $server = IO::Socket::INET->new(
+ Proto => 'tcp',
+ LocalPort => $port,
+ Listen => SOMAXCONN,
+ Reuse => 1 )
+ || die "can't setup server";
+print "[Q3Map2 listener $0 is now active on port $port]\n";
+
+while( $client = $server->accept() )
+{
+
+ $client->autoflush( 1 );
+
+ $hostinfo = gethostbyaddr( $client->peeraddr );
+ printf "[Connect from %s]\n\n", $hostinfo ? $hostinfo->name : $client->peerhost;
+
+ #ask the client for a command
+ print $client "[server]\$";
+ my $text = "";
+ while( <$client> )
+ {
+ $text .= $_;
+ while( $text =~ s|<message[^>]*>([^<]+)</message>|| )
+ {
+ my $msg = $1;
+
+ # fix xml ents
+ $msg =~ s|<|<|g;
+ $msg =~ s|>|>|g;
+ $msg =~ s|"|"|g;#"
+ $msg =~ s|'|'|g;#'
+
+ print $msg;
+ }
+ }
+
+ printf "\n[Disconnected: %s]\n\n", $hostinfo ? $hostinfo->name : $client->peerhost;
+ close $client;
+}
-# -*- mode: python -*-\r
-# QuakeZero build scripts\r
-# TTimo <ttimo@idsoftware.com>\r
-# http://scons.sourceforge.net\r
-\r
-import os, commands, platform, xml.sax, re, string, platform\r
-\r
-class vcproj( xml.sax.handler.ContentHandler ):\r
- def __init__( self, filepath ):\r
- self.source_files = []\r
- self.misc_files = []\r
- self._files = []\r
- print 'parse %s' % filepath\r
- xml.sax.parse( filepath, self )\r
-\r
- def getSourceFiles( self ):\r
- return self.source_files\r
-\r
- def filterSource( self, expression, filelist = None ):\r
- if ( filelist is None ):\r
- filelist = self.source_files\r
- match = []\r
- nomatch = []\r
- for s in filelist:\r
- if ( re.match( expression, s ) ):\r
- match.append( s )\r
- else:\r
- nomatch.append( s )\r
- return ( match, nomatch )\r
-\r
- def startElement( self, name, attrs ):\r
- if ( name == 'File' ):\r
- self._files.append( attrs.getValue('RelativePath') )\r
-\r
- def endDocument( self ):\r
- # split into source and headers, remap path seperator to the platform\r
- for f in self._files:\r
- if ( platform.system() != 'Windows' ):\r
- f = f.replace( '\\', '/' )\r
- if ( f[-2:] == '.c' or f[-4:] == '.cpp' ):\r
- self.source_files.append( f.encode('ascii') )\r
- else:\r
- self.misc_files.append( f )\r
- print '%d source files' % len( self.source_files )\r
-\r
-# action uses LDD to verify that the source doesn't hold unresolved symbols\r
-# setup as an AddPostAction of a regular SharedLibrary call\r
-def CheckUnresolved( source, target, env ):\r
- # TODO: implement this for OSX\r
- if ( platform.system() == 'Darwin' ):\r
- return None\r
- print 'CheckUnresolved %s' % target[0].abspath\r
- if ( not os.path.isfile( target[0].abspath ) ):\r
- print 'CheckUnresolved: %s does not exist' % target[0]\r
- return 1 # fail\r
- ( status, output ) = commands.getstatusoutput( 'ldd -r %s' % target[0] )\r
- if ( status != 0 ):\r
- print 'CheckUnresolved: ldd command failed (exit code %d)' % status\r
- os.system( 'rm %s' % target[ 0 ] )\r
- return 1 # fail\r
- lines = string.split( output, '\n' )\r
- have_undef = 0\r
- for i_line in lines:\r
- regex = re.compile('undefined symbol: (.*)\t\\((.*)\\)')\r
- if ( regex.match( i_line ) ):\r
- symbol = regex.sub( '\\1', i_line )\r
- try:\r
- env['ALLOWED_SYMBOLS'].index( symbol )\r
- except:\r
- have_undef = 1\r
- if ( have_undef ):\r
- print output\r
- print "CheckUnresolved: undefined symbols"\r
- os.system('rm %s' % target[0])\r
- return 1\r
-\r
-# http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/413486\r
-\r
-def Enum(*names):\r
- ##assert names, "Empty enums are not supported" # <- Don't like empty enums? Uncomment!\r
-\r
- class EnumClass(object):\r
- __slots__ = names\r
- def __iter__(self): return iter(constants)\r
- def __len__(self): return len(constants)\r
- def __getitem__(self, i): return constants[i]\r
- def __repr__(self): return 'Enum' + str(names)\r
- def __str__(self): return 'enum ' + str(constants)\r
-\r
- class EnumValue(object):\r
- __slots__ = ('__value')\r
- def __init__(self, value): self.__value = value\r
- Value = property(lambda self: self.__value)\r
- EnumType = property(lambda self: EnumType)\r
- def __hash__(self): return hash(self.__value)\r
- def __cmp__(self, other):\r
- # C fans might want to remove the following assertion\r
- # to make all enums comparable by ordinal value {;))\r
- assert self.EnumType is other.EnumType, "Only values from the same enum are comparable"\r
- return cmp(self.__value, other.__value)\r
- def __invert__(self): return constants[maximum - self.__value]\r
- def __nonzero__(self): return bool(self.__value)\r
- def __repr__(self): return str(names[self.__value])\r
-\r
- maximum = len(names) - 1\r
- constants = [None] * len(names)\r
- for i, each in enumerate(names):\r
- val = EnumValue(i)\r
- setattr(EnumClass, each, val)\r
- constants[i] = val\r
- constants = tuple(constants)\r
- EnumType = EnumClass()\r
- return EnumType\r
-\r
-#if __name__ == '__main__':\r
-# print '\n*** Enum Demo ***'\r
-# print '--- Days of week ---'\r
-# Days = Enum('Mo', 'Tu', 'We', 'Th', 'Fr', 'Sa', 'Su')\r
-# print Days\r
-# print Days.Mo\r
-# print Days.Fr\r
-# print Days.Mo < Days.Fr\r
-# print list(Days)\r
-# for each in Days:\r
-# print 'Day:', each\r
-# print '--- Yes/No ---'\r
-# Confirmation = Enum('No', 'Yes')\r
-# answer = Confirmation.No\r
-# print 'Your answer is not', ~answer\r
-\r
+# -*- mode: python -*-
+# QuakeZero build scripts
+# TTimo <ttimo@idsoftware.com>
+# http://scons.sourceforge.net
+
+import os, commands, platform, xml.sax, re, string, platform
+
+class vcproj( xml.sax.handler.ContentHandler ):
+ def __init__( self, filepath ):
+ self.source_files = []
+ self.misc_files = []
+ self._files = []
+ print 'parse %s' % filepath
+ xml.sax.parse( filepath, self )
+
+ def getSourceFiles( self ):
+ return self.source_files
+
+ def filterSource( self, expression, filelist = None ):
+ if ( filelist is None ):
+ filelist = self.source_files
+ match = []
+ nomatch = []
+ for s in filelist:
+ if ( re.match( expression, s ) ):
+ match.append( s )
+ else:
+ nomatch.append( s )
+ return ( match, nomatch )
+
+ def startElement( self, name, attrs ):
+ if ( name == 'File' ):
+ self._files.append( attrs.getValue('RelativePath') )
+
+ def endDocument( self ):
+ # split into source and headers, remap path seperator to the platform
+ for f in self._files:
+ if ( platform.system() != 'Windows' ):
+ f = f.replace( '\\', '/' )
+ if ( f[-2:] == '.c' or f[-4:] == '.cpp' ):
+ self.source_files.append( f.encode('ascii') )
+ else:
+ self.misc_files.append( f )
+ print '%d source files' % len( self.source_files )
+
+# action uses LDD to verify that the source doesn't hold unresolved symbols
+# setup as an AddPostAction of a regular SharedLibrary call
+def CheckUnresolved( source, target, env ):
+ # TODO: implement this for OSX
+ if ( platform.system() == 'Darwin' ):
+ return None
+ print 'CheckUnresolved %s' % target[0].abspath
+ if ( not os.path.isfile( target[0].abspath ) ):
+ print 'CheckUnresolved: %s does not exist' % target[0]
+ return 1 # fail
+ ( status, output ) = commands.getstatusoutput( 'ldd -r %s' % target[0] )
+ if ( status != 0 ):
+ print 'CheckUnresolved: ldd command failed (exit code %d)' % status
+ os.system( 'rm %s' % target[ 0 ] )
+ return 1 # fail
+ lines = string.split( output, '\n' )
+ have_undef = 0
+ for i_line in lines:
+ regex = re.compile('undefined symbol: (.*)\t\\((.*)\\)')
+ if ( regex.match( i_line ) ):
+ symbol = regex.sub( '\\1', i_line )
+ try:
+ env['ALLOWED_SYMBOLS'].index( symbol )
+ except:
+ have_undef = 1
+ if ( have_undef ):
+ print output
+ print "CheckUnresolved: undefined symbols"
+ os.system('rm %s' % target[0])
+ return 1
+
+# http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/413486
+
+def Enum(*names):
+ ##assert names, "Empty enums are not supported" # <- Don't like empty enums? Uncomment!
+
+ class EnumClass(object):
+ __slots__ = names
+ def __iter__(self): return iter(constants)
+ def __len__(self): return len(constants)
+ def __getitem__(self, i): return constants[i]
+ def __repr__(self): return 'Enum' + str(names)
+ def __str__(self): return 'enum ' + str(constants)
+
+ class EnumValue(object):
+ __slots__ = ('__value')
+ def __init__(self, value): self.__value = value
+ Value = property(lambda self: self.__value)
+ EnumType = property(lambda self: EnumType)
+ def __hash__(self): return hash(self.__value)
+ def __cmp__(self, other):
+ # C fans might want to remove the following assertion
+ # to make all enums comparable by ordinal value {;))
+ assert self.EnumType is other.EnumType, "Only values from the same enum are comparable"
+ return cmp(self.__value, other.__value)
+ def __invert__(self): return constants[maximum - self.__value]
+ def __nonzero__(self): return bool(self.__value)
+ def __repr__(self): return str(names[self.__value])
+
+ maximum = len(names) - 1
+ constants = [None] * len(names)
+ for i, each in enumerate(names):
+ val = EnumValue(i)
+ setattr(EnumClass, each, val)
+ constants[i] = val
+ constants = tuple(constants)
+ EnumType = EnumClass()
+ return EnumType
+
+#if __name__ == '__main__':
+# print '\n*** Enum Demo ***'
+# print '--- Days of week ---'
+# Days = Enum('Mo', 'Tu', 'We', 'Th', 'Fr', 'Sa', 'Su')
+# print Days
+# print Days.Mo
+# print Days.Fr
+# print Days.Mo < Days.Fr
+# print list(Days)
+# for each in Days:
+# print 'Day:', each
+# print '--- Yes/No ---'
+# Confirmation = Enum('No', 'Yes')
+# answer = Confirmation.No
+# print 'Your answer is not', ~answer
+
-# install the fucking files\r
-# check the md5 to decide for a copy\r
-# we have a site.conf to go through\r
-# and a data list of stuff\r
-# it's called at the end of each build to copy what needs to be\r
-# it could be called only at GtkRadiant link time\r
-\r
-# command line: a bunch of config switches default would be debug?, and release flag\r
-\r
-\r
-import sys, traceback, os, re, filecmp, shutil, pickle, string\r
-from makeversion import get_version\r
-\r
-(line, major, minor) = get_version()\r
-\r
-paths = {\r
- 'CORERADIANTDIR' : 'C:\\Program Files\\GtkRadiant-1.' + major,\r
- 'RTCWRADIANTDIR' : 'C:\\Program Files\\Return to Castle Wolfenstein - Game of The Year Edition\\Radiant-1.' + major,\r
- 'HLRADIANTDIR' : 'C:\\Sierra\\Half-Life\\Radiant-1.' + major,\r
- 'SOF2RADIANTDIR' : 'C:\\Program Files\\Soldier of Fortune II - Double Helix\\Radiant-1.' + major,\r
- 'QUAKE2RADIANTDIR' : 'C:\\Quake2\\Radiant-1.' + major,\r
- 'HERETIC2RADIANTDIR' : 'C:\\Heretic2\\Radiant-1.' + major\r
- }\r
-\r
-conf_filename='site.conf.win32'\r
-\r
-# site settings ----------------------\r
-\r
-if (os.path.exists(conf_filename)):\r
- site_file = open(conf_filename, 'r')\r
- p = pickle.Unpickler(site_file)\r
- paths = p.load()\r
- print 'Loaded configuration from ' + conf_filename \r
-\r
-# end site settings ------------------\r
-\r
-# command line overrides -------------\r
-\r
-print '\nCommand line:'\r
-regex = re.compile("(.*)=(.*)")\r
-for i in sys.argv[1:]:\r
- #print i\r
- if ( regex.match(i) ):\r
- (key, val) = string.split(i, '=')\r
- #print 'key: %s val: %s' % (key, val)\r
- paths[key] = val\r
- else:\r
- print 'Can''t parse command line - ignore: ' + i\r
-\r
-# end command line overrides ---------\r
-\r
-# save config ------------------------\r
-\r
-site_file = open(conf_filename, 'w')\r
-p = pickle.Pickler(site_file)\r
-p.dump(paths)\r
-site_file.close()\r
-\r
-print '\nConfiguration:'\r
-\r
-for i in paths.keys():\r
- print '%s -> %s' % (i, paths[i])\r
-\r
-# end save config --------------------\r
-\r
-q3map2_list = [\r
-# ( ( '..\\libpng\\projects\\msvc\\win32\\zlib\\dll_dbg\\zlibd.dll', '..\\libpng\\projects\\msvc\\win32\\zlib\\dll\\zlib.dll' ), '$CORERADIANTDIR' ),\r
-# ( ( '..\\libpng\\projects\\msvc\\win32\\libpng\\dll_dbg\\libpng13d.dll', '..\\libpng\\projects\\msvc\\win32\\libpng\\dll\\libpng13.dll' ), '$CORERADIANTDIR' ),\r
-# ( ( '..\\libxml2\\win32\\binaries-debug\\libxml2.dll', '..\\libxml2\\win32\\binaries-release\\libxml2.dll' ), '$CORERADIANTDIR' ),\r
- ( ( 'tools\\quake3\\q3map2\\Debug\\Q3Map2.exe', 'tools\\quake3\\q3map2\\Release\\Q3Map2.exe' ), '$CORERADIANTDIR' ),\r
- ]\r
-\r
-all = [\r
- ( ( 'radiant\\Debug\\GtkRadiant.exe', 'radiant\\Release\\GtkRadiant.exe' ) , '$CORERADIANTDIR' ),\r
- ( ( 'contrib\\bobtoolz\\Debug\\bobToolz.dll', 'contrib\\bobtoolz\\Release\\bobToolz.dll' ), '$CORERADIANTDIR\\plugins' ),\r
- ( ( 'contrib\\camera\\Debug\\camera.dll', 'contrib\\camera\\Release\\camera.dll' ), '$CORERADIANTDIR\\plugins' ),\r
- ( ( 'plugins\\entity\\Debug\\entity.dll', 'plugins\\entity\\Release\\entity.dll' ), '$CORERADIANTDIR\\modules' ),\r
- ( ( 'plugins\\eclassfgd\\Debug\\fgd.dll', 'plugins\\eclassfgd\\Release\\fgd.dll' ), '$CORERADIANTDIR\\modules' ),\r
- ( ( 'contrib\\gtkgensurf\\Debug\\gensurf.dll', 'contrib\\gtkgensurf\\Release\\gensurf.dll' ), '$CORERADIANTDIR\\plugins' ),\r
- ( ( 'contrib\\hydratoolz\\Debug\\hydratoolz.dll', 'contrib\\hydratoolz\\Release\\hydratoolz.dll' ), '$HLRADIANTDIR\\plugins' ), \r
- ( ( 'plugins\\image\\Debug\\image.dll', 'plugins\\image\\Release\\image.dll' ), '$CORERADIANTDIR\\modules' ),\r
- ( ( 'plugins\\imagewal\\Debug\\imagewal.dll', 'plugins\\imagewal\\Release\\imagewal.dll' ), '$QUAKE2RADIANTDIR\\modules' ),\r
- ( ( 'plugins\\imagehl\\Debug\\imagehl.dll', 'plugins\\imagehl\\Release\\imagehl.dll' ), '$CORERADIANTDIR\\modules' ),\r
- ( ( 'plugins\\imagepng\\Debug\\imagepng.dll', 'plugins\\imagepng\\Release\\imagepng.dll' ), '$CORERADIANTDIR\\modules' ),\r
- ( ( 'plugins\\map\\Debug\\map.dll', 'plugins\\map\\Release\\map.dll' ), '$CORERADIANTDIR\\modules' ), \r
- ( ( 'plugins\\mapxml\\Debug\\mapxml.dll', 'plugins\\mapxml\\Release\\mapxml.dll' ), '$CORERADIANTDIR\\modules' ),\r
- ( ( 'plugins\\model\\Debug\\model.dll', 'plugins\\model\\Release\\model.dll' ), '$CORERADIANTDIR\\modules' ),\r
- ( ( 'contrib\\prtview\\Debug\\PrtView.dll', 'contrib\\prtview\\Release\\PrtView.dll' ), '$CORERADIANTDIR\\plugins' ),\r
- ( ( 'tools\\quake3\\q3data\\Debug\\q3data.exe', 'tools\\quake3\\q3data\\Release\\q3data.exe' ), '$CORERADIANTDIR' ),\r
- ( ( 'plugins\\shaders\\Debug\\shaders.dll', 'plugins\\shaders\\Release\\shaders.dll' ), '$CORERADIANTDIR\\modules' ), \r
- ( ( 'plugins\\spritemodel\\Debug\\spritemodel.dll', 'plugins\\spritemodel\\Release\\spritemodel.dll' ), '$CORERADIANTDIR\\modules' ),\r
-# ( ( 'Debug\\TexTool.dll', 'Release\\TexTool.dll' ), '$CORERADIANTDIR\\plugins' ),\r
- ( ( 'plugins\\vfspk3\\Debug\\vfspk3.dll', 'plugins\\vfspk3\\Release\\vfspk3.dll' ), '$CORERADIANTDIR\\modules' ),\r
- ( ( 'plugins\\vfspak\\Debug\\vfspak.dll', 'plugins\\vfspak\\Release\\vfspak.dll' ), '$QUAKE2RADIANTDIR\\modules' ),\r
- ( ( 'plugins\\vfswad\\Debug\\vfswad.dll', 'plugins\\vfswad\\Release\\vfswad.dll' ), '$CORERADIANTDIR\\modules' ),\r
- ( ( 'plugins\\surface\\Debug\\surface.dll', 'plugins\\surface\\Release\\surface.dll' ), '$CORERADIANTDIR\\modules' ),\r
- ( ( 'plugins\\surface_quake2\\Debug\\surface_quake2.dll', 'plugins\\surface_quake2\\Release\\surface_quake2.dll' ), '$QUAKE2RADIANTDIR\\modules' ),\r
- ( ( 'tools\\quake2\\q2map\\Debug\\q2map.exe', 'tools\\quake2\\q2map\\Release\\q2map.exe' ) , '$QUAKE2RADIANTDIR' ),\r
- ( ( 'tools\\quake2\\qdata\\Debug\\qdata3.exe', 'tools\\quake2\\qdata\\Release\\qdata3.exe' ) , '$QUAKE2RADIANTDIR' ),\r
- ( ( 'plugins\\vfspak\\Debug\\vfspak.dll', 'plugins\\vfspak\\Release\\vfspak.dll' ), '$HERETIC2RADIANTDIR\\modules' ),\r
- ( ( 'plugins\\imagem8\\Debug\\imagem8.dll', 'plugins\\imagem8\\Release\\imagem8.dll' ), '$HERETIC2RADIANTDIR\\modules' ),\r
- ( ( 'plugins\\surface_heretic2\\Debug\\surface_heretic2.dll', 'plugins\\surface_heretic2\\Release\\surface_heretic2.dll' ), '$HERETIC2RADIANTDIR\\modules' ),\r
- ( ( 'tools\\quake2\\qdata_heretic2\\Debug\\qdata3.exe', 'tools\\quake2\\qdata_heretic2\\Release\\qdata3.exe' ) , '$HERETIC2RADIANTDIR' ),\r
- ( ( 'contrib\\bkgrnd2d\\Debug\\bkgrnd2d.dll', 'contrib\\bkgrnd2d\\Release\\bkgrnd2d.dll' ), '$CORERADIANTDIR\\plugins' ),\r
- ]\r
-\r
-config = 0\r
-q3map2 = 0\r
-\r
-# config check\r
-for i in sys.argv:\r
- if ( i == 'release' ):\r
- config = 1\r
- elif ( i == 'q3map2' ):\r
- q3map2 = 1\r
-\r
-if ( config == 1 ):\r
- print 'installing release binaries'\r
-else:\r
- print 'installing debug binaries'\r
-\r
-def expand(path_in):\r
- for matches in paths.keys():\r
- exp = re.compile('\\$%s' % matches)\r
- if ( not re.match(exp, path_in) is None ):\r
- #print "Got a match for %s on %s" % ( matches, path_in )\r
- path_in = re.sub(exp, paths[matches], path_in) \r
- #print "Processed to: %s" % path_in\r
- return path_in\r
-\r
-# don't bother about stderr\r
-sys.stderr = sys.stdout\r
-\r
-if ( q3map2 == 0 ):\r
- stuff = q3map2_list\r
- stuff += all\r
-else:\r
- stuff = q3map2_list\r
-\r
-for entries in stuff:\r
- try:\r
- src = expand(entries[0][config])\r
- #print "src basename: %s -> %s" % (src, os.path.basename(src))\r
- dst = entries[1]\r
- dst = os.path.join( entries[1], os.path.basename(src) )\r
- dst = expand(dst)\r
- #print "src: %s dst: %s" % (src, dst)\r
- if (os.path.isfile(src)):\r
- if (os.path.isfile(dst)):\r
- if (not filecmp.cmp(src, dst)):\r
- shutil.copy(src, dst)\r
- print "%s: OK - updated" % dst\r
- else:\r
- print "%s: OK - already up to date" % dst\r
- else:\r
- shutil.copy(src, dst)\r
- print "%s: OK - installed" % dst\r
- else: \r
- print "%s: FAILED - not found" % src\r
- if (os.path.isfile(dst)):\r
- print "delete %s" % dst\r
- os.remove(dst)\r
- except:\r
- print "%s: FAILED" % src\r
- traceback.print_exc()\r
- \r
+# install the fucking files
+# check the md5 to decide for a copy
+# we have a site.conf to go through
+# and a data list of stuff
+# it's called at the end of each build to copy what needs to be
+# it could be called only at GtkRadiant link time
+
+# command line: a bunch of config switches default would be debug?, and release flag
+
+
+import sys, traceback, os, re, filecmp, shutil, pickle, string
+from makeversion import get_version
+
+(line, major, minor) = get_version()
+
+paths = {
+ 'CORERADIANTDIR' : 'C:\\Program Files\\GtkRadiant-1.' + major,
+ 'RTCWRADIANTDIR' : 'C:\\Program Files\\Return to Castle Wolfenstein - Game of The Year Edition\\Radiant-1.' + major,
+ 'HLRADIANTDIR' : 'C:\\Sierra\\Half-Life\\Radiant-1.' + major,
+ 'SOF2RADIANTDIR' : 'C:\\Program Files\\Soldier of Fortune II - Double Helix\\Radiant-1.' + major,
+ 'QUAKE2RADIANTDIR' : 'C:\\Quake2\\Radiant-1.' + major,
+ 'HERETIC2RADIANTDIR' : 'C:\\Heretic2\\Radiant-1.' + major
+ }
+
+conf_filename='site.conf.win32'
+
+# site settings ----------------------
+
+if (os.path.exists(conf_filename)):
+ site_file = open(conf_filename, 'r')
+ p = pickle.Unpickler(site_file)
+ paths = p.load()
+ print 'Loaded configuration from ' + conf_filename
+
+# end site settings ------------------
+
+# command line overrides -------------
+
+print '\nCommand line:'
+regex = re.compile("(.*)=(.*)")
+for i in sys.argv[1:]:
+ #print i
+ if ( regex.match(i) ):
+ (key, val) = string.split(i, '=')
+ #print 'key: %s val: %s' % (key, val)
+ paths[key] = val
+ else:
+ print 'Can''t parse command line - ignore: ' + i
+
+# end command line overrides ---------
+
+# save config ------------------------
+
+site_file = open(conf_filename, 'w')
+p = pickle.Pickler(site_file)
+p.dump(paths)
+site_file.close()
+
+print '\nConfiguration:'
+
+for i in paths.keys():
+ print '%s -> %s' % (i, paths[i])
+
+# end save config --------------------
+
+q3map2_list = [
+# ( ( '..\\libpng\\projects\\msvc\\win32\\zlib\\dll_dbg\\zlibd.dll', '..\\libpng\\projects\\msvc\\win32\\zlib\\dll\\zlib.dll' ), '$CORERADIANTDIR' ),
+# ( ( '..\\libpng\\projects\\msvc\\win32\\libpng\\dll_dbg\\libpng13d.dll', '..\\libpng\\projects\\msvc\\win32\\libpng\\dll\\libpng13.dll' ), '$CORERADIANTDIR' ),
+# ( ( '..\\libxml2\\win32\\binaries-debug\\libxml2.dll', '..\\libxml2\\win32\\binaries-release\\libxml2.dll' ), '$CORERADIANTDIR' ),
+ ( ( 'tools\\quake3\\q3map2\\Debug\\Q3Map2.exe', 'tools\\quake3\\q3map2\\Release\\Q3Map2.exe' ), '$CORERADIANTDIR' ),
+ ]
+
+all = [
+ ( ( 'radiant\\Debug\\GtkRadiant.exe', 'radiant\\Release\\GtkRadiant.exe' ) , '$CORERADIANTDIR' ),
+ ( ( 'contrib\\bobtoolz\\Debug\\bobToolz.dll', 'contrib\\bobtoolz\\Release\\bobToolz.dll' ), '$CORERADIANTDIR\\plugins' ),
+ ( ( 'contrib\\camera\\Debug\\camera.dll', 'contrib\\camera\\Release\\camera.dll' ), '$CORERADIANTDIR\\plugins' ),
+ ( ( 'plugins\\entity\\Debug\\entity.dll', 'plugins\\entity\\Release\\entity.dll' ), '$CORERADIANTDIR\\modules' ),
+ ( ( 'plugins\\eclassfgd\\Debug\\fgd.dll', 'plugins\\eclassfgd\\Release\\fgd.dll' ), '$CORERADIANTDIR\\modules' ),
+ ( ( 'contrib\\gtkgensurf\\Debug\\gensurf.dll', 'contrib\\gtkgensurf\\Release\\gensurf.dll' ), '$CORERADIANTDIR\\plugins' ),
+ ( ( 'contrib\\hydratoolz\\Debug\\hydratoolz.dll', 'contrib\\hydratoolz\\Release\\hydratoolz.dll' ), '$HLRADIANTDIR\\plugins' ),
+ ( ( 'plugins\\image\\Debug\\image.dll', 'plugins\\image\\Release\\image.dll' ), '$CORERADIANTDIR\\modules' ),
+ ( ( 'plugins\\imagewal\\Debug\\imagewal.dll', 'plugins\\imagewal\\Release\\imagewal.dll' ), '$QUAKE2RADIANTDIR\\modules' ),
+ ( ( 'plugins\\imagehl\\Debug\\imagehl.dll', 'plugins\\imagehl\\Release\\imagehl.dll' ), '$CORERADIANTDIR\\modules' ),
+ ( ( 'plugins\\imagepng\\Debug\\imagepng.dll', 'plugins\\imagepng\\Release\\imagepng.dll' ), '$CORERADIANTDIR\\modules' ),
+ ( ( 'plugins\\map\\Debug\\map.dll', 'plugins\\map\\Release\\map.dll' ), '$CORERADIANTDIR\\modules' ),
+ ( ( 'plugins\\mapxml\\Debug\\mapxml.dll', 'plugins\\mapxml\\Release\\mapxml.dll' ), '$CORERADIANTDIR\\modules' ),
+ ( ( 'plugins\\model\\Debug\\model.dll', 'plugins\\model\\Release\\model.dll' ), '$CORERADIANTDIR\\modules' ),
+ ( ( 'contrib\\prtview\\Debug\\PrtView.dll', 'contrib\\prtview\\Release\\PrtView.dll' ), '$CORERADIANTDIR\\plugins' ),
+ ( ( 'tools\\quake3\\q3data\\Debug\\q3data.exe', 'tools\\quake3\\q3data\\Release\\q3data.exe' ), '$CORERADIANTDIR' ),
+ ( ( 'plugins\\shaders\\Debug\\shaders.dll', 'plugins\\shaders\\Release\\shaders.dll' ), '$CORERADIANTDIR\\modules' ),
+ ( ( 'plugins\\spritemodel\\Debug\\spritemodel.dll', 'plugins\\spritemodel\\Release\\spritemodel.dll' ), '$CORERADIANTDIR\\modules' ),
+# ( ( 'Debug\\TexTool.dll', 'Release\\TexTool.dll' ), '$CORERADIANTDIR\\plugins' ),
+ ( ( 'plugins\\vfspk3\\Debug\\vfspk3.dll', 'plugins\\vfspk3\\Release\\vfspk3.dll' ), '$CORERADIANTDIR\\modules' ),
+ ( ( 'plugins\\vfspak\\Debug\\vfspak.dll', 'plugins\\vfspak\\Release\\vfspak.dll' ), '$QUAKE2RADIANTDIR\\modules' ),
+ ( ( 'plugins\\vfswad\\Debug\\vfswad.dll', 'plugins\\vfswad\\Release\\vfswad.dll' ), '$CORERADIANTDIR\\modules' ),
+ ( ( 'plugins\\surface\\Debug\\surface.dll', 'plugins\\surface\\Release\\surface.dll' ), '$CORERADIANTDIR\\modules' ),
+ ( ( 'plugins\\surface_quake2\\Debug\\surface_quake2.dll', 'plugins\\surface_quake2\\Release\\surface_quake2.dll' ), '$QUAKE2RADIANTDIR\\modules' ),
+ ( ( 'tools\\quake2\\q2map\\Debug\\q2map.exe', 'tools\\quake2\\q2map\\Release\\q2map.exe' ) , '$QUAKE2RADIANTDIR' ),
+ ( ( 'tools\\quake2\\qdata\\Debug\\qdata3.exe', 'tools\\quake2\\qdata\\Release\\qdata3.exe' ) , '$QUAKE2RADIANTDIR' ),
+ ( ( 'plugins\\vfspak\\Debug\\vfspak.dll', 'plugins\\vfspak\\Release\\vfspak.dll' ), '$HERETIC2RADIANTDIR\\modules' ),
+ ( ( 'plugins\\imagem8\\Debug\\imagem8.dll', 'plugins\\imagem8\\Release\\imagem8.dll' ), '$HERETIC2RADIANTDIR\\modules' ),
+ ( ( 'plugins\\surface_heretic2\\Debug\\surface_heretic2.dll', 'plugins\\surface_heretic2\\Release\\surface_heretic2.dll' ), '$HERETIC2RADIANTDIR\\modules' ),
+ ( ( 'tools\\quake2\\qdata_heretic2\\Debug\\qdata3.exe', 'tools\\quake2\\qdata_heretic2\\Release\\qdata3.exe' ) , '$HERETIC2RADIANTDIR' ),
+ ( ( 'contrib\\bkgrnd2d\\Debug\\bkgrnd2d.dll', 'contrib\\bkgrnd2d\\Release\\bkgrnd2d.dll' ), '$CORERADIANTDIR\\plugins' ),
+ ]
+
+config = 0
+q3map2 = 0
+
+# config check
+for i in sys.argv:
+ if ( i == 'release' ):
+ config = 1
+ elif ( i == 'q3map2' ):
+ q3map2 = 1
+
+if ( config == 1 ):
+ print 'installing release binaries'
+else:
+ print 'installing debug binaries'
+
+def expand(path_in):
+ for matches in paths.keys():
+ exp = re.compile('\\$%s' % matches)
+ if ( not re.match(exp, path_in) is None ):
+ #print "Got a match for %s on %s" % ( matches, path_in )
+ path_in = re.sub(exp, paths[matches], path_in)
+ #print "Processed to: %s" % path_in
+ return path_in
+
+# don't bother about stderr
+sys.stderr = sys.stdout
+
+if ( q3map2 == 0 ):
+ stuff = q3map2_list
+ stuff += all
+else:
+ stuff = q3map2_list
+
+for entries in stuff:
+ try:
+ src = expand(entries[0][config])
+ #print "src basename: %s -> %s" % (src, os.path.basename(src))
+ dst = entries[1]
+ dst = os.path.join( entries[1], os.path.basename(src) )
+ dst = expand(dst)
+ #print "src: %s dst: %s" % (src, dst)
+ if (os.path.isfile(src)):
+ if (os.path.isfile(dst)):
+ if (not filecmp.cmp(src, dst)):
+ shutil.copy(src, dst)
+ print "%s: OK - updated" % dst
+ else:
+ print "%s: OK - already up to date" % dst
+ else:
+ shutil.copy(src, dst)
+ print "%s: OK - installed" % dst
+ else:
+ print "%s: FAILED - not found" % src
+ if (os.path.isfile(dst)):
+ print "delete %s" % dst
+ os.remove(dst)
+ except:
+ print "%s: FAILED" % src
+ traceback.print_exc()
+
projects / xonotic / netradiant.git / commitdiff