Vehicle storage in a larger vehicle

[haiironosora]

(De)coupling trailers would be a different aspect but maybe an easier starting implementation. Would make trains aboveground and in subways more possible too.

[Keyreper]

do you think it would be possible to put the vehicle in a “loading phase” turning it into terrain and allowing the smaller vehicle to move onto acceptable vehicle parts?

[i2amroy]

do you think it would be possible to put the vehicle in a “loading phase” turning it into terrain and allowing the smaller vehicle to move onto acceptable vehicle parts?

Not really, terrain and vehicles are totally different data structures and aren’t really interchangeable (even furniture and terrain can’t be easily switched back and forth).

That said the most likely thing that will show up first IMO is coupling/decoupling through trailer hitches.

[stk2008]

that would be great to see this come to life

so many cool things would come of this I think.

Is there a PR going for it?.

Thanks

[haiironosora]

Not really, terrain and vehicles are totally different data structures and aren’t really interchangeable (even furniture and terrain can’t be easily switched back and forth).

How does the game handle vehicle collision detection? As a method of the vehicle structure itself, or independently?

Also, does the engine limit how many vehicle part tiles can exist on one coordinate? Like say, vehicle tiles are contained also in a map coordinate structure rather than vehicle objects haveing a coordinate data?

[stk2008]

Has there been any more progress on this?

It would be great to have this and a tow bar

[stk2008]

Just a shameless bump incase some one has missed this and might feel like takeing on the challange.

OH how I wished I was a programmer

[SiegeLion]

Buildable bridges are in the game now, right?
Can you drive a vehicle over them?

How feasible would it be to adapt the code from those into a vehicle tile? That might work for being able to drive a vehicle into another one without collison, keeping it there during motion is a different thing though.

[stk2008]

Yeah bridges was some thing I mentioned on the IRC I said could we adapt them to the vehicle construction.

have zero idea though

[jokermatt999]

Yup, I added the buildable bridges. It was my first addition, actually. However, that’s because it was really easy. It was basically making a new terrain type that you’re able to drive over, and then adding construction options for it.

Unfortunately, vehicles are a whole separate beast from terrain. I did the bridge PR all in the json and mostly adapted existing terrain/constructions. Adding vehicle storage would require proper storing of vehicle data, correctly rotating it in relation to vehicles, handling what happens to it when the sorting vehicle gets damaged, writing an exception into vehicle collision code to be able to drive them over another, and I’m sure there’s more stuff that I’m forgetting. It’d be a huge project, which is why no one is tackling it.

I do understand the urge to have a small exploration vehicle you can stash inside your giant mobile command center, which is why I did some expansions of the folding vehicle code. Right now, (in experimental builds of course), there’s about 2 to 3 times more foldable parts, including smaller batteries, alternators, a new foldable shopping cart basket, lights, etc, and it properly calculates volume for foldable parts. They’re still limited to foot cranks and hand rims for propulsion, but you can quickly weld on an electric motor if need be since you can leave smaller batteries on there. I know it’s not the full feature you guys want here, but it was a reasonable compromise instead of several days of coding and weeks of nasty bug fixing.

[stk2008]

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

[SiegeLion]

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.

[Daidalon]

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.

[vache]

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.

[SiegeLion]

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.

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.

[SpeedDaemon]

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.

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!

[Llamageddon]

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.

[Flashlight_Hoarder]

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

[ragamer]

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”.

[Llamageddon]

snip

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.