-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(spawning): functionality for spawning parking vehicles #354
Conversation
…h phabmacs because vehicle types have not been used previously
@@ -412,6 +413,8 @@ private void completeSpawnerDefinitions() { | |||
VehicleTypesInitialization generateVehicleTypesInitialization() { | |||
HashMap<String, VehicleType> types = new HashMap<>(); | |||
|
|||
// TODO maybe find a better solution, this is just a first test to see if anything breaks | |||
prototypeConfigurations.forEach(p -> types.put(p.name, new VehicleTypeSpawner(p).convertType())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@FunKuchen Main problem now comes with predefined SUMO scenarios which cause the failing tests. When we use predefined SUMO scenarios which bring their own vehicle type definitions, we explicitly forbid that a vehicle spawner in mapping_config.json uses a vehicle type which is already defined in the loaded SUMO scenario. The main problem is, that we cannot know from SumoAmbassador perspective which vehicle types are configured in these predefined scenarios. Therefore even merging them somehow would be very difficult, because you'd need to parse all loaded route files and also additional files for vehicle type definitions. So we may need to find a better solution I guess. However, my goal was to see if anything breaks with this line, and luckily we found this already with our integration tests!
A quick (and not so clean) solution would be to add a new property in the MappingConfiguration class called propagateAllTypes
which we set to false
in the default case, and only do this line of code when this new property is set to true
. As an alternative we could completely close this PR and see if we could fix the problem of missing prototypes in the PHABMACS federate somehow differently. As a third option we could go the full route of defining parking vehicles in the mapping configuration. However, this would require some additional discussions. Therefore we may go the proposed "quick'n'dirty' path and try to find a clean solution in follow up work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you somehow revert just this commit but keep everything else? The changed tests now fail again and have to be reverted to the old ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd just close this PR and you'd switch to main as we don't need any changes, do we?
No required anymore |
Description
This pull request adds necessary functionality that allows phabmacs to spawn vehicles anywhere on a map. For this new feature it became necessary that all in the mapping configured prototypes are also converted and saved as vehicle types.
Unit Tests that then failed because of this new implementation have been adjusted.
Issue(s) related to this PR
Affected parts of the online documentation
No changes in online documentation required.
Definition of Done
Prerequisites
Required
type(scope): description
(in the style of Conventional Commits)enhancement
, orbugfix
)origin/main
has been merged into your Fork.Requested (can be enforced by maintainers)
Special notes to reviewer