OpenRCT2

[Pales]

I think the work you have done is fantastic but I was just curious as to how far you think you can go in terms of development and features.

Edited October 12, 2016 by Pales

[Nubbie]

If you have anything in mind are you more than welcome to share your ideas

There is of course 'a limit' but it's wide, almost all things requested could get pushed inside the game

[Pales]

What sort of restrictions do we have?

[YoloSweggLord]

we have all the restrictions left over from the save file formats, for one. This includes, but is not limited to: number of rides in a park, number of objects in a park, amount of scenery selectable for scenarios, and map size.

[Nubbie]

That is a restriction right now, however, it will be lifted - But will take a while

[Pales]

Do you think it will be possible to amend sprites? For example, roller coaster designs do not have ladders. Would this be something that could be introduced, is it even possible?

[Nubbie]

There are plug-ins for ladders etc already that you can download and use now

If there are any new rides etc (sprite based), someone needs to draw them :U - But yes, yes it is possible now but not really active

[X7123M3-256]

57 minutes ago, Pales said:

What sort of restrictions do we have?

Right now, the game is still dependent on the vanilla code, which means we can't change the data structures used to represent the map, and are therefore subject to all the existing limits they impose. We cannot remove the limit on loaded objects, placed map elements, total rides, train count, station count, sprites, and many other things. We also can't implement new ride types or track pieces, or anything else that cannot be saved in the existing format. Dependence on the original code also means that the game can only run properly on x86.

However, it's getting close to the point where the game will no longer include any vanilla code. At that point, it's a question of what we want to change, rather than what we can. Some things would require more work than others. The developers aim to remain compatible with save files from vanilla, which means that even if the save format changes there will be limits on how drastically it can differ - some hacks rely on the specific manner in which RCT2 handles map elements.

 

28 minutes ago, Pales said:

Do you think it will be possible to amend sprites? For example, roller coaster designs do not have ladders. Would this be something that could be introduced, is it even possible?

Changing and adding sprites is already possible - the fast forward button and junior coaster steep-to-flat piece are sprites that were not present in vanilla. At this point, any change to the game that doesn't touch the save format can probably already be implemented.

[imlegos]

3 minutes ago, X7123M3-256 said:

We also can't implement new ride types or track pieces

Steep Hill Juniors say hi

[X7123M3-256]

I meant altogether new track pieces (like diagonal loops), not new sprites for those already in the game. That isn't to say that adding existing elements to more track types isn't a good idea - and now that almost all the track paint is implemented, we should be able to start doing that to a lot more rides. I'm planning to take a look at the giga coaster track - I'd really like to add inversions and verticals to it.

[Pales]

12 minutes ago, X7123M3-256 said:

Right now, the game is still dependent on the vanilla code, which means we can't change the data structures used to represent the map, and are therefore subject to all the existing limits they impose. We cannot remove the limit on loaded objects, placed map elements, total rides, train count, station count, sprites, and many other things. We also can't implement new ride types or track pieces, or anything else that cannot be saved in the existing format. Dependence on the original code also means that the game can only run properly on x86.

However, it's getting close to the point where the game will no longer include any vanilla code. At that point, it's a question of what we want to change, rather than what we can. Some things would require more work than others. The developers aim to remain compatible with save files from vanilla, which means that even if the save format changes there will be limits on how drastically it can differ - some hacks rely on the specific manner in which RCT2 handles map elements.

 

Changing and adding sprites is already possible - the fast forward button and junior coaster steep-to-flat piece are sprites that were not present in vanilla. At this point, any change to the game that doesn't touch the save format can probably already be implemented.

Incredible detail. Thanks a lot

Edit:  Where can I locate the plugins for ladders? (I'm using the stable build at this time.)

Edited October 12, 2016 by Pales

[imlegos]

@X7123M3-256 So, like this you mean? 

 

[YoloSweggLord]

50 minutes ago, X7123M3-256 said:

I'm planning to take a look at the giga coaster track - I'd really like to add inversions and verticals to it.

I think you're my new favorite person.

Also, will we be using some of recurious' work in this? I know he mentioned contacting Gymnast about the diagonal log flume sprites.

Edited October 12, 2016 by YoloSweggLord

[X7123M3-256]

59 minutes ago, YoloSweggLord said:

I think you're my new favorite person.

Also, will we be using some of recurious' work in this? I know he mentioned contacting Gymnast about the diagonal log flume sprites.

Recurious' work is of much better quality than anything I can produce. He draws them by hand, pixel by pixel. But I intend to develop the method I used to render the RMC track instead - it will not produce anywhere near as good a result (the output looks as bad as my rides because it's the same renderer), but once implemented it's much faster to generate the pieces, and with this method, once I've done the pieces for the giga track, it would be trivial to add them to another track style. The main things that need changing are:

 

• The original renderer was based on defining a profile for the tie and then extruding it along the track profile. Extending this to cover complex geometry like the Intamin track isn't easy - and I soon realized it was entirely pointless, as it would be better to treat the track profile as a non-linear transformation of a straight track piece. This method is actually easier to implement, and can trivially handle any track geometry.
• I had previously assumed that the sprites were split up according to the tiles they cover. This is not the case; I don't know how it's done but I suspect it's done in screen space. This is the major unknown, and will probably be the factor that determines whether this is at all successful.

I expect Recurious will probably get his pieces implemented before I can get anything working, because he already has the sprites. I don't have a good track record of actually finishing projects like this.