STAGEs are broadly similar to PAYLOAD *except* they constitute additional stages to your vessel. Most DLL-based craft won't unless they too are CVE-lite compatible, but most CFG-based vessels will quite happily. Not all vessels support the changing of their fuel state at creation, however. 'Fuellevel' is the level (0->1) of fuel you wish the spawned payload to be equipped with. 'Xrot' is now sadly abandoned due to a limitation in Orbiter's current API, simply put a zero (0) here. If you vary the loaded fuel (see later), you really ought to change this value here to be consistent. 'Mass' is the all-up-mass of the vessel that is to be created, INCLUDING fuel load. An example would be '0 0 4' for four metres along the centreline of the vessel. 'x', 'y' and 'z' represent floating point offsets from the launching vessel's reference point (normally the centre of mass) that the mesh should be drawn. 'Class' is the payload's classname, such as 'deltaglider' or 'module1'. 'Mesh' is the name of the mesh file, including any paths off ~/Mesh that will represent the payload on the stack before it is separated, minus the '.msh'

Here, 'payloadname' is simply the alphanumeric name you wish the created payload to have. PAYLOAD payloadname mesh class x y z mass xrot fuellevel Put simply GPDS allows users of CVE-lite compatible vessels to describe multiple payloads quickly and easily using the PAYLOAD tag in the scenario file. Since the release of CVEL v1.0, there have been a large number of vessels released that support the system including, of course, the original Ariane 5 updated to version 2.ДЄ beta library, including the Orbiter 2005 VESSEL2 class updates was compiled and added to the downloads section of the CVEL website, and is considered by most to be stable for the current implementation of Orbiter.

Vessels that didn't support CVELmessage simply never receive the information.

This enabled CVEL vessels to communicate not only with other CVEL vessels for the purposes of exchanging payload information, but to any other vessel about any information without requiring crash protection. Dropping some of the features of CVE for a closer release date and quicker debugging.Д¬rucially, CVEL also removed the need for vessels to all be compiled with the same library by introducing the messenger DLL cvelmessage.dll. CVE-lite was an attempt to distill CVE into a lighter, more easily integratable system. Unfortunately, CVE was also limited to interacting successfully only with other CVE vessels of the same library vintage, and the impressively complex library was slow to debug. So was born COMMON_VESSEL_EX (CVE) which iterated through several beta variations building up an impressive array of supported vessels. This included standardised mesh handling classes and an extensible GPDS handler. Something needed to be done.Дave Rowbotham proposed extending the COMMON_VESSEL class to provide even more functionality. The problem with this system (based on Rob Conley's COMMON_VESSEL class) was that, using C++ callbacks, calls between vessels compiled with different libraries would cause a crash. to allow the Ariane 5 to tell the Fregat it should have a Probe attached). This was not ideal and so an Inter-Vessel Payload Description interface was developed to allow communication between 'active' vessels (ie. The two would necessarily have to jettison as separate vessels. That is to say one couldn't mount an upper stage (eg. It quickly became clear that combinations of payloads couldn't be specified. GPDS was conceived as a way to mount a payload of the end user's choice atop the Ariane 5 as it was developed from a Vinka Multistage vessel to a standalone DLL.

3.4 MarsExpress probe on a fregat and star48 upper stages.

3.3 Two Module-2s, each with their own CVE-lite fregat.

3.1 One Module-1 aboard a Proton-K from Baikonur.

Soyuz orbiter addons