Likes Dislikes And Suggestions

[Unskilledlaborer]

LIKES

 

1 lower memory usage compared to doomedit

2 camera movement

3 the direction right click is going is a good direction clean but useful

4 I like texture menu just loads all the textures I select.

 

 

 

Dislikes

1 entity inspector missing usage information. (Very helpful if it was available

2 Entity inspector missing create button

3 Entity inspectors is missing GUI, SOUND, SKIN, MODEL, preview button and preview window.

4 I miss pressing J to bring up the light inspector

5 I miss a separate light inspector that works outside the entity inspector(wht you get when you press J in doom edit

 

 

 

Though the entity inspector does not have usage information available if it does get added it should expand on doomedits limited usage information by giving both side of the usage example:

When you add a property to a target_x and trigger_y must have some other property added before it can trigger target_x. but you don’t know that until you read about it in trigger_X

 

So I can’t remember exactly what property it was but it was like my example and I would have loved to know the other side of the usage information…anyways that is how I learned about the triggers and targets and gui and stuff. One night I sat and read the the usage and tested it in a test map. I suppose lots of us learn best when we can figure it out. Sometimes we can even learn a better way of doing something just by reading the usage information provided. And the key value information provided inside entity [like how to set gui_parm3 to name the area.]

[OrbWeaver]

1 lower memory usage compared to doomedit

 

It's probably not fair to compare the two, since with DoomEdit you have the whole game loaded as well. Nevertheless DarkRadiant having acceptable memory usage is a good start.

 

2 camera movement

 

I agree, this is much easier to use.

 

3 the direction right click is going is a good direction clean but useful

 

Glad you like it.

 

4 I like texture menu just loads all the textures I select.

 

Yep, this should improve with the Media Browser, which will allow you to load any individual texture or group of textures into the texture preview window.

 

3 Entity inspectors is missing GUI, SOUND, SKIN, MODEL, preview button and preview window.

 

These won't take the form of buttons, but of Property Editors in the Entity Inspector. I.e. when you select the "model" or "skin" property, a widget will be displayed allowing you to browse these DoomEdit-style.

 

4 I miss pressing J to bring up the light inspector

 

Initially I was planning to do a separate light inspector, but decided to merge this functionality into the Entity Inspector. I might consider a dedicated dialog for lights if enough people request it, but it's not a priority at the moment.

 

Though the entity inspector does not have usage information available if it does get added it should expand on doomedits limited usage information by giving both side of the usage example:

 

The usage information is parsed directly from the entity definitions, there won't be any way to expand on the information that the developers put into the DEF files.

[NeonsStyle]

This is a little old now, but might as well freshen it:

 

Likes:

 

Love the camera view, works the same as GTK

Love the texture view system, except that caulk often disappears for some reason when I hit U to show only those on the existing map. This is annoying since I have to reload common, and once caulked, need to reload all the darkmod textures. There is a way around it, but it doesn't seem to always work (show all).

Love the feel of it, its exactly like GTK.

Absolutely love the texturing method, though there's a bug in there when textures go fuzzy and u undo, it crashes.

I like the right click menu, no where near as crowded as gtk1.5 (I never used doomedit, I hated it).

I love the model viewer. Absolutely love it.

 

Dislikes:

 

I miss J key to toggle the face and brush colouring. In GTK, J on (brush lines/texture faces selected, patches selected when they are red) toggles thru the red disappearing, or the red lines around brushes disappearing in cam view. It was useful for texturing brushes and patches by seeing it without the red)

 

I miss the [ & ] keys to alter the grid size

 

I've not done much with entities yet, still building. However I did have a look at one, func_door. I gave it some of the standard keys I used to use for doors such as lip, wait and speed. These were not recognised.

Lip I can understand with rotating doors.

 

I absolutely hate the entity editor. Can you do it like GTK did? With a dialog, that allowed you to enter all the keys one after the other just with the enter key. In the current one, I have to click (all properties), then click add, then type in my key name, then the value, then I have to click on the white somewhere before I can add another one, then I have to repeat all that again. Much better to just be able to select the typing part, type in the key, then the value, then hit enter to enter a new key. Not sure if your going to add the angle buttons GTK had, but I miss them too.

 

I miss autosave - I've mentioned before it doesn't work.

 

Other than that; I am totally in love with this editor.

 

Venus

[OrbWeaver]

I miss J key to toggle the face and brush colouring. In GTK, J on (brush lines/texture faces selected, patches selected when they are red) toggles thru the red disappearing, or the red lines around brushes disappearing in cam view. It was useful for texturing brushes and patches by seeing it without the red)

 

I miss the [ & ] keys to alter the grid size

 

I haven't actually removed any key shortcuts to my knowledge, but these might be additions to GTK since the start of DarkRadiant. It may be possible to merge these features into the codebase if they are upstream.

 

I've not done much with entities yet, still building. However I did have a look at one, func_door. I gave it some of the standard keys I used to use for doors such as lip, wait and speed. These were not recognised.Lip I can understand with rotating doors.

 

I absolutely hate the entity editor. Can you do it like GTK did? With a dialog, that allowed you to enter all the keys one after the other just with the enter key. In the current one, I have to click (all properties), then click add, then type in my key name, then the value, then I have to click on the white somewhere before I can add another one, then I have to repeat all that again. Much better to just be able to select the typing part, type in the key, then the value, then hit enter to enter a new key. Not sure if your going to add the angle buttons GTK had, but I miss them too.

 

The idea is that all of the keys mappers need to use will be in the tree list (this mirrors the Dromed and T3Ed methods, and is more user-friendly than requiring mappers to memorise key names). There are a lot of keys still to be added which is why you need to use the All Properties dialog, but this is not the intention in the long run. You shouldn't have to deselect a key before using the Add button however, this may be a bug.

[New Horizon]

Looks like they just released a heap of fixes for GTK too, plus some enhancements to the texture browser. Going to check it out and see how it looks.

 

Edit:

 

Well, they didn't really do anything too spectacular to the texture browser...but what they did makes sense.

 

[sparhawk]

How are such changes incorporated. You created your own branch, right? But this would mean that any enhancements or fixes have to be merged in our version, right? Isn't there some better way to keep the two in sync?

[OrbWeaver]

How are such changes incorporated. You created your own branch, right? But this would mean that any enhancements or fixes have to be merged in our version, right? Isn't there some better way to keep the two in sync?

 

Not really, a manual merge is the only real way to do this. Fortunately SVN makes it very easy to get a repository-wide diff of each revision, and using patch on Linux I can merge in changes without too much effort. Obviously this will get harder as the two codebases tend to separate, and patches for GTKRadiant will no longer work - fortunately most upstream fixes are irrelevant to DarkRadiant (like enhancements for Enemy Territory support, or bugfixes in code that I have already replaced) so this won't be too much of a problem.

 

The "enhanced texturebrowser" functionality is similar to what I was intending for the media browser, except that it limits space by combining the tree and the texture view in a single window, and also only allows single-level browsing of texture "families".

[Gildoran]

I absolutely hate the entity editor. Can you do it like GTK did? With a dialog, that allowed you to enter all the keys one after the other just with the enter key. In the current one, I have to click (all properties), then click add, then type in my key name, then the value, then I have to click on the white somewhere before I can add another one, then I have to repeat all that again. Much better to just be able to select the typing part, type in the key, then the value, then hit enter to enter a new key. Not sure if your going to add the angle buttons GTK had, but I miss them too.

I completely agree... the entity editor drives me absolutely bonkers too. If I want a list of things I can enter, I look in the entity documentation that's displayed in the entity browser in D3ed. It has a list of keys and what they do, and double clicking on a key even automatically types it for you. Plus, there's cases where you can't get a list of every possible key... for example readables, where the keys depend on the GUI.

[OrbWeaver]

Would these issues be improved by modifying the All Properties dialog so that you could enter a number of keys just by typing and pressing Enter (like Venus said)?

 

I actually agree that the categorised entity list may need some improvement, for the simple reasons that I hardly ever use this method to examine keys - "too many clicks" I think is the problem. It is not obvious what to do about this: although a simple Doom 3 interface could be used, I don't want to lose either the newbie-friendliness of making all the available keys visible, or the key-specific editing interfaces (like the color selection button for "_color" keys). I wonder if the two interfaces could be combined in some way, bearing in mind the screen space is limited.

 

I guess as a last resort a simple preferences option to select one of two interface styles would be sufficient, but I don't really favour this kind of thing because it requires twice as much maintenance, and doesn't encourage the development of a "good" interface which should be usable by all.

[sparhawk]

For the menu entries, it would be nice if a key could be added like "menuname" "Darkmod/maybeasubmenu as well/andhere/..." (as example), and then the entity will be listed under this menuentry.

Currently the def files are parsed and the menu is constructed based on the names of the entities. If the parser would recognize such a key, then it would be easier to specify where an item should go. If an entity doesn't have such a key, then the algorithm can work as it is now. Should be rather straightforward to implement this and would allow to create a nicely structured menu.

[OrbWeaver]

For the menu entries, it would be nice if a key could be added like "menuname" "Darkmod/maybeasubmenu as well/andhere/..." (as example), and then the entity will be listed under this menuentry.Currently the def files are parsed and the menu is constructed based on the names of the entities. If the parser would recognize such a key, then it would be easier to specify where an item should go. If an entity doesn't have such a key, then the algorithm can work as it is now. Should be rather straightforward to implement this and would allow to create a nicely structured menu.

 

That is perfectly possible to implement, if that is the direction we want to go in terms of specifying the entity hierarchy (and it sounds reasonable enough to me).

 

I would suggest a key like "editor_entityBrowserPath" since I am pretty sure than anything starting with "editor_" is ignored by the game (which actually gives us a potentially unlimited amount of editor-specific information storage).

[NeonsStyle]

I haven't actually removed any key shortcuts to my knowledge, but these might be additions to GTK since the start of DarkRadiant. It may be possible to merge these features into the codebase if they are upstream.

 

The idea is that all of the keys mappers need to use will be in the tree list (this mirrors the Dromed and T3Ed methods, and is more user-friendly than requiring mappers to memorise key names). There are a lot of keys still to be added which is why you need to use the All Properties dialog, but this is not the intention in the long run. You shouldn't have to deselect a key before using the Add button however, this may be a bug.

 

Yes I think it may be something added after. Its definitely in GTK, the J key I mean. Yes I can understand your thinking on the way you'd like to do it. I love the idea of having all the keys visible. What I ask you to keep in mind in all of your thinking, is to make it as effecient in terms of mouse clicks, keys hit for mappers to activate things. Given how often we repeat the same thing, being able to do it as efficiently as possible is a real time save (not to mention my poor wrist lol).

 

Would these issues be improved by modifying the All Properties dialog so that you could enter a number of keys just by typing and pressing Enter (like Venus said)?

 

I think so yes, however I also like the idea of being able to just click a key from a list and have it add it. The way I worked in GTK was simply scan the key list of the func etc then just type it in. But I'd much rather just click on the key, and have it entered for me, then I just have to give it a value (type it, hit enter and its done).

 

I actually agree that the categorised entity list may need some improvement, for the simple reasons that I hardly ever use this method to examine keys - "too many clicks" I think is the problem. It is not obvious what to do about this: although a simple Doom 3 interface could be used, I don't want to lose either the newbie-friendliness of making all the available keys visible, or the key-specific editing interfaces (like the color selection button for "_color" keys). I wonder if the two interfaces could be combined in some way, bearing in mind the screen space is limited.

 

I think it would be a big mistake not to have the available keys visible. For me when I was learning, that list was invaluable (and I'm learning all over again now, so I need it even more lol). I wouldn't mind a preferences way. I think really, the best thing, is to come up with something that is similar to GTK. There's a window to slide up that shows all the keys, but for those who know them all, it can remain hidden, and just quickly enter what you need and its done. Entities can then be knocked off really quickly. I'd be happy with something like GTK's way. Anything that is efficient and has information handy when needed.

 

Venus

[NeonsStyle]

For the menu entries, it would be nice if a key could be added like "menuname" "Darkmod/maybeasubmenu as well/andhere/..." (as example), and then the entity will be listed under this menuentry.

Currently the def files are parsed and the menu is constructed based on the names of the entities. If the parser would recognize such a key, then it would be easier to specify where an item should go. If an entity doesn't have such a key, then the algorithm can work as it is now. Should be rather straightforward to implement this and would allow to create a nicely structured menu.

 

Sounds like programming speak lol... Are you saying the keys would be stored in a menu next to the entity name? ie right click, Entity, Func_Door, then list of keys; as a menu?

 

If so, not sure I'd like that, as I want that key info open so I can see it when I'm creating an entity; I have a crappy short term memory (too many drugs when I was younger) lol..

 

Ven

[OrbWeaver]

I think so yes, however I also like the idea of being able to just click a key from a list and have it add it. The way I worked in GTK was simply scan the key list of the func etc then just type it in. But I'd much rather just click on the key, and have it entered for me, then I just have to give it a value (type it, hit enter and its done).

 

I almost wonder if the best way to display the keys would be to have a flat list, rather than a categorised list (hence minimising clicks and displaying more information at once), but have an "Add" button/menuitem which allowed you to select a key to add from a hierarchical menu (like Dromed), as well as text boxes to enter the keys by hand if preferred, and the key-specific property editor at the bottom.

 

The categorised view does have a certain "cool factor" but it seems like for actual use by mappers it might be more of a burden than an enhancement.

[OrbWeaver]

Sounds like programming speak lol... Are you saying the keys would be stored in a menu next to the entity name? ie right click, Entity, Func_Door, then list of keys; as a menu?

 

I believe sparhawk is talking about the "Create entity" dialog not the Entity Inspector. As you will have noticed, this dialog is just a flat list with everything in it, rather than a tree with entities structured by purpose.

[sparhawk]

That is perfectly possible to implement, if that is the direction we want to go in terms of specifying the entity hierarchy (and it sounds reasonable enough to me).

 

I would suggest a key like "editor_entityBrowserPath" since I am pretty sure than anything starting with "editor_" is ignored by the game (which actually gives us a potentially unlimited amount of editor-specific information storage).

 

Yeah! That would be cool. Especially if you can also support hierarchies like I showed in the example. So the key

"editor_ourmenu" "Darkmod/AI/Servants"

 

would mean that you create the complete subhierarchy in case none of it exists yet, and if another one is specified it can use existing entries, if they already exist. So you must keep track of the individual names as "Darkmod", "AI" and "Servants" in this case.

 

And also the special name

"editor_whatevermenu" "none"

 

would be helpfull to ommit helper classes that are not supposed to be converted into entities anyway (like frobable_base or others).

[OrbWeaver]

Building the hierarchy from a list of "a/b/c" strings which may appear in an arbitrary order is decidedly non-trivial if you want to do it in a way which is neither incomprehensible nor appallingly slow. Fortunately I already have code to do that for the model selector (actually it's mostly comments, since without them I can't understand what the code is doing) so it shouldn't be too difficult to genericise this for use elsewhere.

 

I wouldn't want to omit classes entirely; a class that is only used for inheritance would simply appear as a "directory" and would not be created by the user in most circumstances (this was the same in Dromed as I recall).

[sparhawk]

Well, that's ok for me. I thought it might be nice to explicitly flag them not to appear, but it's not really a big issue. As for the complexity of the code. You would need to keep an array of the names that you already created along with their handle. Parsing the string and split it into seperate names should be easy, because there are already filefunctions which can do this. So you would only have to loop through the array and check if the name already exists and if yes then reuse it, otherwise create a new menuentry and put it in the array. Seems not so hard to do for me. I doubt that the loading speed would be so much slower, because how many entities are there? Splitting the string, if it exists, and scanning the array is pretty fast, because the number of entries will be pretty low anyway.

[OrbWeaver]

That's basically it, except it is recursive because adding "a/b/c" requires adding "a/b", but "a/b" is itself a child of "a" which may not have been added. If you didn't keep a cache of strings->tree entries, you would probably find this is O(N^2) complexity as you had to scan down from the parent for each new entry, checking if every ancestor was created every time. I'm actually quite pleased with how quick the model selector is when it does this - only a few seconds delay on my system the first time it is created.

[sparhawk]

You don't need to construct the menu from scratch everytime. And even if you do, that doesn't matter, because you need to create the structure only once, while parsing the def files. After that it doesn't change anymore. Once you got the hierarchie laid out, and you want to createt he tree for the menu, you just traverse it, or you create the menu once and then hide it when you don't need it. I can guarantuee you that even though the complexity is O(N^2) that doesn't matter, because you only deal with a small number of items.

[OrbWeaver]

Yep, that's exactly how I did it for the Model Selector, and how I would do it for this also. The dialog widget is created on first use and then just hidden/redisplayed every time afterwards.

[OrbWeaver]

In the current one, I have to click (all properties), then click add, then type in my key name, then the value, then I have to click on the white somewhere before I can add another one, then I have to repeat all that again.

 

I just tested this - at least on my system, you don't have to click on the white to add another key, you can just use the Add button immediately using the keyboard shortcut.

 

I.e.

 

Alt-A

<type key> Enter

<type value> Enter

Alt-A

<type key2> Enter

<type value2> Enter

 

Does this method not work on your system? Maybe there is a problem in Windows, I guess I'd better look into it.