[Eldorado.Railroad]

?

[longiron]

OR doesn't support Variable3 in SMS file because the physics trigger for activating the sound wasn't completed. It's just about done and ready to be committed to the latest development build.

I don't know how to respond to a vague claim with no support, no information, no data or specifics to go on. Please give the OR team something specific and we'll try to address.

"I have tested OR on two separate machines and the same MSTS Bin Sound in OR does not seem equal to the task. What was expressed elsewhere was that OpenAl could handle the sound tasks with ease, that does not seem to be the case ... So are there some snags/issues that are not being discussed openly?"

[Genma Saotome]

Eldorado.Railroad, on 15 October 2011 - 08:19 AM, said:

Could you please release to the public what features of sound are implemented in the next release of OR?

Nope. What gets done for a release is what gets done, something that may or may not have any relationship to what we hoped could be done.

Quote

I think that it helps your users/bona fide testers at large to know what is going to work and what is currently going to be a test that is a waste of both of our times because it has yet to be implemented.

Quite understandable but it does not justify making promises that may or may not be kept.

Quote

What I can't figure out is why it took a second post in this forum to get this concern (Does OR(v0.6.2) not support Variable3 in the SMS file?) addressed? How can we avoid this next time?

WE can avoid this by YOU not expecting an answer for every question you ask.

This is the 2nd time I have had to intervene in this forum, as admin, to tell you to to settle down and let those OR people spend their time doing their work. When you post stuff like the above it certainly gives the impression you expect the OR team to drop what they're doing to jump over to your feet with "Yes Eldorado?". You want to be helpful? Great! Share insights, findings, problems. You're good at finding stuff and that's a skill that can be appreciated. Don't expect a dialog each time.

[Genma Saotome]

Eldorado.Railroad, on 15 October 2011 - 02:08 PM, said:

Dave,

I acknowledge that you do not wish to publish what should work (in this case sound) in any release. Are you asking that there should be no comments/queries on sound problems in OR because it will be difficult for the user to determine what should work? How does this allow for the resolution of problems for things that are apparently implemented/fixed?

Questions and comments are always welcome, including observations and insights on what doesn't work.

What I am saying that here is you, or anyone else for that matter, should not expect an answer every time. No one here at Elvastower is under any obligation to post more than they feel like doing. As for Open Rails, if is was a commercial venture and you paid money to use it, then yeah, it would be reasonable to expect somebody might have the responsibility to respond to public queries -- not least because you'd expect someone was being paid to do so. But OR isn't commercial (nor do I expect it ever will be). It's staffed by ordinary guys who find a few hours here and there in their otherwise busy lives to volunteer to OR.

Think about it: Would we all rather have them spend those few gift hours answering each and every question posted on each and every board... or spending that time working on the project? Not to mention maybe refreshing their enjoyment of the hobby by reading and posting on non-OR stuff, or gosh, even using the simulator itself for fun?

Keep posting stuff. Others will learn from it. Maybe the OR team will observe something they were not already aware of and some sort of dialog will ensue. But like any other post on anywhere this board, understand and accept that not each request for information will get a reply.

[Shay 5]

I can't imagine being able to stuff in time for OR in an already tight schedule. That there alone says something about these guys. I think we have underestimated the OR team. They deserve our support, not our persistent bugging.