The scenery and building systems need to be unified into one, coherent concept. Not two separate chunks with two separate sets of rules.

AndyC1

A
Yeah, but it wouldn't be better if sometimes this just made all your guests disappear from a savegame, or made your savegame stop working, or any number of other bugs. if we chose to support it, it'll require a great deal of work and verification. It's not just "change a zero to a one" and everything works.

Cheers

Andy
 
Yeah, but it wouldn't be better if sometimes this just made all your guests disappear from a savegame, or made your savegame stop working, or any number of other bugs. if we chose to support it, it'll require a great deal of work and verification. It's not just "change a zero to a one" and everything works.

Cheers

Andy

Aye exactly that :) that is why I am hoping although it isn't on the list to come back now it may do in 6 months or so. Please let it be so.
 
Cheers Andy. The response Is appreciated :) does mean that we can "never say never" however certainly not on the list. I would however suggest if you made a pole with 20 features this would be in the top 2 along with more terrain textures in biomes which we also know is a technical reason. Just hope and prey that maybe by next xmas we have these things as it would be killer.

It's probably

  1. multiple textures in one biome
  2. collisions dectection of scenary
  3. Rotation of all items except shops/benchs
  4. multiselect tool to be more similar to select tool in building mode

I mean beside that you have waterfall/whether but those i mentioned are really common.

I think no ammount of "its not possible" will make people stop asking for all texture in one biomes.
 
Last edited:
It's probably

  1. multiple textures in one biome
  2. collisions dectection of scenary
  3. Rotation of all items except shops/benchs
  4. multiselect tool to be more similar to select tool in building mode

I mean beside that you have waterfall/whether but those i mentioned are really common.

I think no ammount of "its not possible" will make people stop asking for all texture in one biomes.

Aye I would agree with your list. I would then end up placing a lot of the management side of things to follow on from those ones.

And no it wont but it's a starting point at least. Hey if the dev from one of their other projects done the FLAC files cause he wanted them so much maybe one of them will sort the textures for the PC Devs [big grin] start adding your PC suggestions to the Elite Dangerous forum hahaha [mouth shut]
 
It's probably

  1. multiple textures in one biome
  2. collisions dectection of scenary
  3. Rotation of all items except shops/benchs
  4. multiselect tool to be more similar to select tool in building mode

I mean beside that you have waterfall/whether but those i mentioned are really common.

I think no ammount of "its not possible" will make people stop asking for all texture in one biomes.
+1 for this list !!!
(But with a "No collisions checkbox in every rides window" instead of "Collisions detection of scenery")

Yeah, but it wouldn't be better if sometimes this just made all your guests disappear from a savegame, or made your savegame stop working, or any number of other bugs. if we chose to support it, it'll require a great deal of work and verification. It's not just "change a zero to a one" and everything works.

Cheers

Andy

I hope you "chose to support it" like you said AndyC, even if it's not just "change a zero to a one" and that it require "works" like ... well ... everything (The code of a program does not magically appear, everybody know that, it was needless to say, we all have a job too) but what is in this list is really important for the "creative" part of the game.

Because for now :
- I just can not make a "winter" land using snow texture on the ground in a sunny sandbox park (or the opposite)
- I'm not free to put everything I want close (or inside) a ride because the collision system can not be disabled
- I just can not make inclined buildings made with ... walls
- I'm forced to make many useless blueprints, that I delete later, to copy/paste something that is made with several objects (which is what happen 90% of the time when you want to make something nice and complex, using dozens or even hundreds of different grids) because I can not merge objects together inside one grid, or duplicate more than one object at the time with the multiselect tool

I'm not saying that is not "a great deal of work and verification" as a developer, but that "It would be better to be able to do it" as a player/user [yesnod][up]
 
Last edited:

AndyC1

A
I can't help but feel a little ignored here. [haha]

Sorry - I don't have time to reply to everything, I've got patch notes to proof read ;-). But seriously this is a product of how the two systems developed over time. I'm aware that the integration between buildings and scenery could be better, and no doubt going forward we'll look at ways to improve them. It's more a hangover from when we had completely different people working on Scenery (which was basically freeplacement of models in the simplest possible way, back when we were getting the very first versions of the Planet Coaster engine up and running) verses Building (which we always designed to be much more complicated, with things like correct merge pieces being applied, snapping to existing pieces etc.).

So yes, it certainly could be better - we do take your feedback on board, we could all do with a Christmas Break right about now, but after Christmas we'll be regrouping and working out what our next round of "quality of life" features will be, and I'll certainly raise these issues then.

Cheers

Andy
 
Sorry - I don't have time to reply to everything, I've got patch notes to proof read ;-). But seriously this is a product of how the two systems developed over time. I'm aware that the integration between buildings and scenery could be better, and no doubt going forward we'll look at ways to improve them. It's more a hangover from when we had completely different people working on Scenery (which was basically freeplacement of models in the simplest possible way, back when we were getting the very first versions of the Planet Coaster engine up and running) verses Building (which we always designed to be much more complicated, with things like correct merge pieces being applied, snapping to existing pieces etc.).

So yes, it certainly could be better - we do take your feedback on board, we could all do with a Christmas Break right about now, but after Christmas we'll be regrouping and working out what our next round of "quality of life" features will be, and I'll certainly raise these issues then.

Cheers

Andy

Brilliant response Andy, thank you for that :) Merry Christmas by the way to you and all the team there.
 

AndyC1

A
- I just can not make a "winter" land using snow texture on the ground in a sunny sandbox park (or the opposite)
Apologies, but this isn't going to change any time soon. I've spoken before about why this is, and nothing has changed since then. The biomes will still be locked to specific textures. And we've taken on board your feedback about wanting to be able to pick from a texture palette rather than using our pre-authored Biomes, and while I can't promise anything regarding that just yet (you know how we roll - we only like to commit to something when we're 100% sure we can deliver it), but watch this space!
- I'm not free to put everything I want close (or inside) a ride because the collision system can not be disabled
The collision system is used for lots of different things in game, so this isn't an easy option at all. We make many spatial tests during the game, which won't work if things are intersecting, so again this isn't just a checkbox and turning a flag off somewhere. I know this is an often requested feature - rest assured it's been recognised here at Frontier. But it's perhaps not as easy to implement as you might think.

Cheers

Andy
 
Apologies, but this isn't going to change any time soon. I've spoken before about why this is, and nothing has changed since then. The biomes will still be locked to specific textures. And we've taken on board your feedback about wanting to be able to pick from a texture palette rather than using our pre-authored Biomes, and while I can't promise anything regarding that just yet (you know how we roll - we only like to commit to something when we're 100% sure we can deliver it), but watch this space!

The collision system is used for lots of different things in game, so this isn't an easy option at all. We make many spatial tests during the game, which won't work if things are intersecting, so again this isn't just a checkbox and turning a flag off somewhere. I know this is an often requested feature - rest assured it's been recognised here at Frontier. But it's perhaps not as easy to implement as you might think.

Cheers

Andy

Again another great post and feedback from you Andy, you really on top of it all today :) so thanks for all the info on these things.
 
Andy, thanks a lot for your insight about these issues, it's a breath of fresh air to get some feedback about the features people have been debating for so long.

It just makes me really wish there had been some sort of dev blog where you guys could share interesting programming snippets as I'm sure the game is full of them, like the wooden supports, coaster physics, AI etc... though I realise Frontier would probably prefer to stay secretive about these [wink]
 
Andy, thanks a lot for your insight about these issues, it's a breath of fresh air to get some feedback about the features people have been debating for so long.

It just makes me really wish there had been some sort of dev blog where you guys could share interesting programming snippets as I'm sure the game is full of them, like the wooden supports, coaster physics, AI etc... though I realise Frontier would probably prefer to stay secretive about these [wink]

Yes that would be pretty cool
 
Sorry - I don't have time to reply to everything, I've got patch notes to proof read ;-). But seriously this is a product of how the two systems developed over time. I'm aware that the integration between buildings and scenery could be better, and no doubt going forward we'll look at ways to improve them. It's more a hangover from when we had completely different people working on Scenery (which was basically freeplacement of models in the simplest possible way, back when we were getting the very first versions of the Planet Coaster engine up and running) verses Building (which we always designed to be much more complicated, with things like correct merge pieces being applied, snapping to existing pieces etc.).

Bah, I hate when that happens. Holdovers from early builds screw everything up. [cry] That is a pretty reasonable explanation for how such bizarre differences would end up in the final game, but it's unfortunate all the same. [up] I really hope by the time Planet Coaster's first expansion pack shows up stuff like this is unified. For now I can continue working with multiple buildings to get multiple grids and make modifiable scenery chunks I GUESS [tongue]

The collision system is used for lots of different things in game, so this isn't an easy option at all. We make many spatial tests during the game, which won't work if things are intersecting,

I don't really understand what this means, but it sucks to hear. It seems odd to me that in a game where collision means nothing but visuals and people movement (which already don't care about collision except between each other!), collision would be key to literally anything. I can see coaster to coaster train collision, coaster train to etc collision, people to people collision, and coaster to people collision, but there's nothing else in the game insofar as I can tell that depends on collision being a thing. So it's a little hard to understand what you mean by that. Elaboration would be appreciated but this is not the thread for this topic anyway and we've already gone off topic with elaborations a few times here [haha]

Personally I just can't get past "Rollercoaster Tycoon 3 let us do it in the base game" even though I know that's not exactly fair. :(

Thanks for the input all the same, I'm really glad you guys give input on stuff like this.
 

AndyC1

A
No problem - it's difficult to give examples, and again while I know how some of this works I'm no Physics Programmer :). Specifically I know we make spatial queries against our spatial database (which is populated by collision mesh data from items) for things like queue scenery evaluation. Anything where you might want to make "spatial queries", as in the relationship of one object to another. I'm not saying it's impossible, just again it's not as easy as unticking a box or removing a physics material from items or something.

Cheers

Andy
 
So the aura scenery gives off has some sort of dealings with collision, things like that. The item's collision data is tied to its position, and is used to see if it "collides" with the area around rdes and junk? Something like that? That does still sound really odd to me but I guess there's probably a reason for it. [up]

Here's hoping it's not so hard that it's outside the realm of possibility. There's so much cool stuff we could do. [knockout]

Here's also hoping that adding an emote to every sentence I write is making them come off more how I intend to instead of sounding super serious and scary. [mouth shut]
 
Last edited:
No problem - it's difficult to give examples, and again while I know how some of this works I'm no Physics Programmer :). Specifically I know we make spatial queries against our spatial database (which is populated by collision mesh data from items) for things like queue scenery evaluation. Anything where you might want to make "spatial queries", as in the relationship of one object to another. I'm not saying it's impossible, just again it's not as easy as unticking a box or removing a physics material from items or something.

Cheers

Andy

Ah see that makes sense. However does this mean that you code specifically so that for instance the collision mesh to detect distance of said item (such as scenery piece) however you allow it to be placed within the collision mesh. Can you have a mesh that maybe isn't "Collision" but just spatial evaluation to calculate a formula result of the queue scenery. And thus with that as long as element 'X' is within the area it is counted but it can sit on top of the ride for all it cares?

- - - - - Additional Content Posted / Auto Merge - - - - -

So the aura scenery gives off has some sort of dealings with collision, things like that. The item's collision data is tied to its position, and is used to see if it "collides" with the area around rdes and junk? Something like that? That does still sound really odd to me but I guess there's probably a reason for it. [up]

Here's hoping it's not so hard that it's outside the realm of possibility. There's so much cool stuff we could do. [knockout]

Here's also hoping that adding an emote to every sentence I write is making them come off more how I intend to instead of sounding super serious and scary. [mouth shut]

Actually the emotes are very much better for that [happy]
 
Ah see that makes sense. However does this mean that you code specifically so that for instance the collision mesh to detect distance of said item (such as scenery piece) however you allow it to be placed within the collision mesh. Can you have a mesh that maybe isn't "Collision" but just spatial evaluation to calculate a formula result of the queue scenery. And thus with that as long as element 'X' is within the area it is counted but it can sit on top of the ride for all it cares?

Yeah, thats how I figured it worked. Obviously the game needs to know "where" something is and if it's "inside" that "aura" to be able to figure out if it's "pretty" or "not". """""""" But tying that to collision models themselves seems a bit clumsy. [haha] I can imagine without intending for there to be a no clip feature they wouldn't have had a second thought about it though. [knockout]
 
Top Bottom