16.12.2021, 9:00 - 11:00: Due to updates GitLab may be unavailable for some minutes between 09:00 and 11:00.

Commit e31feedc authored by Benedikt Kleinmeier's avatar Benedikt Kleinmeier
Browse files

Updated "CHANGELOG.md" according to v0.6.

Changelog entries were take from https://conwiki1.cc.private.hm.edu/confluence/display/FK07PD/VADERE+Change+Log
parent 6e6c893f
Pipeline #68323 canceled with stages
**Note:** Before writing into this file, read the guidelines in [Writing Changelog Entries.md](Documentation/contributing/Writing Changelog Entries.md).
# 0.6 (2018-09-07)
# v0.6 (2018-09-07)
# 0.2 (2016-12-22)
## Added
- Graphical simulation result is displayed in a table view to show run-time and overlap information if the corresponding processors are loaded. The Simulation result dialog can be deactivated in the preferences. (5ffca5a3: Simulator, GUI)
- Added new OutputProcessors for Overlaps. (8028c523: Simulator)
- Added "fixedSeed" and "simulationSeed" to AttributesSimulation. (79268262: Simulator)
- VadereConsole.jar migrate will migrate all scenario files within the specified directory and all child directories. (37fde165: Simulator)
* To exclude specific sub-trees or only specific directories the igonoreDirs List can be expanded.
* DO_NOT_MIGRATE or .DO_NOT_MIGRATE: Ignore current directory but continue with existing child directories.
* DO_NOT_MIGRATE_TREE or .DO_NOT_MIGRATE_TREE: Ignore the directories and the complete sub-tree.
- Added a new OutputProcessor, NumberOverlapsProcessor. This processor saves the number of overlaps that occurred during a simulation run. It needs the PedestrianOverlapProcessor. (57d90e93: Simulator, State)
- Added sub commands to "VadereConsole": project-run, scenario-run, suq, migrate (c7e0538c: GUI)
- In the onlinevisualization it is now possible to display the target potential field of a selected pedestrian. (123457aa: GUI)
## Changed
- PedestrianOverlapProcessor returns two values "distance", "overlaps"for each overlap detected. (5ffca5a3: Simulator)
* If no overlap occurs the output is empty.
* "distance": The distance between the center of the two pedestrians
* "overlaps": The amount the two pedestrian overlap
- Moved and renamed attributes in scenario files. (c7e0538c: State)
* Move /scenario/attributesModel/org.vadere.state.attributes.models.AttributesCGM/groupSizeDistribution to each source in /scenario/topography/sources/[]/groupSizeDistribution. This allows different group size distribution for each source
* Rename /scenario/attributesModel/*/timeCostAttributes/standardDerivation to standardDeviation.
## Performance
- Faster distance computation. (6214738c: Simulator)
* To compute the distance from a point x the closest obstacle we compute the distances on a Cartesian grid of cell size equal to the default value of AttributesFloorField.potentialFieldResolution. There are two methods to compute the distances.
* Brute force (default): Compute the distance for a grid point x by computing all distances (for all obstacles) taking the minimal
* Eikonal Equation solvers (unused): Use obstacles to be the targets are of the eikonal equation and solve the equation using one of the solvers (default is the Fast Marching Method).
# v0.2 (2016-12-22)
## Added
- Stability and usability improved, additional pedestrian simulation models are supported. (GUI, Simulator, State, Utils)
- Stability and usability improved, additional pedestrian simulation models are supported. (babf0b67: GUI, Simulator, State, Utils)
# 0.1 (2016-08-05)
# v0.1 (2016-08-05)
## Added
- Initial release of the software as open source. (GUI, Simulator, State, Utils)
- Initial release of the software as open source. (72391fab: GUI, Simulator, State, Utils)
......@@ -2,7 +2,7 @@
## Introduction
A good changelog entry should be descriptive and concise. It should explain the change to a reader who has *zero* context about the change. Each change should be categorized into on of the following types: `added`, `fixed`, `changed`, `deprecated`, `removed`, `security`, `performance` or `other`.
A good changelog entry should be descriptive and concise. It should explain the change to a reader who has *zero* context about the change. Each change should be categorized into on of the following types: `added`, `removed`, `changed`, `fixed`, `performance`, `security`, `deprecated` or `other`.
- **Bad:** Highlight agents.
- **Good:** In class `OnlineVisualization`, highlight the agent which was selected with left-mouse button.
......@@ -11,20 +11,26 @@ The first example doest not provide any context where the change was made or wha
## Writing into Changelog.md
1. Each new version number gets an own section prefixed with `#` and a date, e.g., `# 1.1 (2018-01-31)`.
1. Each new version number gets an own section prefixed with `#` and a date, e.g., `# v0.1 (2018-01-31)`.
Notes:
* Unreleased versions should be marked explicitly, e.g., ``# 1.1 (unreleased)`.
* Unreleased versions should be marked explicitly, e.g., `# 0.1 (unreleased)`.
* New versions should be added on top (and not at bottom).
2. Each change type gets an own subsection prefixed with `##`, e.g., `Added`.
3. Each change description should contain following parts:
3. Each changelog entry should contain following parts:
1. An own bullet point.
2. A list of affected simulator components: `Annotation`, `GUI`, `Simulator`, `State` or `Utils`.
2. The description of the change.
3. The commit hash.
4. The description of the change.
4. A list of affected simulator components: `Annotation`, `GUI`, `Simulator`, `State` or `Utils`.
5. Optional: More details as sub bullet points.
For instance:
- e8af1b77 Removed obsolete model attribute "foo" from class "bar". (State).
```
# v0.1 (2018-01-31)
## Removed
- Removed obsolete model attribute "foo" from class "bar". (e8af1b77: State).
* ...
* ...
```
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