docs/developer/DRAFT

   1 usefull global variables in Radiant:\r
   2 g_strAppPath has the path to the binary\r
   3 \r
   4 -----------------------------------------------------------------------\r
   5 using prefs / ini settings:\r
   6 are stored in Radiant.ini and *.bin files\r
   7 win32:\r
   8 looks in the current directory for a Radiant.ini file\r
   9 if found, will use it and set the ini directory to the proper location\r
  10 if not found:\r
  11 the registry has a path to the default directory?\r
  12 under key HKEY_CURRENT_USER/Software/GtkRadiant/PrimaryEditorPath\r
  13 (DefaultEditorPath cause that gets used for \r
  14 if the key doesn't exist create in current directory and set the key\r
  15 NOTE: need some registry version info, when we find in another dir than ours,\r
  16   check version and prompt to use existing settings or our own?\r
  17 \r
  18 storing version information:\r
  19 each build publicly released should have a version string\r
  20 - use it in the about box\r
  21 - store it in the Radiant.ini file\r
  22 - use it in the registry GtkRadiant/\r
  23 do we need major and minor? minor could be used for versions that don't break .ini compatibility\r
  24   (well I'm lazy .. won't do)\r
  25 \r
  26 linux:\r
  27 look in the current directory (check write permission!)\r
  28 if found, use it\r
  29 if not found:\r
  30 look in ~/.q3a/radiant\r
  31 \r
  32 -----------------------------------------------------------------------\r
  33 icons:\r
  34 look for bitmaps/ under g_strAppPath\r
  35 win32:\r
  36 if not found, use DefaultEditorPath registry key and try to locate there\r
  37 linux:\r
  38 we also need a DefaultEditorPath kind of thing?\r
  39 somewhere in ~/.q3a/radiant?\r
  40 \r
  41 -----------------------------------------------------------------------\r
  42 project file:\r
  43 Radiant.ini must have full path to the project file\r
  44 if no project file path:\r
  45 win32:\r
  46 we have to locate BASEPATH one way or the other. we have code that will look for the\r
  47 main directory and go down into baseq3/scripts. If that fails we prompt the user.\r
  48 it would be good to store BASEPATH in the .ini as well!\r
  49 linux:\r
  50 store path to Radiant installation somewhere in ~/.q3a/radiant\r
  51 if not found try some defaults and prompt the user\r
  52 \r
  53 NOTE: on linux radiant is in /usr/local/games/quake3/ instead of some\r
  54 quake3/tools directory. This makes looking for the basepath easier.\r
  55 \r
  56 g_PrefsDlg.m_strLastProject points to the project to be loaded\r
  57 if radiant cannot find it at startup it will try to guess and/or ask the user\r
  58 once the project file is loaded you can deduce a lot of things..\r
  59 but project file parsing has some prerequisites: __QERPATH / __QERHOMEPATH ??\r
  60 need to unify between win32 and linux!\r
  61 PrefsDlg has a bunch of defaults, but it must not try to guess \r
  62   __QERPATH and __QERHOMEPATH until there has been an ini load (or a lack of)\r
  63 the involved members are:\r
  64 m_strQuake2 <- points to the engine path, renamed to m_strBasePath m_strEngine\r
  65 m_strPAKFile <- built from m_strBasePath, removed (not used?)\r
  66 and: need to add more, like map compilers directory m_strToolsPath\r
  67 \r
  68 project file syntax:\r
  69 linux version is using __QERPATH / __QERHOMEPATH\r
  70 win32 has __Q2PATH __QERPATH\r
  71 and the overall syntax is different!\r
  72 \r
  73 big problem is user customization, it performs expansion and saves with static\r
  74 paths. but we'd like to keep the original one with generic naming. (cause if the\r
  75 config fucks up and user reinstalls he'll still get broken project settings)\r
  76 so: we try to load quake.qe4 project, expand it, and save as user.qe4\r
  77 (on linux, user.qe4 goes in ~/.q3a/baseq3/scripts)\r
  78 \r
  79 TODO: how is "New project" supposed to work? would copy the current project..\r
  80 TODO: get rid of m_bLoadLast .. we require having a project loaded for use?\r
  81 TODO: store path to the tools in prefs? (see usage for project file expansion?)\r
  82   -> so you can use q3map in a given dir etc?\r
  83 \r
  84 unifying project file syntaxes:\r
  85 \r
  86 get rid of BuildShortPathName things!\r
  87 \r
  88 -----------------------------------------------------------------\r
  89 some common operations and portable code:\r
  90 document XP use of stat, checking for directory / file existence\r
  91 \r
  92 how to have code that reads well across XP:\r
  93 don't use TABS, have them emulated to 2 spaces\r
  94 \r
  95 -----------------------------------------------------------------\r
  96 project files:\r
  97 unless we rewrite a whole bunch of it from scratch there's no much\r
  98 hope for evolution of the project files. Nevertheless, introduced\r
  99 a new "version" key that describes the version of the project file.\r
 100 version 2 adds a # keyword for q3map global options\r
 101 NOTE: and it's a compatibility nightmare, we can't call this one\r
 102 quake.qe4 or default.qe4 cause it will break backward compatibility\r
 103 \r
 104 -----------------------------------------------------------------\r
 105 monitoring BSP process:\r
 106 we monitor through network connections\r
 107 we need to stop the process if an error occurs during one of the three steps\r
 108 and launch quake3 when all is done\r
 109 we don't want to CreateProcess and watch cause for rsh mode it will return immediately\r
 110 a BSP process is decomposed in several steps and we expect a connection at each step\r
 111 - later we can add custom steps that don't net connect and then we just spawn and\r
 112 watch them\r
 113 - we could add a name to the step to identify them, for now we'll just assume\r
 114 the first connection that we get is the one of the process we spawned\r
 115 when we loose the connection we wait one sec and spawn the next one...\r
 116 - we don't use batch file, just produce the command lines for each steps, the batch file\r
 117 will be produced only if we don't monitor the process (we can add an option to output\r
 118 the BAT file anyway)\r
 119 \r
 120 what stuff goes in prefs? "Monitor BSP process"\r
 121 \r
 122 detecting when the socket closes?\r
 123 using select() one can detect if a socket has closed or if there's some input\r
 124 NOTE: when launching a new BSP process we may still be connected. Need to ask the user\r
 125 about overridding and closing current connection.\r
 126 \r
 127 in prefs, boolean flag for process monitoring .. g_PrefsDlg.m_bWatchBSP\r
 128 \r
 129 when running in monitored mode, the BSP watcher is in charge of spawning and watching\r
 130 the processes (and more later when it will be parsing the output).\r