mirror of
https://github.com/UberGames/GtkRadiant.git
synced 2024-11-25 13:21:47 +00:00
more eol-style
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/ZeroRadiant.ab@187 8a3a26a2-13c4-0310-b231-cf6edde360e5
This commit is contained in:
TTimo
parent
b1bfb19ecd
commit
2b5ef55c7c
53 changed files with 3141 additions and 3141 deletions
14
INSTALL.txt
14
INSTALL.txt
|
|
@ -1,7 +1,7 @@
|
|||
Compilation instructions
|
||||
------------------------
|
||||
|
||||
See latest information for compiling and installation
|
||||
on the developer pages:
|
||||
|
||||
http://www.qeradiant.com/wikifaq/index.php?GtkRadiant%20Hacker
|
||||
Compilation instructions
|
||||
------------------------
|
||||
|
||||
See latest information for compiling and installation
|
||||
on the developer pages:
|
||||
|
||||
http://www.qeradiant.com/wikifaq/index.php?GtkRadiant%20Hacker
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,131 +1,131 @@
|
|||
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
|
||||
|
||||
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
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,17 +1,17 @@
|
|||
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
|
||||
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
|
||||
|
|
@ -1,61 +1,61 @@
|
|||
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
|
||||
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
|
||||
|
|
@ -1,61 +1,61 @@
|
|||
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
|
||||
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
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
base_support/support1rust
|
||||
base_support/support1shiny
|
||||
base_support/support2rust
|
||||
base_support/wplat1_1
|
||||
base_support/support1rust
|
||||
base_support/support1shiny
|
||||
base_support/support2rust
|
||||
base_support/wplat1_1
|
||||
base_support/plate2_5
|
||||
|
|
@ -1,10 +1,10 @@
|
|||
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
|
||||
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
|
||||
|
|
@ -1,14 +1,14 @@
|
|||
{
|
||||
"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"
|
||||
{
|
||||
"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"
|
||||
}
|
||||
|
|
@ -1,12 +1,12 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,96 +1,96 @@
|
|||
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 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 ;]
|
||||
|
||||
|
|
|
|||
|
|
@ -1,77 +1,77 @@
|
|||
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
|
||||
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.
|
||||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
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
|
||||
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
|
||||
|
|
@ -1,266 +1,266 @@
|
|||
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
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,27 +1,27 @@
|
|||
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 ..
|
||||
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 ..
|
||||
|
|
|
|||
|
|
@ -1,34 +1,34 @@
|
|||
========================================================================
|
||||
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.
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////
|
||||
========================================================================
|
||||
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.
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////
|
||||
|
|
|
|||
|
|
@ -1,27 +1,27 @@
|
|||
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..
|
||||
|
||||
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..
|
||||
|
||||
|
|
|
|||
|
|
@ -1,76 +1,76 @@
|
|||
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.
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -1,33 +1,33 @@
|
|||
** 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
|
||||
** 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)
|
||||
File diff suppressed because it is too large
Load diff
|
|
@ -1,75 +1,75 @@
|
|||
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
|
||||
|
||||
|
||||
=====================
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,73 +1,73 @@
|
|||
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
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
96
install.py
96
install.py
|
|
@ -1,48 +1,48 @@
|
|||
#!/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] )
|
||||
#!/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] )
|
||||
|
|
|
|||
|
|
@ -1,190 +1,190 @@
|
|||
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
|
||||
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?
|
||||
|
|
@ -1,59 +1,59 @@
|
|||
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
|
||||
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?
|
||||
|
|
@ -1,85 +1,85 @@
|
|||
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
|
||||
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
|
||||
|
|
|
|||
144
makeversion.py
144
makeversion.py
|
|
@ -1,72 +1,72 @@
|
|||
# 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)
|
||||
# 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)
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,30 +1,30 @@
|
|||
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.
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; model.def : Declares the module parameters for the DLL.
|
||||
|
||||
LIBRARY "MODEL"
|
||||
DESCRIPTION 'MODEL Windows Dynamic Link Library'
|
||||
|
||||
EXPORTS
|
||||
; Explicit exports can go here
|
||||
; 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
|
||||
|
|
@ -1,8 +1,8 @@
|
|||
; 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.
|
||||
|
||||
LIBRARY "Shaders"
|
||||
DESCRIPTION 'Shaders Windows Dynamic Link Library'
|
||||
|
||||
EXPORTS
|
||||
; Explicit exports can go here
|
||||
Synapse_EnumerateInterfaces @1
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
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"
|
||||
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
|
||||
|
|
@ -1,8 +1,8 @@
|
|||
; 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
|
||||
; 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
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
; 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.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
|
||||
|
|
|
|||
|
|
@ -1,30 +1,30 @@
|
|||
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.
|
||||
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.
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
332
win32_install.py
332
win32_install.py
|
|
@ -1,166 +1,166 @@
|
|||
# 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()
|
||||
|
||||
# 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()
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue