[R H Steele]

Kazareh, on 22 April 2015 - 08:05 AM, said:

Not to mention how the ORTS Team has the software on lockdown, where as folks if they want can code their own stuff; but it can only be submitted if the team 'approves' of it. Kind of loses the whole point of Open Source if you ask me.
But why should there be no need for a slider or option to increase/decrease that, hm? Tell me why. Is it because there is truly no use for one, or because you all are simply not -wanting- to do one? Volunteer projects work like that, you may volunteer your time, but for software projects? You listen to what people want, not what -you- want.

I have to interject here...
First lockdown.... it was stated in posts a while back that while running up to V1.0 the lockdown you mention would pertain to adding new features, the team needed time to clean up code, finish debugging features already in place and generally make the platform ready for V1.0. There is no lockdown as you are implying. Features are still being discussed and people are working on them, they are just not being added to the main official version, until after the team clears V1.0. Make no mistake...not every one will be happy with V1.0 .... but that just is the nature of people.

The OR development team has always been responsive to the community...there have been reasoned debates in public about different aspects...and I suspect more spirited debates on the private developers forum, but all considered the project is a remarkable testament to open source software development. This in a community known for its opinions, and willingness to wrangle about details and rivets.

I think you are off base here....taking a look at this all volunteer project to make a platform compatible with MSTS...the results are indeed excellent.

Note: I DID NOT use the wording "exact" in regards to compatibility....that was never the stated goal. At least from what I have read.

Note: after reading what I posted...this seems far astray from precipitation but you know..."when it rains, it pours"

[Kazareh]

Well, sorry if I"m 'off base' then... The general impression I get reading through a lot of stuff, even before stuff started going for 1.0(Which I still say we are nowhere close to meeting the milestones for), is that the ORTS will do what they want how they want. And if they don't want it in the sim, they aren't going to add it, end of story. I had to fight tooth and nail to get that moveable interior view, and the issue of the gyra-cam effect in Passenger cam and 3DCab cab are still present, and we've pretty much been told 'it's not a bug, deal with it' more or less. :/

Maybe it's the differences in some of our coders and such languages and relevency to speaking English, as folks like me and you are native speakers, where as others, it's not their 1st language, but that's the impression I've really gotten from them. Sorry if that's an inaccurate impression, just how I've been taking it.

[copperpen]

The base target for ORTS version 1 was compatibility with MSTS, not to be an exact mimic of it. I suggest that the initial aim has been reached, with some small bugs to fix. 3D cabs were never part of MSTS and can be considered as icing on the cake, along with things like timetable and AI shunting/switching. There are areas where OR is far in advance of anything MSTS could accomplish. All of this has been done by people like you and me giving up their free time to make the code for all this to happen. Just accept that there are some things that are not going to happen in the short timeframe, but if you wait patiently, something may come along to fix what ever it is that you don't like.

[edwardk]

It is quite painful to watch when your camera view is just above the train. I have to wonder if this done by mistake. When you think about graphic resources, raising the ceiling should not be that demanding. The catch is understanding how everything works in the code. One variable under Precipitation is ParticleBoxHeightM. This could be the key to the starting height, but changing this alone does not work. I did attempt to change the value, but evidently other processes are tied to this so more than one change is evidently needed.

Edward K.

[James Ross]

Kazareh, on 22 April 2015 - 08:05 AM, said:

But why should there be no need for a slider or option to increase/decrease that, hm? Tell me why. Is it because there is truly no use for one, or because you all are simply not -wanting- to do one?

There is no need for one, because the limitation with certain graphics cards is not about their general performance or anything, it's just an arbitrary limit (16bit index buffers). If you have a graphics card that does better (e.g. 32bit index buffers), we can just do better precipitation. That means someone writing the extra code to do both kinds, which nobody's done yet.

edwardk, on 22 April 2015 - 01:04 PM, said:

It is quite painful to watch when your camera view is just above the train. I have to wonder if this done by mistake. When you think about graphic resources, raising the ceiling should not be that demanding. The catch is understanding how everything works in the code. One variable under Precipitation is ParticleBoxHeightM. This could be the key to the starting height, but changing this alone does not work. I did attempt to change the value, but evidently other processes are tied to this so more than one change is evidently needed.

It's definitely not a mistake; I worked hard to balance the distance and height of the precipitation. I tuned the values such that the heaviest rain and snow would still fit in to the buffer whilst ensuring a reasonable distance is covered. Making it closer and taller just changes where it looks bad and I tried to focus on the cab view and ground level as that's where most play is likely to occur.

The issue is the restriction to 16bit index buffers on some graphics cards, which puts a hard limit on the number of particles, not the graphical demands of it. Even graphics cards with only 16bit index buffers could probably handle five times the number fine, but that means writing code that uses five different index buffers, which is more complicated and error-prone.

I have no objection to someone implementing multiple 16bit index buffers and/or 32bit index buffers, but nobody's done it yet. :sign_sorry:

[Kazareh]

copperpen, on 22 April 2015 - 12:47 PM, said:

The base target for ORTS version 1 was compatibility with MSTS, not to be an exact mimic of it. I suggest that the initial aim has been reached, with some small bugs to fix. 3D cabs were never part of MSTS and can be considered as icing on the cake, along with things like timetable and AI shunting/switching. There are areas where OR is far in advance of anything MSTS could accomplish. All of this has been done by people like you and me giving up their free time to make the code for all this to happen. Just accept that there are some things that are not going to happen in the short timeframe, but if you wait patiently, something may come along to fix what ever it is that you don't like.

Fair enough, however if you all are considering Timetables a 'icing on the cake' deal... Do you plan on releasing 1.0 without an activity editor? I remember a while ago when the bare-bones stuff for the AE was implimented; but never touched on after.

[James Ross]

Kazareh, on 22 April 2015 - 01:21 PM, said:

Fair enough, however if you all are considering Timetables a 'icing on the cake' deal... Do you plan on releasing 1.0 without an activity editor? I remember a while ago when the bare-bones stuff for the AE was implimented; but never touched on after.

That's the way volunteer and open source projects work, unfortunately. Whatever we might want to include/make, unless we have the people and their valuable time to do it, we don't have much choice. There's nothing particularly special about 1.0 to me, but I believe that getting past it will help us with people for whom 1.0 is special.

[edwardk]

The question is, did you know that the balance would have the precipitation start just a few mere feet(so to speak) above the locomotive? Its one thing to establish balance, but to distort some form of reality in doing so. So I am guessing to raise the ceiling would require switching to a 32bit buffer?

Edward K.

James Ross, on 22 April 2015 - 01:21 PM, said:

There is no need for one, because the limitation with certain graphics cards is not about their general performance or anything, it's just an arbitrary limit (16bit index buffers). If you have a graphics card that does better (e.g. 32bit index buffers), we can just do better precipitation. That means someone writing the extra code to do both kinds, which nobody's done yet.


It's definitely not a mistake; I worked hard to balance the distance and height of the precipitation. I tuned the values such that the heaviest rain and snow would still fit in to the buffer whilst ensuring a reasonable distance is covered. Making it closer and taller just changes where it looks bad and I tried to focus on the cab view and ground level as that's where most play is likely to occur.

The issue is the restriction to 16bit index buffers on some graphics cards, which puts a hard limit on the number of particles, not the graphical demands of it. Even graphics cards with only 16bit index buffers could probably handle five times the number fine, but that means writing code that uses five different index buffers, which is more complicated and error-prone.

I have no objection to someone implementing multiple 16bit index buffers and/or 32bit index buffers, but nobody's done it yet. :sign_sorry:

[James Ross]

edwardk, on 22 April 2015 - 01:43 PM, said:

The question is, did you know that the balance would have the precipitation start just a few mere feet(so to speak) above the locomotive? Its one thing to establish balance, but to distort some form of reality in doing so. So I am guessing to raise the ceiling would require switching to a 32bit buffer?

I wouldn't call 43 meters "just" anything, but it was enough to look okay from the cab when this was written. You can experiment with the value (and the box size one) if you like, since I put an assert in the code that you haven't exceeded the 16bit limit. :sign_sorry:

To go beyond in anything other than tiny amounts we'd need either multiple 16bit index buffers or a 32bit buffer, yes.

[roeter]

And all this because of a snow-flake. Oh dear.

;)
Please note : these rantings are my own personal feelings and in no way represent a general opinion of the development team as a whole or any of the other members of that team, who indeed may have very different views on this.

Kazareh, on 22 April 2015 - 08:05 AM, said:

Volunteer projects work like that, you may volunteer your time, but for software projects? You listen to what people want, not what -you- want.

So, what you mean to say here is that we are just like machines : you push the button and we dance to your tune?
Well, "he who pays the piper calls the tune" - except, ofcourse, that you don't pay anything, so - no, you can't call the tune.

And yes - we do take heed of what people want - but : in the end, it's all my time I'm spending on this, and so I will indeed spend it pretty well on what - I - want - within the constraints of the project and the approval of the ORTS management, ofcourse. If others have usefull ideas, I take these into consideration, and if others point out that things don't work, I will look into it. But if others make suggestions that would take up a lot of my time but for which I have no interest at all, those items do end up at the bottom of the list.
Am I ashamed of that? No, not really. It may seem strange, but when it comes to the bottom line : I have no interest in whether people like what I have made, or not. If I spend a lot of time on something what I really want but what no-one else will ever be using, I will still be where I am now, it would have no consequences. On the other hand, if lots of people do like and use it - it will still not make any difference, I will not be better off than I am now in any way at all.
This may all seem very harsh - but just remember you're talking about what others do in their own spare time without any compensation.
So if you want anything - try asking for it rather than demanding it, and if you get it, count yourself lucky - and if not, well, better luck next time.

Quote

Maybe it's the differences in some of our coders and such languages and relevency to speaking English, as folks like me and you are native speakers, where as others, it's not their 1st language, but that's the impression I've really gotten from them. Sorry if that's an inaccurate impression, just how I've been taking it.

Rubbish :sign_sorry: .

Quote

Do you plan on releasing 1.0 without an activity editor? I remember a while ago when the bare-bones stuff for the AE was implimented; but never touched on after.

Sadly, the person who was working on that had to leave the project due to personal circumstances. We're not a company which can just go out and fill a vacancy. If no new volunteer comes forward, the work simply stops, as happened in this case. And which could happen to any part of the project at any time - the development team is only a very small group at the moment, each with his own area of interest. If anyone would leave, work in that area would slow down considerably, and in some cases probably grind to a halt. That's the problem with projects like these.

Enough for now - time to hand you back to the snowflakes.

Regards,
Rob Roeterdink