Vehicle storage in a larger vehicle

Game Talk The Drawing Board
21

thanks for your work buddy :).

I understand that vehicle construction would reqiure a lot more work.

Maybe one day some one might tackle this as I really do think it would be amazeing to have this feature in the game :slight_smile:

22

Thank you for the work you’ve put in.
I wasn’t aware you’d added so much to foldables, so an extra thank you for that because that seems like an acceptable compromise, it wouldn’t take long to park your mobile fortress outside a town, set your loot ‘n’ scoot up and ride it around, then fold it up and store it back in your fortress, so it’s an acceptable compromise for now, especially considering the work required to implement this.

23

You could do something funny like, say, turning this into a crafting recipe. You can ‘craft’ or perhaps ‘build’ one vehicle into another. If the first vehicle has at least 1 tile of vehicle storage, it also gains a pair of x and y coordinated of its greatest square upon addition. During the crafting check, one of the ‘to be stored’ vehicle could be stored using a pointer to its vehicle object, and (on the assumption that vehicles don’t autocontain their iteams) add an index for each item which will be stored in a seperate vector. To deconstruct it, you could simply require interaction with one of the storage tiles, and (as this would be a rare event) manually check for a feasible drop location of its ‘square’. If one is found closeby, place it there. If not, tell the player to either move or flatten the area.

Of course, that’s all dependent on a lot of things (I have no desire to trace anymore linker insanity after last semester), but, if you want to not change the root vehicle code fundamentally, this might be an easier option.

24

What if there was a vehicle bay part that does not trigger collisions with other vehicles, and to load a vehicle, you just drive it onto the bay. When vehicles drive, they look for other vehicles in the loading bay and move them along with the vehicle. If a vehicle in a loading bay has any parts outside of the loading bay, it has a chance of being left behind.

25

I imagine that’ll be how it’s done. However from what I understand that entire process is a pain in the ass to code and way too complicated. Otherwise it’d have been done by now. That is pretty much the best way to implement it though, as far as I know.

26

I was thinking about this today, and decided to have a look to see if anyone else was discussing it


Here are my thoughts on how it could work, with a potential solution to the vehicle-inna-vehicle problem. Might even look at trying to add it myself, but that definitely won’t happen until I graduate (in March).

New vehicle parts:

  • Vehicle Tie-Down: When nothing is parked there, it acts just like an aisle. The underlying frame part determines the max weight it can support.
  • Winch and Electric Winch: Used to enable the loading and unloading of vehicles too heavy to be dragged around by the player. Takes about 1 minute per tile to move a vehicle, but is relatively quiet.
  • Winch Hook: Installed on a target vehicle to enable a winch to operate on it.
  • Ramp: Works just like a multi-tile door (open = lowered, closed = raised).
  • Lift Gate: Installed on a vehicle tie-down tile. Blocks storage of vehicles larger than 1x1. Can lift and store a 1x1 tile vehicle in an orthogonally adjacent tile, and deploy it to same, assuming there are no obstructions. Hand crank operated, and makes a lot of ratchetey/clanky noise.
  • Stored Vehicle: A generic part to represent part of a vehicle stored on the tile. These would be weightless.
  • Stored Vehicle Wheel: A generic part to represent the places a stored vehicle would apply load to the carrier. Weight would be dynamically calculated as (target vehicle weight / number of wheels on target vehicle).

Mechanics (for large vehicles):

  • Install a “winch hook” on the target vehicle. It must be on (one of) the front- or rear-most tiles of the vehicle (IOW, nothing can stick out fore- or backwards past the hook).
  • Position the target vehicle. The installed winch hook must be on a line formed by the winch tile and an orthogonally adjacent vehicle tie-down tile. Higher mechanic skill could allow you to be one or two tiles off the line.
  • Validation: The target vehicle will be stored relative to the placement of the winch hook. The tile with the hook will occupy the vehicle tie-down tile directly adjacent to the winch. The target vehicle must have sufficient wheels. There must be a ramp tile with nothing but drivable terrain or target vehicle tiles between it and all wheels on the target vehicle. There must be vehicle tie-down tiles between the ramp and the final resting places of all of the target vehicle’s wheels. There should be nothing but “walkable” tiles (aisle, floor trunk, etc) occupying any other tile between the ramp and the target vehicle’s final resting place, or in the final footprint of the vehicle.
  • Activate the winch. The player receives a prompt, “Winch in ?” After an amount of time, and if all of the conditions are met, appropriate Stored Vehicle and Stored Vehicle Wheel parts are installed in the carrier, and the target vehicle is no longer rendered in the world (not sure exactly how this would have to be handled
).
  • Activating the winch again will prompt, “Deploy ?”, check for enough free space beyond the ramp (and that the ramp is open!), and place the stored vehicle relative to the hook, with the hook placed two tiles beyond the ramp, and in line with the winch.

Mechanics (for lift gate):

  • The lift gate would only require that the target vehicle be 1x1, and have the weight (including contents) be within the limits for the underlying frame.
  • The target vehicle must be orthogonally adjacent to the tie-down tile, OR on the other side of a roll-up or sliding door tile that is orthogonally adjacent to the tie-down tile.
  • Activating the lift-gate would prompt, “Stow ?”, and install a Stored Vehicle Wheel part in the tie-down tile after 2-3 minutes.
  • Activating the lift-gate with a stored vehicle would prompt, “Deploy ?”, validate the destination tile is clear, and place the vehicle back on the same tile (relatively) that it was picked up from.
  • Any items left in the destination tile would be destroyed (crushed), including the player if they ignore the “Really deploy lift gate on your head? Y/N” message. :slight_smile:

This removes some of the challenge of trying to drive a vehicle into a small space, but I think that would end up being more frustrating than anything else, anyway. And it has the potential to avoid a whole slew of nasty coding challenges.
One major limitation is that you can’t interact at all with stored vehicles, but I would be more than happy to deal with that in order to gain this capability!
Even just the lift-gate - being able to store small “looter scooters” and mobile welding apparatus would be great!.

Your wall of text skill has increased to 8!

27

Offtopic, but since this was dug up, I totally think that (rigid) connectors for vehicles would be an awesome thing to add. Non-colliding frame-like part on vehicles, and if connectors of two vehicles touch, they are connected. Since proper trailers would be a huge pain, this would be rigid, and the vehicles would be essentially treated as one. It would probably need both vehicles to be 90 degree aligned. It would be pretty awesome to add trash trucks(and modify trash containers into vehicles!), and then have a mobile RC-bomb/shopping cart carrier.

28

I just wish I could get to the point where I can drive an intact bicycle.

29

I was giving a thought on this and while paying attention to some already existing pieces of code, in particular:

  • Headlights (Stores directional information in a vehicle square)

  • Wreck generation (Combines plans coming from different vehicle templates)

An idea came to my mind so here goes. The following proposal will allow:

  • Integrate one vehicle into another as “functional wreckage”.

  • Control docking orientation.

  • Full interaction with the docked vehicle (See below for optional features).

  • Deploy stored vehicles.

It would require new components (In what follows D is the vehicle to dock, G is the garage):

  • Landing Bay Door (LBD). Placed in an outer border frame of G. The goal is that D colliding here will trigger the Fusion Operation.

  • Landing Bay frame (LBF). Dedicated frames that should connect a Hooking Station to a Landing Bay Door into G. They will be replaced by the Fusion Code with the squares of D.

  • Hooking Station (HS). Placed into the Garage and requiring an orientation like Headlights (For simplicity could be restricted to 90Âș options only). It will mark the exact place at which D plan will be assembled into G. It will be also the component the player will interact to initiate the deploy operation.

  • Hooking Point (HP). The fusion and deploy code will assume this component is placed in the southernmost square of D. It will mark the point used to align D plan axis (From South to North) to G’s HS selected orientation.

  • Docked Armor (DA). Ghost component added by the Fusion Code to label resulting vehicle parts to dissassemble by the deployment code. I choose Armor as it’s already the component that can float in almost any existing vehicle square. OFC, it still need to be tweaked to cohexist with another piece of armor in the same location and it should weight exactly the same as a LBF.

The Docking Procedure will be very simple:

  • Player rams D into a LBD on G. Collision code should evaluate FIRST this condition BEFORE triggering any damage to any vehicle. Optionally this could be only possible if LBD is in Open state.

  • The “fusion code” will proceed to integrate D plan into G plan. It will try to place D’s HP next to G’s HS obeying HS orientation and then proceed to check if ALL squares of D can replace a LBF into G. If there aren’t enough LBF to hold each square of D’s plan
 A regular collision will happen.

If everything went smooth
 The resulting “wreckage” will be a vehicle based on G with a lot of LBF replaced by components of D marked with DA. G’s HS will be next to a HP component surrounded by adjacent components marked with DA (HP is also “DAed”). Player possition will be “carried over” based on were he was in D at the moment of the collision.

The Deployment Procedure will also be equally simple:

  • Initiated by the player activating an HS in G.

  • The Deploy Code will then locate the closest LBD in G on the direction marked by the HS. It will then create a new vehicle by possitioning next to that LBD the HP next to the HS triggered by the player and then export all Squares of G linked to that HP with the component DA. The process will fail if in the world there is any obstacle or creature in the resulting squares. On G, each square exported will be replaced by a LBF. DA component will also be removed as part of the export.

This setup has a few caveats that would require extra coding:

  • The Mechanic menu should gray the option of removing DA components.

  • The collision check just check the pressence of a single LBD to trigger the fusion. Increased reallism should require a width enough set of continuous LBDs so D could enter physically into G
 I have the impression that this kind of checks would be maybe a waste of resources to be performed at each potential collision (and/or vehicle movement step).

  • It will be impossible to add new frames to D, unless specific options are added to the Mechanic menu to convert G squares into “DAed”.

  • Player can become trapped in the vehicle if the bay isn’t configured properly or D is not prepared to have valid access points once “fused” into G.

  • Vehicle performance module should be made sensitive to the pressence of DA component or energy/fuel/water/motive power/wheels of both vehicles will be shared.

  • Vehicle transition will be instant. A lot of code and extra management will be required at the very moment you want the world to add steps during each docking/deployment maneuver. This is, ofc, the worst aspect of this “solution”
 No fancy docking/deployment minigame will be needed.

  • Extra components should be added if players want to control if their bays are roofed or directly explosed to environment.

On the plus side this way to do things, which is just a way to morph vehicles together, should be relatively light to code as the resulting vehicle is basically defined as a regular one with a fex extra “tricks”.

30

That sounds great, though I feel like the parts are more reflective of the underlying implementation rather than the functionality, and also perhaps a bit complex. Personally I’d probably prefer a single in-frame part on D(that can coexist with anything else), and a single part on G, perhaps even of the same type, with the connected vehicles being treated equally(e.g. make a new vehicle, temporarily remove the underlying vehicles from the world, recreate them based on some original vehicle field). It could be a bit too easily accessible tbh, but would make detachment easier. Make it so that you can only connect at perhaps ±15 or so degrees from a 90-degree-aligned orientation(relative to parent vehicle), with the vehicle(or at least one of them) reorienting itself to a 90-degrees-aligned(relatively to parent vehicle) direction.

31
I feel like the parts are more reflective of the underlying implementation rather than the functionality, and also perhaps a bit complex.

Absolutely
 I haven’t inspected 1st hand the code myself (Or I would be just adding code to git for aproval :)). I have just used my knowledge as programmer, after seeing how vehicles work ingame, and “distilled” a suggestion that “scavenge” as many existing features as possible. That’s why parts are so tied to the potential implementation and a bit far from the real gadgets involved into vehicle docking.

Personally I'd probably prefer a single in-frame part on D(that can coexist with anything else), and a single part on G, perhaps even of the same type, with the connected vehicles being treated equally(e.g. make a new vehicle, temporarily remove the underlying vehicles from the world, recreate them based on some original vehicle field)

That would require extensive data modification because you will have to “temporarily store” the original configuration. Maybe I should ellaborate a bit more why I think each part is needed:

LBD: At its essence is just the spawn point on Deploy. Coincidently, most players on this thread instinctively think on the common scenario of the “Towing Vehicle” were D enters and exits through the same access point but in reverse, that’s why I also chose to make it the landing point. But IRL there are plenty of scenarios were vehicle storage is not done that way
 The best example I can find is a Carrier’s Figther complement, that docks on one side but “deploys” through another. Notice how I deliberataly left LBD selection on spawn logic a bit fuzzy and atm just simply linked to “be in front” of G’s HS
 With a more ellaborate model you can split LBDs into a landing point and a spawn point BOTH linked to the same HS to recreate complex vehicles in the future. Regarding your concerns about the realism of the docking operation, indeed, restricting angles could be added, but first I would start by restricting speeds (to just 16kph for example) not only for the sake of realism
 But also to ONLY spend time checking LBDs pressence at this particular speeds (the 1st step with Cruise Control On forward or backwards) while most of the time the code sections ran when a vehicle is moving are the current ones.

LBF: Is just simply needed to designate a “capacity” so a big vehicle requires a bigger storage. Again I’m following the average perception of the users requesting this feature, that is internal docking. Coming back to RL, for example, the external hardpoints used for missiles are an example of 1 vehicle “stored” in another without the needs of “LBFs”. This could also be mimicked with my suggestion if the HS was at the outer border and also detected as a valid “collision point” to trigger the fusion, this time the Fusion Code will not check, nor replace LBFs (But notice that the resulting plan still needs to label one of the vehicle squares using DA’s to distinguish how to split them
 Even more, this DA should be new as, on Deploy, shouldn’t generate LBFs back on G).

HS: It’s basically the “boundary” between vehicles. I added “directionality” because, on a Carrier Vehicle, the “deployment vector” do not have to necesarily match the movement vector of the Garage (What happens with some Racing Bikes transport trailers some teams use
 The bikes enter/exit through lateral ramps). It’s still, ofc, a requirement to perform deployment/storage operations WHILE on the move IRL. I chose to use the Headlight Dialog because it’s capable of “storing” facing information into a given vehicle square. In principle a simpler “widget” were the user selects front, back, left or right orientation for the HS is enough, as arbitrary angled docking bays do not work well with the “squared” model vehicles use on DDA.

HP: After a second thought, in fact I agree with you
 This component is superfluous for now
 As a basic logic of “Docking Point will be the central southernmost square of D’s plan” will work most of the time (With the extra advantage of NOT having to alter any of the currently created default vehicle templates). The problem are even width vehicles, which should require an arbitrary decission on which square to select as HP. Nonetheless, and looking ahead, the original idea of an specific HP component was to allow for orthogonal docking were D plan final orientation in the resulting vehicle wasn’t only controlled by HS orientation (Think on how a motorbike sidecar is attached, in comparison with how you drive-in a car into a towing truck).

DA: Is, by far, the most imporant component. It’s critical to be able to distinguish what to split from what WITHOUT actually having to modify the current way vehicles function as single entities, which, in turn allows easy to access operations to D while docked (Like repairing it or accessing its storage). It’s also needed so the total weight of the final vehicle respects the basic premise of D + G, as we are destroying LBFs on fusion. If I just add a logical flag/state/whatever the information about the weight to pay for storage would be lost. Notice that this simple mplementation is far from perfect, for example, If you design a “shared bay” with multiple HS in them and 2 vehicles stored at different times end been adjacent, the resulting “wreckage” will be deployed at the same time by operating ANY of the HSs. It would fall in player’s hand to be carefull when mixing multiple HS on the same G. Notice that the source of most problems is precissely accessing D’s features while docked WITHOUT mixing operative stats of D with G but, again, a lot of users on this thread requested precissely this (In fact the main reassons IRL to dock one vehicle into another is usually to perform maintenance/refuel/rearm and/or that the smaller vehicle benefits from the superior armor/defenses/operative range of the Garage).

EDIT: Forgot one detail
 The names I use are just functional. If it helps visualizing, for example, DA could appear ingame as “Docking Harness” which will loosely ressemble the different implementations used IRL to secure D’s hull to G’s to prevent violent motions from making it damage itself or the hangar interior by collision. The same could be applied to HS
 That could translate to “winch”, “clamp”, “hardpoint”, etc.

32

This would be great to see ingame at some point :slight_smile:

33

I think I could use a bit of a mockup of your idea, it’s quite confusing, especially when you use symbolic names. I think I get the gist of it, for the most part, though. That said, personally, I would still want to see simple rigid connectors, like this mockup of mine, for storage of bicycles, trash containers, shopping carts, and other manually-moved objects.

On a related note, moving furniture to the vehicle architecture, like discussed with kevin briefly in a thread I made a while ago, could be a good idea.

34

Also want to +1 this idea.

All I want is to be able to put a shopping cart in my RV, without disassembling it and reassembling it every time.

35

[quote=“Lanceo90, post:34, topic:7513”]Also want to +1 this idea.

All I want is to be able to put a shopping cart in my RV, without disassembling it and reassembling it every time.[/quote]

Currently doable with folding vehicles. Casters, foldable frame, foldable shopping basket, controls (to fold/unfold), and you’ve got that right now.

I know this is a feature a lot of people want, but unless someone is willing to take the headache of getting it all working (I think many people are underestimating what a pain it’ll be), I don’t see it happening any time soon.

36

Yeah, it probably will be a pain, though assuming ragamer did indeed look at the code and knows what s/he’s saying, it might be less of one than you think. Particularly rigid connectors like the one I had in mind might just be doable without being insanely difficult. Once I work through what I’m working through, I might take a look at related code and perhaps try implementing it if it seems doable for me.

And speaking of foldable vehicles, they could use a bit of work. Bigger batteries need to be disallowed for foldable vehicles, if current vehicle is foldable, list foldable parts before unfoldable, maybe make the really small engines and tanks foldable?

37

I have looked at the code, specifically with an eye to doing this, it’s going to be a PITA.
Rigid links wouldn’t be hard at all though, it would just end up with somewhat weird characteristics.