Jump to content

The "New File System" List of Ideas


imlegos

Recommended Posts

So, the phrase "New File System" has been used quite a lot on this forum, so I decided to think back to some of the biggest requested features of this game on the forums.

1. RCTLL styled terrain paints

2. Expanded path constructing options (RCT styled)

3. A form of "Fastpass" system for ride queues

4. New boosters (Already sorta in-game, but lacking specialized sprites)

5. New ride types (Such as rotating haunted hotel rides/Doombuggies)

6. More involved staff system (Staff specialization, training, etc.)

 

  • Like 2
Link to comment
11 minutes ago, imlegos said:

New boosters (Already sorta in-game, but lacking specialized sprites)

I don't see a reason why this isn't possible. The current drawing code points booster track pieces to the brakes drawing code. All we need to do is point it instead is add the sprite to G2.DAT and point the drawing code to that specific sprite which I may be working on creating by editing straight track sprites

13 minutes ago, imlegos said:

New ride types (Such as rotating haunted hotel rides/Doombuggies)

I feel like this should be clarified as "new track types," as it could be confused with custom vehicles and flatrides, which are possible.

things you should add:

7. New track pieces

8. Removing in-game limits, such as: map size, object selection limits, attraction/scenery map limits, number of stations per ride, etc.

  • Like 1
Link to comment

I'll add a few (mostly related to the object files rather than savegames):

Track:

* Track sprites could also go in object files (and so should terrain). Like coasters, it would make sense to divide the track sprites up into groups, and allow some or all to be provided. I don't think there's any easy way to avoid hardcoding the set of available track pieces, but we should leave plenty of room for more to be added in future.

* Brakes could be added as a flag instead of a seperate track piece, so they can be set on any track piece.

Rides:

* Flat rides could be a distinct object type from tracked rides and their animation sequence should go in the object file, similar to animated scenery items. The base size could also be adjustable.

* All flat ride sprites in g1.dat could be moved into object files (as it is I don't know why they're there)

* Swimming pools and water rides. Of all of them this is very ambitious, I think it would be the hardest to support not least because of the number of new sprites required. Would be really cool if it were done though.

 

You've got

1 minute ago, YoloSweggLord said:

I don't see a reason why this isn't possible. The current drawing code points booster track pieces to the brakes drawing code. All we need to do is point it instead is add the sprite to G2.DAT and point the drawing code to that specific sprite which I may be working on creating by editing straight track sprites

 

Exactly. Though it should be pointed out that boosters were added via an awful hack, and are also next to useless because they're so weak (apparently this is for RCT1 compatibility). So better boosters (and additional track pieces in general) is something I'd like to see support for.

 

 

  • Like 1
Link to comment
5 minutes ago, X7123M3-256 said:

* Track sprites could also go in object files (and so should terrain). Like coasters, it would make sense to divide the track sprites up into groups, and allow some or all to be provided. I don't think there's any easy way to avoid hardcoding the set of available track pieces, but we should leave plenty of room for more to be added in future.

That thought actually occurred to me right after I posted my post. I think the problem with that is that, in releasing the track/terrain object files to the public, we would be re-distributing Simon Foster's artwork for free. I think we're stuck with the current G1.DAT format for base-game sprites.

Edited by YoloSweggLord
Link to comment
29 minutes ago, YoloSweggLord said:

That thought actually occurred to me right after I posted my post. I think the problem with that is that, in releasing the track/terrain object files to the public, we would be re-distributing Simon Foster's artwork for free. I think we're stuck with the current G1.DAT format for base-game sprites.

 

There are two ways out of this: make our own similar open source sprites (like what OpenTTD did), or get Simon Foster to release his artwork as open source.

Link to comment
Just now, cascadia said:

There are two ways out of this: make our own similar open source sprites (like what OpenTTD did), or get Simon Foster to release his artwork as open source.

I don't think we need to contact Chris Sawyer rather than Simon FOster. Gymnast contacted him in the past concerning file for modeling more sprites, and Foster said that he can't release them to Gymnast for some legal reason. Ask Gymnast about it if you want more information as to what he asked.

Link to comment

If you're going to a completely new file format I'd suggest it be something extensible like XML or similar to the formats used for audio and video. Old versions of such formats can be easily picked up by new versions of the program with no difficulty and  usually old versions of the program can pick up new files by simply ignoring the unsupported content.

  • Like 1
Link to comment

A few more:

  • Support for any number of custom songs
  • Embedding music (or a reference rather) into the saved game
  • Ability to use and load a new type of custom object: surface and ground textures
  • Support complex map shapes (instead of just removing the limit, in which case you still have square maps)
  • Other limits: staff count, sprite count, map element count, ride/shops count
  • Preview image - basically a screenshot at the time the save was created
Edited by Broxzier
  • Like 1
Link to comment
1 hour ago, X7123M3-256 said:

This is already implemented, it's just not enabled by default.

He mentioned "working lights" as far as I know the old branch for this is broken.

2 hours ago, Broxzier said:

Another thing: - Allow some shops/stalls to sell multiple kinds of items

Custom stalls can already do this from what I've seen. Many of the counter/invisible stalls sell multiple objects that weren't used together in even the expansions.

Link to comment
17 minutes ago, imlegos said:

He mentioned "working lights" as far as I know the old branch for this is broken.

It's in develop now, so you don't need to use that old branch anymore. It's a bit temperamental (sometimes path lamps fail to illuminate and I'm not sure why) and it still has the same issues it did before (performance, lights showing through the GUI), which is why it isn't turned on by default, but it more or less works and is still worth having IMO, particularly for viewing finished parks (it's a pain when building, but it turns off if you disable day/night cycle which you can do from the options).

Edited by X7123M3-256
Link to comment
26 minutes ago, X7123M3-256 said:

It's in develop now, so you don't need to use that old branch anymore. It's a bit temperamental (sometimes path lamps fail to illuminate and I'm not sure why) and it still has the same issues it did before (performance, lights showing through the GUI), which is why it isn't turned on by default, but it more or less works and is still worth having IMO, particularly for viewing finished parks (it's a pain when building, but it turns off if you disable day/night cycle which you can do from the options).

Where is the option to turn it on? I don't see it in the config file.

Link to comment

It's not in the config file, it's a compile time switch. You need to define __ENABLE_LIGHTFX__ when you compile the game, and then in the options window make sure you have "Drawing Engine" set to "Software (hardware display)", and the day/night cycle enabled. I've found that that sometimes it doesn't seem to work properly and not all the lights come on - I've been trying to trace the cause of that issue because I never had the problem before it was merged.

Edited by X7123M3-256
Link to comment
23 minutes ago, X7123M3-256 said:

It's not in the config file, it's a compile time switch. You need to define __ENABLE_LIGHTFX__ when you compile the game, and then in the options window make sure you have "Drawing Engine" set to "Software (hardware display)", and the day/night cycle enabled.

So, why bother merging it into develop if you have to re-compile the game anyway to use it?

Link to comment

Because the old branch was forked from a really old version and wouldn't merge cleanly with develop. The guy who originally submitted the PR had stopped developement, and it wasn't (and isn't) ready to be turned on by default. Why it's a compile time switch and not a config option I don't know, but presumably @IntelOrca does (maybe it wasn't easily done or they don't want it in the binaries they distribute?). My understanding is that the plan is to eventually fix the issues with it and then remove the ifdef.

This is the PR that merged the light effects

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...