I think the Counter actor really works as it should. It's all about how on thinks about the wrapping
For example, here's a graphic representation of a Counter with the 'min' input set to -3 and the max to +3, with the 'amount' amount set to 3.
As you can see, if you go up by three, and if you have both -3 and +3 as part of the cycle, then it works exactly as it should. Can you see why this makes sense?
It is true that the float counter works differently, so there is an inconsistency ,this I will admit. That's because the true upper limit is a fraction less than 'max'. For a Float Count with the 'min' input set to -3 and the max to +3, with the 'amount' amount set to 3, you get this pattern:
In fact, you never hit +3 because the actual limit is 2.99999999999.... (Try it and you'll see it's true.) Also not so intuitive.
Fred, if you want the Counter to work the way you want, you can set the 'max' value to the desired max value plus the amount value minus 1. So, for your case, if you set the 'min' input to -45, and the 'max' input to (45 + (5-1)) 49, you'll see that it goes 30, 35, 40, 45, -45, -40, -35, etc.
Now, I am open to changing this – we could have an "inclusive" input which would either include or exclude the maximum value. (The Counter is currently "inclusive" while the Float Counter is currently "exclusive.")
Do you have a different suggestion about how it should work to make it more logical? In the end, you probably want the behavior of the Float Counter in the normal, integer Counter. But then to get the results you desire, you'd have to set a range of -45 to 50. This also is not very intuitive.