Question about why duplicating NPC entries resets search filters/view

[Rades]

Hey all, a bit of an odd question and I'm not sure if this is the right subforum for it.

As I'm sure we're all aware, dragging and releasing an existing NPC entry within the NPC list (let's say one for a generic Dragonborn Fighter) creates a second, duplicate entry. However, when you do this, the NPC list clears any search filters and puts you back to the first page of the NPC list. Is there any way to stop this behavior? It's annoying when I want to create, for example, five different Dragonborn Fighters - for the different breath weapon entries - and each time I duplicate the NPC, I have to once again type "dragonborn fighter" into the search field, or flip a few pages to manually get to the Dragonborn Fighter NPCs.

Most of the NPCs I create for my campaign are modifications of official ones, and I don't want to mess up the originals, so I always duplicate them first. Which means I'm constantly having to re-filter or re-toggle through list.

It's not a HUGE deal or anything, it just seems strange that this happens? And I can't think of any logical reason for Fantasy Grounds to do this.

[Zacchaeus]

I don’t know the reason but that is the way it works.

[Bidmaron]

And the beauty of FG is that if it bothers you enough, you could fix it in an extension.
Look, it would not have to work that way but when the groups were added in place of the old categories, this was the easiest implementation. I doubt Moon Wizard would try to defend it. People were clamoring butt-loud for something better than the old categories that were colored graphic tabs. They got their wish. And now people (rightfully because they probably don’t know what we had before) bitch about what we have now.
So most of us old timers are very happy that SW gave us a much superior interface to what we had. But it isn’t perfect, as you rightly point out.
I am glad he got us something much better and more powerful instead of taking more time to perfect it (let alone the opportunity cost of what we wouldn’t have if he had taken the time to perfect it). This is what the UI bitchers here just will not accept. They are a small company and doing ANYTHING is always a decision of what not to do. By all means point out the issues, like this fine fellow has done but please don’t admonish this wonderful team with cries of how the UI is broken or that SW will go bankrupt the day after tomorrow unless they stop everything and instantly give us FGU with a Da Vinci quality UI.

[ProNobis]

The easy way to "fix" this is to open the npc then drag the shield on the opened npc into the box that lists all of them. Since the opened npc stays open, even though it "resets" to the first page you can keep dragging until you have done it 5 times then search for dragonborn then make the changes to all of them.

Personally, I would create a new category (drop down box at the top, edit list, new, new ones are always named "Group 1" so find it and change the name to what you like, close edit list view then click into it) by dragging the npc into that list it will only show that new group allowing you to not need to search for it. I try to use enough groups to keep things in relatively short groups to make finding stuff easy and fast.

[Rades]

Don't get me wrong, I fully agree that the groups we have now are MUCH superior to the colored tags from before (I definitely remember jumping through the hoops to make those subcategories work). Mostly I was just wondering if there was a reason this happens, like some sort of technical memory requirement behind the scenes, or if there was an option to disable it that I was unaware of. But if that's just the way the system works, so be it!

ProNobis, that's a great suggestion about keeping the NPC sheet open, or using a "workspace" category. I'll do those in the future. :)

[LordEntrails]

Add the idea to the wishlist, link in Mr. Z's signature.

[Trenloe]

Mostly I was just wondering if there was a reason this happens, like some sort of technical memory requirement behind the scenes, or if there was an option to disable it that I was unaware of. But if that's just the way the system works, so be it!
The filters are generated dynamically based off all of the entries in the campaign datalist being shown.

If a new record is added (even a copy) FG needs to re-initialize all of the filter fields so that they show the most current available filter options.

Now, I'm not sure if there is a specific reason why the free form name filter field needs to be reset as part of this. I would imagine it’s cleaner to do so within the bounds of how the windowlist control operates and processes data. But is is required? I’m not sure.

For background, info on the windowlist control is found in the API guide here: https://www.fantasygrounds.com/refdoc/windowlist.xcp

[Moon Wizard]

It has to do with making sure that new records are included in the index, especially empty records added using the Add button, or modules loaded during play. Let me review the use cases, and see if I can fine tune it.

Regards,
JPG

[Moon Wizard]

Coming in v3.3.7

https://www.fantasygrounds.com/forums/showthread.php?46523-Beta-Release-v3-3-7&p=414260&viewfull=1#post414260

[Bidmaron]

Awesome MW. Thanks

[ProNobis]

Wow, I've been using a clunky work around for the last year. Should have just asked. Thank you MW!

[Moon Wizard]

I vaguely remember wrestling with this several years ago as to how it should work when making the campaign list improvements. I remember that the filter reset wasn't optimal, but it made everything work without losing state.

Sometimes coming back to it is much easier to find a fix; either because other features have evolved to make it easier, or because the use cases are more clear, or because I'm thinking differently, or all of the above.

Cheers,
JPG

[Rades]

That's terrific, thanks MW! :D Really appreciate your efforts!

[Kelrugem]

I vaguely remember wrestling with this several years ago as to how it should work when making the campaign list improvements. I remember that the filter reset wasn't optimal, but it made everything work without losing state.

Sometimes coming back to it is much easier to find a fix; either because other features have evolved to make it easier, or because the use cases are more clear, or because I'm thinking differently, or all of the above.

Cheers,
JPG

This is also something I experienced in my work (and many other probably, too) :) I struggle a lot with some problem, I "give up" somehow and some time later (which can be much time later) I can solve it, sometimes without any much effort and I wonder why this worked so much faster now :D