View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000155 | DarkRadiant | GUI | public | 27.02.2007 03:24 | 04.03.2007 18:13 |
Reporter | SneaksieDave | Assigned To | greebo | ||
Priority | low | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 0.9.0 | ||||
Fixed in Version | 0.9.0 | ||||
Summary | 0000155: Not all colors customizable? | ||||
Description | Please see: http://img219.imageshack.us/my.php?image=colorswa1.jpg The color I'm referring to specifically is that of the guard and his naming letters. They're pretty hard to read on my background color (a standard color scheme in DoomEd, 'Super Mal'). "So change the background!" I hear you say. :) Well, sure. But I'm wondering, why no support for changing the guard's color (which also happens to be the color of moveable_base_brick, and light_candleflame_moving (TDM-specific), etc.)? | ||||
Tags | No tags attached. | ||||
Those colours are defined in the .def files. They can of course be overriden (and I actually did that with the light colours), but enabling this for various types of entity classes would require a separate GUI. Don't know if that's worth it. This is really a weird background colour, btw. ;) |
|
To be honest, I have been toying with the idea of removing the DEF-defined colours altogether and have the entity colour configured through the colours dialog like everything else. This would simplify the code quite a bit (entity classes would no longer have to maintain colour and shader information) but there might be some mappers who actually like the per-entity colouring. | |
I dunno, it's a standard color definition in DoomEd ("SuperMal"). Black is too stark, and white will make you go blind! So what do we do? Leave it to people to hack def files (wait, do you mean Doom3 def files, or DR def files??) or...? As long as the def option is available to me, I'm thankful. It's not really every entity, just these hard to see green ones. |
|
It's in the Doom3/Dark Mod .def files as there exist no other def files ;). I'd prefer leaving the per-entity colouring, because it's easier to distinguish loot from other stuff, func_statics from entites, etc. |
|
If I understand correctly, it sounds like Doom3 def files determine what colors the items have the editor (oddly enough) but that gives the added feature of letting colors distinguish custom items. In that case, agreed, we should not mess with it. | |
Make entity default colour customizable. | |
Entity default colours are customisable now. | |
Is it reflected on the View | Colors dialog? On that page, the only thing I have set to black is 'Default Brush'. The entities (moveable_base_brick, builder guard) that I linked in the original entry used to be green, but now they are black. To confirm whether or not they are included with default brush, I changed default brush to an obnoxious pink, and here is the result: http://img184.imageshack.us/my.php?image=blackobjme9.jpg The entities are still black, while the default brushes have in fact turned pink. Maybe the entry for entity defaults was left off the dialog? |
|
You probably have to delete your local colours.xml file, otherwise the new settings will not be effective. And you have to restart DarkRadiant for the changes to take effect. |
|
To clarify, I did see changes (to default brush) without restarting, just not changes to the entities (nor a specific entry for them on the dialog). I've also tried deleting colors.xml but then DR refuses to start. Is there a way to do this without wiping out every setting I've defined? Edit: hmm, I'm guessing not. I look in the xml and do see an entry for default entity, but it doesn't show up on the dialog. Edit2: on second thought, even if I don't have an updated dialog which shows default entity, I still see in the xml that the definition is 1 .5 0, which IIRC is green, so for some reason I'm seeing them as black even though they're defined as green. |
|
Sorry, I should have been clearer: Please do NOT delete the colours.xml file in the installation folder, but this one: C:\Documents and Settings\SneaksieDave\Application Data\DarkRadiant\colours.xml This is where your local colour preferences are stored. They are blocking the default colours from being used, therefore you'll have to delete the file in order to make the changes visible. As for the restarting: Not all colour changes require a restart but some do. The entity def files are parsed at DarkRadiant startup and their default colours are set during that phase, so currently you'll have to restart to see the colour actually change. |
|
This quickly turned into a mini-nightmare, but I managed to get through. I had first moved the files so as to keep them (before your clarification), then tried to start DR without them. I guess that causes them to be reset, but it apparently didn't like it when I tried reinstating them. When I got rid of the user-specific xml, DR was crashing on map loads. Eventually, after much gritting of teeth and swearing, I manually updated the file and got it to work. DR is still acting weird; I have no more icon in the menus next to colors or background image, and my maps path is wrong, but at least it's not crashing anymore. Changing of default ent color confirmed. |
|
Date Modified | Username | Field | Change |
---|---|---|---|
27.02.2007 03:24 | SneaksieDave | New Issue | |
27.02.2007 03:24 | SneaksieDave | Description Updated | |
27.02.2007 08:09 | greebo | Note Added: 0000258 | |
27.02.2007 08:10 | greebo | Assigned To | => SneaksieDave |
27.02.2007 08:10 | greebo | Status | new => feedback |
27.02.2007 21:52 | orbweaver | Note Added: 0000262 | |
28.02.2007 02:40 | SneaksieDave | Note Added: 0000269 | |
28.02.2007 09:14 | greebo | Note Added: 0000275 | |
28.02.2007 21:16 | SneaksieDave | Status | feedback => closed |
28.02.2007 21:16 | SneaksieDave | Note Added: 0000290 | |
28.02.2007 21:16 | SneaksieDave | Resolution | open => fixed |
01.03.2007 21:58 | greebo | Assigned To | SneaksieDave => greebo |
01.03.2007 21:58 | greebo | Status | closed => feedback |
01.03.2007 21:58 | greebo | Resolution | fixed => reopened |
01.03.2007 21:58 | greebo | Note Added: 0000299 | |
01.03.2007 21:58 | greebo | Status | feedback => assigned |
03.03.2007 14:08 | greebo | Status | assigned => resolved |
03.03.2007 14:08 | greebo | Resolution | reopened => fixed |
03.03.2007 14:08 | greebo | Note Added: 0000307 | |
04.03.2007 16:09 | SneaksieDave | Status | resolved => feedback |
04.03.2007 16:09 | SneaksieDave | Resolution | fixed => reopened |
04.03.2007 16:09 | SneaksieDave | Note Added: 0000324 | |
04.03.2007 16:20 | greebo | Note Added: 0000327 | |
04.03.2007 16:21 | greebo | Note Edited: 0000327 | |
04.03.2007 17:21 | SneaksieDave | Note Added: 0000330 | |
04.03.2007 17:23 | SneaksieDave | Note Edited: 0000330 | |
04.03.2007 17:30 | SneaksieDave | Note Edited: 0000330 | |
04.03.2007 17:32 | greebo | Note Added: 0000331 | |
04.03.2007 18:13 | SneaksieDave | Status | feedback => closed |
04.03.2007 18:13 | SneaksieDave | Note Added: 0000333 | |
04.03.2007 18:13 | SneaksieDave | Resolution | reopened => fixed |
04.03.2007 18:13 | SneaksieDave | Fixed in Version | => latest SVN |