There’s a scale in the MFD and I’ve read you’re supposed to trim it 50 % right before takeoff. But I guess lots of right foot could work too.
The 50% trim is not much in relation to the pedals and the deflection of the actual rudder. It’s really not bad at all to keep straight, wouldn’t even call it tricky. Plenty of planes need more rudder work. What is a pain is messing around with rudder trim.
Given the further decreased performance in the recent update, and subsequent bug reports and testing to finally understand the issues with the Kodiak, it does appear to be power/engine as the cause of its anemic STOL Utility performance.
In any event, it seems you have finally identified the issues with the Kodiak that severly impacted its ability to perform STOL Utility work. The issues don’t really seem to be a problem for people that just tootle around in for GA, which I can understand as they don’t go anywhere near the STOL Utility flight envelope, but unfortunately the plane was designed and built to fulfil a STOL Utility task first and foremost.
Hopefully, SWS has finally nailed these issues (as well as keeping up with SDK changes) and we’ll be able to use it properly for the job it’s designed for.
To clarify, there were no SDK changes that broke the engine. It is undocumented FM updates that affect the airplane’s performance.
For example in v1 the plane cruised fine, but with SU8 the same flight model cruised with the nose down.
The engine was set up with data from the prop factory, but eidnt perform after SU8 and we didn’t have a probable cause. Now I just boosted thrust by 15% and it flies by the book again.
The key takeaway is that MSFS was changing things without us knowing what they are or how they affect performance, while straying away from established physics.
At lease we got it working again…
Thanks for the clarification, though technically the FM is part of the SDK, which is more what I was getting at - the underlying infrastructure that all products are built on.
You’re not the first to hit undocumented issues, and likely won’t be the last - unless something is done about it. Devs have been complaining about if for ages.
I think there really needs to be more knowledge sharing on a developer level and collaboration so you can all resolve these issues faster and without the stress.
Maybe there needs to be an official 3rd party developer organisation to aggregate this dev force so it can be applied to MS/Asobo to get some more warning of things like this too. It’s too diffused when devs are asking them one by one, which leads to no response from MS/Asobo usually, and the simple fact is the changes affect everybody. It’s a large economy now, and MS/Asobo need to take it seriously.
Onwards and upwards!
My own view on all of this..
When you look through the posts in these forums, especially the third party aircraft forums, the developers of an aircraft are often flooded with demand for alterations and “improvements”. Some of those “improvements” demanded by a very vocal set of customers, are real and good, others not so. Developers who don’t ( or can’t ) provide regular updates to their products are roundly criticised here although they don’t get any extra funding out of us to make those changes…
But my point is that too many updates and changes don’t necessarily result in a better aircraft. A real pilot wouldn’t turn up at work one morning and find that a SW update had totally altered the flight model of the aircraft and added in more failure modes to worry about. When the Kodiak first came out it was the aircraft I flew the most. I spent 25 hours learning to fly it in normal and STOL environments - and I loved the experience - it felt real.
But now it sits most time in the hangar and I think about uninstalling it sometimes.. and that’s because there have been so many changes to the way it handles that I don’t know the aircraft - and there have been so many changes that I don’t feel like relearning the aircraft when I know there will be further mods coming along which will probably change the flight model significantly again. I’d roll back to the original aircraft I purchased tomorrow if I could.
So too much change can be a bad thing I reckon. Its not just true of aircraft developers - MSFS is more often than not guilty of this too..
Anyway, that’s my own view of the Kodiak today. As a result of my experience (same happened on a C414 update recently but was quickly fixed) I now don’t install an aircraft update for a ‘plane I like flying until I know what the consequnces will be and that nothing I enjoy about that ‘plane has been broken.
There should also be a debate with developers about how products should be supported and for how long - we shouldn’t expect lifetime support of products unless we fund the devs somehow - through buying new updates versions or by some sort of subscriptions. It’s not talked about enough here.
I suspect they do in fact make money out of it, as they build a positive reputation both for their team and their planes.
There is necessarily going to be an expectation of long term support, since MSFS development environment is a moving target by grace of Asobo. I wouldn’t be surprised every plane out today would brake at some point in this game’s active development lifespan.
I suppose the type support could be categorized:
Improvement support, providing improvements for the aircraft within boundaries of existing SDK and flight/systems model.
Feature support, providing improvement support for the aircraft as new options are unlocked in MSFS.
Custom feature support, providing improvement support for the aircraft via custom code to bypass sim limitations.
Compatibility support, providing support to maintain existing functionality as SDK and flight/systems model change.
Both plane are great, but I don’t like the sound of the Kodiak.
For me it comes down to glass vs. steam gauges.
Never regretted buying the Analog Caravan.