Hello
Please allow me two quick corrections / clarifications about some past posts regarding Vinka's cool multistage2.dll capabilities, eventual limitations and eventual ways of working around some issues:
1) It *IS* possible for multistage2.dll powered launchers to perfectly support docking port definitions (and quite a few other nice extras)… I have been using such ‘strategies’ on my development files for years! All what is needed (in this case, for docking ports) is to add the proper port definition in the configuration file that acts as bridge between the INI file and the multistage2.dll (I recommend creating a specific launcher configuration file with that and other eventual ‘extras’ instead of using the default cfg file).
2) Although multistage2.dll, by default, does not take in account the atmospheric pressure impact on thrust / ISP of a rocket stage (Vinka was planning that and other goodies for a future multistage3.dll but from some time now that do not know anything about the author) it is also truth that the implementation of the multistage2.dll performance can be worked in order to roughly obtain a more realistic representation of the stage / booster / overall rocket performance while being in the lower and denser parts of a planet’s atmosphere…
This can be done by properly using already available multistage2.dll features such as calibrated thrust curve definitions (for the planet you are launching from) and/or automatic guidance inputs (for variation of thrust levels / rates of propellants consumptions) and/or by paying more attention to the definition of thrust / burn times definitions and/or burnout masses all that vs ascent pitch program, etc, etc, etc…
In addition, there are also a number of ascent ‘ground rules’ that can be included in the simulation (guidance constraints, maxQ/g limits, burnout masses, jettison events parameters, performance reserves, boil-off simulation, etc) that can contribute for a much better and realistic simulation… even with multistage2.dll (in comparison with not using such rules or with not taking some care when implementing the numbers).
Happy development,
António
PS: Being that the files were referenced in this thread, and speaking only for myself, see that some of my past AresI work (3D files, textures, performance implementation) have been used on other addons apparently without someone having the courtesy of contacting or referencing me (CEV-Orion Correct assembly by Alcione, CEV-Orion Upgrade by columbia42)… I know that have not been particularly active all these years/months but would appreciate that in future occasions such does not happen… Among other things, it is kind of against the spirit of my ‘conditions of use’, makes a number of the same files being scattered around and becomes more difficult when I wish to update my own files… I have nothing against improvements to my or to others works... Just saying that there could exist other ways of doing so... instead of simply grab files and republishing them without 'control'... (imagine everyone does the same!)
see attachment)
