Skip to content
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

[EPIC] UI: Parking Tool #47

Open
originalfoo opened this issue Feb 8, 2019 · 3 comments
Open

[EPIC] UI: Parking Tool #47

originalfoo opened this issue Feb 8, 2019 · 3 comments
Labels
EPIC Collation of related issues PARKING Feature: Parking AI / restrictions / etc UI User interface updates
Projects

Comments

@originalfoo
Copy link
Member

originalfoo commented Feb 8, 2019

Parking icons

When hovering an icon, associated lane should be highlighted. See #33.

Car parks

Update to Traffic info view:

By "parking spaces" I mean a place where car can park, regardless of whether that space is currently available or not. The value of '10' is just a guess, based on most growables having fewer than 10 parking spaces.

  • Red gradient buildings = cims struggling to find parking when travelling to that building
    • Existing functionality
  • White buildings = not enough parking to be considered a car park / no parking issues
  • Shades of green = buildings with 10+ parking areas are considered car parks:
    • Light green = Few spaces (>10)
    • ...gradient...
    • Dark green = Loads of parking spaces (>100, like this or this...)
  • Parking props from 'parking lot roads' should be treated as car parks despite only having few spaces
  • Possibly highlight normal parking lanes on roads if that's possible?
@originalfoo
Copy link
Member Author

originalfoo commented Feb 8, 2019

Park and Ride

EDIT: Instead of hub/spoke buildings turning blue, maybe use those 'sun shaft' lines that 'shine' out of the ground? Like on education info view where they're used to highlight active/inactive buildings for the selected info view tab.

With Parking tool active, click a building to select it. The Traffic info view is activated. The clicked building turns blue indicating it's selected. Let's call this building a hub:

  • A "lane connector" style line then connects mouse pointer to the hub.
  • User can then click on one or more other buildings to 'connect' them to the hub.
    • Let's call these spokes.
  • The spokes turn light blue; clicking them a second time will disconnect them from the hub

Once the user is done, they can right click to exit from the currently selected hub:

  • The spokes for that hub go back to their normal colours
  • The hub remains blue? (not sure about this; what if it is a red "can't find parking" building?)
  • User can now select another hub to work with.

It's a bit like on lane connector tool where you right-click out of a junction and then you can select a different junction to work with.

If the hub is a station, the spokes can be car parks: Places where cims will prefer to park before they ride at that station. If cims find those car parks full, they'll return to usual 'search nearest' approach.

If the hub is a RICO, or unique, or monument, or park, or park entrance, spokes can be car parks and/or stations.

Essentially user is defining "preferred stations" and "preferred car parks" for a given destination.

Use cases 1: Observatory

I have an observatory at the top of a hill, there's not much parking. I click the observatory (hub) and connect it to nearby cable car station (spoke). Now cims going to the observatory will try and use the route associated with the cable car. At the bottom of the hill, I connect a cable car station (hub) to a large car park and a rail station.

A cim wanting to get to observatory checks if it's a hub: It is! So they want the cable car, which means they either park in the car park or arrive via the train station.

Use case 2: Train station

Cims are struggling to find parking for a station (hub) so I connect it to some nearby carparks that might otherwise be overlooked by cims. Now cims doing park and ride use the preferred car parks for that station, leaving smaller car parks free for shoppers or residents.

Park and ride cims could, ideally, drive straight to the car park. Currently they drive to station and then start looking for parking; with new system they know where preferred parking is and drive to nearest parking.

When I'm driving IRL, I head to general vicinity of station but I'm looking for parking garages (either via road signs or satnav) and head for those.

Can pedestrian route between spoke and hub be cached?

As pedestrians will be using the route more, could caching that part of the journey help reduce pathfinder load?

For example, taking the use cases above:

  • Normal pathing to train station
  • Cached walk from train station to bottom cable car station
  • Normal routing to top cable car station
  • Cached walk from cable car station to observatory

Not the only route

We wouldn't want all drivers to use the hub/spoke system.

For example, people living half way up the hill aren't going to drive to the bottom, they'll just drive up the hill or look for nearest cable car station.

So there needs to be some extra logic in there that increases the chance of using the hub/spoke system depending on, say, route length? Also, it has to factor in preference of cims: car vs. PT

Reckless drivers would always head straight to their destination (eg. observatory or train station) and try and park local.

Validity checking

Would need to check viable route between a hub and its spokes.

Eg. For observatory: Can cims walk or cycle between the cable car station and the observatory? For lower cable car, can cims walk from the train station or car park? For train station, can they walk from the car park? etc.

@VictorPhilipp
Copy link
Collaborator

VictorPhilipp commented Mar 10, 2019

Regarding park & ride: What about an automated approach?

  1. Identify potential hubs (parking buildings placed by user, no RICO, at least X parking spaces). (*)
  2. Then, for every public transport station/stop, find all potential hubs in the vicinity.
  3. Check if there is a pedestrian path between the PT station and the potential hub. If yes: Mark potential hub as valid for the given PT station. If no: Mark potential hub as invalid for the given PT station
  4. During vehicle path-finding, if the path contains a PT station: Select a (random) valid hub for the first PT station from the path and perform another custom Parking AI path-find to make the car park at the hub.

(*) the player could help with this, as you have suggested

@originalfoo
Copy link
Member Author

Yes, automating good defaults would be desirable. However, as a player, I'd still want to be able to customise it (ie. it becomes a gameplay element).

@VictorPhilipp VictorPhilipp added the UI User interface updates label Mar 14, 2019
@originalfoo originalfoo changed the title UI: Parking Tool [EPIC] UI: Parking Tool Jul 26, 2019
@originalfoo originalfoo added the EPIC Collation of related issues label Jul 26, 2019
@originalfoo originalfoo added the PARKING Feature: Parking AI / restrictions / etc label Aug 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
EPIC Collation of related issues PARKING Feature: Parking AI / restrictions / etc UI User interface updates
Projects
Development

No branches or pull requests

2 participants