Custom Scenery Exchange / Patching objects once and for all

It is obvious to all NEDesigns users that custom scenery is a wild west. There are no standards for object design, and this is most clear in the realm of quarter tile scenery, in particular trims and other decorative elements.
Trims and decorative elements often do not take up a full quarter tile, and thus are less-than-quarter-tile scenery. They are often biased to one edge or corner of the quarter tile, which causes problems when objects are constructed improperly. The same idea applies to scenery that occupies a whole tile - they too can be biased to one corner or edge and brings with it the same problems for less-than-full-tile scenery.
OpenRCT2 gives us the opportunity to fix these issues with objects editable in plaintext and the promise of versioned objects.
The improper construction of objects is not the fault of the creator. Without the knowledge of the best practices for scenery creation, creators were left to their own devices and the overall experience of using custom scenery is impacted.
The primary places the user is impacted is in non-standard rotations, improper flag setting, and wrong offsets. Non-standard rotation affects less-than-quarter-tile scenery in that variants of the same scenery, such as different heights of corner pole, must be rotated to connect to each other. Improper flag setting affects how mirror code works, and custom scenery users are limited by the scenery being improperly mirrored. Improper offsets are a major source of scenery versioning, and having a definitive good version prevents the accidental use of known bad versions.
Along with fixing the rotation, flags, and offsets, this project has the opportunity to tweak other aspects of custom scenery:

• Standardize placement cursor
• Reduce glitching of less-than-quarter tile and less-than-full-tile scenery
• Standardize naming
• Add translations
• Standardize cost of scenery objects
• Fix zoomed-in scenery previews
• Fix glitching of multi-tile scenery
• Fix ugly slope sprites for walls

Old scenery should be cleanly replaced with the appropriate new versions, without changing the aesthetics of parks using older objects. This will occur when loading, and the colors, rotation, and other parameters as necessary will be modified in each occurrence of the scenery in the map to keep the looks the same. This is not imperative for the success of the project, but it will help cement it as the definitive custom scenery repository.
 
Scope
 
This project should be limited to custom scenery objects that are common across many parks, following the community-accepted conventions for aesthetics. Base blocks, trims, walls, fences, and roofs are the primary targets for this project. The scope is subject to change as the creators deem it necessary.
 
Missing Features
 
Some features necessary for full completion of this project are not yet implemented, both on the pipeline side and the game side.

• A simple method to convert .DAT objects to json does not yet exist. There does exist code to make a program to do this, but it does not work.
• Extracting sprites does exist, and OpenRCT2 will extract all the sprites from a .DAT file and put them in a folder, but there are some issues with the printed offsets that must be manually corrected when using windows.
• OpenRCT2 does not yet reliably replace custom scenery .DATs with updated json versions when the OriginalId matches.
• OpenRCT2 does not yet have any mechanism to modify existing objects when replacing them with newer versions.

Current Pipeline
Despite some pipeline tools being incomplete or missing, it is possible to create json scenery that can replace .DAT scenery. The process is fine for scenery whose main differences are the sprites, such as base blocks.
The following steps demonstrate how to convert a scenery using current tools:

• Find the .DAT identifier you want to use. This can be found in the object selection window.
• Use the command line to extract all the .DAT sprites.
• Copy an object in the same category and name the folder with the new object’s name.
• Move the images into the object’s images folder.
• Modify the json to suit the scenery object.
• If the scenery is rotated the wrong way, reorder the sprites until it is the correct rotation.
• Credit the author of the scenery
• Get the original id identifier from the .DAT using the datnameformatter program.
• Put the original id in the json. a. If the original object requires rotation, use the currently-ignored replacement field to store this information.
• Remove the .DAT from the object folder (I put it in a ‘done’ folder outside of the object folder).
• Test the scenery ingame.

Pipeline enhancements

Things that would be helpful to streamline the object conversion process

• The object identifier is listed in the scenery selection window
• The game itself can export a specific object to json and sprites in the desired format into a specific folder

With these improvements, the pipeline can look like this:

• Load up a workbench with the desired scenery in it
• Use the pipette tool to find a piece of scenery or find it in the scenery window
• Use the command line to export the scenery to the appropriate folder
• Tweak the json to suit project standards a. Fix rotation issues b. Fix other sprite issues like zoomed-in preview
• Test scenery ingame

I’m open to any other pipeline suggestions.

How you can help

I have started by converting the scenery found in Xtreme 2017 bench. If you want to help, you can fork this repository to your own github account, download the repository, and start converting changes and making commits.

Can you show a screenshot of what the functionality of the multiple version organisation looks like inside ORCT2?

 

We will likely do these linkages across our object data internally on NE at some point in the future, based on the knowledge of the object experts we have, and on the release dates of parks that first published these objects.

 

I'm not sure I fully understand what you mean about non standardised rotations of micro objects, but that's probably just because I myself am too inexperienced with the usage of these objects.

OpenRCT2 currently does not have code for switching between versions of the same parkobj. This project may affect some parts of that.

 

 

Regarding nonstandard rotations, the simplest demonstration is these two corner trims:

 

These inward-facing corner trims have the same rotation, but the graphics show them facing different directions. Another example is a 1/4 height corner pole and full height corner pole are on different corners, which requires the user to rotate the scenery around to get the pole to line up. The mirror functionality of track designs (eventually, blueprinnts) and the scenery manager expect objects to be constructed a specific way, which most custom scenery makers did not do.

I’d at least gotten a handful of us that are also interested in this. I didn’t yet have the motivation to actually get it off the ground. If you’re heading up the operation, I’d love to put in my input and efforts, and I’m sure some of those I’d loosely gathered would as well.

It’d be very nice to have a bench even with ‘working’ tabs that grow as new, semi-official objects are added as well. All with the correct rotations, coloring, alignment, naming, pointers, etc.

I have started the conversion process. It's going through some teething stages so it should get more streamlined soon. You can find the github repository with what I've done so far here: https://github.com/s...EDesignsObjects
 

I have started a wiki page for the standards that each object must follow. I've wrote down most of what I think is necessary to begin with, with more to follow. Suggestions are welcome!

https://github.com/s...bject-Standards

I think before you introduce some naming standards we should maybe form some "commitee" first that sets these standards in consensus.

I think it's important to define the sets of scenery so the smaller aspects of standardizing the objects can be defined.  For example, we need to discuss what the properties of a base block should be, what textures we should include, etc.  I'd propose basing this on scenery tabs.  Perhaps it's a good point to start working from there as it would guide the rest of what needs to be defined across tabs/groups and what is important to standardize within groups.  I'd propose:

 

1. Base Blocks (limit this to full and quarter tile blocks; possibly diagonal blocks)

2. Building Blocks (smaller block scenery; alternative name = Deco Blocks)

3. Walls

4. Roofs

5. Doors/Windows (alternative name = Wall Additions; should probably also include flower boxes, etc.)

6. Trims (includes poles)

7. Water Features

8. Land Blocks (alternative name = Landscaping; not sure if there's much to include here outside of land blocks)

9. Supports

10. Ride Scenery (includes catwalks, whole ride objects like the Ferris Wheel)

11. Trees

12. Shrubs

13. Gardens (includes any of the ornamental foliage like hedges and such)

14. Paths

15. Path Additions

16. Fences

17. Miscellaneous (alternative name = Theming Objects

 

It's possible to place one object in multiple tabs, so some of the objects may fall into multiple tabs, for example flower boxes would fall into Gardens and Wall Additions.  Anyways, I think it would be important to figure out what these are so we can then figure out what to do with all of these.  For example, within base blocks, I had the thought of automatic rotations of the square pieces, so the texture is varied even if you stack them.  Is this something we should do?  At the moment, there is no purpose of having the block rotate as it's the same image every time.  Another question is, should the block even have two colors?  I for one spend more time on rearranging the colors to be the same and get little value of the different color top.  It also changes on the blocks: on blocks with one color, the top is recolorable; but, for those with two colors, the top is remapped to be the secondary remap.  In all honesty, I rarely if ever use multiple colors on blocks and question the utility of having two remap colors.

Base Blocks I think should include triangle blocks, inside and outside curved blocks, half-diagonal blocks.

I think for varying the look based on rotation, I think this should not happen randomly - it should be user defined. A reason against is that it has unknown impact on old parks that the new scenery supersedes. A reason for doing this is it gives users the ability to add variation to what is otherwise an extremely repetitious texture.

 

For legacy reasons yes I think they should have two colors, although I'm open to suggestions on which color should go where on base blocks. I think it makes more sense to have the top be color 1 and the sides be color 2.

The beauty of it is the old parks wouldn’t be affected. The orientation should still all be the same because they were placing rotatable objects then but the views were all the same. So this would still give old parks a repetitive texture, assuming the builders didn’t randomly rotate the blocks as they built.

Now, Changing from two colors to one color would affect viewing old parks. I can be convinced two colors is better for options, however we’re sort of stuck with the colors being mismatched in location between one and two colored blocks.

The two colored objects exist for a reason and I think it wouldn't be very wise to make objects less flexible. I can see the point with the order, although I don't know how many objects are affected by this? However, changing the first remap to the top color and the second to the side will cause the same problem when selecting in between walls and building blocks (of the same texture even), so the inconvenience would be just transferred from one place to another. Solution that works after a quick test with parkobj: let the top color always be the second remap color and only activate that flag in the respective object. Then only that remap option shows in the selection but everything still works fine.

So the convention could be:

First remap: sides

Second remap: top

Third remap: (side) details (recently added for SS and LS)

 

regarding the random rotation:

I think it is a good practice for blocks that have a texture that benefits from more variance, noisy ones like the spanish wall. For very homogeneous textures like the marble or ones that require to be precise (certain bricks) I don't think its not really needed to add that cause then those added 'imperfections' will stick out more than they bring benefit. Especially I would refrain from adding rotation varations for existing blocks deliberately.

Before starting this you should also investigate the possibilty of the sceneryGroup entry in the json with custom groups and create "legacy" scenery groups like what dirt proposed above. then objects would sort themselves into these groups and future objects could do the same without being stated in the group a priori. (Don't ask me how the sorting in the group ingame works then though)

That's quite interesting that the remap for the blocks would work like that.  Would be very slick to not have to switch colors as much.  How would that affect previous parks?  Would the base blocks with single remap color be changed to whatever the secondary color the builders happened to use at that time?

 

I agree on certain textures wouldn't want random rotations, like brick for example, which stacks well as is.  The marble actually benefits a lot from it because the blocks have obvious repetitions.  Although, there is the annoyance that if you add that, you're taking away the ability to rotate other objects in the scenery window when the base block is selected.

If I understand this correctly, the suggestion is to add "master" scenery groups which the objects of the specified type always show up in, I think it is a good idea, and I think it is a good idea to remove stuff from the default walls scenery group, since it is polluted with many quarter tile objects. I think that the default categories should be re-used where possible, and add new ones as necessary.

 

I think if an automated build system is created like what the OpenRCT2 repository has, it will not be a big deal to have the master scenery groups directly reference all of the scenery it uses, but it could go either way.

 

My belief is that there will be more objects in the repository than the game can handle, and if so, benches will still be relevant. I think the new default categories should allow bench creators to avoid making new categories if they so desire, but there's always branding to consider.

I thought the idea is to somehow solve it such that you don't have to worry about affecting old parks cause different objects will be loaded. Personally I still think that just introducing new objects that are clearly labeled to come from this project would be enough but I know you guys have other plans.

If the old objects are not replaced then there will be 5 objects in the "fixed" chain instead of 4 and the other 4 objects will still show up in the object selection list, so I would like to clean up those other objects, and that means loading the objects in old parks as well.

I think it would replace objects when possible, but if an object needs a 'correction' that would render parks using the old version ruined or changed, then that warrants an updated object.  I think the vast majority would fall into the former but there would have to be some objects that are released as standalone corrections, or at least until there is a way for open to do more complex updates to objects or something.

I am currently working on the 'more complex updates to objects' part but it is slow going.