Official: Upcoming changes to IntSlider

TL;DR: In order to fix Groups we had to significantly change the behavior of the IntSlider control. The new control will be available in the next beta.


The Old IntSlider

The previous behavior of IntSlider and its remappers, which has been there since FF1.0, was to automatically restrict its range to prevent out-of-range situations.

For example, if you plugged an IntSlider with the range of 1...20 into an Integer input with the range of 1...10, the IntSlider would truncate its maximum range to 10. If you subsequently plugged the same IntSlider into an additional input with the range of 1...7, the IntSlider would truncate itself to 7, so that none of the target inputs would receive values greater than their maximum range allows. IntSlider’s remappers also limited their Step and Offset settings automatically, for the same reason.

This scheme was a bit confusing for some users, but it had an important quality to it, which I dubbed as “you connect it and it works” (actually, this was one of the foundational principles of Filter Forge). That is, you could plug any IntSlider into any input, and this will result in a reasonable control behavior.


The Problem with the Old IntSlider

Keeping the old scheme was problematic because with the introduction of nested Groups, we essentially allowed users to create long chains of inputs and remappers between the IntSlider control and the target input(s). If the range of an Integer input of an innermost Group got reduced, and there was a chain of remapped IntSliders connected to it (via multiple nested groups), we had to somehow make sure that all this chain does not produce values that exceed the new reduced range. To do that, we’d have invent some cascading way of automatically adjusting the ranges of IntSlider group inputs all the way up. Due to non-locality of the changes and non-obviousness of choice (which IntSlider or remappers do we truncate, if there are many?), this would require a lot of rewriting, testing and debugging.

So, in order to fix Groups, we decided to abandon automatic range adjustment for IntSlider and its remappers, and replace it with a simplier scheme.


The New Implementation

The new implementation does not automatically limit the range of IntSlider or any settings of its remappers automatically. Instead, it allows you to adjust Max Value and remapping settings freely and alerts you with a connection warning when the resulting range exceeds the maximum range of a target input.

For example, you have an IntSlider with the range of 1...10, which you want to connect to two inputs: the first one with the range of 1...15, and the second one with the range of 1...7.

When you plug the IntSlider into the first input, everything is perfectly fine. But when you connect it to the second input, a red connection warning appears near it, telling you that the range of your IntSlider exceeds the range of the input:

“The incoming value range (1...10) exceeds the maximum range of this input (1...7). To fix this, lower the Max Value of the IntSlider connected to this input, and if it uses remapping, check the remapper settings as well.”

To fix that, you simply reduce the Max Value of the IntSlider to 7, and the warning goes away.


Is it Better or Worse?

Having spent some time with the new scheme, I think it may be good in its own right, as opposed to being a necessary evil we needed to fix the Groups.

The new approach feels simple and straightforward. It doesn’t attempt to do the thinking for you. You are free to tweak the settings anywhere you want, but you are responsible for out-of-range errors, and you get notified when they happen. It’s fully local: while the old scheme could ninja-change settings in various places when you least expected it, the new scheme never changes anything other than what you’re currently adjusting.


Is Any Functionality Lost? (Or Added?)

Everything the old IntSlider was capable of doing in terms of filter creation remains intact -- we just changed the user interface logic.

As for the new functionality, we decided to add a new parameter to the IntSlider-to-IntSlider remapper that allows you to flip the range of IntSlider values.


Some Technical Notes

The change is not versioned, so there will be no previous version of IntSlider in the Obsolete category. If you open filters made in older versions of Filter Forge in Filter Forge 4.0, any IntSliders in them will behave according to the new scheme.

The connection warnings generated by new IntSliders count towards filter problems that must be removed before submitting a filter to the Library. The Submit Wizard will include these warnings in its notifications.

Good to hear! Int-slider always bugged me a little. Seems like the problems are gone, but I'll have to play with it

Quote
Btw... Will you be adding a non-procedural control script component ("gray" script) so we can work out more advanced logic for controls?

A numeric script makes perfect sense, but it cannot be introduced unless first-class Numeric components are implemented first. BTW, I have a feeling that this new way of dealing with out-of-range situations may make the development of numeric components much easier. We'll see about that when we get there.

Andrew, versioning was technically difficult. We'd have to keep the both mechanics in the code, which would have made it much more messy and buggy than it already was. Sure it's possible but it would take months (and a lot of brain cells).

As for missed scenarios, there shouldn't be any, or at least we thought so. There's this problem with range warning appearing on the old IntSliders, and I remember discussing and designing a workaround for that. We'll look into it when the main feature for the beta is productized and ready for release.