[Csantucci]

Jared,
the swing rate is determined by the animation parameters within the .s file. Geoff selected 16+1 frames corresponding to a 2 seconds full swing rate; if a different frame number is used a different swing rate will result. No need for further parameters in other files. Of course the sound file shall be tuned to the swing rate.

[Csantucci]

Trello box to vote: https://trello.com/c...-bell-animation .

Feature now available in OR NewYear MG rel. 22.

[mrmosky]

It probably is not necessary to be able to vary the rate of Bell swinging. Locomotive bells are of a similar size and should swing at a similar rate, if you consider them as a pendulum.

This is borne out by the video below, which seems to show that all bells are swinging at the same rate of about 2 hz.


https://www.youtube....h?v=SoKs2-YJnDY

Anyway, the animation speed can be varied by changing a number in the .s file, but that might affect other animations. It is the number 30 that controls the speed of animation. The higher the number, the faster the animation.

animations ( 1
animation ( 16 30
anim_nodes ( 17
anim_node MAIN (
controllers ( 0


Geoff

[ErickC]

mrmosky, on 21 May 2019 - 01:06 AM, said:

It probably is not necessary to be able to vary the rate of Bell swinging. Locomotive bells are of a similar size and should swing at a similar rate, if you consider them as a pendulum.

Anything between the air valve and the clacker itself can affect the time between strokes, so the rate at which a bell rings will vary greatly - and it's often uneven. What you're saying only really applies to steam locomotives, where the entire bell moved.

Anyway - using animation length to control the bell animation cycle will cause problems with any other animation (doors, for example), because all animations will necessarily be slaved to the longest animation in the model. For example, I might want a door to open and close in one second. I might want the wipers to cycle every two seconds. So I animate accordingly. But now the doors will open and close in two seconds, for a total cycle length of four seconds. The door might only move for a second, sure, but there will be a delay while the animation completes itself. This is problematic if you want to synchronize audio to visuals. You could change the door animation length, sure, but nobody takes two seconds to open a locomotive door. The rate at which animations loop absolutely needs to be controlled separately (this is the root of the 3D cab door/wiper bug, which is why I don't bother to animate the doors and wipers in the 3D cab). I mean, could you imagine what the sim would be like if wheel rotation speed was controlled solely by animation length? Why should the door animation length be slaved to the bell, or the mirrors, et cetera?

I can see how it might be a bit much for now, but some sort of rudimentary scripting will really be necessary at some point. I suggest using a format similar to the SMS file, where animations outside of the basic wheel/bogie/et c. animations can be triggered by discrete events, and be looped or not, with the rate controlled by dedicated parameters, that way doors can animate at one speed, bells at another, wipers at another, and so on. Ideally, the configuration file would specify the name of the part to be animated, so that the developer can just name the parts whatever they want, and the code does all of the work, much like the SMS code does with sound samples.

[jared2982]

I must second the above post. I really think the bell animation speed should be tied to an entry in the eng file or something for bell animation speed in fps. Some are slower, some faster. There isn’t a one size fits all.

[mrmosky]

ErickC, on 21 May 2019 - 03:35 PM, said:

Anything between the air valve and the clacker itself can affect the time between strokes, so the rate at which a bell rings will vary greatly - and it's often uneven. What you're saying only really applies to steam locomotives, where the entire bell moved.

This animation that Carlo has added only applies to locomotives where the entire bell moves, doesn't it?

For any other bell, like the ones where the clacker only moves, I would doubt that an animation is needed, since the clacker movement will be too small to matter.

These type of bells will be able to have any chosen ring rate required, since that will be controlled by the sound file and not an animation. Or am I wrong?

Geoff

[jared2982]

Nothing prevents the animation of the clapper in other bells if the clacker is appropriately named. Som engines, especially those with bells mounted on the front of the firebox, this animation would be noticeable.

[wacampbell]

These sorts of animations add a lot of realism to our models. One day we will want brake linkages to animate, and reverser linkages on steam locos and there are an endless number of possibilities.

Rather than create an endless number of these reserved names with special canned animation behavior, I had in mind originally to use a loadable .DLL for a locomotive or wagon to override the default MSTS behavior. A .wag or .eng file could specify to load a .dll which would contain custom functionality. In fact I envisioned such a .dll to override even the default physics behavior, keyboard bindings etc. Its very hard to make a general purpose physics model that can be configured for every type of locomotive made. Eventually the advanced builder will want to customize the code to better suit his prototype. Its the same for animated parts, cab control bindings to locomotive behaviors etc.

The .dll would be a simple c# ( or other .net language ) script, JIT compiled by the OR loader thread. It overrides the MSTSWagon or MSTSEngine class providing new functionality. I am not sure of remnants of this are still present in the source code. I know at one time I had a sample locomotive with a custom engine .dll that animated the bell. But I think its a good direction to go.


Wayne

[ErickC]

The only problem I can see with that is the fact that not a lot of us content developers are particularly fluent in c#, so most of us would need to have other people build the modules for us. That's why I suggested maybe basing some kind of rudimentary scripting off the SMS code, because most of us understand that. The code would specify the name, the triggers, whether it plays one shot or loops, and so on.

[Csantucci]

Every solution has advantages and disadvantages, and it's difficult to determine what's best.
C# scripts are of course the most powerful solution. C# scripts may already be used in OR for train control systems and brake control, however as far as I know only gpz in Hungary and Serana in France have developed scripts for their national trains. ErickC's concern about few content developers having the needed programming knowledge is therefore a justified one. This does not mean that a support for further scripting has not to be made available; however only few people will make use of it.
I think also that for some general functionality it makes sense to have a built-in solution, and the bell is one of them. Another could be ventilation, but implementing it requires also intervention in the loco physics if one does not want to do only eye (and ear) candy.
Generating intermediate solutions like a simple language is also a solution, but it requires significant programming effort and could probably not become general enough.
Re Jared's request to make available the possibility of setting the bell oscillation frequency in the .eng file, I see its rationale, but from an architectural point of view I don't like that parameter in the .eng file; therefore I'd prefer to read a word of James about this. Implementing it would be simple, because the parameter already exists in the code, where it is hardcoded; when the parameter in the .eng file would be absent, a default value would apply. Adding the management of .eng parameter can also be developed in a second phase.

[scottb613]

Hi Folks,

Well - putting this to good use - rigged up one of my models last night - won't be able to test until the weekend...

Thanks Carlo...

Regards,
Scott

[Csantucci]

One way to at least partially meet Jared's concern could be to modify the code so as to play 32 instead of 8 animation steps per second. This would allow for a finer graduation of oscillations per second, and would allow also for faster oscillations if desired. Comments?

[mrmosky]

If a swinging period of 2 seconds is wanted (which is typical for steam engine with a swinging bell), then the bell would need to have 64 animation steps. This is not practical, I think.

Geoff

[scottb613]

Hi Folks,

Would that mean I'd have to create 32 or 64 key frames per animation in my modeling software - hmm - yeah - I'm at 16 now - I wouldn't be too keen on increasing that - especially for something as simple as a bell swing... I haven't been able to test this feature yet - so my feedback is of limited worth...

Regards,
Scott

[Csantucci]

You don't need to create 64 animation steps. Geoff, I took your .s file, multiplied by 4 the first parameter of the various linear_key and tcb_key lines, and the bell worked as before.