News:

Simutrans Sites
Know our official sites. Find tools and resources for Simutrans.

Changing Buildings

Started by Leartin, August 14, 2017, 11:28:13 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Leartin

Quote from: Ters on August 13, 2017, 02:01:02 PM
Some of the city attractions in pak64, such as the old school and old town hall, should really have existed before they became attractions. Basically, what was once just a building should suddenly become an attraction once there were few enough left of them on the map.

If every citybuilding could be an attraction if it's old enough, you would get attractions that are just some empty storage space in a former industrial destrict, or something silly like that. And the description would not change automatically either, so it would still read as if that old blacksmith does the best horseshoes in town.

It would be much better if there was a "school" that, at some point in time, becomes an "old school".

So I propose 3 new parameters:
1) replacement = [object name]
This is a reference to another object via name that's supposed to replace 'this' building. If the referenced object does not exist, the replacement is simply ignored. Same happens if the referenced building has a different size. There should not be any other requirements, so a city building could become an attraction, industry etc. and vice versa. So the RES-Building "school" can become the CUR-Building "Old School". Or a land-cur "boring mountain" could become the land-cur "ski paradise" with many more pax - which would allow land-curs to be 'build' later in the game by replacing placeholders which existed, but were not worth a connection.
Industry would of course require the most careful handling and most programming - I'm not even going into all the problems it might bring. But it should still be very useful to upgrade the visual design of factories, as they quite often look out of place.
2)replacement_time=[year?]
This parameter would tell us WHEN a building is to be replaced. Akin to introduction and retirement dates, it might be broken up in year and month. If no replacement time is set, but a replacement object is referenced, the retire date should be used.
3)no_upgrade=[0/1]
For citybuildings, essentially the same as if you bought that building, it will not be replaced by buildings of a higher level due to city growth. This is intended to be used with buildings that don't spawn on their own, but can spawn due to being referenced by other buildings (since chance would not be used). The idea is that you could have buildings that are buildt in the 18th century, and if they still exist in, say, 1950, they will be replaced by very similar buildings which reference their status as heritage conservation and won't be removed for skyscrapers. Perhaps you could say it's a "light" version of turning the building in attractions?

Ters

I wasn't thinking that every old building should become an attraction, not that I had spent much time thinking about it at all. Perhaps more that any type of building that is an attraction of type old something should have a regular building preceding it in the timeline that was just something, and was more common. However, it turns out there isn't as many "old" city attractions as I first thought. Most were "rural attractions" or not even attractions at all. Which leads to the fact that the English translation at least for pak64 makes every other building seem like an attraction, some bigger than others.

That attractions are spawned by city growth is also quite odd for several of them. For some of them, it should be the other way around. Some of the land attractions in pak64 should also logically cause a town to spawn around them. The common theme being that they are fortifications.

And this replacement thing is something I miss for industries more than anything, or rather than anything else.

prissi

That is a very eurocentric view. Most building here in Japan are rather considered worthless, when they reach 30 years of age. Just last month they cleared an old farm house near a river surrounded by cherryh trees to make place for a parking lot.

So there must be a threshold, i.e. the building must survive a certain time after their retirement date. Then it can be just make owned by the public player and then be protected as well.

Ters

I don't think age in itself has anything to say. It is when people suddenly realize that a particular building style is about to be wiped from existence that they hurry to preserve some of the few that are left. Sometimes the scope is entire neighborhoods, and not just individual buildings, but I didn't think of bringing that into Simutrans.

Leartin

Quote from: prissi on August 19, 2017, 02:56:34 PM
That is a very eurocentric view. Most building here in Japan are rather considered worthless, when they reach 30 years of age. Just last month they cleared an old farm house near a river surrounded by cherryh trees to make place for a parking lot.

So there must be a threshold, i.e. the building must survive a certain time after their retirement date. Then it can be just make owned by the public player and then be protected as well.

If a building is not worth being refurbished, just don't create a refurbished version of it, and it won't ever refurbish. If that is the case for all japanese buildings, then pak.japan probably won't use that functionality. But since most paksets are eurocentric, most paksets could use it.
There does not need to be a threshold, at least not in the game code. The creator just needs to set the replacement date correctly. Sometimes, a replacement date equal to retirement date makes sense. For example, think of a parking spot with cars. The parking spot itself would not change much over time, but the cars would. It would not matter at all when the parking spot was buildt, when the time for different cars is reached, they change.

The protection thing is more of an afterthought to protect really old buildings. The straightforward way would probably be to have something like "no_upgrade_after=[date]", which could be implemented completely seperately from self-replacing buildings. But I have an issue with the idea of descriptions, and which tense to use. Descriptions about how this morning a wench stumbled over the chamber pot of the houselord wouldn't quite make sense if the building was still around in the 21 century.

prissi

So it would mean that for every building you want to upgrade you would need to specify a name on that description? Or would any upgrade to a current building with the same level do?

But I am not sure if such a replacement would not lead to more uniform cities than what we already have. Whereas protecting "old" buildings (maybe counting rather from introduction data?) would rather increase cites appearance. Such a protection would also naturally lead to some "old town squares" typical for so many cities in Europe.

Leartin

Quote from: prissi on August 21, 2017, 01:15:59 PM
So it would mean that for every building you want to upgrade you would need to specify a name on that description? Or would any upgrade to a current building with the same level do?

Only to one specific named building. The main use would be to show the progression of the same building through time, though it's open-ended on purpose, so it's up to pak creators how to use it.

The attached buildings, for example, are essentially the same. The first is for an earlier time period, in which most buildings are depicted either raw brick or white. In later periods, buildings become more colorful. A few year after the first versions retirement, all those buildings change to the second version, because owners decide to do a paint job - not far fetched.

Another thing are modern elements on old architecture, like solar panels on roofs. In reality, there are obviously many old buildings where these things get attached later on, but in current Simutrans, you always have to create the finished building. So either you get some solar panels around 1900, or you get new pre-war-architecture in 1990. With this, you can take existing buildings and create versions of them with solar panels on the roof, ready to let them be changed around 1995.

The other way around is possible as well. In the 1940s, you might want to decorate all commercial buildings with neon signs. Older buildings might change around that time to include lightcolor text, and after a while, in the 1960s, all changes back to versions without neon lights.

Except for factories, this should not cause any kind of trouble at all. It would be just as if a player would switch to public hand, delete the building, and set the replacement building in it's stead. Only some basic information needs to be retained (eg. rotation).

Quote from: prissi on August 21, 2017, 01:15:59 PM
But I am not sure if such a replacement would not lead to more uniform cities than what we already have. Whereas protecting "old" buildings (maybe counting rather from introduction data?) would rather increase cites appearance. Such a protection would also naturally lead to some "old town squares" typical for so many cities in Europe.
If it is used in the ways I described above with "all commercial gets neon lights" - yes, the appearence would be more uniform, but that's because it would be less chaotic, not because there would be less variety - hence it's "good uniformity".
This is not supposed to be a replacement for the current city growth, it's a supplement. Even if a building changes, as long as the building it changes to does not have a different level, it should not affect city growth at all. Not even the "no_upgrade" flag would cause bad cities, unless it's put into everything.

However, when I thought of a fixed replacement time, I thought it would simply be much easier than counting the age of each building. If replacement after a certain amount of years was possible as well, this could have it's own merit. You could have each building with "no upgrade"-flag, but after 10 years it turns into an older version of itself, with faded colors, lost plaster, bit of mold - and that's replaceable. Again, the main point is the flexibility it gives to pak designers. Specifically for protecting old-age buildings, there might be better solutions, but it would be a much, much narrower path with less usability.

makie

Quote from: Leartin on August 14, 2017, 11:28:13 AM

So I propose 3 new parameters:
1) replacement = [object name]
This is a reference to another object via name that's supposed to replace 'this' building. If the referenced object does not exist, the replacement is simply ignored. Same happens if the referenced building has a different size. There should not be any other requirements, so a city building could become an attraction, industry etc. and vice versa. So the RES-Building "school" can become the CUR-Building "Old School". Or a land-cur "boring mountain" could become the land-cur "ski paradise" with many more pax - which would allow land-curs to be 'build' later in the game by replacing placeholders which existed, but were not worth a connection.
Industry would of course require the most careful handling and most programming - I'm not even going into all the problems it might bring. But it should still be very useful to upgrade the visual design of factories, as they quite often look out of place.
2)replacement_time=[year?]
This parameter would tell us WHEN a building is to be replaced. Akin to introduction and retirement dates, it might be broken up in year and month. If no replacement time is set, but a replacement object is referenced, the retire date should be used.

Need this for factory  :exclaim:

This  allow to define factory chains. Start with a special piece of green meadow.
This change in replacement year (starting year of the company) to a few shed.
Then expand in year xxxx, or  modernized and so on.
May be retire  as the real model do, or change to a touristic attraction, with no production.

Leartin

Servus makie :D

Just to stress this again: While it would work relatively simple for normal buildings (using "delete" and "build" in quick succession), factories would be a whole different beast, since the replacement should not be a completely new entity - it would need to remain contracts, goods in store, goods on route, the productivity should be in proper relation... so all in all, if it was only for factories, it would be better if it was one object with changing graphics.
Doing it with Object Replacement for factories would only be a good idea to be consistent with replacement of other buildings, if that ever comes.

Ters

Doing replacements for factories is the only good idea in my opinion. Other buildings are mostly getting replaced already, and I don't care about what the replacement looks like or is, as long as it keeps generating passengers and mail. (I can spend a long time playing with buildings set to transparent and not noticing.) But these wind mills with their crappy production rates really need to invest in some more modern machinery.

Leartin

I consider it blasphemy to play with hidden buildings ;D to each their own.

What if a factory wasn't a building?
What I mean is - let's have buildings of a new, more general type, that have all the common characteristics (dimensions, rotations,... defined replacement) and additionally a "multiplicator" or "level".
And a factory would have all the information about a factory (goods, production rates, boosts,...) but instead of the image definition, it would link to buildings by name, allowing for a wildcard character (*).

Whenever a factory is supposed to be buildt, it chooses one of the linked buildings based on their chance and introduction/retirement dates and tries to place that building. The production rate is altered based on the "multiplicator" of all buildings it consists of.
Because Building and Factory are seperated, the building can be replaced while the factory stays the same. Allowing the wildcard character would mean that additional graphical representation of the factory could be added with no need to alter the source. Eg. a factory that makes flour from grain could link to "factory_mill*". The base pakset perhaps only includes "factory_mill", but someony could create an Add-On called "factory_mill_windmill" or "factory_mill_lasergrinderofthefuture". It would, of course, also work with the Annex-Idea from another thread.


...but that's the kind of stuff I dream about at night, as a reasonable suggestion it just seems too much.

Ters

Actually, a factory isn't a building in the code.

Leartin

Err... I mean, I know it's not an object of type building. But isn't it still dependent on building? Meaning pretty much everything introduced for buildings (eg 5 seasons) works for factories as well? Or does it just behave similar, but is technically completely seperate?

makie

Quote from: Leartin on October 03, 2017, 06:02:26 PM
Just to stress this again: While it would work relatively simple for normal buildings (using "delete" and "build" in quick succession), factories would be a whole different beast, since the replacement should not be a completely new entity - it would need to remain contracts, goods in store, goods on route, the productivity should be in proper relation... so all in all, if it was only for factories, it would be better if it was one object with changing graphics.
Doing it with Object Replacement for factories would only be a good idea to be consistent with replacement of other buildings, if that ever comes.

No!
It should be done the same way as if the player delete the building and build the new one. All contracts, goods in store, goods on route should go down. Because the new building may be have other goods, contracts, production rates.

An entry in the log for the player is useful. He have to adjust the Routes.

May be, the used goods change from wood to plastic.

May be, the factory change to a museum and produced nothing any more.

And it is possible to define a placeholder that change at a given time in a factory or something else. 
Place the placeholder in saved games for start, painted maps with real cities  or scenarios.

Ters

I think most players won't like their nicely set up routes to become worthless because industries suddenly mutate into something completely different in an instant, whether they play for the challenge of logistics or just for show. It is not justified by realism either. While plastic may replace wood in many applications in real life, the change is not sudden. A factory may gradually switch from making stuff out of wood to making them out of plastic, probably adding new suppliers, but keeping the consumers, or a new factory doing plastic stuff will come and outcompete it over a few years.

Quote from: Leartin on October 03, 2017, 06:58:54 PM
Err... I mean, I know it's not an object of type building. But isn't it still dependent on building? Meaning pretty much everything introduced for buildings (eg 5 seasons) works for factories as well? Or does it just behave similar, but is technically completely seperate?

In the pak format, factories have a nested building definition. In the game world, a factory has one or more buildings representing it. (In the game, a building only covers a single tile.)

makie

Quote from: Ters on October 03, 2017, 08:20:41 PM
I think most players won't like their nicely set up routes to become worthless because industries suddenly mutate into something completely different in an instant, whether they play for the challenge of logistics or just for show.

This spams not coincidentally, to annoy the player. This is a tool for Pak and Addon maker, to design events and adjust long running epochal games to centurie changes.
This happens only, if the designer of the Pak plans this.

If the replacement_time year is far past the retire_month/year then a short range player doesn't see replacements.

It make no sense to spam coincidentally placeholders, this make only sense in designed save games.   

Leartin

Quote from: Ters on October 03, 2017, 08:20:41 PM
In the pak format, factories have a nested building definition. In the game world, a factory has one or more buildings representing it. (In the game, a building only covers a single tile.)
Isn't that true for Curiosities, Townhalls, Station Extensions, Docks,... and if it ever comes to multitile-citybuildings, Res, Com and Ind as well?  :o
Which information belongs to the actual, one-tile-building of the code, and which is only in the since-its-not-a-building-what-is-it-called overhead? Is the "building" of the code more than just the graphics definition of one tile?

...though I guess that should make it easier to exclude the nested building definition in the pak format and link to it instead, right?

Ters

Quote from: Leartin on October 04, 2017, 04:53:56 AM
Isn't that true for Curiosities, Townhalls, Station Extensions, Docks,... and if it ever comes to multitile-citybuildings, Res, Com and Ind as well?  :o
Which information belongs to the actual, one-tile-building of the code, and which is only in the since-its-not-a-building-what-is-it-called overhead? Is the "building" of the code more than just the graphics definition of one tile?

Stations have something encapsulating all the buildings making up that station (platforms and extensions), but as far as I can tell, there is no game object binding other buildings together. (Nor does the link appear to be as direct as it is for factories.) Their only link is ultimately pointing to different parts of the same building descriptor from the pak file format, but that is stateless.

The fact that factories something else than just the buildings seen in the map means that it should be somewhat easier to replace all the buildings while keeping all contracts and graph histories as long as the old and new factory descriptors have the same supplies and products. One would need to tweak the production rate in the factory object, as each factory instance takes the basic production rate from the descriptor and adds a random deviation, or upgrading would be eye candy only.