Feature Request: Forward & backward cycling preset type or incremental/decremental constant value modifier about 3dmigoto

[DarkStarSword]

I believe I proposed these when we were originally adding the input infrastructure, but at the time we decided it was complex enough already. Still seems worthwhile adding though, especially as we no longer need to worry about Flugan's wrapper maintaining compatibility with ours.

[DJ-RK]

Just wondering if this might gain traction anytime soon? About to revisit my Xcom 2 fix where I came up with this notion, so having this would be pretty sweet for it, but it's certainly not a deal breaker if it's too complicated to implement easily. Just thought I'd follow up while I was here since I just posted another feature request.

[bo3b]

I can likely take a look at this in a couple of weeks. I'm finishing up a contract, and will have more free time after that.

This is a smallish change that can probably be implemented.

[masterotaku]

Pasting part of my forums post with added/modified content:

Can we have synchronized cycles/toggles when using different keys to change variables or separation or convergence? Assigning two keys for the same "Key =" would be a good step forwards, although incomplete.

I'm asking because sometimes I make hotkeys for the same stuff in keyboard and controller, and it's jarring how values cycle in a separate way.

The function I ask would be like this: I press a key that would trigger a "cycle", then 3Dmigoto checks the current value to see what step should be the current one in the cycle. If it's different, then it gets corrected. If the current value doesn't exist, then it could either go to the nearest higher value, or not be corrected, I don't know.

Expanding the original feature request, it would be cool to have sticky increase and decrease values in a "hold" type hotkey, with customizable speed (cool for static depth crosshair, bloom values, etc). Also, using the analog range of the controller triggers to change a variable between two values would be great too.

[DarkStarSword]

Forwards & backwards cycles are now supported in 3DMigoto 1.3.7, as well as assigning multiple key bindings to the same section.

The function I ask would be like this: I press a key that would trigger a "cycle", then 3Dmigoto checks the current value to see what step should be the current one in the cycle. If it's different, then it gets corrected. If the current value doesn't exist, then it could either go to the nearest higher value, or not be corrected, I don't know.

We won't implement this - there's too many undefined edge cases that we have no way to know how to sensibly handle (which current value? x? y? z? w? x1? y1? separation? convergence? a combination of the above? which combination? what if it doesn't match any of them? what if it matches several of them? what if it partially matches all of them?).

However, you can write a custom shader implementing whatever logic you need to do this, and have it update values in a custom resource rather than an iniparam.

I'm still planning to add conditional logic and an expression parser into the command list, and once that is in you will have some flexibility to do this from the d3dx.ini as well.

Alternatively, this is where I also think having incremental/decremental values would be useful, instead of having to create potentially tens or hundreds of values in a cycle ( z = 0.1, 0.2, 0,3, 0,4... 100), it could just add a certain amount ( z += 0.1), and with some amount of testing it would hopefully be possible to create 1 to 1 scaling with such an ingame zoom. For this, though, it would also be ideal to be able to set a upper and lower limit for the values (or min/max, if you will).

This is a simpler case of masterotaku's request, and the same comments apply to this as well. This in particular I think would be particularly well suited to the expression parser whenever I get around to writing it (ideally allowing for something like "x = min(x + 0.1, 100)"), but I'm not sure when that will materialise. In the meantime this could be implemented using a custom shader.

Expanding the original feature request, it would be cool to have sticky increase and decrease values in a "hold" type hotkey, with customizable speed (cool for static depth crosshair, bloom values, etc).

We don't currently expose repeat functionality for key inputs, but we potentially could (some of 3DMigoto's internal key bindings use this, such as for hunting), but until we get an expression parser this would be of limited use I think. However, if the existing transitions are insufficient I would suggest you consider having the [Key] section just set an ini param while held, and have a custom shader run on [Present] implement any custom logic you need, especially now that you can pass timestamps into a shader to transition something at a fixed rate independent of framerate.

Also, using the analog range of the controller triggers to change a variable between two values would be great too.

This is probably something we should add to the command list ini param override code (the plan is that everything that supports will eventually be usable inside more complicated expressions).

[DarkStarSword]

3DMigoto 1.3.11 now includes the first implementation of expressions and conditional logic, which should provide more flexibility here. Note that the expressions cannot be directly used from Key/Preset sections as yet, but they can be used from a command list linked to those sections via run=CommandListFoo, like:

[KeyIncrementX]
key = e
run = CommandListIncrementX

[CommandListIncrementX]
x = x + 0.1
if x > 100
    x = 100
endif

[KeyDecrementX]
key = q
run = CommandListDecrementX

[CommandListDecrementX]
x = x - 0.1
if x < 0
    x = 0
endif

[KeyIncrementY]
key = y
run = CommandListIncrementY

[CommandListIncrementY]
y = (y + 1) % 50

In the future we may add some more features to make this easier (such as min/max* or a ternary operator), but I think this should be enough to cover everything raised in this issue, so I'm closing it.

* Does anyone else always get these wrong? In my head I think of this as "I want x to be a minimum of 1", but the way to say that in most programming languages is "x = max(1, x)", so I almost always choose the wrong one on my first attempt. This is to the point where I'd actually rather add some form of constraint operator instead, but I'm not entirely sure what that would look like.