|
|
|
but that won't let you line up the oceans if you use a non-standard ocean height in order to go deeper than 20 m.
It was a toss up for me whether this was a bug or a feature request, but I considered chunks of ocean sticking up out of normal ocean-level was really a low-priority bug. YMMMV The problem, though. Is that height can't go below 0. So if this proposal was implemented, everything could only be 20m at most below the water.
That would completely destroy things like undersea kingdoms. /me does not vote. Sorry. WarKirby, you are assuming I am proposing to change anything but the way in which ocean levels are stitched across sim boundaries, which I am not. 0m would still be the bottom of the sim, whether 0m (local) was 128m below (general) sea level or 127m above. The whole sim is shifted up or down relative to surrounding sims to line up sea-level, but to change anything within the sim would cause too much breakage (as you have spotted). With my proposal, sim-crossing ('physically' and visually) would require a quick add/subtract based on local sea-level, but nothing local to the sim would change.
runs across this entry in an unrelated search Great idea, though I can't help thinking it won't be easy to make it so that, say, 26m high in one region = 76m high in another. I could be wrong but I'm imagining it would add significant complexity to their already not-so-good region crossing code. Maybe after they clean up that code (which I thought I heard they're working on lately) they'll get around to this. Perhaps they'll even change it so that "0" actually means sea level (but they'd have to warn of that beforehand due to the risk of breaking content).
Another, perhaps more important note is that this would really have to be implemented as a separate feature from the current water level settings, as I suspect a number of people like being able to use the shiny Linden water to simulate how the water table rises as you go upstream, and/or being able to create below-sea-level valleys (like the 86-meter-deep Death Valley IRL). Once again it's a great thought; the infinite ocean-water shouldn't have to be stuck looking like it's only 20 meters deep. This would really help an "undersea kingdom" to look like it's under the enormous sea, not just under a high, deep lake. Yes, Al Sonic is right: separate 'water level' and 'sea-level' would be needed. Thanx for spotting that!
Actually, that might solve the backward-compatibility issue - all present sims get set at 'sea level'=0 and 'water-level'=20 (or whatever their manager has set their region 'sea level' to). This should stop breakage of existing scripts that expect these values. The region-manager can set the values otherwise after they have made sure their scripted items can handle it. (In this case 'sea-level' is being used to refer to the BOTTOM of the sea, which is not my intended usage, but is fine for backward-compatibility purposes. Ideally, sea-level would represent grid-wide ocean water level with 'below sea level' on the negative side of the Z-axis. Most of the time (post-compatibility) when water level is not equal to sea level, the water is not actually sea - it might be lake, river, inland sea, lava, sludge, etc. Hmmm: per-parcel water level settings! Interestingly, the SL client itself doesn't seem to have an issue with a negative Z-value for AV position: OpenSL was letting me build and fly around sims with a -128 to 127 elevation the other week - their physics engine couldn't parse the terrain collisions, though! So the SL physics engine would have to be able to handle it (try to get this into Havoc 4??). Also, if negative z-axis was explicitly supported, that would make a better place to put the 'privacy basement' in feature requests like SVC-1138 as a section from, say, -8192 to -4095 could be reserved for such use instead of sticking it at some arbitrary height in the air (obviously scripts would have to be made 'basement compatible' by not borking on negative Z-values, but since the basement would be a new feature that such scripts are moved into, rather than applied to scripts that are already in-situ, breakage should be a minimal issue (some scripts might break, but only upon the user explicitly moving them to a negative altitude, so they can be debugged/replaced at the time - no one is going to log on one upgrade to find a sim-full of broken scripts). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Alternatively, you can download the terrain RAW file, edit it in a graphics editor, and reupload it. You should be able to simply adjust the "lightness" of the first (or second) channel to add height uniformly.