easy to clone way too many brushes holding spacebar

[Komag]

This happened to me today, I went to clone a brush and I just sort of absentmindedly held the spacebar for a few seconds. After a moved the new clone, I though about it and checked, and sure enough there were like 30 brushes in the same old spot!

 

I don't know if this is something to add to bugtracker, as I don't know if there's really anything to do about it. Are there other commands or things in DR that we would want key-repeat on for? If not, can key-repeat be turned off when DR window is active?

[greebo]

The key-repeat handling is done by Windows/GTK itself - DarkRadiant just receives the events and acts about it.

 

In principle I could write some solution around it (like check both key-up and key-down events and keep track of their state using a timer, but this would probably introduce a lot of bugs (like what happens when the player is holding down a key and then switches between applications - DarkRadiant will never receive the key-up event).

 

Too much of a hassle, in my opinion - if the user is holding down the spacebar for 30 seconds, I'd say it's his own fault.

[Komag]

ah well, I guess it's fine as is, since this is the first time it's happened to me (that I know of) after a ton of hours of use. And I can set my own Windows key repeat delay (I think) to make it a bit longer

[sparhawk]

In principle I could write some solution around it (like check both key-up and key-down events and keep track of their state using a timer, but this would probably introduce a lot of bugs (like what happens when the player is holding down a key and then switches between applications - DarkRadiant will never receive the key-up event).

 

Don't do it so complicated. You might add a flag to the key configuration, and a boolean for each key. When the flag is set, which means to prevent repeating, then you can set the boolean when the key is pressed and clear it when the key is released.

 

if(bool == true)
  return;


bool = true
... perform operation ...

[greebo]

You might add a flag to the key configuration, and a boolean for each key. When the flag is set, which means to prevent repeating, then you can set the boolean when the key is pressed and clear it when the key is released.

As I wrote above, I think this is not as easy as it might sound. Trouble starts when key-down and key-up events start to get unsymmetric due to application switching or whatever.

 

My standing is that it's not DarkRadiant's job to prevent the user from doing pathetic things.

[sparhawk]

Yeah, I also think it's not a priority. But it's not as hard as it seems. I have done this before, for other applications.

[SneaksieDave]

What if this is the same as the duplication others (e.g. Fidcal) have reported? A hiccup in windows process, which happens all the time. Mouse down received, some CPU logjam for a fraction of a second, something duped twice, and then mouse up received. End result, mapper doesn't notice that instead of one dupe, he's got two.

[OrbWeaver]

I suspect this kind of problem was one of the reasons behind Doom 3's duplicate offset feature, which would make it very obvious when accidental duplication had occured because the new brush would be in a different position.

 

Another (possibly better) solution would be to have a more sensible default key binding for duplicate, which involved a modifier (like Blender's Shift-D). It is rather hard to accidentally hold down two keys at once.

[Domarius]

Another way could be to detect the instantiation of several brushes quickly, something that would most likely be a mistake, and prompt to clean them up.

[Komag]

Or DR could disallow more than two brushes of the same exact size and location. So if you really want to make multiple copies you have to copy, move, copy, move, etc. That would solve it pretty well. Does anyone ever actually WANT to make 6 copies of a brush all at once?

 

This would also help just in case you forgot if you cloned it yet. Sometimes I'll move the brush and see that it hasn't been cloned yet, when I thought it had (or the other way around too), and with this I could just try to clone it again and if it worked great and if not no harm done)

[OrbWeaver]

Another way could be to detect the instantiation of several brushes quickly, something that would most likely be a mistake, and prompt to clean them up.

 

Not a trivial solution, it would require timestamping brush creation and special handling for map load (when many brushes are instantiated very rapidly).

 

Or DR could disallow more than two brushes of the same exact size and location. So if you really want to make multiple copies you have to copy, move, copy, move, etc. That would solve it pretty well. Does anyone ever actually WANT to make 6 copies of a brush all at once?

 

That just sounds like a more technically-complex version of the automatic duplicate offset. Determining that two arbitrary brushes are equivalent is probably non-trivial to compute, and this would only force the user to do something (move the brush) which DR could just as well have done automatically.

[Komag]

That just sounds like a more technically-complex version of the automatic duplicate offset. Determining that two arbitrary brushes are equivalent is probably non-trivial to compute, and this would only force the user to do something (move the brush) which DR could just as well have done automatically.

 

So if it DID offset on duplication like Doom 3, if you dupe again does offset from the new brush? Yes that would solve this issue, but I'm not sure I like the idea of offsetting. I'm sure I could get used to it and live with it, but I like having the brush in the same place because very often I want to keep the same line up for the walls or floor corner or something.

 

To avoid having to figure out whether two brushes are the same, could DR simply disallow two duplicate commands to happen consecutively? Technically one could duplicate, the go move some other brush or click on something else, then select the brush and dupe it again unknowingly, but that's just a crazy "what if" scenario.

 

So disallowing two dupes in a row would solve it handily I think, maybe with a little "bing" sound on successive dupe attemps so we know what's going on.

[greebo]

So disallowing two dupes in a row would solve it handily I think, maybe with a little "bing" sound on successive dupe attemps so we know what's going on.

This sounds quite feasible, except the part with the "bing" sound. I don't really know how GTK is dealing with emitting sounds for user feedback.

[OrbWeaver]

So disallowing two dupes in a row would solve it handily I think, maybe with a little "bing" sound on successive dupe attemps so we know what's going on.

 

It would also be extremely annoying for a user who actually wants to create multiple duplicates in a row (for example to create a series of pillars in a room). I am not at all in favour of imposing restrictions that advanced users will have to work around, just to stop careless users from doing something accidentally.

[Crispy]

Er... can't you just duplicate on a key-up event, instead of a key-down event? I'm not familiar with how GTK does things, but every other windowing toolkit I've used sends this sequence of events if you hold down a key for some period of time:

 

key down (the initial press)

key down (a repeat, after some interval)

key down (ditto)

key down (ditto)

key up (when the key is released)

 

Surely it would make more sense to tie the "duplicate" operation to the key up events, not the key down events. Especially since there's no direct feedback on the number of brushes you've just cloned.

[Komag]

It would also be extremely annoying for a user who actually wants to create multiple duplicates in a row (for example to create a series of pillars in a room). I am not at all in favour of imposing restrictions that advanced users will have to work around, just to stop careless users from doing something accidentally.

 

 

But it wouldn't cause a problem there because of the moving inbetween dupes. Unless you are suggesting that you have a pillar and you actually hit spacebar 5 times in a row and THEN move the brushes to their positions. That's why I asked above "Does anyone ever actually WANT to make 6 copies of a brush all at once?" If people really do this type of thing then I agree that we shouldn't limit it.

 

I'm simply concerned that duplicate brushes are bad for the map, and we're all human so they are bound to happen, and measures should be taken to minimize that. But are dupes bad for the map? All my past experience tells me they should be avoided, but I may be wrong. Will they cause trouble during map compiling?

[Tels]

But it wouldn't cause a problem there because of the moving inbetween dupes. Unless you are suggesting that you have a pillar and you actually hit spacebar 5 times in a row and THEN move the brushes to their positions. That's why I asked above "Does anyone ever actually WANT to make 6 copies of a brush all at once?" If people really do this type of thing then I agree that we shouldn't limit it.

 

I'm simply concerned that duplicate brushes are bad for the map, and we're all human so they are bound to happen, and measures should be taken to minimize that. But are dupes bad for the map? All my past experience tells me they should be avoided, but I may be wrong. Will they cause trouble during map compiling?

 

Dupes of moveables are definitely bad. Just a few days ago angua fixed a bug that having two objects sticking at inside each other at exactly the same place would simple hang doom if you run into them

 

Now this "works", but it is still apparent that if you pick up one carrot, another stays in the same place.

[SneaksieDave]

To try to make the point again, it's not necessarily user error or carelessness causing this. Many times CPU spikes (for whatever background reason) will cause programs to stutter. If that stutter happens after a down event but before the up event, that's probably the origin of the rogue dupes. If some kind of dupe "flood control" could be implemented, it would fix the problem while also allowing weirdos (kidding!) to make multiple dupes. I was going to suggest a dialog after one ("You are about to duplicate this item more than one time. Continue?"), but if Crispy's idea can be done, I think that's even better. Even if someone does want multiples, they surely want a controlled number of multiples, which that method allows for gracefully.

[OrbWeaver]

I think using the key up event rather than the key down event would be the best initial solution, however I didn't write the event manager code so I guess Greebo would need to determine whether that is possible.

[greebo]

I think using the key up event rather than the key down event would be the best initial solution, however I didn't write the event manager code so I guess Greebo would need to determine whether that is possible.

It is possible, yes. I can test it by changing that globally, but I have a feeling that for some commands this might feel awkward. I'll have to check it out.

 

(To be honest, I don't believe that CPU "stutters" are able to cause these type of duplication issues. When the CPU stutters, there won't be any duplication routines in DarkRadiant running either.)

[Tels]

It is possible, yes. I can test it by changing that globally, but I have a feeling that for some commands this might feel awkward. I'll have to check it out.

 

(To be honest, I don't believe that CPU "stutters" are able to cause these type of duplication issues. When the CPU stutters, there won't be any duplication routines in DarkRadiant running either.)

 

Mouse clicks on buttons typically also work on the "mouse up" event, meaning if you accidentily click a button, you can still move the mouse out of the way before releasing the mouse button.

 

Dunno why that would't work for keys, tho.

[greebo]

Just checked it out. It does prevent mass duplication, but it breaks the camera movement and the nudge/texture shift operations. It is not ok if the camera only moves a single step forward on the key up event.

[Komag]

Woah, can't break those, definitely not OK.

 

If nothing else can be done I'd say just leave it as is.

 

If duplicate terrain brushes just get eaten up by the compiler and don't make a difference in the end, then maybe they simply aren't a problem. If duplicate moveables like carrots or whatever can cause a problem, wouldn't those be relatively easy to run a check on, just see if any of the same moveables share the exact same center point.

[SneaksieDave]

The system I use for work exhibits such stutters (maybe that's not a good description) when running automated scripts frequently; it unfortunately completely destroys script operation. Keypresses will fire and then somehow a mousemove will get lost (that's the assumed stutter) and next thing you know, it's jumping around the desktop icons (first letter) due to a typing step in the script, and then focus is wrong and you're deleting the wrong things, and everything goes haywire. I don't honestly know if that could apply here, but I was just putting it out there so we had more reasons to look at than user error (which I'm doubting from those who have reported it).

[greebo]

The other two options we have now are

 

- offset the duplicated objects by one grid unit (can be made an option)

- hack in a special handling for some commands (like CloneSelected)

 

I'd rather vote for 1), because 2) is a hack.