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.

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).

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.)

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.

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?

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.

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.

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.

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.

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.

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"?

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).

Silly cosmetic thing? 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! (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?)

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?)

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.

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.

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.

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:

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.

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.

"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.

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.

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:

Fields and buildings are quite different things in Simutrans, for whatever reason. Fields do not interact with stops. If such a complex was made in Simutrans using fields for growth, the poor player would have a hard time figuring out which building is the building and which are just fluffy "fields".

Growing factories is an interesting idea, but perhaps more related to industrial evolution. They probably were not using the same production methods when they started as when they closed. (Although that could explain why they closed.)

We have some buildings in water in pak128.german, but only factories(3yards, swimdock, oilrig, fishing area). Buildings with no function, and I´m not shure, maybe on one field(?), could be realized also as ground/ moving objects, I think. It has a speed-option, but never tested, if it works with speed=0.

I have no Facebook-Account, but I also vote for swimming curiosities, maybe swimming citybuildings .

/Sry, now seen the first page, idea with ground objects already exist.

To my knowledge, nothing stationary besides factories can exist in water. This includes all kinds of buildings (curiosities, citybuildings, monuments, headquarters, townhalls), non-moving ground objects and fields. Honorable mention to elevated ways, which can be placed on shallow ocean, but not on deep ocean and not in lakes.

But I think there is more that could be done instead of just allowing other buildings in water. It probably won't, but hey, let's put the idea out there for an "update aquatic"

Step 1: Make water a "location"

Currently, water is many things, among which it is a "climate". Lake-water and sea-water are indestinguishable, except for the edges (sloped vs. flat). I think it would make more sense if lakes would be part of the same climate as the land around them. Flooding a tile would not change it's climate information, just it's "location" information. In the case of the current map generation, lakes would adapt the climate of their surface height level.

Since they are different climates, they can have different graphics. This allows for crystal blue mountain lakes and murky green tropical lakes - all of which could have much less waves then the actual seawater, as they are still.While we are at it: Lakes need a size restriction. Mostly because otherwise, you can have huge bodies of water on a map that was not visible in the preview and unplanned in custom maps.

So what about the "water" climate? I think that should become an "ocean" climate - different word to avoid confusion. The ocean climate would work exactly like all the other climates, except that it's completely covered by water upon generation. Ocean would have it's own land texture as well, on one hand for shorelines which currently use desert texture, on the other hand in case someone raises the ocean floor (Raising and lowering land shouldn't change climate, at least as a setting) or drains part of it.

Let's talk compatibility for a second: I would not mind if "climate=water" would still work and be interpreted by the game as "climate=ocean". The difference for those objects would be that they won't spawn in lakes (since lakes are not ocean), and objects with the location "land" may spawn in a dried up ocean. To maintain a more accurate behaviour, instead "climate=water" could be interpreted as "climate=ocean", while "climate=water; location=land" could be interpreted as "location=shore".If there is no texture defined for land in the ocean climate, it would use the desert texture instead. Even in paks where it isn't sand like in the german one, it's a coast-texture, which makes just as much sense.

Another thing: Since water would be a location within a climate, it could be affected by seasons. Water itself might not change, just like the ground on land does not change (regretably), but there is no reason there can't be ice on an oil rig.

Step 2: The Water Waytype

It was already talked about many times: Ships should be divided into riverboats and large ocean vessels, without being as complicated as in Extended. I think the waytype can be used for that distinction. Similar to "tram_track", I suppose the waytypes "fresh_water" and "deep_water" in addition to simply "water". Rivers and canals may have any of the three waytypes as defined in the dat. For tiles with "location=water", there would be an additional setting for which depht levels count as freshwater, water and deep_water, similar to the climate settings. For lakes (=water other than in the ocean climate), these depth settings can be disabled, such that it's always freshwater. Keep in mind here: While it would be set up like the climates, those would not be climates. The information which tiles has which climate is saved, and can be changed with a climate tool. Whether ocean water counts as freshwater, water or deepwater is not saved and solely depends on the distance between water surface. Hence changing the depth of ocean water would also change the water subtype.Vehicles with the waytype "fresh_water" can only navigate ways of the waytype "water" or "fresh_water". Vehicles of the waytype "deep_water" can only navigate ways of the waytype "deep_water" or "water". Vehicles of the waytype "water" can navigate all three waytypes.

This would be backward compatible, while also allowing to confine some boats to rivers/canals and others to the open sea. While river-bound ships could be balanced somewhat like cars (partly available ways, not direct), ocean-ships would be balanced more like planes (no waycost, mostly direct route). It also allows for a freshwater-depot (can only be buildt on canals/rivers) and a deep_water-depot (only on water tiles), just like it works with the tram depot.

Step 3: Populating

Straightforward, since that's the whole point of the thread: Things should be able to be buildt, and spawn, in water. But with above changes, there would be a different quality to it. We can stop talking about the ocean and offshore, and instead simply not use the climate=ocean for anything that would not make sense off shore. For example, we could have venetian citybuildings spawning in the water. Same with stilt houses. (yeah, yeah, citybuilding algorithm wouldn't allow it, since "n" needs to be bare land, so you would need to add "w" as bare water or something...)As for ground objects, without the harsh conditions of wave and saltwater, there are many many more possibilities, from waterlilys to reed islands to a patch of mangroves (trees with location=water? Why not?)

The problem of "what's underneath" has a relatively simple solution. Add a tag "is_island". If active in an object for the water, it would not be buildt in what's defined as "deep_water". Additionally, upon placement, the floor underneath is raised to reach the surface while remaining a water tile. Hence those islands would only appear in shallow water, and there would be ground underneath them, but they would not require an actual island.

Since it is not possible to build stop in water (and also not very realistically), I do not think this will get much approval. But you can make a factory with not production (like the wind mills) and those can be placed in water as well.

I mean... we are talking about enabling buildings in water, and stops are buildings. Furthermore, the same arguement could have been made for factories, so the same solution could be applied if needed.

When Mark Ferrari started out making graphics for LucasArts, he was told he couldn't use dithering, since it wouldn't compress. He created a beautiful twilight scene with dithering. Two month later, dithering could be compressed, and graphics changed from Zac McKraken to Loom.So I guess I need to make a mockup

Strictly speaking, the building is on a rock, and that rock - while it could be called "land" itself - is not on land. Unless you count land that is covered by water, in which case an oil rig is just as much on land, somewhere deep down.

Changing the words does not change the wishes. We might as well talk about buildings on land surrounded by water, or buildings on land under shallow water, but it does not change what we wish for.

Changing the words does not change the wishes. We might as well talk about buildings on land surrounded by water, or buildings on land under shallow water, but it does not change what we wish for.

Those are very important differences in terms of how things work in Simutrans. It is therefore important to use the words that accurately describe the wish.

First of all, whether it is buildings on land surrounded by water or buildings on shallow water, that makes it different from the off-shore industries Simutrans already have, as they can be built on water of any depth. It makes them more similar to elevated roads. You may build underground buildings directly beneath them, unlike buildings residing on water of any depth.

Secondly, a building on land surrounded on all sides by water means that there is a ground tile underneath it. If it is demolished, you end up with a tile of bare land. A building built on shallow water means that only water is left behind if you demolish it.

Thirdly, if the buildings must have ground underneath them, then it is important to make it clear whether such buildings should spawn only on existing islands, or whether the game must go through the trouble of creating islands specifically for such buildings when it wants to spawn them.

Those are very important differences in terms of how things work in Simutrans. It is therefore important to use the words that accurately describe the wish.

People want buildings (and other objects) placable on a water surface.

It is that simple.I currently use the original island as a factory. Therefore, the same thoughts apply. Should it only be placed in shallow water? Should the ground underneath change upon placement?If it does matter for factories, than the game is already in need for a change in that regards. Allowing other buildings in water wouldn't change the existing need.If it does not matter for factories, then neither does it matter for any other kind of building, so they would not require a change in that regard to be made.

That's not to say there can't be extra settings for that. But they are just not as vital as you make them seem.

Do you think of some real thing that exists in the middle of deep ocean? I think that only the "fish swarm" can. Oil rigs need connection to the bottom, although as the technology improves it can be deeper and deeper. But everything else I can think of has to be on real land even if a very small piece, surrounded by shallow water. So an adjustment of landscape generator, to produce an occasional volcanic island would be the right thing.

People want buildings (and other objects) placable on a water surface.

It is that simple.

It is never that simple in my experience. Developers who think so get heat from the users for not delivering what the user wanted, only what the user said/wrote that he wanted. So asking follow-up questions to get all the details straight is instinctive to me. Even if I'm not the developer on the case, just to help other developers out.

It is never that simple in my experience. Developers who think so get heat from the users for not delivering what the user wanted, only what the user said/wrote that he wanted.

In paid development, certainly. In Simutrans, it's baby steps, and not each step needs to be done by the same developer. The first step would be to put buildings in water. In a second step, one could implement further restrictions. Again, those are not vital - I wouldn't mind a lighthouse in the middle of the ocean any more than I mind an oil rig in an alpine lake, both are equally stupid.

So asking follow-up questions to get all the details straight is instinctive to me.

Huh? Maybe indicate them with a question mark? I see no questions. At best, I see statements about what you'd want as a user. At worst, I see a personal opinion presented as if it was facts.But let's turn them into questions - then I can answer them:

Quote

Wouldn't buildings in shallow water or surrounded by water be different from the off-shore industries Simutrans already have, as they can be built on water of any depth?Aren't they more similar to elevated roads? Shouldn't you be able to build underground buildings directly beneath them, unlike buildings residing on water of any depth?

Answer: It's uncertain what artists would create, therefore it would be unwise to generally disallow anything from being buildt on water of any depth. While the things on the surface of a very deep ocean are limited, we should remember that the same is true for off-shore industry, and most paksets have but one example: An oil platform.Additional parameters to limit the dephts at which water objects can be placed would be a nice addition, if only to ban oil platforms from shallow water. Even better would be a destinction between lakes and ocean.As for tunnels, I'm not sure you can build them underneath every object that's supposed to be in shallow water. Might be the ground is just mud and sand, too flimsy to hold a tunnel. And drying up the water to dig from above might be a bit silly to place a station under a great barrier reef.

Quote

Since a building on land surrounded on all sides by water means that there is a ground tile underneath it, while a building built on shallow water means that only water is underneath it, shouldn't deleting such buildings have different results (ground vs. water)?

I don't think we can have buildings on land surrounded by water, as they would never spawn. But since such buildings would most likely depict their own piece of land, I'd go with the logic that deleting such buildings deletes the depicted land as well, leaving shallow water behind. This would not be stranger than an island turning into a sandsquare when it's deleted.

Quote

If buildings must have ground underneath them, shouldn't it be made clear whether such buildings should spawn only on existing islands, or whether the game must go through the trouble of creating islands specifically for such buildings when it wants to spawn them?

While I doubt that those buildings would have ground underneath them in game terms, the same logic could apply to creating shallow water out of deeper water. That is, if the object indicates via parameter that it wants to do that, since we shouldn't assume. And if so, there might be need to state how much deeper the water can be.

However, another nut to crack is what even is "shallow water", since that depends on the scale the player plays the game at. Essentially, if the player plays a world map, there might not be any shallow water. If the player plays a map of a small country or region, most water on the map would be either lakes or near to a coast, hence shallow. Therefore, it might not be a good idea to define shallow by the depth level alone, but allow the pakset and the player to have their own settings on how many depht levels are shallow, just like they can decide how high up the snowline is. Both to allow for lighthouses and to disallow oil platforms.

Okay, so pointing out things that make people think through aspects they either have not have thought through before or have not made clear that they have thought through before and which I as a developer would need to know in other to pick the right solution to the issue is instinctive to me. (I do generally present it as what-if cases and examples, not questions in a grammatical sense.)

I almost wrote that iterative development was more common in actual businesses, although more in self-paid companies like Google, Facebook, Twitter or even Netflix. With Simutrans, I'm more used to developers coming with a finished solution and it's either included or it's not, and that is that for years. The scripting is the only exception I can think of, although even that seemed pretty fleshed out when it appeared.

It is not like developers are crawling all over this forum looking for something to do. I was hoping that if they knew exactly what was wanted, and what might be accepted, that it might be more attractive and have a greater chance of success. It is very demotivating to hear that what you've spent much time making isn't what the community wanted. This seems to be the bane of several attempts at two-lane roads.

Well, I've used the term for water of depth 0. The major difference is between a depth of 0 and 1. Depths of 1 and greater are conceptually similar, since then there is a volume of water below the surface. Maybe we need a clearer term for water that is just at the surface. This is what you get if you just drag the water climate tool across a piece of land.

As for tunnels, I'm not sure you can build them underneath every object that's supposed to be in shallow water. Might be the ground is just mud and sand, too flimsy to hold a tunnel.

Currently, the only things that can't be tunneled through is water and air, which is why I thought it might be important as to whether you should be able to tunnel up under these buildings. There is a whole host of other issues that crop up if one starts to wonder how buildings at sea affects things Simutrans does not (yet) have. Fortunately, Simutrans doesn't take vertical distance into account for stops, so you might build a subway station a kilometer below the water under a bungalow on a (floating) sand bar, and it would still serve it just fine. However, some players would likely be confused why they can't build anything directly below it. There should obviously be land there.

I've just realized one implication of scale that somehow I didn't think of in all the time I've been playing Simutrans: If a tile is 1km square, it surely is 1kx cubic, as well, meaning except for rivers and hand-drawn water, water is 1km deep near the shore.

I've just realized one implication of scale that somehow I didn't think of in all the time I've been playing Simutrans: If a tile is 1km square, it surely is 1kx cubic, as well, meaning except for rivers and hand-drawn water, water is 1km deep near the shore. Now, carry on in discussions, don't mind me.

The physics in Simutrans Extended with pak128.Britain and default settings has an implied height of 5m per (half-height) level, which seems like a decent number to work with for all non-graphics purposes. Actually, that might even be consistent with the graphics as well.

I almost wrote that iterative development was more common in actual businesses, although more in self-paid companies like Google, Facebook, Twitter or even Netflix. With Simutrans, I'm more used to developers coming with a finished solution and it's either included or it's not, and that is that for years. The scripting is the only exception I can think of, although even that seemed pretty fleshed out when it appeared.

What doesn't happen is someone providing a tool with no function by itself, just so other developers can continue from there, to achieve a premeditated goal.What does happen is that someone provides a new usable function, and someone else at a later time develops it further.For example, when tunnels were implemented, they went in on one side and straight out the other. Later, an underground mode was established. At a time before tunnels, if someone would have asked for tunnels, it would have been pointless to discuss an underground mode, or make that a requirement for tunnels to exist. Tiny improvements come over time, eg. underground transformers, and I'm certain that chapter is not finished in the long run (underground extension buildings, depth restrictions etc.)Or a more recent example: Shorthand dats were implemented by kierongreen, and it was a great change by itself; and then An_dz added ways and vehicles to the logic.

It is not like developers are crawling all over this forum looking for something to do. I was hoping that if they knew exactly what was wanted, and what might be accepted, that it might be more attractive and have a greater chance of success.

I see myself as an "expierienced requester" at this point. And in my expierience as a requester, I tend to get better results with simpler things. Asking too much seems to be overwhelming, so it's best to lure a dev in with something simple, and once they are hooked, you start talking about all the implications and possible additions No, really, pointing at an issue or a lack of something is usually much better than suggesting a solution, especially to get things going. Almost as if people don't like to be told what to do.

It is very demotivating to hear that what you've spent much time making isn't what the community wanted. This seems to be the bane of several attempts at two-lane roads.

More important than just whether something would be liked is whether something would be used. If there are only one or two water-curiosities in each pakset, I'd consider the feature used, but not used enough to need further expansion. (After all, that's the situation with factories). Perhaps if an artist proclaims that they lack another feature for them to use it extensively.But if there are a lot of them, it would make sense to look at what people actually come up with, and how to improve the spawning algorithm to accomodate it. The key here is to balance work between developers and artists. No developer wants to program something that won't be used, and no artist wants to draw something that can't be used.

Well, I've used the term for water of depth 0. The major difference is between a depth of 0 and 1. Depths of 1 and greater are conceptually similar, since then there is a volume of water below the surface.

I assumed as much.But as you can see from other responses, one level of depth can be anywhere between 200m and 3m, depending on your point of view. If it was closer to 200, maybe the zero-depth shallow water in Simutrans would make sense as being only a few meters deep. If it's closer to 3m, that zero-depth water wouldn't wet your shorts when you stand in it. A rock that would reach the surface from 200m depht is unlikely, but from 3m it's not uncommon. So if you assume a level to be 200m, what you think of as shallow water would be a bunch of depth levels for someone who assumes a level to be 3 meters.What should zero-depth-water even be, it certainly doesn't exist in reality (except as "wet ground")?

Currently, the only things that can't be tunneled through is water and air, which is why I thought it might be important as to whether you should be able to tunnel up under these buildings. There is a whole host of other issues that crop up if one starts to wonder how buildings at sea affects things Simutrans does not (yet) have.

You are absolutely right. If, for example, Simutrans gets submarines and underwater landscape, 'floating' islands would become a huge problem. But that problem is not dependent on whether the island is a factory or a building, so even if we don't get buildings in waters, it would need to be solved. The same solution can be applied in both situations, so having or not having buildings in water has virtually no impact on that. It's something that should be done, eventually, but if not, it's not the biggest issue the game has, and it's not an outright requirement.