Seriously, It would work if just did an oxygen check. If there is oxygen where you are, just don't do the swimming post effects, and have normal gravity. I can spawn an airtight base underwater, and have oxygen in it- but it still plays the swimming effect.
Right click with your hand drill, select fill mode, and fill the entirety of your underwater base with terrain. After you fill every last spec with terrain, right click again and select drill mode, and now remove all the terrain you just filled in. The terrain replaces the water everywhere the terrain touches. Then when you remove the terrain you are left with open air. No more swimming and you can now properly pressurize your base. It's extremely tedious. Unfortunately this is the only way to remove water. The devs would have to completely change how terrain and water work in order to change this behavior.
They wouldn't have change anything- Just do an oxygen check for the base/ship. If there is oxygen where you are, you are not underwater. It already has the ability to do that. Try it. Build a base underwater, and oxygen and ventilator and turn it on. The debug open says there is oxygen where you are, however it still does the undewater effects and you drown if you take your helmet off. All they need to do is check if there's oxygen and it would work. Literally should be one line of code, but I have feeling their code is spaghetti.
The game can only remove water and terrain on planet generation, and it only works for POI's spawned in by the game. There is no method currently for the game to remove it afterwards, especially not just with an oxygen check and on a player base. So yes, they would have to change how the game handles terrain and water, since currently it only happens when the planet is being generated on first load. I understand that the game knows you have the underwater base "oxygenated", but there is no method for the game to use that info and cause the water to be removed. So this means changes have to happen first, as I said.
Even if it's "only one line of code" to make the "check" there still needs to be many other lines of code to act upon the result of the check, because there is no such thing right now as "remove water when O2 is detected" . Because what @krazzykid2006 explains as workaround to remove water with terrain (then remove terrain) is a complex series of player actions in the game, this would need to be replicated in some manner via code, less the "player" presence and randomness of motion/ action. A function could "clean up" the BA volume this way, but... see next. If terrain had to be re-generated at each physics tick just because the game allows to play around with water it would become unplayable. We all know how long terrain generation takes when starting a game, now this would happen virtually at each frame update, because the game would need to check if a player has done something with water/ terrain all the time and adjust the dataset accordingly. When terrain is generated it is then packed into .dat files, probably in some kind of "chunks" system, to be referred to quickly by coordinates to avoid to maintain the whole terrain in memory. So of course nothing is "impossible" here, it's rather a question of : is it worth all the trouble ? We may think somethink would be cool when analysed on a 1-time occurrence (1 base underwater) but then AI would need to be also adjusted (drones and critters going there or not ? How weapons behave? Lasers? ), it would become problematic in multiplayer (performance killer), inconsistencies would arise when players or explosions (attacks) remove blocks and create openings in walls and water just stays out. Then there would still be the problem of having water inside cockpits : we can't use the "add/remove terrain" trick there, so how would players get their ships/ hvs into their underwater bases without drowning along the way ? And here again, asking for "yet another check" for O2 presence in cockpits to remove water while the ships constantly change coordinates... Honestly we don't have to go into the "spaghetti code" theory to see this whole "water" issue is a pandora box no one would want to commit to open for the little "cuteness" benefits it would yield vs an eternity of bug fixes and player's requests and complaining.
No it should literally be one line of code if it were programmed correctly. Hence why it's probably not. Like I said, it still checks if the base has oxygen in debug- and it does. It is just not taking that into account when it make you underwater. None of the terrain code has to be changed at all, just check if you are in an oxygenated place before you apply the underwater shader. I have a feel they are using all kinds of objects with separate scripts and what not. Unity is kind of mess by itself, and really doesn't teach great coding techniques. void WaterShader { if (doOxygenCheck()) return; //do underwater stuff }
Codeing doesnt work like that Anyway Underwater Building isnt support and not a GameMechanic Till water will be reworked, it wont become a GameMechanic
Um, I have BS in CS and have been a programmer for 30 years. Yes it does. Unless of course the code is spaghetti- which is probably since you build the code into each object instead of having a dictionary and adding objects to it. That why I can't stand Unity, it's easy to make "a game" but impossible to do something this simple? Unity sucks, but you should ask Boundless Dynamics, LLC for help since he seems to be the only person that can write a functional Unity game.
I don't think that the Developers of Subnautica would agree with you. Here you can find a list of 'not-working' Unity-Engine Games https://en.wikipedia.org/wiki/List_of_Unity_games#2019
If water is done with a volume defined at its upper limit by a plane, then of course there will not be any O2 check, only a "helmet on" needs to be done, just like in space or moons. You are inferring that things should have been done in a certain manner from the start, but even then it would not be as simple as you described. It's not like applying a simple texture to an object, because there has to be some way for the engine to determine where the player is (usually with colliders). There is no need to check if player is underwater in space, but the way you simplify this in wording indicates that since there is no O2 somewhere, then "just apply water shader" and players should drown in space... Very funny. Now the interesting part is " do underwater stuff " of course, which will undoubtedly be way more than " one line of code". I do believe lots of similar objects were put in arrays, as can be easily deducted by checking the various .ecf config files and to which classes and categories objects belong. You are in very speculative topics here, because you would need to access the game files to make such an affirmation.
Ok, I'm not trying to be a dick here, and I realize I'm coming off like that, so let me reset and say: 1) I love engines like Unity. They allow otherwise inexperienced programmers to put out games they probably wouldn't be able to make otherwise. I worked for THQ for many years, and we simply didn't have those tools. In fact, we had to write our own engines, data structures, and graphics pipelines. I'm glad that it's easy now. Even VR support is built into Unity. I'm just as hard on others as I am myself. I don't mean to sound like a jerk, I'm just very matter of fact. Ask my wife- she says I just don't put up with ****, and apologize to her A LOT The best off the shelf engine is undoubtedly Unreal, but it's pretty low level. I just wish people would spend time learning classical programming to really understand the engine and build a strong code base that won't have to be re-written half way through when they find out the limitations of the engine. Case-in-point- Freeman: Guerilla Warfare. It's a good game but they started writing the game without a clean plan, and as a result have decided they're going to re-write the entire game because their code base simply didn't work for the game. *Write, edit, rewrite your game design doc. You need to have it fleshed out before a single line of code was written. We usually had about 40 programmers on a game with a clear goal. There was no early access back then. You lost money if you didn't go gold on time (Gold literally referred to the color of the writeable CD ROM you'd send off to the duplicator). I think what Eleon is doing is great, but there are things I disagree with. It's my most played Steam game, so I definitely am only critical as I see some areas that could use improvement and not that the whole game sucks. They've build a very unique game and it's a lot of fun to play. That's fine- my original point was fix issues before introducing new features. Unity is a strange beast- while it lets you get started rather quickly I would be willing to be 1/2 of 1 percent of games that launch as early access on Steam ever make it to gold. I don't think that's hard to disagree with, because if you launch too early, get bad reviews, and it stops selling- you can just stop working on it. That's terrible for consumers and only in some circumstances does it ever work out. Empyrion is evolving and has kept most of its promises, even though their sales are probably dwindling off- good on them for keeping their promise.
But this is not true. Right now they MUST be checking a whole bunch of variables to know whether or not you're drowning. Is the atmosphere breathable? Are you wearing a helmet? Do you have oxygen? Are you underwater? And does you base/ship have oxygen? Is it turned on? Is there oxygen in the tanks? Are there tanks? Is it airtight? Are there venilators? Is the power on? Is there fuel/battery available? right now, it needs to be checking all that. Not just: If (underwater && helmet_on) return true; And that's not speculation- that's how the game works. I'm just asking them to optimize that code, and add a check for if you're in the base or a ship, and it's underwater, if it has oxygen available and powered- don't drown. Do you know what I mean? I'd love to see the code they do for all those checks above. It should be generic and mostly automated. My problem with Unity is you can just add some of those parameters to an object itself - like "Space around Akua Breathable: false". So each object would have these isolated parameters that need to be external to be able to see them from other objects. Unity tends to have you isolate systems which makes it MUCH harder to have those systems reliably interact with each other. Colliders are a way to solve for collisions, not find the player's position. He can be in a base and not be touching any colliders. Although maybe you mean inside a bases extents? Sure, that's a great early check- if he's outside of it, you simply move onto the next object and save processing power. I think I know what you're saying. And I didn't say check if the player is underwater in space.... but you know what? Yes. That makes code extensible. Maybe they want to add an alien that shoots a glob of goo at you and and you have to swim out of it. You don't want to hardcode ANYTHING. Everything should be generic. Actually forget I said anything about shooting a glob of goo- this isn't porn. But you get my point There are lots of tricks from the "old days" that were similar to optimize speed- for example, if a polygon's points are counter-clockwise, after rotating it, you don't bother doing any more processing because this is the back side of a polygon so you know you wouldn't render it anyway. Nowadays, You GPU takes care of that, but you still want to limit what you make the GPU do by not just throwing everything at it. I am not sure what you mean. In OOP, objects are kept in collections. Maybe you're not talking about that. Sorry my brain is fried, worked all day. I have been kind of a dick on the forum, and I apologize- that's really all I have to add.
I appreciate that, thanks. Personnally I always do my best to focus on the topic. I'm not stupid either : if making realistic underwater environment could be easily done now on top of what exists, I would be a happy camper like many others. I just have what I think are very reasonable doubts as to what can be achieved here, keeping in mind the whole picture. Well I would tend to believe more your first stance, because honestly, even if Unity originates from my own town, I don't like it. Sure it evolved, may be easy for starters, but I prefer lower-level control and in Unity's cases it means a costly license. And to that point, if performance is important, why not go to Unreal ... Unreal is cool too, but a simple project hits gb range and that's a lot of unneeded fluff in many cases. Huge sheep to shave too, so would not be my go-to either. I agree totally : planning is essential, as prototyping. But I completely believe Eleon's statements that they didn't expect their game to go that far when they first started their project, and that given the playerbase enthusiasm they were willing to push forward. Now we both know what this means in the context we are discussing, so I'm willing to give them lots of headroom to try to fit some new organs in that already packed Frankenstein... Same here. No need to make an apology, we're on the same page. I feel there are lots of back-and-forth discussions at Eleon regarding priorities, and surely some solid friendships might have developed over the years, and this makes decisions more difficult. Yes, and yes on the missing half of that paragraph. I regularly check the state of Godot and Torque 3D engines, as they are among the few that allow access to source and are not of monstrous size and complexity, but they still have work to do to soften some edges. Eleon chose Unity and must live with it now, but even from a player-modder perspective some performance can be shaved here and there just by judiciously designing playfields and various objects, so Eleon can probably do the same in some areas if needed, but I think they have the developer PC syndrome : they don't see 1/10 of the glitches and bugs players see because they have all .net bells and whistles and top notch machines to run the game. And regarding water, like I mentioned and of course you know, everything is possible. Probably not worth the hassle for some time given many other aspects easier to solve which will impact gameplay more globally. Well that's my hope, but time will show if it was worth the wait. Nothing more we can do, he ? .
Well here again I can't tell if you're saying "this is how it's done (because you don't know) or "this is how it SHOULD be done (which is not the only way). If the player hits the water surface past a certain point he's drowning even with the head out of water. You can say all you want, there are many different ways to make water in Unity, and many of them use the surface plane as a simple collider to determine the player's position. Once it is validated, then no need for a dozen unrelated checks since they have no associated mechanics for them underwater. A player can drown in his O2-full ship if he doesn't have his helmet on. Well the only logical result would be "player breathing normally" but that would solve none of the associated rendering and collision/ physics issues I mentioned in my first post. The shader can't be simply "removed" in an undefined volume, unless I'm mistaken. So how do you define that volume ? And to answer we need to know first how it was first defined here. So yes, it's pure speculation. Yes... no... well... I explained in the previous comment. Once player is detected sounds have to be played (water splash) and some other effects, localized around the player. I don't think there needs to be a raytrace in all the playfield volume to find the player when he is inside a much smaller volume under one single y coordinate, after having touched the top water plane. Having a simple plane is much easier and lighter to maintain than a complex set of coordinates defining the precise contour of the water edge. So how does the engine know when "water physics, sound and rendering" have to kick in ? There needs to be some dataset to compare the player position with, and it must not be unneedingly huge. The surface plane might be more appropriately named "trigger" than "collider" but I think "collider" is what is used in Unity to act as "trigger", right ? (non-blocking type) I know that. I read papers some time ago about a rant from one of the top Electronic Arts execs during discussions on the updating of some version of the standard C++ library, where he complained about programming students not learning the good way to work in game environments. He mentioned lots of tricks that are paramount to game programming that EA had to teach their new employees because they had no clue how much performance some small things could save in gaming context, because of the sheer amount of commands and variables thrown at the machines at all times and maintained in low level cache for no sound reasons. I think most C programmers are quite aware of these because of the requirement to manually free unused memory once a task is completed, instead of relying on automated processes like the Garbage Collector in C#, for example. I think "collections" and "dictionaries" are just C# flavors of other languages "arrays", but with different names depending on allowed operations, datatypes and dimensions (2 or 3 dimensional arrays, arrays of arrays, associative arrays, "map" etc).
I am not a programmer, but I can describe in words - HOW IT IS POSSIBLE TO MAKE THE GAME REMOVE OXYGEN FROM THE BASE WITHOUT PROCESSING THE WHOLE GAME ENGINE (!) The SIMPLE COORDINATE SYSTEM (!) Will help you The base is a set of rectangular rooms, which are interconnected by doors - sealed - for moving from one room (box) to another (!) When the player builds a base (box) - he creates COORDINATES OF THE TOP AND CORNERS OF THE CUBE (box) (!) These coordinates are KNOWN to the game, and if the player turns on the oxygen supply, then oxygen fills ONLY the space inside those coordinates that are "hermetic blocks" (!!!) Therefore - knowing the coordinates of the hermetic blocks - the game places inside this space - OXYGEN (!) Therefore - indeed - to remove water from the base - you only need to get the coordinates of these hermetic blocks, and fill this space not with water, but with oxygen (!) Believe me - any game engine CAN be adapted for different tasks (!). Because we are dealing with COORDINATES (!) And I can EASILY prove to you that it is POSSIBLE (remove water from the base - replace the water blocks with oxygen blocks inside the sealed box) (!) Here's a proof example: characters are objects with coordinates - in principle, this is a POINT IN SPACE (!) and a character model is attached to this point - a player, a zirax, a drone, an animal ... If I apply the command "open the ammunition closet -> take off the armor, and put on the Santa Claus suit" (mod) to the character's point, then my character will look NOT IN A SUIT, BUT IN A SANTA CLAUS SUIT (!) .... or in a suit of "fire-seeking dragon" (!!!) These are coordinates, bro, and you can bind to them ANYTHING (!) Therefore, replacing the water block with an oxygen block is EVEN EASIER THAN IT SEEMS (!), Because these are COORDINATES (!!!) .............. God, if you - the developers DO NOT HAVE TIME TO DO IT - GIVE THIS TASK TO PEOPLE (for example @ASTIC) - who can do GOOD MODs for the game (!). You only need to INCLUDE MOD IN THE GAME (!)
