Animation formula brainpicking...

OK, so I need to bounce some ideas off someone and see if anyone else can come up with a solution to this

What I'm attempting to do with this is to introduce a slight delay into the execution of RotateZFunction, along with some other conditions. I've ended up with this, at the moment:

Code:

RotateZFunction = if[trackDistance>150|section < 4,0,min[floor[value+delta],1]] * 0.355398163

So, this *should* do this:

Code:

if[trackDistance>150|section < 4,0

If the distance to the signal is greater than 150m or we're showing a red aspect, then return 0- This works correctly.

Code:

,min[floor[value+delta],1]]

Otherwise, return the smaller of value + delta rounded down to the nearest integer & one.

Code:

* 0.355398163

Finally, rotate the Z-axis.

Now this has a fundamental flaw unfortunately, and one which I'm struggling to solve- The time taken for the function to execute (delta) is never more than a second, and so it's perpetually rounded down to 0.
This also precludes going any further down Michelle's delay formula, as RotateFunction doesn't round it's results as StateFunction does.

Anyone have any bright ideas?

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Any mileage in this?

RefreshRate = Seconds

This defines the minimum amount of time that needs to pass before the functions are updated. A value of 0 forces the functions to be updated every frame. Please note that objects outside of the visual range might be updated less frequently regardless of this parameter. Use RefreshRate when you don't need a perfectly smooth animation (in order to optimize performance), or when you deliberately want the object to be only updated in fixed intervals.

Almost, but not quite- Further than I got mind
That lets the animation delay work, but the speed is wrong compared to the rest and it's decidedly jerky.

What I'm trying to do is to get a dual-arm semaphore starter to work nicely with the home arm activating a little before the distant to simulate the interlock release.
Trouble is I've got no way to carry over a value other than the result of the previous itineration of the function. StateFunction performs rounding on the result, but I have to explicitly round a RotateFunction down, and creates a logic loop, as I can't access the elapsed time without delta which never goes above a second.

I get the nasty suspicion that there's no way round this one; I certainly can't see one purely mathematically.
(I've thought of using the time paramater, but that'd only work reliably at the start of a route where we know the time, and would break as soon as you arrived late at a station)

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Hmm, not knowing about routes....

Could you use the pre-train to do it:

Does a signal have to be placed where it applies, or could the distant actually be a signal the pre-train is passing at some point ahead, but the displayed object is located where you are?  Mind you, you'd have to animate the distant arm in reverse, so it cleared as the pre-train set the signal to danger as it passed.

You'd get some odd behaviour off distant arms from that, but mostly when you're not around to see it?

Well, you are using the FLOOR[n] function, which ALWAYS rounds the value to the closest LOWER integer (ie. 0.9 will be rounded to 0).

1) You could either go for ROUND[n] function, where 0.01 - 0.49 = 0, and 0.5 - 0.99 = 1
2) You could use the same, but go for

Code:

min[floor[1/[value+delta]],1]

Edit: My fault....
Round works, but unreliably; Sometimes the signal will trip, but more often than not it doesn't. Might work better on a slow computer, but not reliable enough at this end.

Your second option has the same flaw I've got, in that delta never gets above a second. (Incidentally, I wish OpenBVE would actually let me see what the formula is returning...)

The pretrain command has the same issue as the time command- As soon as you're late, things stuff up.

I have the nasty suspicion this one isn't going to work

Cheers

Chris Lees

http://www.bvecornwall.co.uk