My understanding is that the workflow to accomplish a fix for your MFS20 aircraft package on MFS24 is:
Shut down MFS24
Compile your MFS20 package using MFS20 SDK after making a fix (this avoids loading MFS20). Copy that new package to MFS24 Community
Start up MFS24 and wait for loading
Load the aircraft and test the change
Now repeat steps 1-4 for each iteration of the change. Some changes like the avionics alone could be reloaded, although we are also seeing an incorrectly-sized entry in layout.json block the sim from loading so that is another easy way to trip up with edits like that.
We canāt resync in the game now without a project, and I canāt open the project without upgrading it to MFS24. I canāt upgrade all my aircraft to MFS24 native packages without an insurmountable work on the port. And I canāt wait much longer on trying to address the problems impacting the MFS20 packages.
Am I missing something? I just donāt have the hours in a day to make this workflow work.
Symlink the built package into your MSFS2024 community directory to save at least one step in that process (MSFS addon linker is good for this). Will the MSFS2020 fspackagetool run successfully while MSFS2024 is running? If it does, simply restarting the flight in 2024 might be enough to test a lot of things.
This is roughly the workflow I use for the FBW A32NX/A380X, but without fspackagetool as we only use that to build the 3D assets infrequently; the real package is built with a custom build system that needs to be able to run on a lightweight Linux machine (GitHub actions).
Surely something can be done to improve developer productivity in MSFS2024 ? The current setup totally blocks the rapid iteration of code changes in files the āBuild Systemā is providing absolutely ZERO value-add for. Was that really necessary ?
Unfortunately I think you are right that there is no alternative to the procedure you describe right now.
As you know we are working on a way to enable/disable packages from the My Library screen but in its first iteration this will require a restart of the sim so it wonāt make your life any easier.
However we are working on an improvement that will eliminate the need for restarting, which would then improve the situation - I have no ETA yet but one of my team members is working on this nearly 100% of his time so hopefully we can come up with the fix early next year.
It is unclear to me if your comment is related to the issue highlighted by the OP.
Are you specifically talking about testing MSFS 2020 package updated in 2024 or are you just saying that you want to build your 2024 packages manually without using the in-sim package builder?
That was the intentionā¦ maybe I worded it badly . I have pretty much all the MSFS2020 gliders to migrate into MSFS2024 and the starting point is to put the 2020 packages into the 2024 Community folder and see what breaks. The reality is all the gliders (from a mix of modellers) have failures in 2024 which makes them unflyable (the most common cause is ā.ā or ā ā characters in node / animation names which once spotted is easy but tedious to address) but also my ambitious adoption of the MSFS2020 āvariantā system using ModelBehaviourDefs for the XML so a 15m and 18m variant of the same plane could share common code but crucially, separate flight models. The fix there is to split the 15m/18m planes into separate packages and duplicate e.g. the model XML but then I have to edit that.
So all that leaves me with the issues of hand-editting very complex XML code while within the MSFS2024 environment, but working on a 2020 package. FWIW also we have 10ās of thousands of lines of html/js code in the nav instruments and I havenāt found out yet whether editting the code and reloading the instrument via the Coherent Console will work in 2024 (Iām pessimistic that the VFS will block it though). Most recently Iāve found a 2020 flight model on a particularly sensitive glider behaves quite differently in MSFS2024 and Iāll need to fix that - I doubt thatās typical but it was unexpected.
So the vague plan is to move the 2020 packages successfully across, and at some point Iām expecting to build new 2024 packages and rebuild the 2020 content and somehow get that working and progress from there, but currently Iām still working on the simplest plane we have in 2020 to try and get that ported to 2024.
I think Iām in the same boat as the OP, apologies if not, that the develop/test loop making multiple small changes in 2020 config and code files for a move of the package into 2024 is pretty excruciating. In 2020 Iād edit e.g. the XML, hit the reload button, and know within maybe 3 seconds whether that change was successful. In MSFS2024 itās more like 3 minutes.
Itās telling MSFS2024 to reload the plane using the updated layout.json thatās the missing link. Even the json update step could be removed if the VFS was smarter about loading a local file.
As a post-note, Iāve discovered Iām a complete idiot. It is infinitely easier to update a 2020 package within MSFS2020 & test it there before the final move/test in MSFS2024. For some reason I was stuck on the idea I should be doing the iterative fix/test in MSFS2024.
. I have pretty much all the MSFS2020 gliders to migrate into MSFS2024 and the starting point is to put the 2020 packages into the 2024 Community folder and see what breaks. The reality is all the gliders (from a mix of modellers) have failures in 2024 which makes them unflyable (the most common cause is ā.ā or ā ā characters in node / animation names which once spotted is easy but tedious to address) but also my ambitious adoption of the MSFS2020 āvariantā system using ModelBehaviourDefs for the XML so a 15m and 18m variant of the same plane could share common code but crucially, separate flight models. The fix there is to split the 15m/18m planes into separate packages and duplicate e.g. the model XML but then I have to edit that.