Create account / Log in

I propose that we fix the "Center on Moves" pref problem.

Discussion area for the development team.

Moderators: uckelman, Tim M

I propose that we fix the "Center on Moves" pref problem.

Postby Cattlesquat » August 2nd, 2020, 4:51 pm

Presently the "Center on Moves" preference can be overridden by the module designer. And in fact *defaults* to "ALWAYS" meaning that modules by default always center on opponents moves and don't allow players to turn that behavior off.

This creates known and frequent issues with 3+ player online games where everyone is supposed to be doing their moves at the same time. And of course the module designer often has to be contacted because they don't know about the Global Option and how to turn it off, and/or individual players have to be taught how to "hack" their module with the Editor to enable the preference, etc. Let's just say it shows up a lot in the forums as an issue, and it's a "known and hated" feature among the 3+ player game online crowd.

And yet I can't think of a single use case where it's actually important for the Module Designer to be able to force one or the other preference onto the players. I could see maybe letting the module designer set the "better default" for the module so that the player's preference for the module in question would initially go one way or the other. But that would just be a little cherry on top.

Completely sufficient would be:
(1) Disable the Global Options entry for Center-on-Moves
(2) Always display the Center-on-Moves preference in the preference window
(3) Always honor the player's Center-on-Moves preference

The eeeeasiest fix would be just to intentionally break the GlobalOptions entry (leave it there, but ignore it and always display & honor the preference). About a 2-line fix.

A cleaner fix is some version of actually removing the option (or at least display of it) from the Global Options. With perhaps some slight tricksy stuff to keep any version of the old preference using the same preference as any that actually got set, and leave some dead entry in the class so that we don't break any old modules, etc. I don't think it will be rocket science, and I'd be happy to put together a PR if there's buy-in.

Brian
User avatar
Cattlesquat
 
Posts: 953
Joined: December 2nd, 2019, 4:57 pm
Location: Baltimore, Maryland, USA

Re: I propose that we fix the "Center on Moves" pref problem

Postby uckelman » August 2nd, 2020, 10:12 pm

Recentering should obviously be a user preference, not one that can be overriden (or even set) by the module. It's a nuisance and confusing the way it is now.
User avatar
uckelman
Site Admin
 
Posts: 9014
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: I propose that we fix the "Center on Moves" pref problem

Postby Brent Easton » August 2nd, 2020, 10:57 pm

Brian,
While you are looking into this aspect of preferences, have a think about this one as well:

http://www.vassalengine.org/tracker/sho ... i?id=13099

This is about the Module Designer being able to specify default values for some module level preferences. It sounds like a good idea, but I struggle to envisage exactly sure how this would be defined or applied, or when.
User avatar
Brent Easton
 
Posts: 3229
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Re: I propose that we fix the "Center on Moves" pref problem

Postby Cattlesquat » August 14th, 2020, 10:31 pm

Brent I do agree. The recentering is already in 3.3.3 beta, but we should do the other stuff.

Especially the heap size stuff - module designers will have a pretty good idea that their module needs more heap so we can probably help them save their players a lot of time/pain.

I think you're right with all the compatibility tab too (or any compatibility-LIKE ones on other tabs from earlier times, although maybe you're moving those onto compatibility tab).

The only other question is the three-ish remaining "Global Options" things, where module designer can *force* one or the other, or allow the preference, but can't set the default value of the preference. That would involve a refactor of the whole "PROMPT" side of things in that class. It's the most amount of effort for the smallest end user value.

Brian
User avatar
Cattlesquat
 
Posts: 953
Joined: December 2nd, 2019, 4:57 pm
Location: Baltimore, Maryland, USA


Return to Developers

Who is online

Users browsing this forum: No registered users and 1 guest

cron