There have been a number of logs come through from users who have set crazy values into the heap sizes for a specific module (e.g. Minheap size = 0, maxheap size = 1Mb). The Player/Editor startup then crashes and it is impossible to fix the problem with editing or deleting the preferences file.
Can you look at enforcing a reasonable minimum heap size as part of the Maximum heap stuff? I think an absolute minimum heap size of 128Mb should not cause any problems.
I already have that in the work I did for Bug 2680395, but I ran out of time
last night, so it isn’t merged yet.
What I’d like to do for 3.2 is have the MM bring up the Preferences for
the module you’ve failed to load, rather than load the module with failsafe
values. That way, you don’t need to load the module twice.
There are “failsafe” initial and maximum heaps, 64MB and 128MB respectively.
These aren’t intended to be such that you use modules with the failsafes,
they’re just so you can get the module loaded and get to the Prefs so you
can make heap size changes.
In the event that either your initial or maximum heap is bogus, your module
will be loaded with the failsafes, and you’ll get a dialog telling you that.
(Note: This involved changing some translation keys, so the non-English
translations are now missing proper messages for these dialogs.)
The failsafe dialog tells you to fix the heap size in your preferences, but it is created by the MM, and when you click on the Ok button, it brings the MM forward. You then open your MM preferences as instructed and the only obvious heap sizes are in the Importer, which look fine. What’s going on?
Either the dialog has to tell you to change the preferences in the module, not the MM, or, preferably, pass a flag to the Editor/Player and have them raise the dialog rather than the MM so that clicking OK on the dialog brings forward the component that the dialog is talking about.
All of the WarningDialog and ErrorDialog show*() methods dump a Runnable
that will display the requested dialog into a queue, to ensure that you
only ever see one such dialog at a time. The ExecutorService which works
on that queue returns a Future<?> which I’d always been throwing away—
most of the time when we display a warning or error message, we don’t care
about waiting for the dialog to be closed, so this is fine.
Here’s the relevance of this for the curent problem: The toFront() method
is treated by Java not as a command, but just a way of registering your
preference about window order. There’s no guarantee that it will do
anything, so we cna’t rely on it for bringing these heap warning dialogs to
the front. However, we don’t need to bring them to the front manually if
they’re shown and closed before the child process is started, since these
dialogs are modal and so are guaranteed to be in front of their parent, the
Module Manager. Therefore, all we need to do is get the Futures I was
throwing away and wait on them to finish.
So, the modification I made was to have all of the dialog methods return
their Futures instead of being void. This way, if you don’t care about
waiting for dismissal of the dialog, the code is the same, and if you do
care, then you do something with the Future which is returned.
For convenience, there’s now a FutureUtils.wait() method for use when you
want to wait on completion of a Future, but don’t care about the return
value.
Brent, I realized just now that what I did here doesn’t address all of
the problems you pointed out. In particular, I’m trying to make the same
messages cover both the module loading and importing cases, and as a result
it’s difficult to word the messages to be both accurate and sufficiently
specific about where to look to change the prefs.
I’m thinking of making a heap-adjustment dialog, which provides validation
for heap sizes and some advice for how to set your heap—when there’s
a heap size problem, we could show that, rather than have the user guess
where too look for making changes. That way, we wouldn’t even need to load
the module successfully in order to change bogus heap settings.
Does that sound ok?
Should we release 3.1.3 as-is, or wait for this? I think the changes
we’ve made w/r/t heap sizing are an improvement over 3.1.2, even if we
can still do better.
As discussed on the forum, I have converted the old ctrl-shift selection filter (which has not worked on any v3+ version) to alt-shift selection filter.
Apart from the fact the this was not actually what we discussed (Doh), Aradiel has pointed out that Does Not Stack units generally do not follow the standard selection/deselection rules and are not selectable by lasso. I am looking into the whole issue.
Wasn’t the lasso decoupled from DNS units specifically because the lasso
would select the the DNS units even when their options were set to “select
never”, or that was a different issue with just “select never” we found?
So from the last part “Dbl click on DNS causes selection status to toggle”
Does this mean that units with DNS can no longer be defined with Select
piece = “never” ?
I know of a few mods where this is an important feature - changing to a user
toggle would not break them but I could clearly envision accidental
misclicks causing undesired effects
If it is one of the cause / problems for DNS, maybe some sort of unique
trait that overrides all might be added for piece selection defined as being
allowed/disallowed. A secondary benefit of this would be that this unique
selection status trait doesn’t necessarily have to reside on pieces that do
stack
No, that was a statement of the bug that is now fixed.
Currently, If you select ‘DNS-Shift select only’ and then double click on it while holding the shift key down, the piece becomes unselected, obviously incorrectly. I fixed just this, plus adding the alt-click functionality. No change at all to Never select pieces.