Itches, Glitches & Anything Else...

[greebo]

Cross hairs 'spontaneously' enabled. I was texturing, mostly in full screen camera view, also used clipper and surface inspector. Went back to the grid view and saw cross hairs enabled. Went to Preferences and found it enabled (definitely not by me as it's days since I used prefs and you just can't miss noticing cross hairs.) I can't see any shortcut key or button I might have accidentally pressed. Very insignificant little glitch if it is one at all but worth mentioning.

Hit Shift-X to toggle the crosshairs. I think that's the shortcut.

 

Piggyback question: is there a way to remove a point set in clipper? I sometimes click again to reposition 1 instead of dragging it and finish up with point 2 where I don't want it. Sometimes I set a point 3 I don't want at all. I have to hit the QE button to clear it and start over. Anyway to just clear the last setting? Or even clear all would help as I'm often in full screen grid view so QE button hidden.

 

After you placed the third clip point just click again to clear the current set and recommence with a first one. Of course, you can switch back to drag mode and back to clipper mode to clear it as fine.

[Fidcal]

Ah shift X makes sense as I use shift C and shift V for copy and paste textures so its next to C; I must have hit it. And X to toggle clipper which is also great. I just didn't look under toggle. I feel an addition to the controls wiki coming on......

[SneaksieDave]

I've reported the selection problem mentioned a few posts back.

 

General comment on defect reporting: when real problems such as this one are found (not just itches, glitches, and anything else (minor or request-based)), they need to be reported on bugtracker, or they will be forgotten and lost. Though I have covered these myself sometimes, I won't do this for everything everyone finds. I tracked this one specifically (and another by another user recently) because it affects my general use, so I run into it myself; I use select complete tall constantly. By reporting these, I'm not trying to steal anyone's thunder (or defect reports), but for productivity's sake, they have to be reported. There is a followup as well of course; if you report something, when it is sent back as fixed, you should verify your submissions as well. It is not requested (or suggested) that people verify other's entries, but it's best if you at least verify your own. A bunch of fixed-but-unconfirmed items isn't really useful to the developers, or us.

[Fidcal]

There's some stuff in the entity list such as these...

 

atdm:item_book_red1

atdm:item_book_t1

atdm:item_paper1

 

When selected I think they are an origin without any model. Is that intended? If I show inherited props I see a model but maybe the path is wrong or something. Just wondering. Or maybe some entities are now obsolete.

[greebo]

Yes, another file that hasn't been updated after the model reorg. I fixed the model paths, it should be resolved now. (not a DarkRadiant issue, btw.)

[jdude]

I found a glitch in Dark Radiant!

 

Copy a texture, apply it to a brush face, press CTRL+Z to undo then try and apply the texture again. It doesn't apply and you have to recopy it in order to do so.

[greebo]

Yes, that's been reported by SneaksieDave before. The ShaderClipboard is cleared when the user hits Undo. My rationale was that I can't know for sure if the Undo operation doesn't delete the source object to copy the texture from (which would result in a crash). The behaviour is intended, but obviously not expected by the user.

 

As it seems to be an annoyance, I can reopen the task on the tracker and look if I can do something about it. (Issue #283)

[SneaksieDave]

Ah, I thought that was familiar, and that you'd be the guy to remember the reason behind it. Well that's cool if something can be done about it. I assume the reference would just be copied in a different way or whatever.

[Fidcal]

Just expanding the Dark Radiant Controls wiki but can't see what paste shader natural does any different to paste shader. I thought it would paste as if 'natural' were clicked on the surface inspector?

[greebo]

Compare these two articles, this should explain the differences:

 

http://www.thirdfilms.com/darkwiki/index.p...xture_Projected

http://www.thirdfilms.com/darkwiki/index.p...Texture_Natural

 

Basically, "Paste Texture Natural" only makes a difference for pasting shaders from brushes onto patches.

[Fidcal]

OK, thanks. I'll do a brief hint and link to that as I don't think it can be summarised adequately - by me anyway!

 

On a slightly related note I created the skeleton of that controls table on the wiki from a DR default input.xml of 27th July but I don't see Shift MMB for the PasteShaderNatural. I see it does work in my current DR tho' PasteShaderNatural is unassigned in the shortcuts. Are there any more like that I can include in the wiki?

 

Let me see I know of shift drag or rather drag shift to move in one plane and those camera moves but a comprehensive list would be good. I'm trying to make a big push to take that controls wiki a bit further. All the shortcuts are listed but only a percentage expanded/explained. I'm working through the menus and adding to them and then the buttons. Might even add mini images. By then most shortcuts should be included in the same process. But mouses? Maybe some of them are in the original Doom? I'll do a search of the doom wiki...

[greebo]

The mouse actions are (code-wise) completely unrelated to the actual commands which can be assigned to a shortcut. All of the available ones should be listed in the input.xml file (with a few ones hard-coded). This should cover everything:

 

XYView:

• RMB: Open Context Menu
  
• LMB: Nothing
  
• Shift-LMB: Toggle selection
  
• Shift-LMB-Drag: Select Partial Tall (toggle selection of items touched by drag rectangle)
  
• Shift-Alt-LMB: Cycle selection (front to back)
  
• Ctrl-Shift-MMB: Toggle Face Selection
  
• Ctrl-Shift-Alt-MMB: Cycle Face Selection
  
• RMB-Drag: pan the xy view (applies for XYView and TextureTool)
  
• LMB-Drag (with nothing selected): NewBrushDrag
  
• LMB-Drag (with active selection): Manipulate the existing selection (resize, rotate, move)
  
• Shift-RMB-Drag: Zoom view
  
• Mouse wheel up/down: Zoom view in/out
  
• Ctrl-MMB: Move camera to here
  
• MMB: Point camera view here
  

Camera View:

• RMB: Toggle free move mode / activate free move mode (depends on preference settings)
  
• LMB: Nothing
  
• Shift-LMB: Toggle selection
  
• Shift-LMB-Drag: Select Partial Tall (toggle selection of items touched by drag rectangle)
  
• Shift-Alt-LMB: Cycle selection (front to back)
  
• Ctrl-Shift-MMB: Toggle Face Selection
  
• Ctrl-Shift-Alt-MMB: Cycle Face Selection
  
• RMB-Drag: Nothing
  
• LMB-Drag (with active selection): Manipulate the existing selection (resize, rotate, move)
  
• Shift-RMB: Move camera to center of clicked item ("Jump to Object")
  
• Mouse wheel up/down: Move camera forward/backward
  
• MMB: Copy Texture
  
• Ctrl-MMB: Paste Texture (projected, where applicable)
  
• Ctrl-Shift-MMB: Paste Texture (natural, where applicable (brushes to patches))
  
• Ctrl-Alt-MMB: Paste Texture to entire Brush (i.e. all faces of clicked object, projected)
  
• Alt-MMB: Paste Texture Coordinates (only applies to Patch-to-Patch paste operations)
  

Now I'll be back to learning...

[Fidcal]

While testing for the wiki I found Insert and Delete keys only zoom on the first opened orthoview window. Mouse wheel zooms on all orthoview windows. Yet oddly, if you maximize a later window, then use the mousewheel, then the keys, it starts to work but now the original window doesn't.

[greebo]

@OrbWeaver: I'm currently into the annoying EntityInspector issue (key entry field gets reset when hitting TAB):

 

Actually, the TAB key is not caught anywhere (via key-release event), so it rather seems that the callbackTreeSelectionChanged() method is called by GTK although nothing has been changed. The GTK manual says:

The GtkTreeSelection changed signal

Emitted whenever the selection has (possibly) changed. Please note that this signal is mostly a hint. It may only be emitted once when a range of rows are selected, and it may occasionally be emitted when nothing has happened.

 

So I'm assuming that I'll have to save the last treeselection and evaluate it against the one passed to the callback to judge whether anything has actually changed? Or should I rather catch the TAB key and handle this event by itself?

[OrbWeaver]

So I'm assuming that I'll have to save the last treeselection and evaluate it against the one passed to the callback to judge whether anything has actually changed?

 

I would take this approach. It will be necessary to make sure that this doesn't interfere with any of the PropertyEditor panel's stuff, although it may even be better to do this (because the PropertyEditor won't be destroyed and recreated whenever it makes an update).

[greebo]

Scrap that, I've found the root of the problem. The TAB key is actually assigned to "GroupCycleForward", which attempts to select the children of any group entity. The problem is that "GroupCycleForward" also changes the selection when only one entity is selected, and the EntityInspector::selectionChanged() call is invoked, which in turn clears and reloads the TreeModel.

 

I'll change the GroupCycle behaviour instead, the EntityInspector code seems to be fine as it is.

[greebo]

Fixed. This was a headache, I already had the code for comparing the TreeIters up and running, when I realised that the TAB was actually caught by the EventManager. Now it's a two-line change.

 

I wonder if the TAB key should be prevented from being passed on to the main window, but I guess the TAB is a special case, as all the other keys are possibly routed directly into the entry fields, where they belong.

[jdude]

I know we've been over this before, but there is definitely something wrong with the model viewer in DR. Over the last week I've had it crash over 5 times only in the model viewer, It seems to be randomly while loading a random model though, so it will be hard to figure out what exactly is going on.

 

edit: It would also be very handy to have a button you can hit to drop a model to the floor so you don't have to do it every time yourself.

[greebo]

I agree that such a button would come in handy. Please add it to the tracker.

 

As for the crash: please try to pin down what we have to do to reproduce that. I've never had any crashes lately myself.

[Fidcal]

edit: It would also be very handy to have a button you can hit to drop a model to the floor so you don't have to do it every time yourself.

 

Yes, like 'floor me' in Dromed to drop down to the next horizontal brush surface. There is also a 'wall me' I think for torches and such and possibly a 'ceiling me'. I'm not sure about both of those as mostly used 'floor me' and didn't discover the other for years!

 

If looking at the model code, and if it is easy to do, and only if it saves display time, I'd like a 'don't load images' option. Waiting half a minute or more just to select from a list when you don't particularly need to see a picture is more and more frustrating. But where would such an option go as it needs to be switched on and off as needed so the Preferences route to turn it off might be just as distracting as just waiting. Or if in the viewer itself then you'd have to wait to switch it off. So either a pre-dialog or two options in the right click menu?

[greebo]

If looking at the model code, and if it is easy to do, and only if it saves display time, I'd like a 'don't load images' option. Waiting half a minute or more just to select from a list when you don't particularly need to see a picture is more and more frustrating.

Are you referring to the load time when you click on "Create Model"? This is due to the filesystem search, as the actual images are only loaded when a model is highlighted in the viewer. The loading process has been sped up a bit by OrbWeaver lately, so expect a change in the next release (the snapshot already contains the improved code).

[Fidcal]

OK, thanks, I'll check that out. But if it only marginally improves the loading time, can't the data (the results of the search), once loaded, be saved as a single data file to load almost instantly with an 'update' option on the viewer which the user can click for instance after each SVN update? To perform the same lengthy file search every time seems wasteful especially since it is finding exactly the same data most of the time. This will be even more true when DM is launched and maybe there will be no updates for months, even years, yet DR will keep doing its file search for the same files every time it is used - forever.

[OrbWeaver]

Yes, as greebo says there was a performance issue which meant that the search took about twice as long as it should have (one period of time on "Searching..." and then a similar period of time with the individual model names being displayed). I don't know whether you are using a version before or after this change however.

 

In theory it would be possible to cache the results, but it would obviously be more work (and introduce issues with cache consistency etc) for what seems to me to be little gain. However, on my PC it doesn't take very long to traverse the model tree so maybe this is more of a problem for other people.

[Fidcal]

OK, thanks, I'll wait for the next update. At the moment it is taking about 40 seconds before the list appears. Even if that is reduced by half, I hope everyone is going to be happy with that in a year or so at launch, when perhaps there might be double the models, or more?

[Fidcal]

Didn't info_player_start use to have an arrow pointer to indicate which way it was facing?

 

On loading a map the camera seems to start at info_player_start's origin but this origin is at the bottom of info_player_start so the camera always starts embedded in the floor for me.