Dev build/Linux: (minor) buying premade spells one at a time

Report specific bugs in Daggerfall Unity. Please read guidelines before posting.
BansheeXYZ
Posts: 124
Joined: Fri Oct 23, 2015 8:19 pm

Re: Dev build/Linux: (minor) buying premade spells one at a time

Post by BansheeXYZ » Sun Dec 02, 2018 12:14 pm

Your PR still insinuates that the close behavior was different by design. It almost certainly wasn't, and DFU should not be matching bugs or oversights. The window should stay open on both button use and double clicking.

User avatar
pango
Posts: 436
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

Re: Dev build/Linux: (minor) buying premade spells one at a time

Post by pango » Sun Dec 02, 2018 12:20 pm

Bug or feature? Up to reviewers to decide.

To be perfectly clear, I think that either modification will be an improvement.
I have no strong opinion on the double-click behavior that I didn't know existed until today; It feels a bit strangely ad-hoc to me, but I can understand that not matching what some people have taken for granted for 20+ years can be a hard sell...
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart

User avatar
Midknightprince
Posts: 836
Joined: Fri Aug 11, 2017 6:51 am
Location: San Antonio TX
Contact:

Re: Dev build/Linux: (minor) buying premade spells one at a time

Post by Midknightprince » Mon Dec 03, 2018 3:41 am

You guys are awesome.
Just sayin :D
Check out my YouTube Channel!

BansheeXYZ
Posts: 124
Joined: Fri Oct 23, 2015 8:19 pm

Re: Dev build/Linux: (minor) buying premade spells one at a time

Post by BansheeXYZ » Mon Dec 03, 2018 10:36 pm

pango wrote:
Sun Dec 02, 2018 12:20 pm
Bug or feature? Up to reviewers to decide.
Anyone claiming it is a feature would need to explain how it qualifies as one. The behavior contradicts the button, other buy menus, and hundreds of other RPGs. I can't think of a single RPG that assumes you're done transacting the moment you purchase 1 thing. This and the duplicate spells thing are bugs. Whereas the lack of alphabetization is just poor design.

User avatar
Interkarma
Posts: 3622
Joined: Sun Mar 22, 2015 1:51 am

Re: Dev build/Linux: (minor) buying premade spells one at a time

Post by Interkarma » Mon Dec 03, 2018 11:55 pm

I'm happy for purchasing behaviour to be identical between double-click and buy button. I will also alphabetise list in future releases.

I'll look into filtering out already purchased spells in future as well. Please note this will involve adding new data to saves and will not retroactively apply to spells already purchased. This is not a priority right now however. :)

User avatar
pango
Posts: 436
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

Re: Dev build/Linux: (minor) buying premade spells one at a time

Post by pango » Fri Dec 07, 2018 9:12 am

Interkarma wrote:
Mon Dec 03, 2018 11:55 pm
I'm happy for purchasing behaviour to be identical between double-click and buy button.
Mmmh but by merging the last version of my PR what is now in master is:
- Buy button => stay in spell merchant window
- Double click => close window
I'm a bit confused...

If that was not intended you can still revert commit 8c74465
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart

User avatar
Interkarma
Posts: 3622
Joined: Sun Mar 22, 2015 1:51 am

Re: Dev build/Linux: (minor) buying premade spells one at a time

Post by Interkarma » Fri Dec 07, 2018 9:51 am

I'm just letting you know I'm happy with that if you choose to do it. Otherwise, I have no problems with the PR as-is, which is why I merged it. Code is a lovely plastic thing and it can always be changed later.

It's not like we're saving lives or anything here, I'm honestly fine either way. :)

User avatar
pango
Posts: 436
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

Re: Dev build/Linux: (minor) buying premade spells one at a time

Post by pango » Fri Dec 07, 2018 1:04 pm

As I said earlier I have no strong feeling about double-click behavior given I didn't know it existed until recently.
I feel having the same behavior for buy button and double-click to be cleaner (code is simpler too), but I expected people to absolutely want classic behavior. You for one do not seem to care that much, BansheeXYZ has been vocal about fixing double-click discrepancy, and I haven't heard from others.

So, unless there's a huge outcry, personally I'd go for same behavior for double-click and buy button.
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart

User avatar
Hazelnut
Posts: 939
Joined: Sat Aug 26, 2017 2:46 pm
Contact:

Re: Dev build/Linux: (minor) buying premade spells one at a time

Post by Hazelnut » Fri Dec 07, 2018 3:38 pm

I prefer to match classic here, and I don't agree with the statement "Your PR still insinuates that the close behaviour was different by design. It almost certainly wasn't, and DFU should not be matching bugs or oversights." as BansheeXYZ does. It's slightly unconventional but I can believe that it could have been done by design, especially given other aspects of classic DF. The reason I prefer to match classic is that I don't think it's obvious enough which way it should behave, so keeping both options is reasonable, albeit inconsistent UI behaviour. Basically I see this as UI design / preferences issue, rather than an obvious OoL improvement - like removing the need to explicitly dismount before you can enter a building for example which removes redundant clicks.

That's my 2p FWIW.

mikeprichard
Posts: 197
Joined: Sun Feb 19, 2017 6:49 pm

Re: Dev build/Linux: (minor) buying premade spells one at a time

Post by mikeprichard » Fri Dec 07, 2018 11:23 pm

Although it's not clear whether this is strictly "bugged" behavior, it is clear (at least to me) that consistency, not to mention user-friendliness, across similar in-game UI functions whenever possible should be the goal. My vote would therefore be to make double-click and the buy button function identically in the spells purchase window (i.e. double-clicking to buy a spell won't close the window). Unless I'm missing something, I don't see any compelling reason not to make that change.

Post Reply