The livery system lets you replace the image files used by an aircraft’s exterior paint, and it lets you replace the image files used by the objects that are attached to the plane via the “objects” folder.
But the livery system does not let you replace the objects themselves.
(It also doesn’t let you replace or modify the actual ACF file or generally change the functional behavior of the plane. The livery system is just for paint, not airplane mods.)
Hi Ben,
do you intend to add this feature in a future version?
I think it’s quite an important feature.
For example the 757:
The window configuration is different for every 757. Take a look at the HZ-HMED:
http://www.airliners.net/photo/Saudi-Arabian-Royal/Boeing-757-23A/1291728/L/
You can see that many windows are plugged in this aircraft.
The all-object XPFW 757 uses 3D windows and a plug object to plug the windows.
These objects are very important for the general appearance of the aircraft. So when objects are not loaded in the liveries feature, it is completely useless for modern all-object planes like the XPFW 757. And there are many more cases where you would need this, not just for the plugged windows of 757s!
Dennis: not sure yet…my goal with the livery system is to start with a small scope – we can always add features later. The windows are interesting because they don’t affect flight dynamics, which was one of the original reasons to reject replacing OBJs.
Thanks for the answer, Ben.
I hope you’ll consider it.
Especially for the future, were more and more planes will be all-object, it’ll be a very important feature.
Well, even if I don’t count OBJ file variants which would call for a different acf file to be used, let me list just a few NOT flight model affecting cases only on the 757 aicraft:
3 possible fuselage base configuration (3 pax doors, 4 pax doors, freighter),
consequently numerous airline specific window plugs,
a minimum of 4 different antenna configurations (freighters don’t have directTV antennas, etc, etc),
3 different landing/taxi light configurations with obj lights placed somewhere on the nose gear assembly
…and I don’t even count the planned inclusion of an aircraft interior which obviously has to match the fuselage config.
So, for real flexibility and first and foremost, ease of use by the casual user/re-painter, overriding obj files is equally important if not more important than just replacing the textures.
Technically it would just be necessary to re-load the base acf file with the ‘livery’ modifications overriding their default counterparts.
After all this new feature is supposed to simplify custom modifications, improve the user experience and cut down disk space requirements.
🙂 p
Have to echo everything Pete posted above. Aircraft (airliners in particular) are notorious for having small, operator-specific differences between different variants of the same basic airframe. The ability to swap object files with liveries for such small trifles as antennas, doors, windows, and other bolt-on pieces would be a godsend. Without such functionality, for the most faithful depictions of their real-world counterparts, it’s still more practical for us to distribute one livery per model packages otherwise.
Hi Ben,
have you thought about this feature again? 😉
I really hope that we’ll see this feature in the near future.
We probably need a better discussion forum for this than my blog…Dennis has revisited this with me by email…and I think my short answer is:
Airliner configuration is a complex problem that is not solved very well by the current SDK. But…the livery system solves a DIFFERENT problem.
Adding objects to the livery system basically hijacks the livery system, in a way that _sort of_ solves configuration, but effectively removes the livery system.
(That is, this scheme gives authors a way to encode variations more orthogonally but makes third party repaints pretty much impossible.)