Commit 218372db authored by David Weiß's avatar David Weiß Committed by Reinhard Biegel
Browse files

mod(openPASS): Rename inappropriate terms 'master' and 'slave'

This commit removes racially-charged language from openPASS by replacing
`master` with opSimulationManager and 'slave' with `opSimulation` (and
similar terms).

Closes
#25

Also-by: René Paris's avatarRene Paris <rene.paris@in-tech.com>
Signed-off-by: David Weiß's avatarWeiss David <david.weiss@in-tech.com>
Signed-off-by: Reinhard Biegel's avatarReinhard Biegel <reinhard.biegel@in-tech.com>
parent 2314ca89
......@@ -31,7 +31,7 @@ The sim@openpass source code can be found [here](https://gitlab.eclipse.org/ecli
To build the project, follow the guide in "pathToRepo\sim\doc\OSI World Setup Guide.pdf".
The branch 'servant' contains the contributions that will be included in the next release. The branch ‘master’ contains the latest stable release.
The branch 'servant' contains the contributions that will be included in the next release. The 'main' branch contains the latest stable release.
### Committer contribution process
......
......@@ -6,7 +6,9 @@ The software suite of openPASS started as a set of stand-alone applications, whi
# Where to get it
As the program is still under development and is extended continuously, we advice you to use the latest sources from our [GitLab repository](https://gitlab.eclipse.org/eclipse/simopenpass/simopenpass). Please download from the master branch which contains the most stable and recent openPASS version. The servant branch contains current developments which are planned to be pushed to the master branch after a comprehensive review by the openPASS Working Group.
As the program is still under development and is extended continuously, we advice you to use the latest sources from our [GitLab repository](https://gitlab.eclipse.org/eclipse/simopenpass/simopenpass).
The `main` branch contains the most stable and recent openPASS version.
The `develop` branch contains current developments which are planned to be pushed to the main branch after a comprehensive review by the openPASS Working Group.
# Installation
An installation guide can be found [here](https://www.eclipse.org/simopenpass/content/html/index.html).
......@@ -39,7 +41,7 @@ OpenPASS can calculate Time-To-Collision (TTC) and Time-To-Headway (THW). The ou
6. __Which probability distributions for parameter variations can be used in openPASS?__
Parameters can either be simple or stochastic. Simple parameters only have one value, while stochastic parameters have a minimum and maximum value as well as distribution specific parameters. If a parameter is stochastic, a distribution can be choosen from [this list](https://gitlab.eclipse.org/eclipse/simopenpass/simopenpass/-/blob/servant/sim/src/core/slave/modules/Stochastics/stochastics_implementation.h). In future (with OpenSCENARIO 1.1) the number of distributions will be extended.
Parameters can either be simple or stochastic. Simple parameters only have one value, while stochastic parameters have a minimum and maximum value as well as distribution specific parameters. If a parameter is stochastic, a distribution can be choosen from [this list](https://gitlab.eclipse.org/eclipse/simopenpass/simopenpass/-/blob/servant/sim/src/core/opSimulation/modules/Stochastics/stochastics_implementation.h). In future (with OpenSCENARIO 1.1) the number of distributions will be extended.
# Contact
......
......@@ -9,33 +9,33 @@
SPDX-License-Identifier: EPL-2.0
************************************************************
.. _slave:
.. _simulation:
Slave
Simulation
==========
.. _slave_commandlinearguments:
.. _simulation_commandlinearguments:
Command Line Arguments
-----------------------
The slave can be configured by applying the following command line arguments.
The simulation can be configured by applying the following command line arguments.
Unspecified arguments will be defaulted (*default values in []*).
The slave supports the following arguments:
The simulation supports the following arguments:
* *--logLevel* [0] :
Logging level between 0 (minimum) and 5 (maximum - debug core)
* *--logFile* [OpenPassSlave.log]* :
* *--logFile* [opSimulation.log]* :
Name of the log file
* *--lib* [lib] :
* *--lib* [modules] :
Path of the libraries (relative or absolute)
* *--configs* [configs] :
Path for writing outputs (relative or absolute)
* *--results* [results] :
Path for writing outputs (relative or absolute)
.. _slave_scheduler:
.. _simulation_scheduler:
Scheduler
---------
......
......@@ -193,7 +193,7 @@ When using the debugging functionality, the according executable will be execute
- This is acceptable for unit test, which do not require openPASS specific libraries.
The corresponding config is ``CMake Target``.
- For the core, located at ``./build/sim/src/core/slave/OpenPassSlave``, this does not work, as no libraries and no configurations are available.
- For the core, located at ``./build/sim/src/core/opSimulation/opSimulation``, this does not work, as no libraries and no configurations are available.
As a solution, a second debug target ``opsimulation`` points at the installed executable instead.
.. warning:: Don't forget to run the target ``install`` before debugging .
......
......@@ -21,11 +21,11 @@
]
},
{
// FOR DEBUGGING OpenPassSlave (DON'T FORGET TO CALL make install)
// FOR DEBUGGING opSimulation (DON'T FORGET TO CALL make install)
"name": "opsimulation",
"type": "cppdbg",
"request": "launch",
"program": "/openPASS/bin/core/OpenPassSlave",
"program": "/openPASS/bin/core/opSimulation",
"args": [],
"stopAtEntry": false,
"cwd": "/openPASS/bin/core/",
......@@ -40,4 +40,4 @@
]
}
]
}
\ No newline at end of file
}
......@@ -28,11 +28,11 @@
]
},
{
// FOR DEBUGGING OpenPassSlave (DON'T FORGET TO CALL make install)
// FOR DEBUGGING opSimulation (DON'T FORGET TO CALL make install)
"name": "opsimulation",
"type": "cppdbg",
"request": "launch",
"program": "C:\\OpenPASS\\bin\\core\\OpenPassSlave.exe",
"program": "C:\\OpenPASS\\bin\\core\\opSimulation.exe",
"args": [],
"stopAtEntry": false,
"cwd": "C:\\OpenPASS\\bin\\core",
......@@ -54,4 +54,4 @@
]
}
]
}
\ No newline at end of file
}
......@@ -70,12 +70,12 @@ The above directory structure will be created by following the instructions of t
cd ~
git clone https://gitlab.eclipse.org/eclipse/simopenpass/simopenpass.git
#. Navigate into repository and checkout master branch
#. Navigate into repository and checkout main branch
.. code-block::
cd simopenpass
git checkout master
git checkout main
#. Create directory structure
......
......@@ -151,7 +151,7 @@ USE_CCACHE
WITH_SIMCORE
------------
- Build OSI based scenario simulation, also know as openPASS core (slave).
- Build OSI based scenario simulation, also know as openPASS simulation core (opSimulation).
- Options: OFF | **ON**
WITH_DOC
......@@ -268,7 +268,7 @@ INSTALL_EXTRA_RUNTIME_DEPS
Make Targets/Commands
---------------------
|Op| defines build targets by major modules or components, such as ``OpenPassSlave`` or ``Algorithm_FmuWrapper``.
|Op| defines build targets by major modules or components, such as ``opSimulation`` or ``Algorithm_FmuWrapper``.
After calling CMake, simply build |op| by calling ``make``.
.. admonition:: See also
......@@ -298,4 +298,4 @@ Executing Tests
~~~~~~~~~~~~~~~
- All tests: ``make test ARGS="--output-on-failure -j3"``
- Single test: ``make test OpenPassSlave_Tests ARGS="--output-on-failure -j3"``
- Single test: ``make test opSimulation_Tests ARGS="--output-on-failure -j3"``
......@@ -106,7 +106,7 @@ The input is focused around the following files, with decreasing importance for
Historically, the referenced files have carry an additional *Model* in the filename: ``VehicleModelsCatalog.xosc`` and ``PedestrianModelsCatalog.xosc``
- **SlaveConfig** (``slaveConfig.xml``)
- **SimulationConfig** (``simulationConfig.xml``)
This is the entry point for the simulation, containing the setup of the core, such as active observers, reference to the scenario, the initial random seed, and the number or invocations.
......@@ -136,7 +136,7 @@ This helps to keep experiments separated.
Outputs
^^^^^^^
Outputs are generated by individual observers, configured by the **SlaveConfig**, and collected within the folder `results`.
Outputs are generated by individual observers, configured by the **SimulationConfig**, and collected within the folder `results`.
This section describes the output files by the :ref:`observation_log`, as configured by the provided example configurations.
Please refer to the documentation of the individual observers and files for more details.
......@@ -158,6 +158,6 @@ Please refer to the documentation of the individual observers and files for more
.. note::
The core generates a file called ``LogSlave.txt`` at the execution path, which logs errors and warnings.
The core generates a file called ``opSimulation.log`` at the execution path, which logs errors and warnings.
If the simulation behaves strange or did not produce any output, check this file.
......@@ -293,7 +293,7 @@ For details on the indivual parameters see the :ref:`components reference <compo
SpawnerProfile ProfileGroup
---------------------------
This sections contains all parameters of the spawners referenced in the :ref:`slaveconfig`.
This sections contains all parameters of the spawners referenced in the :ref:`simulationconfig`.
For details on the indivual parameters see the :ref:`components reference <components_spawner>`.
.. code-block:: xml
......@@ -312,7 +312,7 @@ TrafficRules ProfileGroup
-------------------------
This sections contains the global traffic rules, that may vary depending on the country.
The :ref:`slaveconfig_environment` section in the SlaveConfig defines which set is used.
The :ref:`simulationconfig_environment` section in the SimulationConfig defines which set is used.
Currently there are only rules regulating highway traffic. These are the following:
+---------------------------+---------+---------------------------------------------------------------------------------------------------------------------+
......
......@@ -9,40 +9,40 @@
SPDX-License-Identifier: EPL-2.0
************************************************************
.. _slaveconfig:
.. _simulationconfig:
SlaveConfig
===========
SimulationConfig
================
.. todo: Write a nicer introduction for the slaveconfig, similar to "Overview" section in scenery
.. todo: Write a nicer introduction for the simulationconfig, similar to "Overview" section in scenery
This file describes the user configurable parameters of an experiment.
Several parameters depend on probabilities.
Each invocation then rolls for said probabilities.
All probabilities need to add up to 1.0.
The slaveConfig.xml consists of the following sections:
The simulationConfig.xml consists of the following sections:
* :ref:`slaveconfig_profilescatalog`
* :ref:`slaveconfig_experiment`
* :ref:`slaveconfig_scenario`
* :ref:`slaveconfig_environment`
* :ref:`slaveconfig_observations`
* :ref:`slaveconfig_spawners`
* :ref:`simulationconfig_profilescatalog`
* :ref:`simulationconfig_experiment`
* :ref:`simulationconfig_scenario`
* :ref:`simulationconfig_environment`
* :ref:`simulationconfig_observations`
* :ref:`simulationconfig_spawners`
.. _slaveconfig_profilescatalog:
.. _simulationconfig_profilescatalog:
ProfilesCatalog
---------------
Specifies the :ref:`profilescatalog` for the experiment.
.. literalinclude:: @OP_REL_SIM@/contrib/examples/Common/slaveConfig.xml
.. literalinclude:: @OP_REL_SIM@/contrib/examples/Common/simulationConfig.xml
:language: xml
:start-at: <ProfilesCatalog>
:end-at: </ProfilesCatalog>
.. _slaveconfig_experiment:
.. _simulationconfig_experiment:
Experiment
----------
......@@ -64,12 +64,12 @@ Specifies the general experiment setup, not specific to a single invocation.
If not specified the default name is assumed. yes
===================== ================================================== =========
.. literalinclude:: @OP_REL_SIM@/contrib/examples/Common/slaveConfig.xml
.. literalinclude:: @OP_REL_SIM@/contrib/examples/Common/simulationConfig.xml
:language: xml
:start-at: <Experiment>
:end-at: </Experiment>
.. _slaveconfig_scenario:
.. _simulationconfig_scenario:
Scenario
--------
......@@ -89,12 +89,12 @@ This section contains information about the scenario setup for the experiment. T
This experiment uses the "HighwayScenario.xosc" scenario file.
.. literalinclude:: @OP_REL_SIM@/contrib/examples/Common/slaveConfig.xml
.. literalinclude:: @OP_REL_SIM@/contrib/examples/Common/simulationConfig.xml
:language: xml
:start-at: <Scenario>
:end-at: </Scenario>
.. _slaveconfig_environment:
.. _simulationconfig_environment:
Environment
-----------
......@@ -122,12 +122,12 @@ In 70% of all invocation drivers can see 125 meter and for the other 30% of invo
Every invocation has a friction of 0.3.
Every invocation has sunny weather.
.. literalinclude:: @OP_REL_SIM@/contrib/examples/Common/slaveConfig.xml
.. literalinclude:: @OP_REL_SIM@/contrib/examples/Common/simulationConfig.xml
:language: xml
:start-at: <Environment>
:end-at: </Environment>
.. _slaveconfig_observations:
.. _simulationconfig_observations:
Observations
------------
......@@ -164,7 +164,7 @@ Please refer to the documentation of the individual observers for available para
../outputs/*
.. _slaveconfig_spawners:
.. _simulationconfig_spawners:
Spawners
--------
......@@ -174,7 +174,7 @@ The same library can be loaded multiple times with different profiles.
A spawner is either of type "PreRun", meaning it is triggered only once at the start of the simulation, or "Runtime", meaning it is triggered in every timestep.
If different spawners are to be triggered at the same time the spawner with the highest priority is triggered first.
.. literalinclude:: @OP_REL_SIM@/contrib/examples/Common/slaveConfig.xml
.. literalinclude:: @OP_REL_SIM@/contrib/examples/Common/simulationConfig.xml
:language: xml
:start-at: <Spawners>
:end-at: </Spawners>
......@@ -183,7 +183,7 @@ If different spawners are to be triggered at the same time the spawner with the
Full Example
------------
.. literalinclude:: @OP_REL_SIM@/contrib/examples/Common/slaveConfig.xml
.. literalinclude:: @OP_REL_SIM@/contrib/examples/Common/simulationConfig.xml
:language: xml
:caption: slaveConfig.xodr
:caption: simulationConfig.xml
:linenos:
......@@ -21,8 +21,8 @@ The Project Plugin can be used to simply start a simulation from the gui.
.. image:: _static/images/plugin/project/overview.png
Before the simulation adjustments begin, the user is obligated to load or create a “Master Configuration” (masterConfig).
A Master Configuration in openPASS can be understood as a project.
Before the simulation adjustments begin, the user is obligated to load or create a “Simulation Manager Configuration” (`opSimulationManager.xml`).
Such a configuration in openPASS can be understood as a project.
It is a XML-File which get inscribed the path settings and simulation settings after you click **SAVE**.
General
......@@ -30,7 +30,7 @@ General
.. image:: _static/images/plugin/project/general.png
In this segment you are able to name the Master Configuration. In our example it is called *MasterConfigurationNo1*.
In this segment you are able to name the Simulation Manager Configuration.
Path Settings
-------------
......@@ -45,7 +45,7 @@ On to the settings.
As you can see three paths need to be set.
The library comes with openPASS.
There are plans to remove the option for the user to set the library path, but at this moment there is still the option to change it, although this is not recommended.
The Slave Path references the OpenPassSlave.exe, the file to execute the slave.
The Simulation Path references the opSimulation.exe, the file to execute the simulation.
If you are using the provided Demo, there is no need for you to change it.
The only path you need to set is the path of the Configuration Files.
In the Demo it will be located at ``[directory of openPASS.exe]/configs``, so in this case it would be ``C:/OpenPASS/configs``.
......@@ -55,11 +55,11 @@ Simulation Output Settings
.. image:: _static/images/plugin/project/simOutputSettings.png
Next step is the Simulation Output Settings. There are three output files. First is the log file of the master.
However, when simulation jobs are started by the GUI, the openPASS master is not executed and, hence, the master log will not contain any log entries.
Second is the log file created by the slave. In this log file you will find error messages, actions of the slave etc. depending on the log level.
Next step is the Simulation Output Settings. There are three output files. First is the log file of the simulation manager.
However, when simulation jobs are started by the GUI, the openPASS simulation manager is not executed and, hence, the log will not contain any entries.
Second is the log file created by the simulation. In this log file you will find error messages, actions of the simulation etc. depending on the log level.
The Log level lets you choose which type of messages are logged. “0” means that only errors are logged,
whereas the highest log level of “5” leads to the most detailed description of which steps are executed by the slave.
whereas the highest log level of “5” leads to the most detailed description of which steps are executed by the simulation.
The results path specifies the folder in which the results of a successful simulation will be saved.
.. note::
......
......@@ -20,7 +20,7 @@ This file is also a XML-file and specifies the components of an agent and system
The editing of the System Configuration has two modes: the static and dynamic mode.
The **static mode** requires the user to build a complete system which includes sensors, algorithms and actions.
As the actions directly manipulate the simulated vehicle’s parameters, which are the same no matter the system (i.e. gas pedal position, braking pedal position, steering wheel angle), there is no need to code the interaction between system and slave.
As the actions directly manipulate the simulated vehicle’s parameters, which are the same no matter the system (i.e. gas pedal position, braking pedal position, steering wheel angle), there is no need to code the interaction between system and simulation.
At this point there is no support for supporting statistical inclusion of systems in the static mode.
The current demo only provides an example for the static mode (a System Configuration of an agent to follow a PCM trajectory), so make sure you have the static mode selected.
......
......@@ -68,7 +68,7 @@ Please refer to the individual components, for information about their published
**Example**
.. literalinclude:: @OP_REL_SIM@/contrib/examples/Common/slaveConfig.xml
.. literalinclude:: @OP_REL_SIM@/contrib/examples/Common/simulationConfig.xml
:language: xml
:start-at: <Library>Observation_Log</Library>
:end-at: </Parameters>
......
......@@ -45,7 +45,7 @@ Following parameters are supported:
**Example**
.. literalinclude:: @OP_REL_SIM@/contrib/examples/Common/slaveConfig.xml
.. literalinclude:: @OP_REL_SIM@/contrib/examples/Common/simulationConfig.xml
:language: xml
:start-at: <Library>Observation_EntityRepository</Library>
:end-at: </Parameters>
......
......@@ -42,7 +42,7 @@ Thus, an existing simulation configuration is used and the simulation is started
└── examples
└── lib
│ ...
└── OpenPassSlave.exe
└── opSimulation.exe
#. Create a new folder named "configs" for the configuration files within the |op| install directory
......@@ -78,7 +78,7 @@ Thus, an existing simulation configuration is used and the simulation is started
├── ProfilesCatalog.xml
├── Scenario.xosc
├── SceneryConfiguration.xodr
├── slaveConfig.xml
├── simulationConfig.xml
├── systemConfigBlueprint.xml
└── VehicleModelsCatalog.xosc
......@@ -97,17 +97,17 @@ Thus, an existing simulation configuration is used and the simulation is started
* The trajectory that defines the cut-in maneuver of the scenario agent is defined and editable here.
* The overall simulation time, which determines the end condition of the simulation in seconds, can be adjusted.
c. ``slaveConfig.xml``:
c. ``simulationConfig.xml``:
* The number of invocations can be changed in case more than one run is desired to be simulated. This will incorporate stochastic variation (i.e. initial constellation of surrounding traffic)
* If surrounding traffic is not desired in the experiment, the spawner libraries "SpawnPointPreRunCommon" and "SpawnPointRuntimeCommon" can be deactivated by removing the corresponding sections. Only the "SpawnPointScenario" is mandatory to spawn the ego and scenario agent. More information on the functionality of spawners can be found in :ref:`components_spawner`.
* The output format can be modified by setting the parameter "LoggingCyclicsToCsv" to true.
#. Start the simulation by double-clicking ``OpenPassSlave.exe`` or from the console by calling the executable.
#. Start the simulation by double-clicking ``opSimulation.exe`` or from the console by calling the executable.
#. Once the simulation is successfully completed, the following results can be found in the directory ``results``:
* ``simulationOutput.xml``: Contains general information about the experiment and an overview on all agents from the simulation. Further, an event log is contained. If the csv-output is set to false in the ``slaveConfig.xml``, the ``simulationOutput.xml`` will also include the „cyclics” (state in each time step) of the simulation.
* ``simulationOutput.xml``: Contains general information about the experiment and an overview on all agents from the simulation. Further, an event log is contained. If the csv-output is set to false in the ``simulationConfig.xml``, the ``simulationOutput.xml`` will also include the „cyclics” (state in each time step) of the simulation.
* ``Cyclics_Run_xxx.csv``: In case the csv-output is activated, the „cyclics” of each run in the simulation are logged to a separated csv-file. This file is missing, if "cyclics" are written directly to the ``simulationOutput.xml`` (i.e. when "LoggingCyclicsToCsv" is set to false).
* ``Repository_Run_xxx.csv``: Overview of the agents and objects from the simulation as well as some details on scenery components like lane markings, guard rails, etc.
......@@ -19,21 +19,21 @@
static constexpr char DIRNAME_CASE_RESULTS[] = "results";
static constexpr char FILENAME_SLAVE_CONFIG[] = "slaveConfig.xml";
static constexpr char FILENAME_SIMULATION_CONFIG[] = "simulationConfig.xml";
static constexpr char FILENAME_SYSTEM_CONFIG[] = "SystemConfig.xml";
static constexpr char FILENAME_SCENERY_CONFIG[] = "sceneryConfiguration.xml";
static constexpr char FILENAME_PARKING_CONFIG[] = "SceneryConfiguration.xodr";
static constexpr char FILENAME_SCENARIO_CONFIG[] = "Scenario.xosc";
static constexpr char FILENAME_PROFILES_CONFIG[] = "ProfilesCatalog.xml";
static constexpr char FILENAME_MODELS_CONFIG[] = "VehicleModelsCatalog.xosc";
static constexpr char FILENAME_FRAMEWORK_CONFIG[] = "masterConfig.xml";
static constexpr char FILENAME_FRAMEWORK_CONFIG[] = "opSimulationManager.xml";
static constexpr char FILENAME_OPENPASSSLAVE_EXE[] = "OpenPassSlave.exe";
static constexpr char FILENAME_OPENPASSMASTER_EXE[] = "OpenPassMaster.exe";
static constexpr char FILENAME_OPENPASSSIMULATION_EXE[] = "opSimulation.exe";
static constexpr char FILENAME_OPSIMULATIONMANAGER_EXE[] = "opSimulationManager.exe";
static constexpr char FILENAME_OPENPASSSLAVE_LOG[] = "OpenPassSlave.log";
static constexpr char FILENAME_OPENPASSSLAVE_CONFIGS[] = "configs";
static constexpr char ILENAME_OPENPASSMASTER_LOG[] = "OpenPassMaster.log";
static constexpr char FILENAME_OPENPASSSIMULATION_LOG[] = "opSimulation.log";
static constexpr char FILENAME_OPENPASSSIMULATION_CONFIGS[] = "configs";
static constexpr char FILENAME_OPSIMULATIONMANAGER_LOG[] = "opSimulationManager.log";
static constexpr char REGEX_CASE_NUMBER[] = "\\d*";
static constexpr char REGEX_CASE_SYSTEM[] = "\\d\\-\\d\\-\\d";
......
......@@ -13,7 +13,7 @@
//! @ingroup agentConfigurationPlugin
//! @brief This class defines a presenter object for exporting the model data
//! (AgentConfigurationInterface) of this plugin to the profiles catalogue
//! XML file needed by the simulation slave.
//! XML file needed by the simulation.
//!
//! The only reason why this class exists is because, for a dynamic agent
//! profile, the profiles catalogue partly repeats information already
......@@ -44,7 +44,7 @@
//-----------------------------------------------------------------------------
//! @brief This class defines a presenter object for exporting the model data
//! (AgentConfigurationInterface) of this plugin to the profiles catalogue
//! XML file needed by the simulation slave.
//! XML file needed by the simulation.
//!
//! The only reason why this class exists is because, for a dynamic agent
//! profile, the profiles catalogue partly repeats information already
......
......@@ -142,7 +142,7 @@ void VehicleProfilesPresenter::refreshSystemConfig()
vehicleProfilesView->setSystemProfileSelection(systemList.keys());
if (!QFileInfo::exists(project->absoluteToConfigPath(filepath)))
vehicleProfilesView->setSystemConfigError("System Config not accessible! Check configuration path in Master Configuration.");
vehicleProfilesView->setSystemConfigError("System Config not accessible! Check configuration path in opSimulationManager.xml.");
// check whether systems in current profile exist in systemConfig (systemList)
if (!systemsConsistent())
......@@ -274,7 +274,7 @@ void VehicleProfilesPresenter::refreshModelCatalogue()
if (!QFileInfo::exists(project->absoluteToConfigPath(modelCatalogue)))
{
vehicleProfilesView->setModelCatalogueError("Model catalogue not accessible! Check configuration path in Master Configuration.");
vehicleProfilesView->setModelCatalogueError("Model catalogue not accessible! Check configuration path in opSimulationManager.xml.");
vehicleProfilesView->enableModelView(false);
return;
}
......
......@@ -80,7 +80,7 @@ void ModelPcm_Eval::OnSelectionChanged(const QItemSelection &selected,
}
}
}
QString sceneryFile = caseSystemVarFolder + "/" + FILENAME_OPENPASSSLAVE_CONFIGS + "/" + FILENAME_SCENERY_CONFIG;
QString sceneryFile = caseSystemVarFolder + "/" + FILENAME_OPENPASSSIMULATION_CONFIGS + "/" + FILENAME_SCENERY_CONFIG;
LoadSceneryData(sceneryFile);
}
}
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment