News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

Buildings in water

Started by Leartin, May 19, 2017, 04:54:29 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Leartin

I'm really surprised about that one. Appearently, only factories can be placed in water, while other buildings (tried it with cur only) can not?


Does not look as good on grass as I wanted it to :(

Yona-TYT

I would love to see this incorporated. ;D ;D ;D

If not possible, but I would like to see ground objects too.  8) 

An_dz

What's that? Dragon Ball Z? :D

Yona-TYT

Quote from: An_dz on May 20, 2017, 02:55:40 AM
What's that? Dragon Ball Z? :D
Where will Master Roshi be?.  8)

JHSDF

I was surprised your choice of building! I never thought it is so famous in other country!

I made such building as factory before.
This is not vehicle but "floating ship museum" as factory.


It behaves both factory and port in the sea. So I can put it anywhere, and call passenger as worker with
boat.



If cur can be put on the sea, a lot of buildings will be port.

So, How about make this building as factory as a test?
I think it is better to put it on the sea as factory than as cur,Especially you would like to use transparent on the coast.
My website has some addon for pak128.japan
http://kyuujitujieitai.wixsite.com/simuexpo

twitter https://twitter.com/kyuujitujieitai

Leartin

If there won't be another way, I will make it a factory of course. Not sure if a factory with neither input nor output could exist, but it could always be a power plant, or perhaps an end consumer for magazines.

Still, I think it's strange that it would not be possible to place anything but factories in the ocean.

Quote from: Yona-TYT on May 20, 2017, 03:44:51 AM
Where will Master Roshi be?.  8)
Probably at the Tenkaichi Budokai? I would have to pixel it to see if he is there...

Ters

Quote from: Leartin on May 20, 2017, 06:53:32 AM
Still, I think it's strange that it would not be possible to place anything but factories in the ocean.

Apart from a very small number of military installations, the only off-shore installations in real life are industrial, so why would anyone even consider spending time on writing code for anything else? Even that little building in the first post isn't built on water, it is located one some tiny one-tile island (in principle).

Flemmbrav

I could imagine lighthouses and shipwrecks(attracts divers) as nice "offshore" buildings too.

Yona-TYT

Quote from: Ters on May 20, 2017, 12:06:24 PM
Apart from a very small number of military installations, the only off-shore installations in real life are industrial, so why would anyone even consider spending time on writing code for anything else? Even that little building in the first post isn't built on water, it is located one some tiny one-tile island (in principle).

No matter if it is in the water or on an island, the important thing is that they can be placed on the water without having to modify the terrain.

I can not imagine how many tourist attractions or ground objects  you can build this way. ;)


It is best left to the imagination of the artist.  :P 

Leartin

Quote from: Ters on May 20, 2017, 12:06:24 PM
Apart from a very small number of military installations, the only off-shore installations in real life are industrial, so why would anyone even consider spending time on writing code for anything else? Even that little building in the first post isn't built on water, it is located one some tiny one-tile island (in principle).

There are several things wrong with your assessment.
First, you are talking about off-shore installations. However, Off-shore installations would need to be about 20 kilometers away from any shore. I don't believe in a strict scaling in Simutrans, but even if you would go with one square kilometer per tile, that would be 20 tiles. Sure, especially with larger maps, you might have an ocean somewhere were a reasonable large area of water would actually be off-shore, but I tend to believe on most maps, there is more on-shore water tiles then off-shore water tiles. Especially with lakes (which, as far as I know, can't even be off-shore no matter how large they are)
If we are talking on-shore installations, real life gives us a lot more to work with. From something as simple as a buoy over common stilt houses to more prestigious buildings:


Then there is the question whether it needs to be an installation at all. If Ayers Rock is a valid curiosity on land, why not place Khao Ta-Pu in the sea? Alongside anything stationary that comes out of water and does not need to be buildt on by the player, like smaller islands or rocky, perhaps with something unique on them (old lighthouse?), reefs, or even an animated ground object of a blowing whale. Even a small fish could make an interesting object, just so it's not a wasteland - after all, wastelands in Simutrans are not wastelands either. Both deserts and arctic can be full of stuff, even though realistically, they should be pretty much empty.
If the statue of liberty was made as a land attraction, it could be anywhere inland. I'd rather have it in the middle of the ocean than in the middle of some desert.


So let's say this again: We do have a parameter "climate" which could be set to "water". We have several different kinds of objects for which a climate can be set. It just stands to reason that, if water is a climate, and a climate can be set, we should be able to set water as a climate, so stuff appears in water. That's not the case, and it really feels more like a bugreport than a feature request.

Ters

Both Statues of Liberties I know of are on land, although next to water, which is a concept Simutrans knows about. While I am no expert on lighthouses, all I know about are on land, even if some are surrounded by water on all sides. Unlike oil rigs and fish farms, it is possible to have underground structures beneath them.

Quote from: Yona-TYT on May 20, 2017, 01:12:00 PM
It is best left to the imagination of the artist.  :P 
Quote from: Leartin on May 20, 2017, 02:52:09 PM
it really feels more like a bugreport than a feature request.
The functionality of Simutrans is made by developers. If they don't happen to imagine it, or are told about it, it won't exist. (It also won't exist if the developers do not want it, but I'm going into that aspect here.) Computers aren't magic. Everything they do have to be painstakingly designed and coded by developers. (Developers are in turn restricted by what the hardware designers had in mind.)

The developers wanted, or the community requested, the ability to have industry at sea. So a developer made it so. Industries, while reusing the generic building concept to some degree, function differently from other kinds of buildings. (Well, all types of buildings function differently from each other.) Nobody specified how other buildings should work with that climate, so the developer had no way of knowing how to implement them. A bug is when things don't work the way they were intended to, but in this case there was at the time no intention in the first place.

Flemmbrav

#11
As for Lighthouses: They can stand near stones too, this one by example feels like it's in the middle of it's water.
https://de.wikipedia.org/wiki/Leuchtturm_Kalkgrund

And of course there are ships (Lightvessels) for such services too, marking shallow or stones.

So anyways, now we do know that people are requesting it, and further we have a concrete example (first post of this thread) of a building fitting the climate "water".
Is there a developer out there who is now able to imagine buildings other than industrie beeing build on water?  ;)

Leartin

Quote from: Ters on May 20, 2017, 03:33:33 PM
Both Statues of Liberties I know of are on land, although next to water, which is a concept Simutrans knows about. While I am no expert on lighthouses, all I know about are on land, even if some are surrounded by water on all sides. Unlike oil rigs and fish farms, it is possible to have underground structures beneath them.
Nobody said otherwise. All I'm saying is that I'd rather have the statue of liberty in the middle of an ocean than in the middle of a continent, since it would still make more sense to me. Same for lighthouses - rather out in the sea than somewhere in the middle of a continent.

While simutrans does know how to build something at shore (climate=water, location=land), it only knows that at least one tile must be next to water. Furthermore, it does build on land-level, not sea-level. That's the same with lakes, but at sea, this means there will always be a wall straight up to land level before the object even begins. So not only do you have to create the object in a way that fits the landmass rather than the sea, it also needs to have some reason to have a straight wall down to the sea. If you could force objects to be placed at sea level, and force them to be rotated so one complete side faces the water, it would be very different, as the sea could be incorporated in the object and a smooth transistion could be used. All in all, I find that pretty useless as-is, but that'S not the point here.


Quote from: Ters on May 20, 2017, 03:33:33 PMA bug is when things don't work the way they were intended to, but in this case there was at the time no intention in the first place.
It would be better to define a bug by things not working the way they should. When you, as a user, start a program and it crashes on you, you will not second guess the intentions of the programs creator, crashing is not what it should do, so it's a bug. Furthermore, do you really know whether it was not intended to make it work for all buildings, but whoever made it work for factories simply forgot? Unless it was clearly intended NOT to work, it could still be considered a bug, even if intention had anything to do with it. Not that anyone even claimed it would be a bug in the first place.

Ters

Quote from: Flemmbrav on May 20, 2017, 04:19:13 PM
As for Lighthouses: They can stand near stones too, this one by example feels like it's in the middle of it's water.
https://de.wikipedia.org/wiki/Leuchtturm_Kalkgrund

And of course there are ships (Lightvessels) for such services too, marking shallow or stones.

So anyways, now we do know that people are requesting it, and further we have a concrete example (first post of this thread) of a building fitting the climate "water".
Is there a developer out there who is now able to imagine buildings other than industrie beeing build on water?  ;)

Lightships, buoys and small rocks could be interesting would be interesting maritime equivalents of ground objects. The latter two only makes sense on shallow water, though. And random placement of the former two will probably be a lot more jarring than the typical ground object.

Quote from: Leartin on May 20, 2017, 05:15:32 PM
While simutrans does know how to build something at shore (climate=water, location=land), it only knows that at least one tile must be next to water. Furthermore, it does build on land-level, not sea-level. That's the same with lakes, but at sea, this means there will always be a wall straight up to land level before the object even begins. So not only do you have to create the object in a way that fits the landmass rather than the sea, it also needs to have some reason to have a straight wall down to the sea. If you could force objects to be placed at sea level, and force them to be rotated so one complete side faces the water, it would be very different, as the sea could be incorporated in the object and a smooth transistion could be used. All in all, I find that pretty useless as-is, but that'S not the point here.

That is however something I do see the point in. If it could require water on all sides, it would work for the original image. However, it would be on ground, not water, as you would expect to be able to build an underground structure right beneath it.

Quote from: Leartin on May 20, 2017, 05:15:32 PM
It would be better to define a bug by things not working the way they should.

It is a bug if something does not behave the way the programmer has been told it should. (Although the original meaning is strictly speaking that the computer does not behave the way the programmer programmed it to do, because literal bugs, well moths actually, have entered the computer and short-circuited it.) It is not a bug if something doesn't work as the customer expects because the customer failed to tell the developer. As a professional software developer, this distinction is important. Bugs can typically be fixed by the developer alone, and might be fixed free-of-charge due to warranties and similar. New features on the other hand requires that the customer places an order, which includes both a description of how it should work and money. There is some form of middle ground where the program crashes due to the customer failing to specify how certain conditions should be handled. Ideally, the developer should have spotted this and contacted the customer, so the developer is partially responsible. However, it is also the customers fault, and may require more time and money to fix.

Bugs are not necessarily more important than new features, however. We have a substantial list of known bugs at work, some of them ten years old, but the customer wants us to work on other things. (The customer being another part of the organization means that the organization has to pay either way. Developers with fully independent budgets might not have a choice.) Simutrans is free, so you don't have to pay either way, but also comes with no warranties of any kind. (And I am on both sides of the table in this regard.)

prissi

All those buildings were delibarated build in exactly that place for reason, and almost all offshore structures are industial or infrastruture related. Moreover, Simutrans will likely fail to build in a reasonable place for such buildings. So go to the scenario edior and replace the water by land (if it is shallow enough that is) and place you structure on this single tile.

And yes, factories with neither input nor output are possible, and have been used before (like to old smoking vulkano in former pak.japan). They are, however, not build atomatically.

Leartin

Quote from: Ters on May 20, 2017, 06:26:08 PM
That is however something I do see the point in. If it could require water on all sides, it would work for the original image. However, it would be on ground, not water, as you would expect to be able to build an underground structure right beneath it.

We could go in that direction, but I think that would ultimately fail due to the many restrictions. For example, a single tile surrounded by water can only exist (naturally) in lakes with flat shore, never in the ocean with sloped shore. But even if such a tile exists on the map, the placement algorithm - as it is now - would never find it in time. Which means you would either need to manually place it, or the placement algorithm for such objects would look for water area (object_size+2)², raise the land in the middle of that area, and place the object there. At this point, it would be very similar to just spawning objects in the water though.

As for the matter of underground structure right beneath it: Look no further than the classic game start, a coal mine. Logically, what you see on the land would only be the tip of the iceberg, while most of the mine would be underground. Yet, you can build right underneath it in Simutrans.
Why would a building where you would expect to build underneath but can't be a problem, while a building where you would expect not to build underneath but can isn't?

Quote from: Ters on May 20, 2017, 06:26:08 PMIt is a bug if something does not behave the way the programmer has been told it should. (Although the original meaning is strictly speaking that the computer does not behave the way the programmer programmed it to do, because literal bugs, well moths actually, have entered the computer and short-circuited it.) It is not a bug if something doesn't work as the customer expects because the customer failed to tell the developer. As a professional software developer, this distinction is important.
Besides that story about literal bugs being wrong (The moth was in the Mark II around 1950, while the term "bug" was used by Edison when he invented the light bulb, as if it was already established, hard to imagine that literal bugs could have an impact on the not so filigree electrical wiring of the time...
Let's take a step back. For custom software, it's important whether something is written in the contract or not, and since the word bugs and features come closest to that, it makes sense to use them in that context. Though even then, it's not that clear-cut. A company I worked at ordered a website with a search engine. The search engine we got did not work with Umlaut (ÄÖÜ). It was not specified in the contract, yet it was on the developer to fix it for free - since both partys of the contract were German, Umlaut would be normal letters, and them not working would be the same as XYZ not working. If it had been two English companies with the same contract, it would have required extra payment. And the end say in the matter would have had a court. Can it really be that whether something in a program is a bug or a feature is decided by a court and can change depending on who orderer/made the software? Sure - for custom made software it is, since a bug is an obligation, a request is not.

It makes no sense in free software without a clear objective where nobody pays noone. There is no contract, there are no assignments, nothing to pin down exactly what the software is supposed to be capable of and what not. Hence differentiating between bug and feature request the way it is done for contracted, custom software is impossible - there is never an obligation after all, even if software crashes, devs don't HAVE to do anything about it. Essentially, devs could choose willy nilly whats a bug and whats a feature based on what they want to fix.
Even with paid software, if it's from the shelf, same issue applies. The user wants to do something and the software does not let him. It does not matter whether the programmer botched code or was never told to make it work in the first place, since either way the user has software that does not do what he wants. Use Alpha Transparency in PNGS in Internet Explorer. IE6 could not do it at all, but IE7 could show alpha transparency in PNGs correctly. IE7 also allowed to change the opacity of a PNG, that worked as well. However, if you changed the opacity of an image with alpha transparency, IE7 would drop the complete alpha transparency and only use the opacity setting - contrary to how other browsers at the time worked. That's clearly not what's supposed to happen, as anyone would agree - NOT calling that a bug, no matter how it came to be, would serve no purpose except to act as an excuse not to fix something that clearly requires fixing.

Outside of custom-made software, bugs and feature requests blur into each other, and seperating them serves no purpose. Mind that I posted in Extension Request and said it feels like bug report, noting that this is somewhere in the blurred area, rather than posting it as a bug report, which in case of Simutrans is mostly crashes and UI.

Ters

Quote from: Leartin on May 23, 2017, 11:46:12 AM
Why would a building where you would expect to build underneath but can't be a problem, while a building where you would expect not to build underneath but can isn't?

Because something you expect to work but doesn't is more obvious than something you don't expect to work but does. This discussion is itself proof of that. Nobody has been particularly eager to prohibit construction under coal mines.

An_dz

OT (somewhat): This discussion is really bugging me.

Leartin

Quote from: Ters on May 23, 2017, 02:42:47 PM
Because something you expect to work but doesn't is more obvious than something you don't expect to work but does. This discussion is itself proof of that. Nobody has been particularly eager to prohibit construction under coal mines.

That's just because it is status quo.
Coal mine existed before a complex underground building mode was introduced. They might have existed before straight tunnels, I don't know. Obviously, noone at that point thought it would be required to think about what's underneath the surface. I remember that oil platforms existed at a time where the only water was the sea, and you could not dig below sea level. I don't think a complex underground mode existed either, so there was no way to build anything under those oil platforms - it would not have mattered if they appeared as an island.

When complex underground building was introduced, those things were not important enough to change anything about it, they were left as they were. And that makes sense to some degree, since underground mode should not have been hindered by the complexity of how to decide under which buildings is how much basement.

So it would not have been a problem to get buildings on water like ten years ago, and if that was the case, it would not have changed due to another feature introduced later. But now, since the other feature is established, it's not possible anymore - even though the outcome would be exactly the same. That makes no sense to me.

And, by the way, coal shafts were talked about - in context with other uses of underground mode, including limiting stations to either over- or underground, adding underground extension buildings etc..
This is because it's pretty useless by itself, and only makes sense if the idea of underground mode is changed. It started out completely invisible, turned into a model-railway-like functional system that looked pretty bad, and having dedicated underground stations starts moving it towards being a secondary 'realm' to actually play with and build on. So, if buildings could be underground (in the form of extension buildings), it would make perfect sense to have mineshafts, but since pretty much nothing in the game has "depht", they are not required, simple as that.
Which is, by the way, the same with water. Water can be just that vast, empty thing, a seperator between landmasses - much like it is in games like Anno or Settlers. Or it could be an interesting playing field in it's own right, like in HoMM3.
In order to make the sea interesting, many things would need to be done. Seperated ocean 'dephts' as sort-of different climates, for example, so we could make sure oil platforms are actually 'off shore' and anything more likely in shallow water only appears in shallow water. It could also be used for ship-depht. If a ship requires deep water, it could not normally reach a harbour at the shore. The player would need to either change the water depht at shore to place a deep enough harbour (which requires the ability to change land levels under water), or place special harbour-platforms further out at sea. (Much like a station in orbit for spaceships). Using code similar to that for woods, reefs could be planted underwater and serve as barriers, so the player would have to pick ships not only with 'cost-per-unit-per-tile', but also think about ship-size, since they would use different routes. There is a lot of room for improvement.

Ters

Most players don't know that[citation needed], nor is it important to my argument. They either expect to be able to build under coal mines and are happy to see that it works. Or they don't expect it to work, never try it and live blissfully unaware of the possibility. Or the don't expect it to work, but are then told it does work. But even then, they rarely get so worked up over it as those that expect something to work only to find that it doesn't.

Of course, things are a bit different when things can unexpectedly be used against them, but I can't see how that is the case here.

Leartin

Ouch. I really should start testing stuff before I pixel :(



This is a mockup. The Idea was to make the head a factory and the arms it's fields. However, it appears fields don't spawn in water. But strangely enough, if it is near a coast, invisible fields spawn on shore - You can't see them, but when you click on the location, the factory interface comes up.

Would it be much trouble to allow fields in water, or would they all spawn atop each other due to water-objects not having a "hitbox"?

DrSuperGood

I guess the idea of water fields is not entirely a silly cosmetic thing. One could have fisheries, salmon farms, oyster farms etc which could use the ability to expand.

The game has no concept of hit boxes, instead logic literally checks grounds of a tile until it finds something it does not like. This is why buildings can spawn under elevated ways (no check) which cannot have elevated ways placed above them (does a check).

Leartin

Silly cosmetic thing? :o That's a squid. You can harvest ink from it. The more arms it holds over water, the more ink you can milk, since it's common knowledge that squid ink comes from the arms.
It's not a silly cosmetic thing, no sir, this is a silly functional thing!  ;D (but a fish farm is on my todo-list, and it would have used


Yeah, it's not a hitbox, hence quotation marks. But the term is so commonly known, I think it conveys the issue well enough. (Or perhaps you are not aware that you can place water factories overlapping each other, as if there is no check or nor marker for where the building is?)

IgorEliezer

Quote from: Leartin on October 07, 2017, 10:08:40 PM
The more arms it holds over water, the more ink you can milk, since it's common knowledge that squid ink comes from the arms.
It's not a silly cosmetic thing, no sir, this is a silly functional thing!  ;D
Welp, the Randomness Lounge is leaking again. :o

Vladki


Ters

Squid? Too many arms look too long compared to the head for a squid.

Leartin

Quote from: Ters on October 08, 2017, 08:18:55 AM
Squid? Too many arms look too long compared to the head for a squid.
Well, it's definitelly a Kraken. An octopus has a round head and eight arms, while a squid has a triangular face with fins, eight arms and two tentacles. So given the head shape, I'm inclined to believe that Kraken is a squid which simply does not show it's tentacles.
There are seven arms visible, so the amount fits - assuming one arm is under water. As for the length of the arms, it's really hard to decide how long the arms of a squid that size would be, since it's obviously not a known species. The colossal squid has arms about a fourth the length of it's head, while the giant squid has arms about the same length as the head. It's not too far-fetched that the kraken-squid has even longer arms compared to it's head.

However, I promise if the fields in water are implemented so it can be in the game, I'll immediately send some scientists to it for DNA testing. Perhaps some divers to see if there are tentacles under water (the reason they are not pixelled, besides the workload, is that I can't control which fields would appear. If each field is an arm and there is a max of 8 fields, it's always correct. Add tentacles, and you can never be sure. I don't fathom you'd implement something like "max_field[ i ]" to limit how many of a specific field could appear?)

DrSuperGood

QuoteI don't fathom you'd implement something like "max_field[ i ]" to limit how many of a specific field could appear?)
There is already a limit to the maximum number of fields a factory can have. No farms overgrowing the world! If it works mechanically like you want is another question.

Leartin

Quote from: DrSuperGood on October 08, 2017, 02:03:13 PM
There is already a limit to the maximum number of fields a factory can have. No farms overgrowing the world! If it works mechanically like you want is another question.

Farms wouldn't overgrow the world either way, since there is a max radius of 10, AFAIK hardcoded. And of course there is a limit, in this case the limit would be set to eight. But the point is a destinct limit for each kind of field, which I don't think would be too useful in other cases anyway.

Ters

If there were fields for different products, a limit for each could be useful. A farm can grow many different things. But I can't think of much besides farms that work this way.

Leartin

But if there were fields for different products, the code to generate the fields would need to support that as well, building the "right kind of field" when it's needed instead of a random one.

Ters

After giving it some more thought, a maximum for each field would not be needed, since the production of each goods is defined as a fraction of total production. Unless that also changes, the game should just spawn fields for the product which has less than its target share of the fields.

Ves

Quote from: Ters on October 08, 2017, 05:46:00 PM
If there were fields for different products, a limit for each could be useful. A farm can grow many different things. But I can't think of much besides farms that work this way.
Made me try to think of some examples:

A farm:
you have the "cow" fields generating livestock.
you have 1 "milkmachine-building" field.

Sawmill:
You have the "tree" fields.
You can have "sawdust" fields generating sawdust.

"Lego buildings":
If you make each field a building, connecting to the neighbor buildings/fields, you might want to have only a ceratin amount of certain buildings. Would also benefit from additional rules, like field rotation, field change image dependent on which edge is connected to factory/other fields etc.

wlindley

Detroit's Packard Plant, although now a poster-child for urban decay, does remain frozen in time as an illustration of its expansion between 1903-1958 very much along the "keep adding another building on" farm-field approach to industry.  Starting at the right in this screenshot from Google Maps, they just kept building on (leftward) for decades:


Leartin

Quote from: Ves on October 08, 2017, 07:14:07 PM
A farm:
you have the "cow" fields generating livestock.
you have 1 "milkmachine-building" field.
Each field that increases the number of cows would logically increase both the production of cows and milk, while the milking machine wouldn't really raise either. It might as well be part of the central main building, rather then somewhere on the outskirts of a large farm, having it as a field would just be for visual diversity. For that, it only needs to have it's own "min_fields" of one.

Quote from: Ves on October 08, 2017, 07:14:07 PM
Sawmill:
You have the "tree" fields.
You can have "sawdust" fields generating sawdust.
I'm not sure why a sawmill would have tree-fields at all. But even so, you need saws to cut logs into boards, which also generates sawdust and are probably located in the main building. Hence again, tree-fields would raise the production of both, boards AND sawdust. A "sawdust"-field could be a giant log-blender, but if the trees "produce" boards and the main-building saw is quick enough to cut them all, having a log-blender would reduce the production of boards.

Quote from: Ves on October 08, 2017, 07:14:07 PM
"Lego buildings":
If you make each field a building, connecting to the neighbor buildings/fields, you might want to have only a ceratin amount of certain buildings. Would also benefit from additional rules, like field rotation, field change image dependent on which edge is connected to factory/other fields etc.
I can somewhat agree to that, but rather than adding all that additional functionality to fields, I'd try to allow additional buildings to spawn. See here: http://forum.simutrans.com/index.php?topic=17310

Most factories in Simutrans only have several outputs because it's essentially the same thing intended for different consumers, or because the same process produces two different goods (like a ranch with cattle and milk). So in most cases, having different fields wouldn't do too much. Unless you diversify the goods - if a woodcutter wouldn't produce "logs", but pine, maple, fir, etc., you could accurately represent that in the fields with the different types of trees. Though that would require changes to the way factories demand goods as well, since a toy factory might not accept pine, but why would it need maple AND fir to start producing? And we are in complicated territorry again :(
A more interesting thing to see would be if we a factory would be smart in placing fields for storage vs. fields for production. So, when there is a demand that requires more fields, only place fields that increase production. If fields add too much production compared to storage, get a storage field.