Problem with ground handling with v4.1

[Cargostorm 151]

So it seems that PTA is the only addon left that needs an update. Great that developers managed to make their addons compatible within a couple of days following release of 4.1. 👍🏻

[Lorby_SI 2,042]

9 hours ago, SpiritFlyer said:

Nothing to worry about whatsoever! :)

Except...

- if your favorite ride is a legacy aircraft that will never be updated
- if you are using a cross-platform shared cockpit app that is now sending incorrect rudder values
- if you were recording flights with a software that now cannot properly show rudder movement (or worse) when playing them back
- etc.

I am certain that LM means well when correcting these "bugs". But many developers have been working around those for years, and what has been implemented now is not only a simple "fix", it is also a "change" - breaking compatibility with previous versions.

Best regards

[simbol 5,821]

@Lorby_SI
Oliver,

I get your frustration, what we need is to work harder next time to get early access to LM releases so we can be ready before any change is introduced.

I wish you and your projects the best.

Regards,
Simbol

 

[Lorby_SI 2,042]

11 minutes ago, simbol said:

@Lorby_SI
Oliver,

I get your frustration, what we need is to work harder next time to get early access to LM releases so we can be ready before any change is introduced.

I wish you and your projects the best.

Regards,
Simbol

 

Earlier access wouldn't change a thing, the necessary effort is the same. If it takes a week to analyze this issue and update all apps, these are "virtual" costs of roundabout 5000€ either way.

Best regards

[Guest]

1 hour ago, Lorby_SI said:

But many developers have been working around those for years, and what has been implemented now is not only a simple "fix", it is also a "change" - breaking compatibility with previous versions.

So don't fix bugs?  Don't make any breaking changes?  I don't think I've every been able to accomplish that in my 37+ years of design, coding, and implementation ... although I have worked on projects where I've had to increase bloat and data structure sizes to maintain a level of compatibility, it was NOT a desirable solution and ultimately is a performance penalty. 

Keep slow and expensive and inaccurate layers of compatibility that penalizes performance, performs incorrectly for everyone just to make 3rd party content developers have less support? 

The change was needed which involved:

ROTATION VELOCITY BODY X
ROTATION VELOCITY BODY Y
ROTATION VELOCITY BODY Z

they were using feet per second rather than the correct radians per second, it's now consistent with other rotation velocity sim variables.  I think consistency is a good thing.

I guess LM could have bloated the size of sim variables and create NEW ones but that would just add more confusion in the SDK long term and increase code bloat for the simple reason of reducing 3rd party support.  A2A were able to remedy a very quick fix ... part of the cost of product and their choice to sell products for P3D (and hopefully earn revenue from it). 

So I guess I'll strongly disagree with you, please keep fixing bugs LM, please keep making changes ... if LM do move to PBR there will be a huge change in how textures should be done so if one is committing to P3D platform then price the product accordingly for support/updates because the platform has NO intention of standing still ... LM have been VERY clear about that.   LM will do their best to maintain compatibility but given the complexity of ESP they have done an excellent job and proof of that work is how quickly 3rd party have updated existing products (even the 64bit transition), they didn't have to start from scratch.

Cheers, Rob.

 

 

[Lorby_SI 2,042]

3 minutes ago, Rob Ainscough said:

So I guess I'll strongly disagree with you, please keep fixing bugs LM, please keep making changes ...

Yes, please. It doesn't matter if small developers go out of business, keep up the good work.

5000€ is almost all the income for a whole year from the Lorby-SI addons. So from a project management perspective, the path is clear.

Best regards

[Guest]

5 minutes ago, Lorby_SI said:

So from a project management perspective, the path is clear.

Obviously it wasn't clear before you started.

Cheers, Rob.

[DrumsArt 270]

24 minutes ago, Rob Ainscough said:

So don't fix bugs?  Don't make any breaking changes?  I don't think I've every been able to accomplish that in my 37+ years of design, coding, and implementation ... although I have worked on projects where I've had to increase bloat and data structure sizes to maintain a level of compatibility, it was NOT a desirable solution and ultimately is a performance penalty. 

Keep slow and expensive and inaccurate layers of compatibility that penalizes performance, performs incorrectly for everyone just to make 3rd party content developers have less support? 

The change was needed which involved:

ROTATION VELOCITY BODY X
ROTATION VELOCITY BODY Y
ROTATION VELOCITY BODY Z

they were using feet per second rather than the correct radians per second, it's now consistent with other rotation velocity sim variables.  I think consistency is a good thing.

I guess LM could have bloated the size of sim variables and create NEW ones but that would just add more confusion in the SDK long term and increase code bloat for the simple reason of reducing 3rd party support.  A2A were able to remedy a very quick fix ... part of the cost of product and their choice to sell products for P3D (and hopefully earn revenue from it). 

So I guess I'll strongly disagree with you, please keep fixing bugs LM, please keep making changes ... if LM do move to PBR there will be a huge change in how textures should be done so if one is committing to P3D platform then price the product accordingly for support/updates because the platform has NO intention of standing still ... LM have been VERY clear about that.   LM will do their best to maintain compatibility but given the complexity of ESP they have done an excellent job and proof of that work is how quickly 3rd party have updated existing products (even the 64bit transition), they didn't have to start from scratch.

Cheers, Rob.

 

 

Please, is it possible and easy to correct these parameters for some aircrafts no more supported ?

Thanks and Regards,

[Lorby_SI 2,042]

16 minutes ago, Rob Ainscough said:

Obviously it wasn't clear before you started.

Cheers, Rob.

Just because you don't agree, that is no reason to be condescending. You have no idea who I am and where I come from.

I suppose that you know as well as I do that small developers can never hope to work cost effective. We are just happy to receive a little compensation. If I would have to sell FireFighter X cost effective, using my own hourly rate applied to development effort, one license would cost 500€ - supposing that the same number of people buy the addon at that price as they did for 17€.

Enthusiasm is what keeps me going. But there are limits for everything, and it has become increasingly hard to justify the effort. This issue here is just another drop, albeit a big one.

The prudent thing for LM would have been to leave it like it is and just correct the spec. At the very least, yes, I would have expected them to add three more variables (doesn't really matter, does it?). It is not like they don't do this, SimConnect has grown quite a few duplicate methods.

But you have made it plain that you don't care for small change problems, so there probably is no point in even discussing this.

Best regards

[Lorby_SI 2,042]

17 minutes ago, DrumsArt said:

Please, is it possible and easy to correct these parameters for some aircrafts no more supported ?

Thanks and Regards,

IMHO: No.

If an aircraft makes use of these simulator variables, the original developer has coded his gauge or whatever specifically for those value ranges. If the aircraft is affected by the above mentioned problem, only the developer knows where to change what. (and if it is a programmatic (C++) gauge he is the only one who can change it)

But the probability that aircraft are affected should be relatively small I think. I can't imagine that using these variables is a very common practice. Could be wrong though, I am no aircraft designer.

Best regards

[DrumsArt 270]

Thank you for your answer Oliver.

Regards,

[Guest]

40 minutes ago, Lorby_SI said:

You have no idea who I am and where I come from.

Yes I do know who you are and that changes nothing.  What you're asking for is ridiculous -- so LM should just stop developing P3D and not fix well known bugs?  This isn't FSX, any developer supporting P3D should have been very aware it's a changing platform and as such plan accordingly (cost of product, support for product, expected revenue from product, updates to product, etc. etc.).  P3D is not a dead platform with zero development, it continues to evolve and will continue to evolve.  Just like XP11 isn't static, and FSW isn't static, and AF2 isn't static ... current FS platforms are in a state of constant change.

LM are in this for the long term, you don't leave items wrong if you know you can "easily" fix them ... there is already enough "oddity/quirks" in the SDK so removing those things that are wrong and not consistent with other sim variables ultimately makes the SDK more accurate and clear.  Having duplicate methods and duplicate variables is NOT the way forward, that just bloats code even more and adds to confusion. 

The only fault you can perhaps apply to LM is that this was not in their change log, but again the 3rd party content providers on the Beta I would assume would at least test their own products?

I agree with you, yes it is hard for smaller (one person development) to realize revenue from their efforts, this is one reason why I have not entered into the content provider world as I fully understand the challenges of selling software to real people/clients in the real world.  That's what I do real world, I produce (design/code/implement) software (small development team) and we have a small support team (4 real humans), small sales team ... so yes I'm very well aware as I've been doing this full time since 1992 and it has been full of challenges and also rewards.  It's a very different world today than when I was doing prior (late 80's) design/coding/implementing for Bank of America (a job I hated but brought home some income).  Working for smaller development company is much higher stress levels, you wear many more hats (several jobs wrapped into one).

Today's FS 3rd party projects are getting more and more complex and will probably continue in that direction as end users/customers demand more and more, given that we have a 64bit path in most of the current Flights sims we now have room to expand what can be done (larger project scope) which means larger development teams.  So if one is a smaller developer, it's going to be that much harder to survive, project selection, support, updats, etc. ... every time a new big project steps up the bar it has an impact on the entire 3rd party community ... in some cases forcing small developers to combine resources or stop developing, in other cases taking 5 years to deliver a product.

Trust me, I know the issues involved, but suggesting LM bloat code to support compatibility isn't a good path forward.

Cheers, Rob.

 

 

[Guest]

52 minutes ago, DrumsArt said:

Please, is it possible and easy to correct these parameters for some aircrafts no more supported ?

Yes, but not easily.  You'll need a hex editor and lots of trial and error, not a task I'd recommend. 

OR, you could write your on SimConnect based DLL to modify the sim variables in question.

Cheers, Rob.

[DrumsArt 270]

7 minutes ago, Rob Ainscough said:

Yes, but not easily.  You'll need a hex editor and lots of trial and error, not a task I'd recommend. 

OR, you could write your on SimConnect based DLL to modify the sim variables in question.

Cheers, Rob.

Thank you Rob...I guess it's not possible for me...Not tried yet but I think I can forget all my RealAir in v4.1.

Regards

[Lorby_SI 2,042]

35 minutes ago, Rob Ainscough said:

Yes I do know who you are  

Really? I wonder what would give you that impression. I can't relate to anything in your posts, it is like you are writing to someone else. Lorby-SI is not a content provider, not in the true sense of the word. My addons are not affected by platform architecture, 64 bit, visuals or any of that. But they depend 100% on consistency and reliability of the API. And if that is no longer guaranteed, my addons fail, plain and simple (and others with them, as it seems).

Quote

What you're asking for is ridiculous -- so LM should just stop developing P3D and not fix well known bugs?

Did I say that? What is bugging me is that this change was unnecessary. I have always been fighting that urge in some of my developers, that they want to implement changes just to make the code "consistent". They didn't have to explain to the customer why his application suddenly had developed an unforseen issue - that was always me.

And then I have this strange notion, that an API should be as independent as possible from the base platform - and it absolutely has to be reliable in operation and spec, otherwise there is no point in providing one. But that may just be me.

I must say, I am a little surprised about what you are writing about LM and their goals. Are you speaking in an official capacity here? Because this doesn't really sound like their claims on the website - you know, "developers platform" and all that. This feels more like "keep up or good riddance". If the goal is to only favor the largest and most powerful companies on the market, then this is certainly a sound strategy in the long run. But (for me) this is not what this platform used to be about.