[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.