GitLab

+ MILPv2 now uses the actual route length instead of the euclidean distance
+ Setup the environments for the next evaluation step
+ Implemented the SpotUtilizationMetric

and corresponding necessities.

Merge nr/monitoring model into nr/monitoring-req-resp

See merge request !15

Merge nr/monitoring req resp into nr/monitoring-model

See merge request !14

Merge master into nr/monitoring-model

See merge request !13

Merge nr/res alloc clemens into nr/monitoring-req-resp

See merge request !12

~ HotspotDistribution would lead to massive (more as intended) clustering over simulation time.
~ SearchDistanceThreshold did not increase.

Merge Nr/res alloc clemens into nr/monitoring-req-resp

See merge request !10

Merge nr/monitoring-request-response into nr/resAlloc-clemens

See merge request !11

Merge Master into nr/resAlloc-clemens

See merge request !7

~ Settings of the world size were not employed correctly. Furthermore, setting a different zoom for the visualisation / map would fuck up the positioning.
Now the specified world size is used correctly. Zoom is used to specify the zoom level (detail) on the map. Positioning now works with different zoom levels, however, when visualising positions they now need to be scaled to be drawn correctly.

+ Made the node debug a standalone component similar to the Monitor class positioned properly inside the api and peerfact.
+ Added filtering capabilities
+ Added logging in some classes deep in the architecture the provide node information

~ Analyzer works now with the new structure
~ New positions are always added, old ones are kept.

Rework the plotting view to lay out the charts nicer.
Instead of scaling the charts down till they are not readable anymore, a minimum height is maintained and scrollbars are added instead.

quickFix to prevent adapter dirtNaps

See merge request !6

Prevent the MetricCDFAdapter from setting lower and upper bound of an
XYChart ValueAxis to zero.
This would cause a 'soft' crash of the GUI

Is the Overload case with 100% drop and high latency a potential source
for strange behavior or assures a 100% drop that alle msgs are really
dropped?

Merge Master into nr/monitoring-model

See merge request !4