Skip to content

Release 6 to 7 API Changes Overview

All Products

  • Main model configuration format is rtdcfg now. XML based configuration files are supported for backwards compatiblity.
    • Please contact RTDynamics if you need V7.0 compatible XML files of example configurations.
    • Rime can import old xml formats but saves rtdcfg only.
    • A utility application that can be used to batch convert XML’s to rtdcfg is provided.
  • Support for VC 2010 32 bit dropped
  • The behavior of entity constructors which use ConfigParams pointer directly changed. Previously the ConfigParams pointers were used directly by the entity but not deleted by it. Developers had to delete the pointer once it is not used anymore (after the entity is deleted).Now, the entities make a copy of ConfigParams object for themselves. The pointer provided to the constructor is not used by the entity after the construction. The copied params object is deleted automatically. The original ConfigParams must still be deleted manually but it can happen right after constructor. Also, since each entity makes its own copy, using the same ConfigParams pointer to initialize multiple entities is possible.Example:FixedWingLibCGF::AirplaneDynamics::ConfigParams*  configParams = new FixedWingLibCGF::AirplaneDynamics::ConfigParams();... set parameters in configParams ...// We create two airplanes now. Both make a copy of configParams
    myAirplane1 = FixedWingLibCGF::AirplaneDynamics( myWorld, "airplane1",
    configParams );
    myAirplane2 = FixedWingLibCGF::AirplaneDynamics( myWorld, "airplane2",
    configParams );// Now we can delete configParams; we don't have to wait
    // untilmyAirplane1 and
    myAirplane2 are deleted.
    delete configParams ;
  • RTD::World::reset() used to delete all world participants. Now users can choose between deleting and resetting. Also it is possible to define initial simulation time with an argument.
  • Fixed some const correctness issues in Serialization/Deserialization mechanism. Following method signatures have a const attribute now. If these methods are overriden, the signatures of the overriding code must be modified:RTD::SimulationVariableUser::serializeSimulationVariables()
    RTD::SimulationVAriableUser::serializeSimulationVariablesRec()
    SensorBase::serializeSimulationVariablesRec()
    EWLib::GuidanceDataLink::serializeSimulationVariablesRec()
    EWLib::GuidanceDataLink::serializeGuidanceDataQueue()    
  • Reflection feature introduced for all ConfigParam classes. Configuration parameters of all models can be enumarated and set via parameter names (strings). This feature is implemented to improve RIME’s modeling capabilities.
    • ConfigParams classes are nodes in a parameter tree hierarchy now. They have parents and children.
    • Indivudual parameters are leaves on this hierarchy and basic types and classes such as smReal, bool, smGraph2D are not used anymore. Instead special types such as ConfigParamReal, ConfogParamBool,      ConfigParamCurve are introduced (see ConfigParam.h for a full list)
    • Some configuration parameters are renamed in header files. Mostly the unit informations are removed from names and hence the new names are very similar to the previous ones. Please see the header files for updated parameter names.
    • Names of parameters remained the same in XML files. Example:
      m_bankToSpeedRatioDegPerKIAS member variable is renamed as m_bankToSpeedRatio but this parameter is still read as “bankToSpeedRatioDegPerKIAS” from XML files.
  • Developers who have developed their own models that contain ConfigParams classes need to update their implementation. Contact RTDynamics for technical support.
  • XML formats of MilitaryKinematicVehicle, MilitaryHelicopterDynamics and MilitaryAirplaneDynamics classes changed. Root node of the XML tree must reflect the class name now i.e. MilitaryHelicopterDynamics must have a     <MilitaryHelicopterDynamics> node in the beginning.
  • Changes related to ModelComponentBase class and developing custom models
    • Static methods ModelComponentBase::createClass and ModelComponentBase::createParameters renamed as createModelComponentInstance and createModelComponentParameterInstance. ModelComponentBase derived classes had same named static methods and forgetting to implement these in a new derived class lead to calling the static methods of the ModelComponentBase. This was not the intended behavior.
    • Static methods createClass and createParameters that are declared in all ModelComponentBase derived classes are renamed as createInstance and createParametersInstance. Their signature is also changed to avoid c-style casts within the library. These casts lead to type-unsafety and had the risk of hiding important bugs.
    • Model components are registered into RTD system including their namespaces now. E.g. ConstantRPMEngine was previously registered as “ConstantRPMEngine”, now it is “RTD::ConstantRPMEngine”. This can affect your code if ModelComponentBase::createClass or      ModelComponentBase::createParameters interfaces are used.XML format uses the class names only to identify models in the XML files. To allow backwards compatibility      ModelComponentBase::registerClass has a new argument, XMLTagName. Example:Previously ConstantRPMEngine would be registered as follows:
      RTD::ModelComponentBase::registerClass(           
      RTD::ConstantRPMEngine::getClassNameStatic(),
      [creator function] ,
      [params creator function] );RTD::ConstantRPMEngine::getClassNameStatic() returns simply “ConstantRPMEngine” and this is used in XML tags.After the changes the registration happens as follows:RTD::ModelComponentBase::registerClass(
      ClassName##::getNamespaceStatic()+"::"+ClassName##::getClassNameStatic(),                                          RTD::ConstantRPMEngine::getClassNameStatic(),
      [creator function] ,
      [params creator function] ) Class is registered as RTD::ConstantRPMEngine but the XML tag is registered as ConstantRPMEngine so that existing XML files work.
    • Following macros introduced to streamline and standardize the custom model development process. It is suggested to use these macros in ModelComponentBase derived classes to prevent programming errors at an early stage.
      • RTD_MODEL_COMPONENT_COMMON_DECL
        Used in class decleration of a new model
      • RTD_MODEL_COMPONENT_COMMON_IMPL_VEHICLE: Used in class implementation of a new model whose constructor accepts RTD::VehicleBase only.
      • RTD_MODEL_COMPONENT_COMMON_IMPL_ENTITY: Used in class implementation of a new model whose onstructor accepts RTD::EntityBase.
      • RTD_REGISTER_MODELCOMPONENT_CLASS:
        Used to register a new model component class. It is advised to use this macro instead of using registerClass directly.
    • VehicleBase::TrimCallback::update() signature changed. If a custom callback is implemented and this method overriden it may not be called anymore unless the signature is updated.
    • Changes in FGRotorBladeElement model
      • Removed some small angle assumptions from FGRotorBladeElement theory. This affects T,H and Y forces but is most effective on H and Y.
      • inducedVelocityThrustFactor parameter of blade element theory rotor model was applied twice ( i.e. as inducedVelocityThrustFactor*inducedVelocityThrustFactor ). Note that if you were using the default value (1.0) no change will be observed.

 RotorLib FDM

  • Support for GenHeli600 dropped
  • FGHeliFuselage200 was in RTD namespace instead of in RotorLibFDM namespace. This is fixed now.
  • The copy feature that allowed a stabilizer to copy another one using “copy” keyword in the XML is removed.

FixedWingLib CGF

  • Airbrake usage (m_useAirbrakes) is enabled by default in all maneuvers
  • Aircrafts follow their paths closer during Follow Route maneuver. Previously the Virtual pilot was turning towards the next waypoint but was not trying to get on the path between the waypoints.In the new implementation, Follow Route Controller, uses Basic Flight Controller as slave hence developers who have code to modify Follow Route behavior through slave parameters need to modify them. Example:
    Following was used to set the desired vertical speed of Follow Route maneuver:myAircraft->getVirtualPilot()->getPositionController()->
    m_dynParams.m_desiredVerticalSpeedFtMin = 5000.0f;
    Now this must be replaced as:myAircraft->getVirtualPilot()->getBasicFlightController()->
    m_dynParams.m_desiredVerticalSpeedFtMin = 5000.0f;
  • Added support for rotational wind including rotational component of turbulence. New parameters wingSpan, wingChord, rotationalWindRollCoeff, rotationalWindPitchCoeff and rotationalWindYawCoeff must be defined for a model so that rotatonal wind affects the aircraft.
  • AirplaneBot::setSpeedKtsCommon() was not taking effect for the entire route if the virtual pilot was executing a follow route maneuver. This is now fixed.
  • RTD::WaypointContinuationMode renamed as RTD::RouteContinuationMode
  • RTD::WaypointIndexDirection renamed as RTD::RouteTraversalDirection
  • FollowRouteController’s m_initialWPIndexDirection renamed as m_routeTraversalDirection

RotorLib CGF

  • Flight model improved so that the maximum rotor thrust of the helicopters reduces with altitude to simulate altitude dependent performance changes. Use thrustChangeWithAltitude=”false” on MainRotor and TailRotor sections of HelicopterDynamics configuration xml’s to obtain previous behavior.