[Rct 2 building scenery]

5 hours ago, YoloSweggLord said:

The problem with this is that you'd have clipping issues if you tried to make an entire monorail station 1 piece. There's no way to make "holes" in the clearance checks of the building to allow for the monorail to fit inside it without sprite clipping issues.

I'm 90% sure there is. I've not tested it, but if it's not possible then it could definitely be implemented without a new file format. Large scenery objects have a list of map elements each with x/y coordinates, so I don't see why you couldn't put more than one on the same tile with different clearance heights.

But I actually think OP was talking about a station built out of multiple small scenery objects like the one in the picture, not a single large station object.

[Playing on Mac?]

3 hours ago, cascadia said:

The zipped demo isn't the full game, through.

IIRC, that demo does contain all the assets (though I've not been through the whole list to check).  It's time limited, but that won't apply if you use it with OpenRCT2. The demo linked on the Github page is missing objects, but I think that's a different demo.

[Foxy's Random Stuff]

32 minutes ago, Broxzier said:

Set this high enough for the dark side, and then set the directional light's intensity to get the light side right

I tried that. You can get two sides to match, but the remaining sides then come out wrong. I tried using line search and gradient descent to minimize an overall error function, but I was not able to fit the data well, and even when you have a side that matches by the numbers, the visual appearance is often very different. I've pretty much given up with trying to get the lighting to look remotely decent.

[Foxy's Random Stuff]

35 minutes ago, Foxy said:

Maybe i should mask the green area --> index palette --> copy&paste it back on the true Color image.

RCT2 cannot use true color images, so they will be converted anyway. I think the problem is that your lighting is way too dark. IIRC, the object editor doesn't dither, so it will pick the closest palette color. The dithered image is a better approximation of the actual color of the model, but it does look noisy when given a shade that doesn't have a close match in the palette. You can try turning dithering off if you'd prefer, but I'd say the light needs to be brighter anyway. Lighting is really difficult to get right, and at this point I've pretty much given up trying.

 

[Foxy's Random Stuff]

I have no idea what you've managed to do there, to be honest, but here's what I did:  start with the true color image (which is most likely what you are rendering). Open that in RGB mode, then go to Image->Mode, and select "Indexed". Then select the pallete you got from the screenshot, and set "dithering" to "Floyd-Steinberg". That should convert the image to indexed color.

[Foxy's Random Stuff]

You can find RGB values for the game palette here. (I link this and not the OpenRCT2 source because they assign different values to the remap colors - OpenRCT2 will give you orange colors for the primary remap, but most tools expect green. I'm not sure of the reason for the difference - it doesn't really matter, but consistency would be nice)

However, there's a much easier way: open any RCT2 screenshot in GIMP and then navigate to the palette window. It will show you the current palette, and you can save it for reuse. This will not give you the primary remap colors (they are all shown as black), but as mentioned above, you don't need them for this anyway.

There are a few other palette values you need to exclude when converting images for use in game. The water colors and the chain lift colors will animate, which is probably not what you want. There are a few other values whose purpose I don't actually know. The colors you want to include are in blocks of 12, from dark shades to light shades.

[Foxy's Random Stuff]

2 hours ago, Foxy said:

do you know the hexa-decimal value for both remapable colors? Because the palletizing method looks promizing. But for that i need the value.

Sure. The primary remap colors are palette indices 243-254 (0xF3-0xFE in hex). The secondary remap colors are indices 202-213 (0xCA-0xD5) and the tertiary remap colors are 46-57 (0x2E-0x39).

The primary remap colors are used only for remapping and never appear in game, so you should exclude them from your palette. There are also non-remappable greens, so this does not mean you can't have green areas, but if your object contains green areas and it's remappable then you'll have to work a bit harder to avoid them getting mixed up. The secondary and tertiary remap colors are only remapped if the object is remappable, so there's no need to remove them from the palette - they should show as the expected colors if they are not remapped.

[Foxy's Random Stuff]

This was the main reason why I wrote my own renderer. However, there is another approach, which will work fine for objects which are entirely non-remappable (as here), or objects that are almost entirely remappable. The solution is to simply remove the remappable colors from the palette you use when you convert the image to indexed color. The only time this doesn't work is if you have remappable areas and also non remappable areas in the same color. I saw one approach based on splitting the image into two, palettizing with different palletes and then recombining them.

[Foxy's Random Stuff]

Note that the primary remap colors never appear in game (they are always remapped to another color before being rendered), which makes their actual color somewhat arbitrary. Just about every RCT2 tool (including the object editor) uses green for these remap colors, but OpenRCT2's own sprite importer uses orange. If you are making sprites to be added to g2.dat, that's something to be aware of.

[Arid Heights - openRCT2 & Nolimits 2]

This sounds interesting.

[Number of Guests]

49 minutes ago, SleetFire said:

Now I understand this likely was mentioned here before but I tried the search forum tool with no luck so I am mentioning it again.

Simply wondering, what is maximum number of guests one can have in a park? Also, would it be possible to increase the max number?

Absolute limit is 10000 sprites, but coaster cars and vomit/litter are included in that. I have been unable to spawn more than about 9600 guests. This limit cannot be increased without a new save format.

[RCT1]

OpenRCT2 requires RCT2, not RCT1.  You should point it at the directory which contains the rct2.exe executable and the subdirectories "Data" and "ObjData". The "Data" folder should contain the file "g1.dat" and several files of the form "css<number>.dat", and the ObjData folder should contain a large number of DAT files with names in all caps.

[Foxy's Random Stuff]

Oh, OK, I understand now. That's... really strange. I have no idea what 3DS max is doing there, but that is definitely the correct projection. I think the simplest way to set the correct scale is to make a single square, and then make it the size that you want a tile to be (which seems to be arbitrary, anything between 3 and 4 metres is a reasonable value). Then adjust the camera until the image is 64 by 31 pixels, as this is the size of the tile sprites in gam.

[Foxy's Random Stuff]

1 hour ago, Foxy said:

But 3Ds max has 3 coordinates, that i have to take care of

Yes, of course. Blender works the same way, even if the camera is orthographic it still has a 3D position. But with an orthographic projection, the distance doesn't matter, so you can just choose whatever value is convenient. Your projection does look correct, so I'm not sure why you're finding that the distance matters - are you sure you're not using a perspective projection with a long focal length?

 

1 hour ago, Foxy said:

The X Y Z axis of the camera as well as its FOV determin how the rendering would look as an image.

 

An orthographic camera does not have an FOV (or perhaps another way to think of it is, an orthographic projection is a limiting case of a perspective projection as the FOV angle tends to zero). If you use a perspective projection, the field of view looks like a pyramid, and the FOV angle is the angle that the sides make with with each other. With an orthographic camera, those sides are parallel. Here's a picture I found that illustrates this:

 

 

 

 

 

[Foxy's Random Stuff]

5 hours ago, Foxy said:

See the difference in size:

These appear to be two screenshots taken at different zoom levels. That is not moving the camera, it's rescaling the sprites, so it shouldn't be surprising that it changes the size of the sprites. In fact, RCT2's "camera" only stores two coordinates, so there's no way to change it's z coordinate, it doesn't even have one (since it would do nothing). If the game was using a perspective projection, then placing two pieces of scenery, one towards the back of the visible area and one at the front, would result in two different images because one is further from the camera.

Now, if the projection you're using is not the correct one then it's close enough that I can't tell the difference, so if you are using a perspective projection it must have a very long focal length. It looks to me like your camera is set up correctly, but if you are finding that the distance matters then it definitely isn't.

This property of an orthographic projection is the reason you can't look inside a building, and why you can get confusion where two roof pieces appear to connect but are actually in completely different places. A game like this would not work with a perspective projection - similar games with a perspective projection are all rendered in real time.

 

5 hours ago, Foxy said:

for some reason, it dosnt render the park sign. I think i need to create it by myself anyway.

Sorry, I think I might have confused you a bit - you have to render the background of the sign, the scrolling text is what gets inserted automatically.

[Foxy's Random Stuff]

1 hour ago, Foxy said:

(which is good, because than the distance factor really dosnt matter).

The distance of the camera from the object should not have any effect on the scale of the image. If the position of the camera has any effect besides translating the image, then your projection is wrong - only the orientation is important. If the object looks smaller when the camera is further away, that's a perspective projection.

1 hour ago, Foxy said:

But i think the downloaded version of the object creator is wrong. There is no option for multi-tile objects. I have version 1.01.

Large scenery is a seperate object type. (I've never used the object editor so I really don't know if it's supported, but if the option doesn't seem to be there, it's possible that it isn't. I expect someone else will know one way or another). Entrances are another object type.

The only thing you need to bear in mind when making multi-tile objects is that each sprite can only occupy one tile; you will need to split your sprites up. This can be done by splitting up the model and rendering three images.

[Foxy's Random Stuff]

12 minutes ago, Foxy said:

• figure out the camera distance

 

With an orthographic projection only the angle matters. An orthographic projection is equivalent to transforming the scene into camera space then dropping the z coordinate. It doesn't matter what the z coordinate was because you discard it. If you find that moving the camera further away changes the image, your projection is not orthographic. This is the reason the game uses an orthographic projection in the first place - if it had perspective projection, you would need a different sprite for every possible object position.

15 minutes ago, Foxy said:

banner texture (do i need something special, to add a marquee-like park name in RCT2 -> in case i convert the result as an actual entrance for RCT2)

No, that text is added by the game, you don't need to render it.

[Foxy's Random Stuff]

I know nothing of 3DS Max, but are you sure those settings are for the camera and not the viewport? If those settings are for the camera, why do you have "top" selected? Wouldn't that position the camera to look down the vertical axis?

45 minutes ago, Foxy said:

I'll try to find a tutorial on how to set-up a physics camera for dimetric projection

A dimetric projection is an orthographic projection where 2 coordinate axes are equally foreshortened. I gave you the angles to use, if you have the camera set up like that (which it looks like you do) then your projection must not be orthographic. Try rendering a cube - that will make it immediately apparent if your projection is orthographic or not.

 

51 minutes ago, Foxy said:

my current area per tile in 3ds max is 3m x 3m.

But an increase of the area would make the height look even smaller.

It's the model that needs to be made taller, nothing to do with the projection. If you change the scale you'll make it taller, but you'll also make it wider and it's pretty much the right width already.

[Foxy's Random Stuff]

Are you sure you're using an orthographic camera? In your image, the entrance doesn't line up with the tiles properly (look closely at the bottom corners). An incorrect scale would not cause this, either your view angle is wrong or you are using a perspective projection. The easiest way to test that would be to render a wireframe cube - if the projection is orthographic, all lines that are parallel in 3D space are parallel in the image.

 

6 hours ago, Foxy said:

Maybe, the height-values in RCT2 are not correct. Maybe 1 square is 5m² / 16,4 feet² (and not 3m² / 9,8 feet²)

You're forgetting that RCT2 uses a dimetric projection, not isometric. If you are going by the height marks on the terrain, then size of a tile should be 1.5√ 6m≈3.674m . However, do note that RCT2 doesn't use consistent units throughout, so you are to some extent free to choose a scale. I use the height marks and stick to that; I do not trust anything from the ride stats window as they disagree not just with the measurements used elsewhere in the game, but with each other.

6 hours ago, Foxy said:

But when i use feet, it would look strange in 3d. I think i stick to metric.

 

Changing units should not change the ouput at all as long as you use the correct conversion between them, and even if you get that wrong it cannot be the cause of the misalignment, because this would just make the image larger or smaller, not change angles.

Internally, RCT2 does not use metric or imperial - horizontal distances are measured in fractions of a tile and vertical distances are measured in fractions of a clearance. I sometimes find it useful to work in these units (because it scales out all the irrational numbers from the projection), but I mostly use SI units. You can set the game to use SI in the options (I think this was an OpenRCT2 addition).

[Foxy's Random Stuff]

7 hours ago, Foxy said:

difficult. its hard to get the correct angle in 3ds max

For the camera angle, it should be angled 30 degrees down and then rotated 45 degrees about the vertical axis. If it is correct, horizontal lines should have a 2:1 gradient on screen.

[Group Park 5]

13 hours ago, imlegos said:

If it had supports, then it'd probably depend how strong and deep the supports are.

(Though,  a support connected to the side of the cliff would probably help aswell)

It'd need some pretty hefty supports to stand up in a flood. Moving water is extremely powerful, and even if the structure holds up, the foundations can be rapidly eroded away.

[Failed to Create Dump Upon Restart]

1 hour ago, mikeyc301 said:

so i'm assuming it was an issue with one of the settings i changed (probably OpenGL).

Have you tried changing the settings back?

[Trains... Lots of trains]

7 hours ago, giraty said:

Trying to do TTD/Chris Sawyer's Locomotion on ORCT2 huh..... As long as you're patience enough for 9 mph/15 kmh trains 

You can hack the speed faster. I had implemented a console command for it but it never got merged.

[I Need my Memory Jogged... Ask here.]

1) I don't believe so, but what documentation exists is on Github

2) Max platforms per ride is 4

3)As many as will fit in the shortest platform, but never less than the minimum specified in the DAT, and not so many that the friction would be reduced below a set threshold. The absolute max is 255.

[Stoping Guests From Complaining In Line]

I'd say a queue line should be long enough to fill two trains. A queue line that can't accomodate a full train of passengers will lead to the ride running under capacity, and you want it a bit longer to absorb variations in the rate at which guests arrive. But anything longer than that is pointless - once you have the ride running at full capacity, all a longer queue is going to do is make guests complain.

 

Of course this goes mostly for scenario mode - in a sandbox park you would generally build whatever would be a typical length for that queue IRL.