<- Back to patch notes

Notes

Drag on boat hulls will mostly just slow down acceleration (probably not noticeable). The main reason for this is that when boat hulls are used with aircraft, drag is more accurate. As an added physics bonus boats will now be affected by wind. Drag currently does not affect all parts due to performance concerns (just aircraft stuff and hulls now). Saved vessels automatically migrate from version 1.0 to 1.1 when you load existing vessels. Once saved the vessel version will be saved as 1.1. This updates various information that may now be stored in a different or more efficient way and fixes any parts that may have had model adjustments. There were some models for certain parts made early on that were not exported correctly. Because of some scaling changes, some parts will need to be adjusted on existing vessels (this will happen automatically when loading the vessel). For example cubes. The broader implication of this is that the build system will no longer support parts that have a non-default scale (1, 1, 1) because there are various locations in the build system where this becomes complicated and these parts were scaled long ago and need to be corrected at the model level. Another implication of this is that any mod parts will need to have models scaled correctly, once exported the scale should be (1, 1, 1) as opposed to anything else like (0.5, 0.5, 0.5) or (2, 2, 2). The game will now spit out errors for any parts it detects with incorrect scaling. If this occurs they will still work but some features may not behave correctly. Parts that were not scalable will be auto-scaled to the correct size with an error message and the problem will go away once saved. I added a new misc. setting to help fix scale adjustments before I decided to make a migration script, in any case this setting allows you to change a parts scale without affecting child parts. Set "Auto adjust child parts" to off. This new setting only supports scaling, not stretching or moving, but will make it so you can correct the shape of the part without messing up anything else. Useful for changing designs. New keybindings do not have controller bindings. The default keybindings for chat and reset were in conflict so I am arbitrarily changing them to none conflicting keys (and reset back to what it was previously). The aircraft carrier hull is designed to be more symmetrical in nature (by comparison to real world) to make the part reusable for other purposes (it was also easier to make). The physics engine is very touchy about having landing gear (wheel colliders) on moving vessels, it really wants them to bounce around especially if both vessels are moving and have drastically different mass. Ideally when maneuvering a jet on an aircraft carrier, the ship should be going slow or stopped. You can in fact land while moving though which is super cool. To help with this spastic physics behavior I have added additional handling to parking brakes while parked on moving vessels. As long as the parking brake is on and you are not moving much relative to the vessel you are parked on your aircraft will remain mostly still. Additionally there is new suspension math that helps adjust the landing gear as the platform moves to prevent physics issues. I have attempted to take the landing gear out of the equation when you stop moving (relatively speaking) so that the physics engine will consider the aircraft at rest rather than trying to calculate math for wheels over and over. As soon as you turn off the parking brake you will begin to see the wheels calculating again (possibly spastically if you are on a moving vessel and using the brakes). It is still recommended that you use steel cables to secure aircraft when not in use, ropes will not be sufficient. Obviously this behavior mostly applies to planes, helicopters can just have the parking break on all the time. It is also important to emphasize that many of these complex physics interactions must work and synchronize in multiplayer which rules out certain types of fixes that may work exclusively in singleplayer but cause issues for clients. There is a low priority backlog item about completely replacing wheel mechanics, however I am at this point unsure if I will ever do that for a couple reasons even though that may fix this issue as well as limits on the amount of wheels you can have. The problem is that the whole point of the wheel colliders (aside from being wheel shaped) is that they are fast and do not cost much in the way of performance because all the math is done on the GPU via the physics engine. This functionality is embedded in the physics engine / game engine and cannot be modified. Any replacements would require using scripts to emulate similar custom features but without the benefits of the GPU and would likely be slower and less performant than using the built in physics. A new system will likely just present an entirely new set of problems for moving vessels, so for now this is a playable solution. Because of the automatic suspension forces for landing gear, lighter vessels that would have bounced with more powerful landing gear should not. Additionally scaling landing gear will no longer affect the power of the suspension with the exception of the maximum support weight. Even though it is not realistic to have the landing gear magically adjust for the mass of the aircraft, it is ideal for allowing building of all sorts of neat stuff without having to worry about weird physics bugs. You will still be able to overload the landing gear with too much mass (or make the vessel too light). As a side effect of this, landing may become easier due to increased friction Because of changes to landing gear suspension you may (depending on your design) experience increased drag when attempting to pull up hard during takeoff when you do not have enough lift to leave the ground. Physics wise this will happen because the landing gear will most likely have slightly more play allowing your wings to increase the pitch angle while simultaneous pushing the back landing gear down and the front landing gear up. This will increase the overall forward drag of the aircraft as the pitch increases while you are not gaining altitude. As a general note you should try to reach your desired takeoff velocity before attempting to change your pitch in order to maximize takeoff speed. Because of the new collisions rain may appear slightly less thick close up in storms, although one might argue it is better because your immediate view should not be blocked by lots of rain anyway, but further off in the distance you will see lots of layers of rain. The new collisions allow you to build interiors on boats without rain entering the room. Elevators will save while moving and resume at their previous state just in case you had something on it. An easy way to taxi your aircraft on/off elevators is to use another Nautikin with a rope tied to the top of the base of the landing gear and pull gently. Depending on the vessel brakes on or off may be beneficial. In order to fix some more serious physics problems (vessels stopping instantly, spontaneous explosions, etc.) I have removed a workaround that allowed ships with huge amounts parts (1000-10000) to be manipulated after launch without lag. The lag is actually correct, because the physics engine is having trouble keeping up. I will look into optimizing this more later, but for now when you control a ship of that magnitude it will need a moment to get ready for you to use it. There is now a hard limit on the number of parts you can use to create a ship. The limit is somewhere above 10 thousand parts, depending on what you make. This limit is based on the maximum packet size currently used in multiplayer. While technically you could launch a ship this size in single player, there is currently no know configuration that would be using this many parts and the performance for physics will likely not be very good so this will also fail in single player. This only exist as a way to handle the case where the game would no longer function properly if it did not prevent you from launching. It is not likely you will hit this limit unless you are intentionally trying to do so. If somehow this becomes an issue later it may be changed. Because of changes to build mode snap settings, you will likely have to adjust this value in the misc. view since the measurement has changed. This change was made to make it easier to fine tune walls. The default value should be 100 centimeters (1 meter, the previous default) Some aircraft parts that can benefit from perfect alignment will now snap. For existing vessels you can simply select and place the part again and it will snap to perfect alignment (helicopter / plane hulls). Part snap will override grid snap. Snapping parts will make them move with that part. Not all parts have snap points configured. Snap points do not affect rotation. Snapping parts will not allow you to snap to the exact same position and rotation as the part you are snapping to, however you can have overlapping parts snapped to the same location. Part snapping will only be activated when a snappable part is selected, not with the adjustment arrows (unless the part was already snapped). Part snapping is not enabled unless you turn on grid snap, it is possible this may be a separate feature / button later however I do not currently foresee the use case for minute adjustments when you have a part selected that can snap. If you want it in a specific location after placement you can use the adjustment arrows (but it will no longer be snapped). You can snap cubes and other simple parts in a voxel manner but I do not recommend doing so in excess as it will likely cause physics performance issues. Instead you should simply scale them larger when possible. If you are snapping doors or something that relies on rotation you must first either rotate the door way or object you wish to snap to or adjust the rotation of the door prior to snapping. Stretching snappable parts will snap the part and child parts to their snap positions if grid snap is on. You can stretch stacked parts while they are snapped and you can snap them if they are stretched. If you stretch a part so that it no longer matches up, it will likely never match up again unless you clone a new part to match your stretched wall. Snapping will attempt to optimize parts that are different shapes, but only if there snap points are aligned, which means if you scale something or move it with the adjustment arrows it may not optimize for snapping. Snapping does not care about materials. Snapping parts with child parts snapped will work, just be aware if you have many many parts this may accumulate some sort of measurable performance impact since it will need to calculate snapping positions for all child parts. But this allows you to snap stacks to other stacks in unpredictable ways. It is possible to snap parts to parts that are themselves not snapped (or not positioned on a grid). If you do so, just remember that all subsequent parts will be positioned based on the original part position. You cannot snap your mirror part to its mirror while mirror mode is on. If you wish to do so you can clone it. It is not recommended you snap mirror parts when mirror mode is off, that may create weird non-intuitive movement if you decide to change it later (keep an eye on what is highlighted). If you are scaling snappable parts with the scroll wheel, make sure you have adjust when scaling turned on. Not all parts optimize when snapped. For example, doors and elevators (things that move). Parts will re-optimize if you rotate them into alignment. I added snap points for every part that I thought would snap well together and/or could optimize. There are various parts like hulls or non-uniform shaped parts that do not snap. There are probably some combinations I had not thought of or did not think were needed for one reason or another. If you have a specific snap point you want added be sure to mention it. Some parts may overlap if you snap them together. For example, the corners of the wall and floors may occupy the same location and create a sort of flickering overlap (especially if they are different materials), this is needed to maintain their exact grid / snap dimensions and optimization. If you don't want to see the overlap you can place other parts like the wall pillars over them, change the sizes, or in this example you can build your wall, snap a floor to it, then slightly adjust the floor with grid snap off (creating a new grid for the floor) and then turn grid snap back on and snap all future floor parts to that grid (the floor part you adjusted). If you snap the floor part you originally adjusted it will reset the grid alignment. Grid snap previously only applied to the move adjustment in build mode, now it will apply to stretch and scale as well. This is useful because it will allow you to easily scale snappable parts in a manner that will be unlikely to make them misaligned. Grid snapping relies on the initial position of the part being on the grid, when you adjust, it will simply adjust in increments of the grid. So if you move the part without grid mode the part will still adjust in increments if grid mode is on but it will do so relative to it's current position. Previously for example, move would snap to the grid before then move in an increment, however you can snap to a grid relative to the surface of the hull which is useful, so doing so whenever you adjust is not ideal. Bottom line is that if you want things on the same grid you must select them and place them with grid snap on. Moving a part without grid snap on will cause them to no longer be aligned to your original grid (this includes changing the grid snap interval). Grid snap scaling will not allow you to make the part smaller then the grid interval (as opposed to the minimum part size) because that would misalign it with the grid. The previous build mode camera info will not save with the vessel. This does not save with the vessel because that would increase the size of the vessel file (which affects multiplayer) and this is strictly a client side convenience feature. It is also ideal to have the camera in a clean state for the first time you load a vessel, because that info may have been months old. In general each build area will simply keep the camera where ever you had it last. The undo stack tracking for the grid snap state only really occurs when you have a part selected (similar to mirror mode), so technically the state will not be exactly what it was if you pressed the button without a selection. However the undo stack is only concerned with whether or not it needs to re-snap parts (which it does not track directly). Also if you somehow select a stack of unsnapped parts with grid snap on, they will all snap and later the undo stack will not unsnap them because you are not really supposed to be able to create that scenario without grid snap on. It is extremely unlikely even if you have aligned them without grid snap to visual perfection, when grid snap checks the math it will be able to tell the difference. For similar reasons, the undo stack will always attempt to snap parts (which also means It doesn't have to track a bunch of complicated information about snapped parts). If that becomes an issue though it will likely change. The undo stack will not track any button / mode changes unless you have a part selected. This just means that it will not track in between or empty states when you press buttons, for example if you turn on mirror mode without a selected part, it will not track that, but it will track the mode when you pickup the part. Similarly, if you have mirror mode on and you turn on align to center it will not track different states when you have not placed the selected object. The toggle state for global adjustments will also be tracked by the undo stack if you have an active adjustment Center of mass and camera mode are not tracked by undo because they have nothing to do with part selection / adjustments. The new aircraft carrier engines are slightly more powerful and maneuverable than the shipping engine. With regard to the scale validation error, there will also be an error check for rotation (related to mods), but it is unclear what problems if any this will cause (it is probably not a good idea though). All destructible parts have been re-baked due to various changes with UVs / texture tiling. This process took approximately 5 minutes (which is why it is not calculated at runtime). Helicopter rotor handling can be configured in the "Vessel configuration" dialog under "Aircraft". It is not configurable while piloting. The purpose of this feature is to fine tune control over extra small or extra large aircraft that the build system cannot automatically configure as desired. The more rotors you have the more your handling will 'improve'. For larger vessels with many rotors you will likely want your handling lowered. In sandbox there is no requirement to have Nautikins on board a vessel that is deploying a new vessel with a build area, they will magically teleport to the new vessel. Let's just pretend they swam over really quick. It is more fun that way. When recalled they will swim home. In campaign you must have spare Nautikins in passenger seats on the vessel in order to allocate crew members. When recalled they will be seated back on the vessel or dropped wherever they were if no seats are available. There is a misc. setting to turn on the requirement in sandbox mode (maybe you prefer no teleporting), however this setting is only available at certain times (when not in build mode) to prevent problems with crew allocation. This setting is not available in campaign mode. When distance return to build area is on, you will always be returned to the build area nearest your vessel that matches the vessel type (aircraft vs ship). If you disable this option you will be returned to the last build area your vessel launched from or Portus if that is not available. This may be useful for building bases to attack from in multiplayer or something. Build area vessels can only be launched from vessels that are larger than them. This does not apply to structures / bases which do not move and will more or less be treated like Portus and ignore the size requirement. For some examples: You cannot launch a jet from another jet of equal or smaller size. You cannot launch an aircraft carrier from a jet. You can launch a jet from an aircraft carrier. You can launch a scout ship from a cargo ship. You can launch a gyro from a jet. etc., etc. Build area parts are renamable and will show the name on the map. If the build area is destroyed while you are using it you will be sent back to Portus and any unsaved changes to the vessel you are working on will be lost (risk of using mobile build areas). It could save some sort of temp vessel later but there are several reasons why I do not want to do that atm (Timing issues, needs to be destroyed fast, multiplayer, performance, added risk is sort of desirable, etc.). In campaign, vessels can be refunded/recovered at mobile build areas. Building in mobile build areas may produce jitter sometimes with the exact location you are trying to place and object if the camera is rotating because the vessel is moving, the build system smooths this out a lot but it is really a limitation of the math involved for determining the exact position you are trying to place an object which is affected heavily by the orientation of the camera (as well as other settings). It may also be something you never notice. Crew allocation is not a persistent concept (not saved), and switching crew types only exists as a convenience feature to quickly give you a Nautikin with the stuff you want without switching build areas. If you later give that Nautikin different stuff, for example take away all his pilot stuff and give him a jumpsuit instead he is no longer considered a pilot. Certain parts of crew allocation for various features across campaign vs sandbox will guess the Nautikins type by examining the inventory. By default they will always register as a Seaman Nautikin (orange jumpsuit) when they appear in the UI. When in campaign or disabling teleport Nautikins you will not be able to change the crew type when allocating crew. This is because those crew members are already seated on the vessel responsible for the build area and have inventories that cannot be changed. Because of new random damage, sometimes you may survive a horrific crash or attack by pirates, rather than just exploding outright. This works both ways though, sometimes pirates may survive. It's also awesome. Subvessel toggle groups can control any part they want, it does not have to be attached to the subvessel. The blueprints for the drydock and runway area build kits can be unlocked in campaign at the Portus buy shacks for an absorbent amount of shells. I was looking into having a UI message appear whenever you turn on / off a toggle group so you could tell what was happening in case you forgot what keybindings you setup. This didn't work very well and there are a couple of problems. 1) Toggle group names can be really long so having them prominently displayed on the UI somewhere causes a space issue. 2) Because of the nature of toggle groups multiple groups may be activated or deactivated with a single keystroke. Conveying that in a short message is difficult and it may simply show one of many toggle groups and not offer any information. In any case, if you forgot what keys you have assigned or what they do you must still consult the vessel configuration for your vessel in build mode. I have added a backlog item to look into a more complex way of displaying information for multiple toggle groups at once, perhaps some sort of optional list that shows the states of all groups you have configured in a small box somewhere. If you are hovering over a part, that part will take priority in any interaction, if you are not hovering over a part but are adjusting a part, that part will then take priority. These interactions apply to sample, apply, clone, rename, etc. In most cases center of mass does not need to be perfect, so don't worry too much if your right axis is for example 0.05 instead of 0.00. This information is visible now because for larger vessels CoM becomes more important. It is not displayed by default and can be enabled via a misc. setting "Show CoM readout". The game will move deleted saves to the recycling bin. The game will now move deleted vessels to the recycling bin. On the Steamdeck (Linux/Proton) instead, deleted vessels will be sent to "Trash" instead of the recycling bin. For save directories, they may be deleted in proton instead of sent to the the trash. It may vary based on the version of proton or it could be a proton bug (or it may not be supported). It should send them to the trash, but it is not clear to me what is going on in the emulated environment, it will either make it to the trash or it will be deleted. This behavior is beyond my control and may vary depending on Linux and/or proton versions, but I did report a potential bug. Generally speaking though if you delete something, it is gone. I am making an extra effort to send it to OS so it can put it in recycling bin just in case, but the OS will ultimately decide what it does with the deleted file/folder. By default deleted saves and vessels will be sent to the recycling bin, you can change this setting in the misc. tab under "Files" Currently it is expected behavior that harpoons launchers do not reload automatically when the object they are harpooned to suddenly disappears (i.e. shark or another vessel). The only time an automatic reload will occur is if you click "Cleanup ropes and cables" from the server tab (which is also called via "Cleanup all") The aircraft carrier hull is pretty massive, exit the drydock slowly and with caution (watch the sides!). The pirate flagship is basically an aircraft carrier. It will occasionally launch pirate aircraft to destroy you but you can also sometimes steal the aircraft before they takeout. It is worth noting that the incompetent pirate pilots will sometimes not make it off the runway. I added a keybinding "Select" to select the current part being adjusted, this is the same as clicking on the part but more useful if the part in question is inside something and I want to get it out of there without having to use the adjustment arrows or holding down arrow keys for a moment. This option is set to "V" by default, but I might use that for something else later. There is no controller binding for this option. The short range pirate spotter is slightly more dangerous and maneuverable than the long range scout version. It is more suited for taking off from aircraft carriers and will mostly try to get you targeted by the flagship, but will fire guns at you if given the chance. Distance/spacing restrictions for placing build areas next to each other will ignore mobile build areas because they can move around. The primary reason for this restriction is to keep structure build areas from overlapping and causing problems or confusion. Previously pirate vessels would not trigger a notification that they were destroyed. But the behavior has now become inconsistent with the addition of the ability to steal pirate vessels. So now you will always be notified when a pirate vessel is destroyed. This may be useful for multiplayer too so other players know when the objective makes progress. Also, why wouldn't you want to know the thing you are shooting at blew up, you might not be looking right at it. Another useful effect of this is that if a submarine you were shooting at sinks you will be notified. There are additional performance improvements that need to be made to pirate vessels in general. The flagship is up there with the dreadnaught, so as with other seek and destroy, it is not recommended that you spawn many of them at once. There is some janky behavior with spawning vessels on moving vessels in multiplayer, once the spawn finishes everything should be fine but there may be some yo-yo-ing as the game does the normal network stuff it does to spawn a vessel (which was not designed to hit a moving target). This should work normally in multiplayer with the exception of attempting to launch a vessel without a crew member which will likely have camera jank momentarily for similar reasons. I have added backlog items to address these issues after spending too much timing trying to make it work with the existing spawn system (it cannot). It is also obviously dangerous to spawn while moving, which is why it gives you a warning before doing so, it is recommended you stop before launching. All bets are off if you spawn in the sky while moving (it is pretty fun though!). This update took a bit longer than usual due in part because of the holidays but also because I added a bunch of new unplanned features like part snapping and mobile build areas that seemed too good to pass up as part of aircraft carriers. These additions also drove the need for other sweeping changes and refactoring, which takes time. Guides will be updated when I am done resting my brain. <- Back to patch notes

[ 2025-01-21 14:02:02 CET ] [ Original post ]