zztong
Hunter
Currently:
POI designers (TFP's work as the example) copy/paste sign layers between POIs, Parts, and Tiles. This creates a duplicate sign configuration and new GUID for each copy. It also means the POI designer has to remember "where did I put that sign?" Given many signs are unique to their surrounding, this is generally okay.
There are times when this practice isn't perhaps the best. Consider a sign like "Beware of the Dog" which you might use across many POIs and Tiles. It could be turned into a Part and reused that way, but if there were a mechanism to make a Library then that might be more convenient. A sign in a library would reduce redundant sign data.
When it comes to modlet interaction, putting sign data into Parts and/or using XPATH to insert a sign into the signs.xml file begins to run a greater risk of reusing a GUID. And, that also comes with a greater chance the signs have diverged in their actual definition based on the work of different, isolated, POI developers.
Proposal:
Leave the current Data/Config/signs.xml file and the XPATH integration in place.
Add the ability for a modlet to include a Prefabs/Signs directory where xxx_signs.xml files would be located. The game and the Prefab Editor would know to look for these files. The Prefab Editor would allow them to be edited, much like the current sign functionality in the Prefab Editor, but where you would have to switch between sign sources: game, modlet libraries, or the POI's local file.
A modlet's layout would be:
Anticipated Benefits:
- Sign Tech is built into a POI, Part, and Tile's _sign.xml file.
- The game also has a Data/Config/signs.xml file. Signs listed here are visible to all POIs, Parts, and Tiles.
- Modlets can use XPATH to add POIs to the signs.xml configuration when the game loads.
- Signs must have a globally unique identifier (GUID).
- Any duplicate GUIDs will be ignored in favor of the first one defined.
POI designers (TFP's work as the example) copy/paste sign layers between POIs, Parts, and Tiles. This creates a duplicate sign configuration and new GUID for each copy. It also means the POI designer has to remember "where did I put that sign?" Given many signs are unique to their surrounding, this is generally okay.
There are times when this practice isn't perhaps the best. Consider a sign like "Beware of the Dog" which you might use across many POIs and Tiles. It could be turned into a Part and reused that way, but if there were a mechanism to make a Library then that might be more convenient. A sign in a library would reduce redundant sign data.
When it comes to modlet interaction, putting sign data into Parts and/or using XPATH to insert a sign into the signs.xml file begins to run a greater risk of reusing a GUID. And, that also comes with a greater chance the signs have diverged in their actual definition based on the work of different, isolated, POI developers.
Proposal:
Leave the current Data/Config/signs.xml file and the XPATH integration in place.
Add the ability for a modlet to include a Prefabs/Signs directory where xxx_signs.xml files would be located. The game and the Prefab Editor would know to look for these files. The Prefab Editor would allow them to be edited, much like the current sign functionality in the Prefab Editor, but where you would have to switch between sign sources: game, modlet libraries, or the POI's local file.
A modlet's layout would be:
Code:
ModInfo.xml
Config/
signs.xml (XPATH Currently Supported)
Prefabs/
POIs/
some_poi_signs.xml (Currently Supported)
RWGTiles
some_tile_signs.xml (Currently Supported)
Signs/ (Proposed)
zztong_common_signs.xml (Proposed)
zztong_stores_signs.xml (Proposed)
yolo_signs.xml (Proposed)Anticipated Benefits:
- Reduction in configuration to be stored and loaded into memory.
- Some increased efficiency in POI developer workflow.
- Easier modlet integration and management that might also improve eventual Steam Integration.
- POI creators and POI modlets is a small audience; perhaps not worth the effort required to support.
- Arguably, Parts already provide the necessary function.
Last edited: