From discussion: @BZoennchen @hm\-kleinmei * Find out what and where property files are read into Vadere (and actually used). Make a list and report files that seem irrelevant and seem subject to remove. * One example for a property file: the file `VadereGui/resources/config/global_config.properties` * Note: there can also be other file formats (not necessarily end with `.properties`) **Out aim is to centralise all "internal" properties (that are not given to the user)** * Create this new central properties file in `.ini` format; use the [ini4j](http://ini4j.sourceforge.net/download.html) package, maybe make a little research if there are better ones. * Translate all properties from properties (likely from different file formats) that are scattered in the Vadere project) into the new `.ini` format. * Read this new file into Vadere and define a class that returns the set options * Make this class globally accessible via a single object that is instantiated once via the [singleton pattern](https://javabeginners.de/Design_Patterns/Singleton_-Pattern.php) #### Current list of files that may contain relevant configutation See also `.java` files where there seem relevant global configs. One such file is the class * `DataProcessingJsonManager`, there are many `private static final` which are hard coded, but could be in a central spot. * `OutputFile` contains settings about further info in the column name. #### Current list of deprecated/unused setting files and locations n/a (TODO)