I keep reading that the SDK documentation “is severly lacking” - and although it is true on various topics (as was highlighted above), we rarely get more detailed feedback which would help improving things. Package creation through DevMode has not changed much since MSFS 2020 - and a lot of people created packages for this sim.
How do I go about editing the lights and saving them if there is no layout.json accessible?
also, with the quick reload, I can make changes and quickly reload to see the results. This is why we need a quick reload option. Having to shut down the sim and re load for every change is NOT going to be ok.
I’ll fully admit I’m not very familiar with the projects side of things as I’ve almost never used it. I am very open to being wrong and discovering a new way to do this but I’ve just given this a try in every way I know how and have had zero luck to get a changed file to resync in the sim without a sim restart. This is outside of the massive delays, lags, and temporary freeze-ups I had in dealing with the project editor - to the point that it might just be quicker to restart the sim anyway. At best it turns a 10 second process into a several-minute one.
Is it the “build your package” step that is supposed to resync the files in-sim? From what I knew of FS20, that would merely copy the project files to another package folder.
For perspective, there are times I’ve hit Quick Reload 100+ times in working on a mod so you’ll understand that a convoluted multi-step process (or huge delay, or sim restart) to test changing a number just won’t cut it.
I believe people have trouble with ModelBehavours not for a lack of documentation or examples, but because it’s a overly complex, user-hostile system.
Finding the correct template is like finding a needle in a haystack, if it even exists.
Why do we have to learn a wierd stack-oriented scripting language mixed in with xml files? Huge mental overhead and facepalm every time you see “& gt;”.
Years ago I worked on aircraft products for X-Plane where setting up cockpit interaction was an asbolute breeze compared to MSFS. It took at least 10x less time.
As a modder and working full time for another company I do not have the time and ressources to make a change, then restart the sim just to understand how 5 lines of code work!
layout.json and manifest.json are created upon building the package, they are not part of what we call the “package sources”. In your case the process would be:
1/ Create the package as explained in my previous post (don’t put layout.json and manifest.json in your package sources - this is useless)
2/ Build your package, start a flight with your aircraft
3/ Edit your lights in systems.cfg (you cannot use the SimObject Editor for this since you do not have a full SimObject asset group in your package - maybe we can improve this)
4/ Build the package again - the aircraft will be re-created with the new configuration.
Contrary to what I read here, and unless there is a bug that should be reported as such instead of “the Quick Reload button has disappeared”, you do not have to restart the sim to see your changes when using the official pipeline.
One big issue with this process which others have mentioned is that the “Build package” step in 4/ can take a long time (sometimes several minutes depending on the number of packages that are activated in the sim), which makes it horrible for quick iterations. This is something we are precisely working on right now (it also affects the “live” activation/deactivation of packages in My Library) with optimizations being scheduled for the next SimUpdate. I won’t give numbers right now because the whole thing is still being worked on but from initial tests run yesterday it seems even faster (and more reliable) than the old “Quick Reload” button from the Behaviors window.
The team which designed the system is using a VSCode add-on that seems to help them significantly when searching for the right template - this add-on is being debugged/polished with a view of integrating it into the SDK. Not too sure of the ETA (and I can’t really provide information on features since I haven’t seen it myself yet), but we aim at shipping it sooner rather than later.
As for the X-Plane system you are referring to, maybe you can share some documentation links that explain how it works?
Again, you don’t have to restart the sim. But right now the waiting time between iterations is too long indeed and is being optimized.
On a more global note, I think the focus many have here on the disappearance of the “Quick Reload” button should be shifted to what the real problem is which is long iteration times.
I think it essential to add the many “improvement projects”, including my own G36 Bonanza in 2020 - who would like to modify the existing aircraft to allow them to resemble their real-world counterparts more closely. Several bugs and missing features in the G36 would benefit a mod, from systems and modelling to engine parameters.
Will this be possible?
Sorry, I broke the flow of this thread somewhat as I am coming back after a week or so away. After getting to the bottom of the posts, do I understand correctly that we can set up a project and use the copy feature to copy and modify a default aircraft?
I got the G36 Mod working by copying and tweaking the files in 2020, so this is a new workflow for me.
Start a project costs 1+ minute. Open a template, 2+ minutes. Add an asset group, 1+ minute. Building/rebuilding the project, 2++ minutes. And other areas where it stops to think for needlessly long periods of time. Even if you cut this in half, this is many times slower than what we had before. Hell, decreasing it by 90% vs what it is now still makes it far slower than what it was before.
I gave it another try a few times this morning but it was much less enthusiastic after one Build took over 4 minutes and I still didn’t get a file resync. My patience wore thin and I tested the Alt-F4 command. It worked.
All that being said, I’m still open to the idea that I’m doing something wrong and my basic understanding of the Projects flow is incorrect. In fact, it probably is. But that doesn’t speed up the delays every step of the way.
Creating the project, opening a template and adding an asset group should be one-offs and will take one or two minutes at most when you get used to the system. That being said I am thinking of having an “overriding” wizard which may help making things even faster - need to discuss with the team.
As for the building/rebuilding and the various freezes you are facing, this is what we are working on right now with a view of providing massive improvements in SU1.
What kind of changes did you make that were not resynced when you tried this morning?
This all doesn’t sound too well. Even for aircraft devs that have access to the package files it takes way longer than in 2020.
I was mostly building flight models and for that reason was used to resyncs that only lasted a few seconds (depending on the model of course).
So oftentimes the procedure was like this:
do some changes, resync
testfly for a few seconds
make further changes, resync
That went on an on until i was happy with the behaviour. This also meant several hundret resyncs a day. If every resync now takes two minutes that slows building flight models down massively.
I’m afraid Asobo Studio is misjudging just how many 3rd party developers relied on access to all core resources in 2020 as opposed to documentation and SDK templates.
I see Your point about following the correct workflow from A-Z, but I think this filters out much, much, much more of us than You think, and the ultimate result will be that 3rd party market will dry up in the upcoming months.
By the time You gentlemen will start looking for new 1st party developers for FS28 there will be none, because Your new setup has destroyed the organic learning pipeline that formed around FS2020. Freeware tinkerers became modders, modders learned to make their own payware, and some of the best of those are now with You as first party devs.
The way aircraft development works in 2024 broke the easy access ramp that let them learn, in 2 years there will be no fresh devs to bring into the fold, and You gentlemen will be puzzled why.
This thread is the why. This is the decision that will bring you You to that point in the future.
Did you read the previous answers I made that explicitly stated we were working on bringing a serious speed boost to the official pipeline in SU1?
If we are successful with this your previous workflow will be unchanged except that you will use the “Build package” button from the Project Inspector instead of the old “Quick Reload” one from the Behaviors window.
The only other difference will be that you will be required to create a mod package instead of directly modifying the files in another package that you did not create - which I believe should be seen as safer for everyone.
I don’t think this is true, although I understand why the state of things right now may give such feelings.
I disagree but time will tell - it would be interesting though to know why you think following an official & supported workflow filters anyone out.
You forgot a capital Y in the last “you”.
More seriously, I think it’s rather early to make that kind of predictions. Plus, I already heard similar statements before we release 2020 and, as you know, despite the dark forecasts written here & there,we discovered a lot of talented people thanks to this edition.
I am not saying everything is fine (or set in stone) with 2024 (actually, we’re far from it), but making wrong assumptions and burying everything that’s been done for this new version as you’re doing here seems a bit premature.
I think following official and supported workflow will filter people out because I experienced trying to learn it from SDK docs, and found using 2020 core files as a repository of practical templates much easier. The new workflow requirements are filtering out people like me, the skill requirement for learning on the go from working examples was much lower.
In 2020 we had the alternative, people could learn official flow from docs or learn as they go and so far I found the latter was easier for a wider group of people.
Is it too early to tell? If, as I think You said, quick resync and easy and rapid access to all core files cannot be brought back due to decisions in core sim architecture, then it might actually be too late
no pun intended in my post. I was just trying to point out the current issues with a real life example.
I appreciate all your effort to help out.
If you guys manage to speed the process up, all is good.
Well then you need to re-read what I have written:
The “Quick Reload” you were used to won’t come back but the official pipeline should allow you to work at the same speed and get more reliable results.
Core files that were not accessible at launch: this should be OK now for Standard content through the VFSProjector.
Core files which new format causes problems:
KTX2: we should be able to provide livery makers with the necessary tools to customise (export) each mip - the issue we have right now is that the package builder doesn’t know how to create a KTX2 file from various PNGs (or other), hence there is no direct/easy way back into the sim.
glTF: our mesh optimization extension is not recognized by the usual tools - we are not sure yet if we should provide an importer or publish the specs of the extension. Again, when the choice is made it will be rather easy to overcome.
XML behaviors: this is the most tricky one because packages now use self-contained XMLs and don’t have any record of the templates that were used to produce them. Solutions are being discussed which should be available short-term.
Because you seem quite keen at jumping to conclusions, I’d like to stress that all of these changes were not made to bother modders (whether they create freeware or payware products) - their main purpose is performance and/or related to streaming.
Now, if you tell me that you don’t want to hear about any official & supported pipeline and that you would rather continue tweaking files in packages, then I agree that you might be filtered out - but that’s only your choice.
