CitiesSkylinesMods / TMPE

Cities: Skylines Traffic Manager: President Edition
https://steamcommunity.com/sharedfiles/filedetails/?id=1637663252
MIT License
577 stars 85 forks source link

Update signs, props, etc., to reflect road customisations #49

Open originalfoo opened 5 years ago

originalfoo commented 5 years ago

See also: https://github.com/krzychu124/Cities-Skylines-Traffic-Manager-President-Edition/issues/124

Been pondering this for a while, I think the only way to achieve it would be mini "add-on mods" that tell TMPE, for a given road asset (or collection of assets), details about the road speed signs.


TMPE would come with a default list of vanilla speed signs; for any roads that aren't part of a roadcollection, TMPE will try vanilla sign.

However, any roads using custom signage will have to provide the definition file that tells TMPE about the custom signs.

A template mod would be provided for asset authors (or users who use roads by other authors and want to get the signs working), and all they have to do is change some values and fill in an XML file then publish as mod to workshop.

As a rough mockup of the xml:

<tmpe xmlver="1">

  // name must be unique per author
  <roadcollection name="UKRoadsRevived" author="authorname">

    // adds this road to the group
    <asset id="workshopid.prefabname"> 
    ...
  </roadgroup>

  // where do signs come from for this group?
  <signsfor roadcollection="UKRoads">

    // note: could be in separate asset pack
    <speed value="30" assetname="workshopid.propname">
    ...
  </signsfor>
</tmpe>

So, if user changes road speed, TMPE can find out what road group it's in (eg. "UKRoadsRevived") and from there work out the ids of speed signs for each speed.

It knows current speed and driving direction, so it can find existing speed sign on the relevant side of the road. It can then place a new speed sign (with height, rotation, etc of old sign) and hide/delete the old sign.

If no old sign is found, TMPE won't add a new sign. This prevents unwanted signs appearing.

The XML structure above should facilitate different types of signs at a later date. For example, we could add in toggling of Parking signs (or relevant roadside props) that can be toggled on and off when parking restrictions are applied.

krzychu124 commented 5 years ago

Yup, using this simple definition we could support custom asset modpacks with ease.

If I'll find a way to add/replace sign props to visualize junction priority setting... It would be one step closer to programmatically plopping any roadside signs anywhere we want 😉

originalfoo commented 5 years ago

It could also allow me to replace road signs on vanilla roads with, for example, UK or US road signs.

For example, in mod settings, I could choose from drop down which road sign pack I want.

This could also be used to filter available speeds when setting speed limits. So if I have the UK pack installed, I only get speeds applicable to UK.

originalfoo commented 5 years ago

Could be extended to roadside props, traffic lights, etc.

originalfoo commented 5 years ago

Another useful thing would be some way to change speeds for roads (this is relating to mph vs. km/h: #13).

For example, UK Roads Revived assets are using km/h values. So a 30mph road is actually 30 km/h.

Having an option, when enabling mph speeds in TMPE, to bulk change those roads to the mph value would be useful (so the road becomes 30mph = ~50km/h).

tony56a commented 5 years ago

Hi,

Quick question, is the envisioned end-state for this task supposed to include the addition of new props on a road, or just the replacement of existing props?

originalfoo commented 5 years ago

Replacement of existing props would be a great place to start.

Ultimately I assume people would want to be able to replace the existing props with other workshop props, eg. American style speed signs.

originalfoo commented 5 years ago

One issue of the existing props is that they might not cover the full set of speeds that TMPE offers. Like the 5mph intervals, or 130km/h etc.

As it seems you've got prop updating working, I wonder if now would be a good time to start thinking more about how prop definition packs could be implemented - at least now we know what signage would be required for both MPH and km/h speeds.

tony56a commented 5 years ago

Ultimately I assume people would want to be able to replace the existing props with other workshop props, eg. American style speed signs.

The current method does support that as well, though since it's just attempting a match on the prop name, the final version would probably benefit from a more reliable mechanism for prop lookup.

The main question I have right now is how much flexibility should there be in adding props when rendering. Right now, it'll only replace props that the game has decided to load, so no speed transitions, no appending extra props, etc. If that flexibility is desired, then a more substantial patching/complete replacement of the NetLanes.RenderInstance method would probably be required.

One issue of the existing props is that they might not cover the full set of speeds that TMPE offers. Like the 5mph intervals, or 130km/h etc.

That could be overcome by including a set of fallback props within the mod itself, but that's something that needs further discussion obviously.

originalfoo commented 5 years ago

the final version would probably benefit from a more reliable mechanism for prop lookup.

We'd need some way to handle props from other roads. For example, I use UK road assets which replace vanilla props with custom "essential" props.

Having a tool that collates list of all props and dumps to log or some other file would be useful. I assume we can detect which props are being used for signage by checking the flags that determine whether they appear in the prefab?

Right now, it'll only replace props that the game has decided to load, so no speed transitions, no appending extra props, etc

That's the right approach IMO. For example, I often slow speed at sharp bends, and I wouldn't want speed signs suddenly popping up everywhere I did that. So I think just updating existing props, for now at least, is the right way to go.

It would be cool if any existing 'parking' signs could update for parking restrictions changes, or 'no left/right turn' signs change when customising lane arrows/connectors.

tony56a commented 5 years ago

I assume we can detect which props are being used for signage by checking the flags that determine whether they appear in the prefab?

NetLane props are actually stored as part of the NetInfo.Lane, so it should be pretty easy to grab the list of items, I've added something to the LanePropManager to dump the props in the TMPE log.

tony56a commented 5 years ago

So I've been thinking about the prop availability issue for the fallback speed limit signs, and I was wondering if we can solve the issue of prop availability by simply generating props on the fly, though this seems like it's starting to get out of scope for the mod.

originalfoo commented 5 years ago

Yeah, props on fly is potentially do-able, but is a bit overkill and could cause problems with other mods.

IMO it would be easier to use prop packs from workshop. We can work with a few asset creators to get first few packs done, then post a spec for what assets are required if other creators want to do their own versions.

tony56a commented 5 years ago

Just to clarify:

  1. 3ed124e and b4a82ab already implements the suggestion, and shouldn't interfere with normal props/mods (they're prepended with a TMPE-specfic name, are not accessible via the main game AFAICT, and are only generated on OnLevelLoading to avoid interactions with things like LSM), haven't tested performance yet, but the prop generation is a one-time thing, so even worst-case would only add about a couple of seconds on load, and ~2-3mb of extra textures.

  2. This is more intended to address the issues of when someone doesn't install any prop packs, and we see the issue with the in-game props not covering the full range of possible speed limits. The workshop loading should probably be addressed in the 1st revision while the asset creation process is happening

originalfoo commented 5 years ago

Wow, I thought you were only swapping existing props. So with this we could slap any font on any sign?

Could this be used in UI layer as well? I mean, it's just textures so I guess so? Like currently we have all these individual sprites for the signs - we could just have single background image and then font to overlay on top?

And with the font, we could potentially map all the relevant number typefaces and other symbols in to a single font file (think along lines of FontAwesome or similar)...

tony56a commented 5 years ago

Wow, I thought you were only swapping existing props. So with this we could slap any font on any sign?

Yeah probably, the most recent revision uses the system Arial font, but it can be replaced with either another dynamic font loaded from AssetBundles (I guess reusing work done in #391) or using custom Font textures like PO(not a fan of that though, would be better to use regular TTF/OTF fonts).

Could this be used in UI layer as well?

Yeah I think so, though there's a lot of not-performant operations, so dunno how well this works in real-time.

originalfoo commented 5 years ago

I guess bulk of grindy code is conversion of font to texture, so for UI that only needs doing once per choice of signage style.