Subnautica BZ - Seatruck fix proposals

SSukeSSuke USA Join Date: 2019-07-30 Member: 254013Members Posts: 6 Fully active user
As quoted by /u/Ishantil:
Seatruck feels like it doesn't do anything well. It's not fun to zip around with and explore [compared to the Seamoth], and it doesn't have the 'mobile submarine base' feel of the Cyclops

Let's take a look at 4 big problems with Seatrucks and potential solutions for each of them. I've combined Seatruck issues discussed in multiple threads:

1) Each component of the Seatruck has its own health bar. Makes it very difficult to repair parts of it.
- Suggested fix: Health should be shared among Seatruck modules. Repairing any component of the seatruck should repair all of it.

2) Entering exiting the Seatruck and seat is annoying.
- Suggested fix: Allow for differences between short-pressing (exit seat) and long-pressing 'E' (exit vehicle)

3) The Seatruck is incredibly slow, even without any attached modules. It's not as fun or zippy to drive as the seamoth.
- Suggested fix: Increase the max speed of the Seatruck to match the Seamoth's speed
- Alternatively, increase the # of upgrade modules from 4 to 6 and allow for engine speed upgrade modules to stack.

4) Lack of storage compared to every other vehicle. With more modules, the Seatruck becomes tedious to go from end to end. There's a ton of wasted empty space in the Seatruck modules.
- This is #1 complaint for the Seatruck. Robin can store more items on her body, and as far as I know, she's not fatter than the storage module.
- Allow for a small 4x6 storage cabinet in the main Seatruck cabin.
- Double the storage in the storage module.
- Another option is to allow players to build in select areas in the empty space on existing modules. For example, if you remove the picture frame in the Sleeper modules, users would be able to build a fabricator, storage cabinet, and trash can there.


  • ChudovishChudovish Ru Join Date: 2016-07-01 Member: 219418Members Posts: 34 Advanced user
    1) Disagree. That allow the truck to be splitted into two parts if one of the middle modules be destroyed. Interesting mechanics I suppose, cause it mean you may lose some belongings in a rear part without loosing it forever, just return for your "tale", when giant monsters that bite you apart get rid of you.

    2) Disagreed. Seatruck is NOT the Seamoth, its a habitat, lab. Testing it and find needed that kind of option 20% of times. Another 20% find it wrong, bad a nd dangerous if i occasionly exit vehicle when i just needed tostand up from chair and repair some rear modules and get away quickly.

    3) Disagreed. Partially changed last update. Speed inceased. Anyway, Seatruck is a truck, it is slow. I find that devs design map that way you can use caverns, caves, arks, tunnels like the "roads" for you track. Little sneaky, takes more time, but hey - for me it works great, new mechanics. Just make some polish here an it will be brilliant.

    4) Agreed. Not much space compared to the size of module.

    +5) If we have separate production module that holds ONLY constructor, PLEASE make it happen to connect it with storage module (and aquarium too!). It goddamn crazy to check boxes every time i need to create FirstAid! (Where is it?! Where i put that syntheti... Gosh, i forgot it on the base!!! Right... How many titanium ore i have - lets look another time, all boxes. Again!)
    Scrap english
  • SirenSiren Denmark Join Date: 2019-10-06 Member: 254949Members Posts: 3 Fully active user
    The Seatruck is too slow, the sound it makes grinds on my nerves and it is beyond clumsy making it a tedious experience to operate. The Seamoth was very fun so it is difficult to go from one to the other. I agree that the storage space is lacking, making the storage module almost worthless since it slows you down for very limited net gain. The entire vehicle seems a poor execution of a good idea. It is not a game breaker for me, I love the Subnautica world, I just hope either the devs or the modders fix or replace this vehicle with something enjoyable.
  • BoffBoff Sweden Join Date: 2018-08-12 Member: 242804Members Posts: 34 Advanced user
    edited October 2019
    The buff I presume in the "HorsePower Module"
    It is not stated that it doesn't stack (like the depth module).

    So my assumption is that the Horsepower Module stacks.
    If so it's stats need to be tinkered with as it doesn't bring a fully ladened Seatruck back up to her top speed or ability to accelerate.
    Driving the cabin by itself - OOOH Bruvva!!
    The seamoth was fast, but her storage was abysmal.

    So it's a question of HOW you'd like the Horsepower module to work.
    (I believe the balance passes are coming later on down the line when the majority of assets and content are added, so it gets tweaked at the end, not with every update.)

    You got curves.
    Top speed
    Acceleration / deceleration
    And mass. (number of carriages).

    Currently, each Compartment brings the top speed down, the acceleration to static. Aka 0-top speed is like 2 seconds regardless of "loadout".

    My suggestion is that:
    The top speed does decrease per carriage but in smaller steps.
    However it's the time it takes to acceleration to reach that top speed which is hit hard.

    So each Horsepower "Module" brings the top speed back up but for a set amount of weight.
    but also the acceleration to reach that top speed is boosted-
    i.e. Each Horsepower Module, negate the effect of the extra mass the truck is pulling.
    (And they give a nice revving sound effect)

    Then it's a balance thing.
    Does the Horsepower module negate 2 carriages or 3 carriages?

    Aquarium/storage/fabricator is clearly the winning combo right now to explore and fix stuff on the go. So 3 sound good.

    As for the sleeper truck (why does the player need to sleep, can we heal?)
    the Teleportation carriage or the requirement to have the Prawnsuit tagged on - has yet to be realised in the games full version.
    I've got one of each, (okay 2 storage carriages, as one barely covers food/health/water/equipment) and even with 4 Horsepower modules, it's still slow going, As that's 7 carriages AND the prawnSuit it'self, but thats far better than being without.

  • BoffBoff Sweden Join Date: 2018-08-12 Member: 242804Members Posts: 34 Advanced user
    Additional Nice to haves.
    Power Burns most when Accelerating, not coasting.

    Recharge from Power-transmitters
    Breaks the need for the moonpool and/or keeps Cabins powered up even when the Cab is not attached.

    Looking around / set speed vs Mouse look.
    The seamoth, seatruck(cab) and prawnsuit controls are directly steered by the player as those vehicles are so nimble, you look left with your standard controls, the whole vehicle looks there. You push forward on your controller and the vehicle moves forward.

    The cyclops allowed us to set the speed, and look/walk around, as it was so cumbersome.

    The seatruck starts as seamoth.
    But as the truck expands in size, it's direct steer ability becomes a hazard. You want to quickly look left and right, or getting up to go make a fish-sandwich, whilst hauling somewhere.
    Using Elite Dangerous as an example. Forwards/backwards throttles up and down. So holding down the Forward button move the throttle to the top-speed position. Tapping back, move the throttle to zero, (decelerating and burning energy).
    Hitting the reverse does the same thing. It slows you down until you stopped.
    Throttling back again puts you into reverse.

    You can give the player a bit of look spring dead-zone, (like riding a bike).
    You can look a little bit left and right from the center point, and the vehicle doesn't react, but as soon as your head hits a certain angle from centre, the neck starts twisting the shoulders and arms and suddenly you have turned your bike unconsciously in the direction you wanted to look at.

    Seatruck vitals persistency.

    Solution 1 && bug-fix
    HUD UI Module status and Energy Status are present when operating the vehicle. Keep this persistence similar to entering/exit bases.
    The Logic Event to activate the UI just needs to tweak and test, which needed to be debugged anyway.
    There is a bug when the player rearranges the cabins have been and re-attaches the Cab.

    So the state of operating the SeaTruck (without cabins), swaps out with Seatruck (with cabins). But the updated the in/out flags get confuzzled.
    So the "enter-seatruck message and animations" trigger when trying to exit after docking the Cab to the Carriages and then getting up and walking around.
    So you got to click to enter, so then you can click to leave.

    So this gets iffy in multiple ways, so I've done some puesado-code in the spoiler section.
    Case 1) Show the UI when in unpowered single Cabin
    Case 2) Show the UI of the combined unpowered Carriages even when the "cab" is not attached.
    Case 3) Show the UI of the combined Cabin when the "Cab" is attached.

    Solution 2
    one could have screens and meters in the "Modules/Carriages" themselves, perhaps a 2 bar little panel in the "front-doorways" which gives a [hit box] for repair maybe.
    Unless gameplay is designed for repair to be done externally.

    Solution 3)
    The area could also be used for a quick-release latch.

    The problem being with the later two solutions might lead to more real-estate needed in the models themselves.
    Any dimensional changes in the doorway as a result of too large a model change will compound - multiplying the length of the sea-trucks length depending on how many modules (with the new doorway design).

    Player centred logic to organize the seatruck.
    Since the seatruck can be in multiple components and multiple states. So you can either have multiple seatruck objects and modules connected to different sea-truck objects

    That gets hard to debug, fast.
    (Indulge my by burnt-out programmer's brain which generally gets anxiety looking at code, to do some logic exercises whilst it feels good for a change)

    The best way (I think) is to go after player action and build such a container list on the fly and build the structure "every time" you interact with a cabin via entering or grabbing a hold of the Cabin.
    This belongs to the player, (not the game).

    The Container object is then discarded when you let go/exit. (okay you can make a backup copy somewhere else).

    When the player "Enters" or even takes a hold (externally) of a single Cabin (say the aquarium) - we instantiate "Seatruck-Manager" Object - a simple container.

    5 Values.
    int EntityID
    Int Energy() {fetch from cabin[0]}
    int Health() {fetch from cabin[0] (or lowest Cabin?)}
    Array i]Cabin[/i
    int PilotingState [NONE | AFK | MANUAL | POWERED) (the player is piloting the Seatruck cabins (s) manually or is Piloting the vehicle from inside. The object ceases to exist on exit, so the player is only ever Away from Keyboard so piloting the vehicle and is, therefore, walking around.
    I dropped in a NONE in case of try-catch scenarios that may require it.

    function AttachCabin (int CabinID) { the structure can only be piloted from the cabin in position 0.
    So far the player on the "outside" detaches themselves automatically, so the player now No longer has a seatruck manager attached to them.
    So they much interact again, thus creating a new seatruck Manager so attachment ripple forwards to the cabins ahead or backwards if the Cab is "back onto" a Cabin)}

    function DetachCabin(){quick release button pressed or
    PilotingState = MANUAL
    the player has grabbed a module in a structure so only the Forward(cabin) needs its aft cabin pointer nulled, and the current cabin needs its forward pointer nulled.

    PilotingState = AFK
    the player is walking around the seatruck and hit the quick-release button.
    Only the
    aft Cabin pointer needs its forward pointer nulled, and the current cabin (the cab) needs aft pointer nulled.
    Then run a refresh of the Player owner SeatruckManager array which rebuilds the structure from the interaction point Cabin[0] and checks the forward then after pointers, to create the structure.

    Each individual Cabin Object naturally has
    Int ID
    Int health
    Int energy
    Cabin* Forward
    Cabin* Aft
    internal function attachForward(int cabin = null) { set thefoward cabin to cabin-id or set to null (detatching it) }
    internal function attachAft (int cabin = null) { set the to the aft to cabin-id or set to null (detatching it) }

    Junior developers will use previous and next to keep things abstract which is good coding practice as they do not describe specifics that could make the objects re-use harder in the future.
    Be that as it may, orientation, in this case, is of vital importance for this specific object and developers hopping in and out can rest easy knowing instantly which way things are.

    On instantiating the SeatruckConfiguration Object (enter/piloting) we then do a trawl of all the cabin forwards of the cabin you entered.
    Shunting the start cabin (aquarium) down the list, as next cabin "forward" is then cabin unshifts Cabin[0].

    When we reach the most forward Cabin, we start populating the rest of the Cabin[] array from the first entered module (in our case) aquarium which will always be in the aft-most position so far and ergo the array-length (-1).
    We then work aft, building out the truck structure with pushing the new aft cabin to the Cabin[] array.

    When that is done
    We now know everything we need to know.
    1) Is the player inside/outside/piloting, regardless of the circumstances of how we entered the truck.
    2) The structure of the whole vehicle and each of the health cabins in sequence.
    3) We can quick reference Cabin[0] with is the Cab with power or just a standard cabin without).
    Any interaction, getting up, connecting, leaving, etc etc, we just refresh the list.

Sign In or Register to comment.