imlegos Posted January 10, 2017 Posted January 10, 2017 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.) 2
YoloSweggLord Posted January 10, 2017 Posted January 10, 2017 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. 1
X7123M3-256 Posted January 10, 2017 Posted January 10, 2017 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. 1
YoloSweggLord Posted January 10, 2017 Posted January 10, 2017 (edited) 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 January 10, 2017 by YoloSweggLord
cascadia Posted January 10, 2017 Posted January 10, 2017 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.
YoloSweggLord Posted January 10, 2017 Posted January 10, 2017 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.
cascadia Posted January 10, 2017 Posted January 10, 2017 38 minutes ago, X7123M3-256 said: * Swimming pools and water rides. This is what I want to see, along with custom restaurants and stores that spread over several squares and that you can design in game.
imlegos Posted January 10, 2017 Author Posted January 10, 2017 Can't you already do that with stalls and scenery?
cascadia Posted January 10, 2017 Posted January 10, 2017 2 hours ago, imlegos said: Can't you already do that with stalls and scenery? Yes, but they're just stalls with scenery. In my idea, you could have tables for peeps to sit at, shelves for peeps to browse through, etc.
X7123M3-256 Posted January 10, 2017 Posted January 10, 2017 For the tables thing, I think that could be implemented as an additional path object type, like bins and benches.
JJ_Whelan Posted January 11, 2017 Posted January 11, 2017 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. 1
Broxzier Posted January 11, 2017 Posted January 11, 2017 (edited) 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 January 11, 2017 by Broxzier 1
Broxzier Posted January 11, 2017 Posted January 11, 2017 (edited) That doesn't require a new save format. Edit: Another thing: - Allow some shops/stalls to sell multiple kinds of items Edited January 11, 2017 by Broxzier
X7123M3-256 Posted January 11, 2017 Posted January 11, 2017 (edited) 1 hour ago, NightHawk said: - Working Lights for Day/Night cycle This is already implemented, it's just not enabled by default. Edited January 11, 2017 by X7123M3-256
imlegos Posted January 11, 2017 Author Posted January 11, 2017 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.
X7123M3-256 Posted January 11, 2017 Posted January 11, 2017 (edited) 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 January 11, 2017 by X7123M3-256
imlegos Posted January 11, 2017 Author Posted January 11, 2017 Great, now I REALLY wish I had spent the time yesterday to install updates. The wifi I use away from home blocks the ORCT2 downloads.
YoloSweggLord Posted January 11, 2017 Posted January 11, 2017 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.
X7123M3-256 Posted January 11, 2017 Posted January 11, 2017 (edited) 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 January 11, 2017 by X7123M3-256
YoloSweggLord Posted January 11, 2017 Posted January 11, 2017 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?
X7123M3-256 Posted January 11, 2017 Posted January 11, 2017 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
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now