Retain sidenumber and unit names on copies

[Bankler]

When copying a group using ctrl-c, everything seems to get carried over EXCEPT the sidenumber and the Unit Name. When pasting, these fields get other, generated values.

When copy-pasting large numbers of groups from one mission to another, this is very frustrating, since you will manually have to recreate all these settings (which can take hours if it's a large mission that you're converting from one theatre to another).

I realize the reason is to retain unique numbers. And for Unit names this (almost) makes sense. But only if that unit name is already taken (which is typically not the case if you copy the group into another mission).

In short, my suggestion is, when pasting a group:

• Retain the original sidenumber, unless it is already occupied by another unit in the mission you're pasting to.
• Retain the original Unit Name, unless it is already occupied by another unit in the mission you're pasting to.

 

Edited July 6, 2023 by Bankler

[Exorcet]

19 hours ago, Bankler said:

In short, my suggestion is, when pasting a group:

• Always retain the original sidenumber, no matter what.
• Retain the original Unit Name, unless it is already occupied by another unit in the mission you're pasting to.

 

I understand your request, but changing things and removing the old system is rarely the right direction to take. You're just breaking the system for someone else.

Add a checkbox in the ME to SELECT which option to use on paste. That way, no one is left inconvenienced.

[Bankler]

9 hours ago, Exorcet said:

I understand your request, but changing things and removing the old system is rarely the right direction to take. You're just breaking the system for someone else.

Add a checkbox in the ME to SELECT which option to use on paste. That way, no one is left inconvenienced.

In what way would it affect anyone negatively? A usecase would be helpful. The way I see it, what currently happens is a bug. If you copy something, that clone should be similar to the original. It's kind of the definition of a copy. 

[Exorcet]

37 minutes ago, Bankler said:

In what way would it affect anyone negatively? A usecase would be helpful. The way I see it, what currently happens is a bug. If you copy something, that clone should be similar to the original. It's kind of the definition of a copy. 

Whenever you change how something works, you risk disrupting someone's work flow. This isn't about specific cases, but general good practices when making changes or improvements.

[Bankler]

On 7/4/2023 at 1:28 AM, Exorcet said:

Whenever you change how something works, you risk disrupting someone's work flow. This isn't about specific cases, but general good practices when making changes or improvements.

While your first sentence certainly holds true, if you're holding on to that in dogmatic way, it would mean a developer wouldn't be free to fix bugs and flaws. While I agree leaving options in there for the end user to customize behavior (liked you touched upon) can be great in certain cases, imho it doesn't make much sense to do so if one cannot present a user story where one of the options is at least sometimes valuable. That only results in bloated software. And for those decisions, best practice, imho, is to look at each case, rather than blindly applying a paradigm.

[Exorcet]

7 hours ago, Bankler said:

While your first sentence certainly holds true, if you're holding on to that in dogmatic way, it would mean a developer wouldn't be free to fix bugs and flaws.

Well a bug is be definition not working properly. I don't think the number increments are a bug. As such they are an intended feature that some users may have acclimated to. In such a case, I think an option to choose the behavior makes more sense than just changing the behavior.

 

Quote

While I agree leaving options in there for the end user to customize behavior (liked you touched upon) can be great in certain cases, imho it doesn't make much sense to do so if one cannot present a user story where one of the options is at least sometimes valuable. That only results in bloated software. And for those decisions, best practice, imho, is to look at each case, rather than blindly applying a paradigm.

 

Well as a long time DCS user I've seen plenty of well intentioned changes cause problems. I don't see the addition of a simple option contributing much to bloat unless it's added in an extremely inefficient way.

 

If you really want a use case, then I suspect it the entire reason the number increment exists. If you copy and paste an aircraft, while it may be a copy digitally, it's probably not meant to be a literal copy in reality. Planes all have different numbers for a reason, that being to tell them apart. From that perspective, copy keeping the number doesn't make sense. Changing this creates the same problem that you want to avoid when copy and pasting into the same mission, a lot of manual work.

[Bankler]

21 hours ago, Exorcet said:

If you really want a use case, then I suspect it the entire reason the number increment exists. If you copy and paste an aircraft, while it may be a copy digitally, it's probably not meant to be a literal copy in reality. Planes all have different numbers for a reason, that being to tell them apart. From that perspective, copy keeping the number doesn't make sense. Changing this creates the same problem that you want to avoid when copy and pasting into the same mission, a lot of manual work.

Thanks! Fair enough. I can see that could be an issue if one wants exclusive sidenumber (and doesn't care much what those numbers are, which probably holds true for many users).

I guess my point is that it would make more sense if the current exclusive-number-operation is applied when pasting, not when copying. So if you try to paste a unit and another unit already has that sidenumber and/or unit name, THEN it changes to what ever is available. With the current design, it sort of assumes that there will be a conflict down the road (which isn't true if you paste it into another mission, or delete the original), and "fixes" (aka breaks) it prematuerly. That's the reason I call this a bug. I see the purpose of the behavior, but I think it's implemented in the wrong way.

For what it's worth, I don't personally mind the solution you're suggesting (having an option). Just not sure if ED would like the added complexity (but what do I know?), and would rather prefer a simpler (single) "catch all" solution. So that's why I argue the default behaviour should be the one I suggest (i.e apply exclusivity when pasting, not copying). That solution would cover your use case as well, as far as I can tell.
 

In my original post I wrote "Always retain the original sidenumber, no matter what." Changing that to "Retain the original sidenumber, unless it's already used by another unit" following your feedback.

Cheers!

Edited July 6, 2023 by Bankler