matsim-org/matsim-libs

When I run a minimal MATSim-Setup without pt and without setting scoring parameters for the pt-mode I get the error at the end of this issue. Adding an empty modeParams parameter set to the scoring config module removes the error. I find this behavior confusing, as I have to specify pt scoring parameters even if I don't want to include pt in my simulation. Should I do something about this? Also, is this intended behavior or a side-effect of something else? Additionally, the error message is super unhelpful. The config snippet to mitgate the error: <module name="scoring"> <parameterset type="scoringParameters"> <parameterset type="modeParams"> <param name="mode" value="pt"/> </parameterset> <!-- other scoring stuff --> </parameterset> </module> Stack Trace of the Error: 2026-08-20T12:33:50,846 FATAL ScoringConfigGroup$ScoringParameterSet:1413 this.getModes().get( TransportMode.pt ) returns null; cannot continue;

During the process of deprecating handleEvent in the ScoringFunction for #4611, I was able to retrofit most of the functionality in the freight contrib. Unfortunately, I was unable to fix the RunIT integration test in the shared-mobility contrib. The test collects statistics on a simulation run and then does assertions on them. For example, it counts the number of trips conducted during the simulation. While the test expects 115,802 trips, the result is now off by 5. I don't really know where to start searching for what has changed. Possibly someone with more expertise in share mobility can help here? @tschlenther , @sebhoerl , @marecabo

During the process of deprecating handleEvent in the ScoringFunction for #4611, I was able to retrofit most of the functionality in the freight contrib. Unfortunately, I was unable to fix one integration test. However, I think this test produced wrong results in the first place, as the architecture of the scoring function did not work correctly, as far as I could figure out. The scoring function factory was using a non-static inner class, to produce a scoring function. When used for multiple carriers, this would return the same scoring functions for different carriers. I have switched the architecture to (hopefully) work correctly now. Yet, the integration test would need to be adapted. Possibly, @kt86 or @rewertvsp or @kainagel can take on this task, or maybe this example is not necessary anymore.