Feature - Implemented Most Recently Used Script Menu

fronobulax

Developer
Staff member
Actually this isn't a feature request as much as a feedback request. If a motivated minion believes this is the wrong place or wishes to merge this with some similar requests, that is fine with me.

Many users find the drop down menu of Scripts to be too long. The workaround is to create a subdirectory and dump helper scripts and other things that are not called directly into it. The attached patch is a proposed alternative.

The patch does nothing visible to the user unless the mafia user preference scriptMRULength is set to a value greater than 0. If the value is positive then that is the number of entries that will be maintained. If enabled, using the Refresh button in the Scripts menu will (initially) replace the display generated by the directory contents, with the MRU list. Subsequent uses of the Refresh list will update the display with the current MRU list. When displayed the most recently used script is at the top and the "oldest" use at the bottom. Changes to the list are saved as a preference. Each script will only appear in the list once and the script will be trimmed so that there are no more than scriptMRULength entries. A script will appear if it was invoked from the Script menu or the gCLI but not if it was invoked by another script. Because various operating systems handle case sensitivity differently, the list is case sensitive. On Windows 7, for example, ascend and Ascend will both appear if they were both used to invoke Ascend.ash.

Patch attached. I am interested in feedback in several areas.

Is this useful or A Bad Idea (and why)?
Did I violate coding or formatting standards?
Is CallScriptCommand the best and only place to capture script filenames when they are invoked?
Because the Script menu is built before login the user is not defined and so there is some kludgyness to delay initialization until the user and associated preferences are defined. Is there an alternative that does not disrupt the code too much?
The first press of Refresh to invoke the feature seems equally kludgy but I did not see an obvious, non-disruptive alternative. Subsequent presses are acceptable because of the analogy to adding a new script file to the directory.

Thanks.

Edit: This isn't the post you are looking for. Go here also.
 

Attachments

Last edited:
Just to be certain: If I set the setting to 5 I will only see the last 5 used scripts? How will I then be able to find scripts I have not used recently and use them (unless I remember their names and can call them?)?
 
Because the Script menu is built before login the user is not defined and so there is some kludgyness to delay initialization until the user and associated preferences are defined. Is there an alternative that does not disrupt the code too much?

I ran into this lately, and I was lucky enough that I already had a listener attached to a user preference, so the panel in question gets repopulated when that user preference gets set on login. Of course, that caused a ConcurrentModificationException, so I had to modify the listener to optimistically handle the exception and just try again... (sorry, tangent there)

To get at what you're asking, I don't think kludginess is avoidable there. I've found there are a significant number of things that you can do while not logged in that will cause a NPE, an arrayOutOfBoundsException, or other unhandled exception, and I really don't care. This is all said without looking at your particular implementation, but I'll take a look at it soon. I support this feature.
 
Just to be certain: If I set the setting to 5 I will only see the last 5 used scripts? How will I then be able to find scripts I have not used recently and use them (unless I remember their names and can call them?)?

You use the Load option which is exactly what I have to do on my system, without the patch, for any script that is alphabetically after PA. From my own experience, I would set scriptMRULength to be the largest number of items that would display on my screen without missing anything.
 
Alternatively, you could set it as a global preference instead, right...?

I'd prefer not to since the only script that all of my characters run is EatDrink. I didn't want to my BRICKO summoning script to clutter the menu for the multi with no Tome, for example.
 
Was mostly thinking that would solve the issue regarding when to load it and what to display if someone does click on Scripts before logging in.

Does Java (and by extension, mafia) have any good way of knowing whether the OS running it is case sensitive? Doesn't make much sense to double up on script names because the people who wrote the import failed to properly capitalize, for example...
 
Was mostly thinking that would solve the issue regarding when to load it and what to display if someone does click on Scripts before logging in.

Does Java (and by extension, mafia) have any good way of knowing whether the OS running it is case sensitive? Doesn't make much sense to double up on script names because the people who wrote the import failed to properly capitalize, for example...

As it stands it is initialized - as it is now - with the contents of the scripts directory. A global preference would work although is not my choice. Moving it out of the main frame is probably too visible to the user and will probably smoke out the folks who run scripts without logging in (and I know there are some). There might be some kind of listener or lazy initialization for the menu but both of those might be more work than the feature is worth.

I suspect there could be some kind of normalization done on file names - Java has support for dealing with the case sensitivity or lack there of - but it seems like a lot of work for little gain. I discovered it because on my system the file is Ascend.ash, the Menu invokes Ascend.ash but typing "call ascend.ash" works in the gCLI. So the problem could also be solved by making the gCLI reject "ascend" but that doesn't seem like a step forward in user friendliness.

As far as I know, the MRU only picks up scripts that are invoked by call in the gCLI or invoked by the menu. I had not noticed that scripts that are invoked by other scripts get included. If that is right then the programmer's case doesn't matter. If I'm not mistaken there have been a few reports where something failed because the person who saved the script did not use the name the scriptwriter used when running on a sensitive OS. So it may have to be right anyway. Bottom line, though, is at this point making things case insensitive seems like work with little practical benefit.

Thanks, though. I asked for feedback.
 
Was mostly thinking if mafia actually validates the file name at any point, we might be able to use that instead of what the player typed to easily weed out duplicates. If the validation doesn't actually happen, no sense in complicating our lives... but if it's there anyways... heh.

Another alternative... on login, check for the preference and if it's there, automatically refresh the scripts list. That should be transparent to the end user, since the list will just be what they expect to see, and the global user/login screen shouldn't be affected because they don't have that preference set...
 
You use the Load option which is exactly what I have to do on my system, without the patch, for any script that is alphabetically after PA. From my own experience, I would set scriptMRULength to be the largest number of items that would display on my screen without missing anything.

Ahh yes, that menu option. I've almost only used that when I've put in a new script and didn't want to push the refresh option... I've put my scripts in folders by creator so despite the fact that I have quite a lot of scripts (and old renamed versions) it still is no problem to load them by finding them in the list.
 
Stand by. If my dream last night is correct then my code only works if if the user actually runs a Login script, Theraze's suggestion of doing initialization at login is worth investigating as well.
 
Try the attached. I realized with everything being static I did not need to create a new object. Things will properly initialize whether the user runs a Login script or not. The menu is refreshed when a user logs in and when something is added to it so there should be no need to manually refresh. Since this is an opt in feature, I will probably commit it tomorrow unless someone thinks that is A Bad Idea.
 

Attachments

This seems cool. I was thinking about cleaning up that dropdown, except I was going to do it by deleting scripts, and this way seems better.
 
r9626

Oh Mighty Minions - I presume the Wiki changes would be to document scriptMRULength and scriptMRUList somewhere in the preferences? Point me in the right direction and will try and do so myself or at least verify/edit someone elses work. Thanks.
 
We document properties HERE.

Perhaps we should also have a page for hidden opt-in features like this and chatBeep. Can anyone name any other secret mafia preferences?
 
rememberDesktopSize. Thanks. Any others?

Oh Mighty Minions - I presume the Wiki changes would be to document scriptMRULength and scriptMRUList somewhere in the preferences? Point me in the right direction and will try and do so myself or at least verify/edit someone elses work. Thanks.

I've started a new page for this sort of thing HERE. Please edit it!
 
There's the macroLens property for editing and submitting one-off macros directly from fight.php. When I discovered that, I was able to remove a chunk from my own fight.ash override.
 
Back
Top