rcd questions

[Doctor J]

Greetings! I'm excited about this project.

I have some questions and comments about the rcd specifications...

1) Other than data blocks, are any other blocks (beside ANIM/ANSP) combined in a single rcd file?

2) Are ANIM & ANSP always together in a RCD file?

3) Can there be multiple TEXT per rcd file?

4) CSPL specifies platforms for tracks - what about supports? Many coasters use supports that are poles spaced several track pieces apart rather than per-voxel "wood" supports.

5) TSEL, TARE, PARE, TCOR & BDIR are listed under Game Blocks but they seem more like GUI blocks. I would expect that there would be only one instance of each during program execution.

6) There needs to be a scenery block specification.

7) Will there be multiple tile scenery items?

8) How about a specification for path accessories such as: benches, trash cans, water fountains etc.

9) Will there be banners with text including one-way signs?

10) Will there be special items for ride entrance/exit?

11) Some items will need flags for:
   stackable
   build on water
   build underwater

[Zuu]

Regarding scenary and stackable:

I have a patch queue for fences. It implements fences, but there is some remaining question on how to handle fence on the upper edge of a slope. Should it belong to the voxel above the tile or the tile itself and then be drawn with an y-offset of a full tile above. (this has been discussed elsewhere and I just haven't had time to adopt my code to the discussions as my time available for FreeRCT is currently very low)

http://junctioneer.net/freerct/fence/

These fences are GUI-wise not stackable, but IIRC storage in the map array is made so that they can be stacked.


Otherwise, regarding "there needs to be ...". There are lot of things not implemented yet. Someone (which could be you) can take upon them and work on that.

[Doctor J]

I would like to make a FreeRct Object Editor(?FROE). The more detailed and thorough the rcd specification is, the easier and more usefull such a project will be. Currently, I can read and display the images, texts and shop information. I have a long way to go to be able to edit, create new and save rcd files. The main goal is to use this for scenery items. There is no scenery block defined yet. I can suggest a definition if that is acceptable.


Re 1&2  I see that ground rcd contains both SURF and FUND blocks,
    paths consist of PATH, PLAT and SUPP blocks
    rollercoaster consists of RCST, TRCK, CARS and CSPL blocks
    the gui rcd consists of BDIR, GBOR, GCHK, GSCL and GSLP blocks
    the person rcd consists of PRSG, and 4 pairs of ANIM/ANSP blocks

Re 5    The items listed as "Game" blocks are those which are drawn in the isometric world while those listed as "GUI" blocks are those which are drawn in the 2D overlay. It appears that the x and y offset for sprites used in Game blocks refers to the offset of the upper left of the image relative to the center of the isometric tile. On the other hand, the x and y offset of spirites used in GUI blocks appears to specify the offset of the center of the image relative to its draw location.

Please clarify the x,y offset definitions for me.

For completeness, the following language specifications are present in files but not yet listed in the rcd spec:
da_DK
de_DE
es_ES

[Lord Aro]

Hello! I messaged Alberth (lead programmer) about this, as he's largely away at the moment. Here's his response (to the original post)

Greetings! I'm excited about this project.

Hi

 

I have some questions and comments about the rcd specifications...

Like everything, it's a work in progress, it contains stuff that we needed, and gets extended when we need new or other stuff. That is, it is not a fully planned-ahead design of what it will contain.

1) Other than data blocks, are any other blocks (beside ANIM/ANSP) combined in a single rcd file?

All sprites, and probably texts (I don't remember exactly), at least. In principle, any field in a block that is a reference to another block. Not sure how relevant it is, as rcdgen normally hides such dependencies for you.

2) Are ANIM & ANSP always together in a RCD file?

I don't remember the contents of those blocks exactly, but references to a previous block can only be done in the same file.

3) Can there be multiple TEXT per rcd file?

I see no reason why not.

4) CSPL specifies platforms for tracks - what about supports? Many coasters use supports that are poles spaced several track pieces apart rather than per-voxel "wood" supports.

There is SUPP, which may or may not have a field defining the type of support. I guess a rolleer coaster designer also wants to define what supports go with the coaster tracks. No idea if you can specify that currently. Since we only have the wooden supports now, there has been no need to define and implement these things.

5) TSEL, TARE, PARE, TCOR & BDIR are listed under Game Blocks but they seem more like GUI blocks. I would expect that there would be only one instance of each during program execution.

It's mostly just a matter of naming. GUI blocks were/are the things in windows, and the blocks you mention are in the world display rather than the window. I agree the term Game block is debatable here. On the other hand, imho there are more interesting things to solve, than a category problem.

6) There needs to be a scenery block specification.

We don't have scenery stuff yet, which is why it doesn't exist.

7) Will there be multiple tile scenery items?

I see no reason to exclude it now, but we don't have scenery stuff yet, which is why it doesn't exist.

8) How about a specification for path accessories such as: benches, trash cans, water fountains etc.

I see no reason to exclude it now, but we don't have path accessoires stuff yet, which is why it doesn't exist.

9) Will there be banners with text including one-way signs?

I see no reason to exclude it now, but we don't have that stuff yet, which is why it doesn't exist.

10) Will there be special items for ride entrance/exit?

Very likely, although I am not so happy with their look in the Rollercoaster Tycoon programs. However, we don't have that stuff yet, which is why it doesn't exist.

 

11) Some items will need flags for:

stackable
build on water
build underwater

They do?
So far we have managed without those flags (not having water stuff helps a lot here ) For others, eg supports, the property is implied. When the need arises, they can be added. However, the aim is not to copy what some other theme park program happens to have. If you make that assumption, you are going to miss out on a lot of better alternative solutions, the program is "inspired by", not "a copy of".

 

In response to your last post, I can say

I would like to make a FreeRct Object Editor(?FROE).

Wow. Umm, OK. Sure. Go ahead. Seems a bit early to me though - there are large parts of the game which should be done first, in my opinion.

For completeness, the following language specifications are present in files but not yet listed in the rcd spec: ...

Thanks for pointing that out, I'll fix that

[Lord Aro]

I got a reply from Alberth to your last post:

I would like to make a FreeRct Object Editor(?FROE). The more detailed and thorough the rcd specification is, the easier and more usefull such a project will be.

Euhm, ok, but why would you want to go that way?

FreeRCT is an open source game, and that is also the case for its data files. In other words, you can edit the source of the .rcd file, and recompile it with 'rcdgen' to get an updated .rcd data fiile. There is no need to edit binary data files at all, as far as I can see.
Please have a look at the various .txt files in graphics/rcd (iirc freerct.txt, gui.txt, shops.txt, and tracks.txt).

Currently, I can read and display the images, texts and shop information. I have a long way to go to be able to edit, create new and save rcd files. The main goal is to use this for scenery items.

There is no scenery block defined yet. I can suggest a definition if that is acceptable.

Having a scenery block without being able to use it in the game seems useless to me. Stuff must be testable.
Adding a scenery block would be a useful addition for many players, but it implies adding the functionality to the game engine as well, for testing as well as for checking that the data in the block is sufficient

Re 1&2 I see that ground rcd contains both SURF and FUND blocks,

paths consist of PATH, PLAT and SUPP blocks

rollercoaster consists of RCST, TRCK, CARS and CSPL blocks

the gui rcd consists of BDIR, GBOR, GCHK, GSCL and GSLP blocks

 the person rcd consists of PRSG, and 4 pairs of ANIM/ANSP blocks

I'd make a different categorization, but that's ok.

You seem to assume that the RCD file structure is stable. It is not. As stuff gets added or new requirements pop up, things will shift, get added or disappear.
You can see this by looking at the version history (the big numbers are dates YYYYMMDD). Looking through the history of changes of the graphics/rcd/data_format.rst file will also show it.

For this reason I agree with LordAro that you seem a bit early with your addition. It is not a problem in itself, but please be aware that the format in will change in unknown ways for several years to come.

Re 5 The items listed as "Game" blocks are those which are drawn in the isometric world while those listed as "GUI" blocks are those which are drawn in the 2D overlay. It appears that the x and y offset for sprites used in Game blocks refers to the offset of the upper left of the image relative to the center of the isometric tile.

The game uses the position of the unraised northern corner of the tile as point in your view to draw sprites. (ie in a flat world, the corner of a tile furthest away from you). The sprite offset is a relative position to that corner for rendering the sprite, starting from the top-left corner of its image rectangle.
A relative position (0,0) thus means the top-left corner of the sprite is drawn at the unraised northern corner of the tile. A relative position (-10, -20) means the top-left corner of the sprite is drawn 10 pixels to the left, and 20 pixels up from the tile corner position.

Note that in the rcd source files, you give the relative position of your bounding box. rcdgen crops the images, and adjusts the relative position automagically.

On the other hand, the x and y offset of spirites used in GUI blocks appears to specify the offset of the center of the image relative to its draw location.

I don't know what happens there exactly. A sprite always has a relative position, even with the GUI sprites, where it makes little to no sense. Perhaps I just ignore the relative position in that case. Please check the source code.