Build for the
world of BeamNG.

Begin with a small test loop rather than a giant open world. BeamNG’s current level guide recommends the Starter Level template and a first milestone that loads, spawns a vehicle, and has one drivable road or test area.

1. In BeamNG.drive, open the World Editor with F11 and create a new level from the Starter Level template. Give it a short lowercase folder name.
2. Save the new level and confirm its folder is under your BeamNG user folder’s levels directory. Keep the level’s working files together.
3. Place the SpawnSphere (the spot where the player starts) on safe, flat ground, and set it as the map’s default start point.
4. Make a short road or flat driving pad. Save, reload the level, spawn a vehicle, and drive the whole test area.
5. Check BeamNG’s error log for missing files or materials before adding more content.

Terrain is both a shape and a surface. A hill can look right but still feel wrong to drive if its slope, ground material, or road edge is abrupt.

1. Use the terrain brush in small passes to raise, lower, and smooth the ground. Keep a separate test slope so you can check vehicle behavior as you work.
2. Paint a few materials with clear purpose: road shoulder, dirt, grass, and rock. Use the level’s terrain material workflow and check every texture after reloading.
3. Choose the matching ground behavior for grip and bumps. A gravel-looking image alone will not make the surface feel like gravel when driving.
4. Blend terrain into roads and props. Drive the joins slowly and at speed to find bumps, gaps, and invisible edges.
5. If importing a heightmap, check its orientation and scale in the editor before doing detailed sculpting.

An advanced map route should be easy to understand from the driver’s seat and feel right at different speeds. Every crest, corner, shoulder, and transition should have a reason and enough space for the intended vehicle.

1. Write a route brief: intended vehicles, driving style, average speed, challenge level, and what the player should notice.
2. Lay out the road centerline first. Use broad turns and gentle grade changes to establish flow before adding tight corners or dramatic crests.
3. Check sight distance, corner entry, banking, road width, runoff, and recovery space from the driver’s view.
4. Build a repeatable test route with clear start and end points. Drive it in a light car, a heavy vehicle, and a faster vehicle.
5. Use decals, shoulders, barriers, and terrain transitions to communicate the road edge without creating snag points.

A finished level needs to load consistently, keep a useful frame rate, and include every referenced asset. Validate the packaged ZIP separately from your working folder.

1. Check the map in daylight and at night. Confirm the road is readable, lights do not overwhelm visibility, and the spawn is obvious.
2. Review vegetation and repeated props for density, draw distance, and avoidable clutter. Check the frame rate in the busiest area, not just the empty start point.
3. Inspect the level for missing textures, broken material paths, duplicate assets, and files that are only present on your machine.
4. Include the required /levels/your_map content and referenced assets. Leave your working files, temporary game files, and autosaves out of the ZIP you share.
5. Test the ZIP after moving your working folder out of the way and turning off other mods. Confirm load, spawn, materials, and performance.

The Road Spline Tool lets you draw a road path and make its markings and ground edges follow it. Test a short section first: a road can look smooth from above but still have a bump or rough edge when driven.

1. Open the World Editor with F11, switch to the Road Spline Tool, and make a short test spline on a flat area.
2. Place physics points along the road path where its shape changes, such as where a bend starts or ends, or where the road rises over a hill. Avoid adding a node every few metres; too many make the path harder to smooth.
3. Drag the side handles to set the road width. Add or adjust layers for the asphalt, edge lines, center line, and wear so each layer follows the same route.
4. Choose the terrain material and margin, then enable terrain painting and edge blending. Inspect the seam from the driver camera and from a low side angle.
5. Drive over the spline slowly and at speed. Check for sharp crests, floating edges, sudden grip changes, and markings that drift away from the road.
6. Save your level, reload it, and check the road again. If you need to reuse the setup, save the spline profile and test it on a second short section.

A small cosmetic part is a good first vehicle mod. Start with a simple lip, roof accessory, or bumper detail that fits an existing slot. Keep your own files in a standalone mod folder and give your part names a unique prefix.

1. Choose one vanilla vehicle and one existing part slot that matches what you want to make. Use the in-game parts selector and official part/slot documentation to learn the slot’s exact type.
2. Make a separate working folder for your mod at Userfolder/mods/unpacked/your_unique_mod/vehicles/<vehicle_name>/. Keep all of your part files inside it. Do not edit or redistribute the original game files.
3. In Blender, use a reference mesh only as a placement guide. Create your own mesh, align it to the vehicle, name it clearly, and export a DAE into your mod’s vehicle folder.
4. Make a small JBeam part definition with a unique internal name and the slot type you found. Reference your own mesh and suitable existing node groups only when you understand their purpose.
5. Reload the vehicle and look for your part in the slot. Confirm it installs, appears in the right place, and can be removed again.

The mesh is only the visible part. JBeam identifies the part, connects it to a slot, and maps the visible model to the vehicle’s structure. Start by reading a similar vanilla part to understand the pattern, then write your own small definition.

1. Read the parent part’s slots entry and note the slot type, default part, and display name. The child part’s slotType must match.
2. Give the new part a unique internal name, a readable display name, and your own author information.
3. Export a low-complexity mesh to DAE. Keep the pivot and orientation consistent with the vehicle, and ensure object names match references used in your JBeam.
4. Set up the required material definition and use texture paths inside your mod. Start with a simple material before adding a full texture set.
5. Reload the vehicle after each change. Inspect the part selector, check for console errors, and compare alignment from front, side, and rear views.

Complex upgrades need a clear list of which parts fit into other parts. Separate mesh, JBeam, and material responsibilities so a broken option can be isolated without losing the rest of the vehicle.

1. Write down which part-menu openings accept each part, and which part is selected by default, before editing. Prefer existing compatible slots; adding a new slot to a vanilla vehicle usually means modifying its parent and can create compatibility conflicts.
2. Split related components into focused JBeam files and use unique prefixes for part names, nodes, groups, materials, and mesh objects.
3. Use slot variables when a reusable part needs small placement or configuration changes. Keep each variable’s purpose documented and test every supported combination.
4. Map flexbodies to the intended node groups, check origins and transforms, and use deform groups only when the part needs damage-triggered material changes.
5. Test combinations with other common upgrades, then verify deformation, breakage, reset behavior, and vehicle configurations.

When a part appears offset, floats, or behaves strangely after a crash, diagnose one layer at a time. A model with its center point in the wrong place, a mismatch in physics-point groups, a repeated name, or the wrong parts-menu slot can all look like a modeling problem.

1. Confirm the part is loading from your mod and that its slot type and identifiers are unique.
2. Compare the model’s center point, position, rotation, direction, and size with the car’s other parts. Check carefully where the deforming model is centered and which physics points it follows.
3. Check that the flexbody references the intended mesh and node group. Use node and triangle debug views to understand the structure rather than guessing.
4. Read the console immediately after reload and fix the first relevant error before chasing later warnings.
5. Test with only the mods you need turned on and make sure you have not copied, modified, or redistributed game files without permission.

A slot variable is a setting passed from the vehicle’s parts-menu slot to the add-on installed there. They are useful when a component has small differences between vehicle variants, so you can reuse one part definition instead of copying nearly identical files.

1. Choose a harmless difference to test, such as a node offset or a small dimension. Do not begin with suspension geometry or a safety-critical component.
2. Find the parent slot entries and identify the values the slot can pass. Read the official Slot Variables example and a current vanilla example before editing.
3. Make a copy of your own working part in your unpacked mod. Add a uniquely named variable to the slot definition, then reference it in the child part using the documented syntax.
4. Start with one simple setting and do not make it adjustable yet. Confirm the part loads and behaves exactly like the original test before adding a second variant or a function.
5. Use a second slot/vehicle variant to pass a different value. Make sure names and node/group identifiers remain unique where the part requires them.
6. Reload the vehicle after each change. Check the parts selector, console, node positions, and deformation; remove the part and verify the stock configuration still loads.

A complete car is a much bigger job than a body model. For a first project, choose a simple vehicle concept and reuse a compatible drivetrain or suspension as a learning scaffold, as BeamNG’s basic-car tutorial demonstrates.

1. Write a one-sentence concept and pick a vanilla platform with a similar wheelbase, engine location, and intended use.
2. Decide what is yours: body, chassis design, wheels, engine tuning, or configuration. Make a small scope you can finish.
3. Read the official basic-car tutorial before changing files. Use its included template and examples where appropriate instead of trying to invent every system at once.
4. Keep all the files for your mod together and give them names that will not clash with other mods. Treat vanilla files as references; do not ship the game’s original assets as your own.
5. Block out the body in Blender and check proportions against wheel centers, ground clearance, and the intended driver space.

Get a simple prototype spawning before refining details. A vehicle needs both a visible 3D model (DAE) and JBeam files that define how its physics works.

1. Keep the first chassis simple and follow the template’s coordinate conventions. Separate visible body meshes from the physical structure.
2. Use a simple, evenly spaced layout of physics points and links to make the basic frame. Read each section of the template and change one system at a time.
3. Reference the body mesh as a flexbody and make sure its object name, origin, and node group agree with the JBeam.
4. Start with the template’s compatible suspension and drivetrain. Do not attempt a complex bespoke powertrain before the car can spawn and move.
5. Load the car, inspect it in the vehicle editor/debug views, and test at low speed on a simple map. Fix structural issues before styling.

Advanced vehicle work means designing a coherent physical structure, not just making a detailed mesh. Nodes, beams, triangles, and groups determine how the car deforms and how its visible components follow.

1. Use the reference platform to understand proven geometry, but design and name your own structure deliberately. Keep the overall node layout readable and symmetric where appropriate.
2. Build the chassis in logical groups and connect the structure with beams that provide stable paths for loads.
3. Map body panels and mechanical meshes to appropriate flexbody groups. Keep origins at the expected location and check the mapping in game.
4. Tune deformation and strength gradually. Make one controlled change, then test the same low-speed and higher-energy impacts.
5. Use BeamNG’s debug visualizations to find disconnected nodes, weak links, bad triangles, and meshes that detach or stretch.

A vehicle feels complete when its options form a usable system. Organize the parts tree and configs so players can understand what each choice changes.

1. Separate major components into parts with clear slots and defaults. Avoid one giant file that is difficult to debug.
2. Add only a few meaningful options first: for example, road and off-road suspension, two engines, and a body trim.
3. Set up materials and textures with consistent naming. Verify every material and texture path in game.
4. Create a small number of tested configurations with useful names and thumbnails. Confirm each configuration loads without missing parts.
5. Test handling, deformation, reset, part combinations, and performance. Package only your own required files and test the ZIP outside your working folder.

For the car to move, engine power needs an unbroken route through the gearbox and other parts to the wheels. Treat the powertrain as a chain of devices and debug the connection before chasing performance numbers.

1. Start from a working vehicle of a similar layout. In your own mod copy, list its engine, clutch, gearbox, driveshafts, differential, and driven wheels.
2. Open the in-game Powertrain Visualization app. Confirm torque reaches the intended wheels and note the name and RPM shown for each device.
3. Change one component at a time in your own JBeam. Keep the original device names and input/output names visible in your notes so you can trace every connection.
4. Test at low speed first. Confirm the vehicle moves in the expected direction, reverse works, and the transmission does not produce obvious wind-up or disconnected wheels.
5. Use the Torque Curve and Shift Point Debug apps to inspect engine output and automatic shifts. Do not tune shift points until the device chain is correct.
6. Save a known-good version before changing ratios or torque. Recheck behavior with different gears, a reset, and a fresh game load.

Before opening a painting app, decide what needs a texture and what can use a shared material. A tidy UV layout and clear material names save time in every later step.

1. Apply your modeling scale and create seams in hidden or natural places before unwrapping.
2. Unwrap the mesh, check for stretching, and pack islands with enough padding to avoid texture bleeding.
3. Give similarly sized visible parts about the same amount of texture detail. Give important parts more texture space than tiny hidden details.
4. Name the material and texture files with a unique project prefix. Keep source images in your mod’s own art folders.
5. Start with base color and a neutral material check in BeamNG before adding detailed maps.

Recommendation: Adobe Substance 3D Painter is a strong paid option for painting directly on a 3D model, building layer-based materials, and adding controlled wear. It is not required: a 2D image editor can handle simple liveries and hand-painted textures.

1. Finish the UVs first and export the mesh with its named materials. Each material on the model can create a separate group of texture images, so only split them when there is a good reason.
2. Create a Painter project from the mesh and choose a project template that matches the normal-map convention you plan to use.
3. Create guide images from the model so Painter can place dirt and wear around edges and creases. Check the generated guide images. If there are strange marks, fix the model or texture layout instead of painting over them.
4. Build layers from broad base materials to restrained dirt, edge wear, decals, and small details. Put dirt and worn paint where the vehicle would realistically get dirty or scratched.
5. Use a custom export preset only after checking the output maps and channel packing against BeamNG’s material needs. Export PNG source textures and verify them in game.

Vehicle materials often have role-specific conventions. For example, BeamNG documents separate material types for body, interior, mechanical parts, lights, glass, and wraps. Follow the intended type instead of exporting one generic texture set for everything.

1. Plan the first texture layout (UV0) for the main surface images and small raised-looking detail. For a car body, also plan the second texture layout used by paint skins, if you want skins to work.
2. Set up separate Painter texture sets for materials that genuinely need different maps or resolution. Avoid splitting every small object into its own set.
3. Choose image size based on how close players will get and how much of the screen the part fills. Power-of-two dimensions are common, but the best size depends on the asset and texture set.
4. Export the main color image, surface-detail image, shine/matte setting, and any other needed images. Check which image channels Painter combines into each file. Confirm BeamNG’s expected channels before finalizing a preset.
5. Use BeamNG’s material definitions and texture cooker conventions, then check the final in-game images and how much graphics memory they use.

A reusable skin is more than a decal placed on a render. It needs a suitable vehicle wrap UV layout, a skin material definition, and a part that exposes the design in the vehicle selector.

1. Confirm that the vehicle’s body material and UV layout support a wrap. Use the vehicle material guide to understand the intended UV channel.
2. Build a livery in Painter or a 2D editor using the wrap layout as a guide. Keep logos and text away from seams and distorted areas.
3. Use unique names for the skin material and JBeam part. Follow the skin system’s required slot conventions for the target vehicle.
4. Check the exported image on the 3D car, not only the flat UV. Inspect panel transitions, mirrored areas, and text direction.
5. Install the mod as a standalone package and test the livery on more than one vehicle configuration if the skin is intended to support them.

Exporting the images is only one step; you also need to connect them to a material in the game. Keep your Painter project as the source, export the maps to your mod, and let BeamNG’s texture cooker create the game-ready DDS versions.

1. Before painting, confirm the mesh UVs, material names, and texture resolution. Keep the project’s texture set names clear so the export files are easy to identify.
2. In Substance 3D Painter, choose an export preset that matches the target workflow, then inspect the output template. Confirm which exported map is base color, normal, and packed data before using it.
3. Save source maps with BeamNG’s expected suffixes, such as .color.png, .normal.png, and .data.png. Use simple filenames with no spaces.
4. Reference the PNG paths in your own main.materials.json; do not point the material at a DDS filename. Confirm the material name matches your model’s material slot.
5. Load the vehicle so the game can cook the textures. Check the console for conversion or path errors, then inspect the paint, normal detail, roughness, and color in several lighting conditions.
6. For the release, include the cooked DDS files required by BeamNG and keep your editable Painter project and source PNGs in your development backup.

JBeam is a soft-body structure. Nodes are points with mass, beams connect them and resist changes in length, and triangles describe surfaces used for collision and aerodynamic effects. The visible 3D model sits over this physics structure; the model itself is not what holds the car together.

1. Pick one simple vanilla part and trace its nodes, beams, triangles, and groups. Start with a small structural area rather than the whole vehicle.
2. Use the vehicle coordinate system consistently: positive X is left, positive Y is backward, and positive Z is up. Mark the axes on a sketch before entering node coordinates.
3. Check the node table header and units. Node positions are meters; node weight is mass in kilograms.
4. Follow connections through the structure. A four-sided frame can lean sideways because its links can pivot at the corners. Add a diagonal brace to help it hold its shape.
5. Separate groups by purpose so flexbodies and related parts can map to the nodes that should deform them.

A flexbody is the visible model that follows a group of physics points as they move or bend. A prop is a moving model part, such as a gauge needle. It follows a vehicle signal, but does not bend with the vehicle structure. Choosing the right representation avoids floating meshes and unnecessary physics cost.

1. Find the node group that represents the panel or component. Confirm that the group exists and contains the expected nodes.
2. Match the flexbody mesh name to the exported DAE object and bind it to the correct node group.
3. Keep flexbody origins and transforms consistent with the vehicle. If the model’s center point is in the wrong place, the part can appear misplaced even when its shape is right.
4. Add collision triangles only where the player or another vehicle needs meaningful contact. A visible model by itself does not stop other objects from passing through it.
5. Use props for non-deforming animated parts such as needles, pedals, and steering wheel motion; give each prop valid reference nodes and an input electric.

The settings for each physics link affect one another. Spring and damping influence elastic response; deformation and strength control when beams permanently deform or break; bounds limit how far a beam can compress or extend. Copying a value from an unrelated part rarely produces a sound structure.

1. Write down the behavior you want and identify the smallest group of beams that could cause it.
2. Establish a baseline and use one repeatable test. Change one property at a time, then run the same test again.
3. Use beam stress, displacement, deformation, support-only, node-force, and stability debug views to find the actual failure path.
4. Look for geometry issues before raising strength: precompressed beams, bad bracing, triangle clipping, incorrect groups, and overly dense collision can create instability.
5. Record the test, changed values, and result. Check both expected deformation and failure behavior so “stronger” does not simply mean brittle or unnaturally rigid.

Advanced structures often need special collision or damage behavior. A deform group can change a material when a part bends. A break group can make connected parts fail together. Rails and slidenodes can add collision points that move along an edge. These features add complexity, so use them only to solve a demonstrated problem.

1. Choose a narrow goal: for example, switch a lamp to a damaged material after its support deforms.
2. Use the same group name on the links and visible model parts that should share this damage behavior. Test the trigger at the intended damage level.
3. Use deformationTriggerRatio selectively. BeamNG flags this as a performance-sensitive property; avoid allowing it to leak into unrelated beams.
4. For a part that needs sliding edge collision, study the official rails/slidenodes workflow. Keep collision nodes grouped separately and inspect their forces and stability.
5. Check for self-collision, triangle clipping, shaking, and performance cost. Remove helper nodes or triangles that do not improve the result.

JBeam triangles fill an area between three nodes. They can provide collision between JBeam nodes and contribute aerodynamic drag, but they are not structural braces and do not collide with the static world. Keep those jobs separate while you build.

1. Start with a small test panel on your own prop or vehicle part. Make sure its three referenced nodes already exist and are named uniquely.
2. Add a single triangle using the documented counter-clockwise node order. Load the vehicle and enable triangle debug view to see which side is facing forward.
3. Test it against another JBeam object using very low speed. Remember: a coltri collides with nodes, not with other triangles or the static map.
4. If objects phase through during hard contact, inspect which side faces the impact. Flip the triangle by swapping two node references, then test again.
5. Only add triangles where they have a clear purpose. Compare behavior and performance before expanding a dense panel into many small triangles.
6. If using triangles for aero, tune and test separately from collision. Their drag depends on airflow, surface area, and aerodynamic properties.

BeamNG’s vehicle electrics are a signal bus used by JBeam, vehicle systems, props, and UI apps. The current electric list varies by vehicle. The built-in Force Induction app already shows boost in cars that have a turbo or supercharger, so use that first to confirm the signal and units.

1. Spawn a turbocharged vehicle and add the Force Induction UI app. Compare its reading while the engine idles, while you rev it without moving, and while driving.
2. Open the vehicle Lua console and inspect electrics with dump(electrics). Look for boost and boostMax.
3. Check the official electrics reference for units; boost is reported in PSI. Do not assume every vehicle has the same signals or a forced-induction system.
4. Check whether the signal is smoothed, then compare its quick changes with the slower movement shown on screen. If the gauge needle jumps around, smooth its reading instead of changing the turbo.
5. Write down the source signal, unit, range, and what should happen when the engine is off or the vehicle has no boost signal.

A physical dashboard gauge is a great first “code-like” feature because the JBeam prop system can map an existing electric straight to a needle. No custom Lua is needed for this version.

1. Model a dial and a separate needle in Blender. Place the needle pivot at its zero position and export both with clear mesh names.
2. Choose the dashboard reference nodes for idRef, idX, and idY. They tell the game where the gauge sits and which way it faces. Place them at a right angle so the game can work out its direction.
3. In the JBeam props table, set func to the boost electric and mesh to the needle mesh. Set min and max to the intended gauge range.
4. Work out how far the needle must rotate to cover the numbers on the dial. For a 270-degree sweep across 0–30 PSI, start with 9 degrees per PSI; the axis and sign depend on your needle orientation.
5. Set the offset so zero boost points at zero on the dial. Reload, check both endpoints, and verify the needle does not pass its stops.

The digital display is a BeamNG app. Lua is separate code that runs inside the vehicle when you need to calculate or control something. BeamNG’s UI app guide uses AngularJS and a stream listener. Keep the display in the UI layer; add vehicle Lua only if you need a new signal or behavior.

1. Create an app folder in Userfolder/ui/modules/apps/ with app.js, app.json, and a 250×120 app.png preview.
2. Register an app directive, request the electrics stream with StreamsManager, and update the view from streamsUpdate.
3. Read the boost values from the vehicle data feed. Check a built-in app from your game version to see the exact data names and format.
4. Format PSI clearly, clamp the bar or needle to its designed range, and show a sensible idle or unavailable state when boost data is missing.
5. Stop requesting vehicle data when the player closes the app. Add styling for readable contrast and test several window sizes.

Start with a JBeam custom electric for simple formulas. Move to a vehicle Lua extension when the behavior needs state, several update steps, a custom input, or logic that cannot fit in a formula.

1. Confirm that the needed source electric exists on the target vehicle. Use a unique output name so your mod does not overwrite another value.
2. For a simple derived signal, define a JBeam electrics.customValues entry. Example: ["jack_boost_bar", "electrics.boost * 0.0689476", 0] converts PSI to bar.
3. If the value needs a gradual response, define a smoother for that custom electric and tune it by observing the display under a repeatable load.
4. For stateful behavior, add a vehicle Lua extension under the vehicle’s lua/vehicle/ folder and expose only the callbacks or functions your mod needs.
5. Keep vehicle-only APIs in the vehicle Lua VM. Use the UI VM for display code and the game Lua VM for global game or editor behavior; connect them through supported streams or hooks.
6. Reload the vehicle after changes, inspect the output electric, and test reset, engine-off, missing-signal, and unsupported-vehicle cases.

This project links a simple controller signal to a visible light. First decide what the signal means: for a beginner-friendly shift light, use a threshold you can test reliably, such as engine RPM relative to a chosen target. Keep the controller logic separate from the material that displays it.

1. Copy a small, relevant controller example into your own vehicle mod and read its update/reset functions. Do not edit the game’s installed controller files.
2. In the controller, calculate a clear 0 or 1 state from a value that exists on the vehicle. Give the electric a unique name and make sure the state is written every update.
3. Add a small indicator material to your own model and define a glowmap that reads that electric. Start with only off and on materials, then confirm the material name matches the model exactly.
4. Load the vehicle and inspect the electric using the vehicle debug apps. Temporarily use a low threshold so you can see the signal switch, then set the intended threshold.
5. Check the lamp in daylight and darkness. If the signal changes but the lamp does not, debug the material name and glowmap separately from the Lua logic.
6. Test after reset and with the engine off. Make sure the code resets the light to a known state and does not leave the lamp stuck on.

This first build is a tray that can be pulled in and out by hand. Rails define the path and slidenodes constrain selected tray nodes to that path. They guide motion; they do not act as a motor.

1. Block out a fixed cabinet frame and a separate moving tray. Keep the refrigerator as a separate mass or visual part so its weight can be tested.
2. Place two straight, parallel rails on the fixed frame. Each rail needs at least two support nodes; extend the rails only as far as the intended travel.
3. Add matching slide nodes to the tray structure. Position each node exactly on its rail at spawn and use multiple separated sliders so the tray cannot yaw easily.
4. Define the rails and slidenodes in JBeam. Use capped rails so the tray stops at each end; start with a short travel and conservative forces.
5. Connect the tray’s visible mesh to its own flexbody node group. Add only the collision nodes and triangles needed for the tray to meet the cabinet without snagging.
6. Reload and inspect the Rails and Slidenodes debug view. Use the node grabber to move the tray slowly from one end of the rails to the other and watch for twist, shake, clipping, or detachment.

Once the basic tray works, add collision and a deliberate lock. Keep the latch separate from the rail constraint: the rails guide the tray, while the latch prevents unwanted travel when closed.

1. Test the tray both with the refrigerator inside and with the tray empty. Add structural beams between slide nodes and the tray frame to control roll and yaw without rigidly attaching it to the cabinet.
2. Add a few physics points along the front and sides so the tray can bump into nearby parts. Check for self-collision and use noncollidable triangles only where the anti-clip surface is needed.
3. Make a latch with a clear locked and released state. Copy a suitable latch example from the original game files, or a small vehicle Lua controller if your latch needs its own state.
4. Place a triggers2 box at the handle and connect its primary action to a *.interaction.json action that releases or re-engages the latch.
5. Expose that action with actionsEnabled only when the slide part is installed. Keep the trigger volume small and place it where a player naturally reaches.
6. Test the clickable handle, how far the tray slides, whether the lock holds, and what happens after resetting the car. Use the rail, force, and collision views to find what is making the tray shake or stick.

A canopy door needs a straight hinge line and a powered part that opens and closes it. A torsion hydro swings a panel around its hinge when told to open or close it. A regular hydro pushes or pulls in a straight line. Prototype the movement before adding a trigger.

1. Build the fixed canopy frame and separate moving door as their own node groups. Keep the visible panel mesh as a flexbody on the door group.
2. Place a pair of hinge-axis nodes along the intended pivot line. Keep both hinges aligned so the door does not bind as it swings.
3. Design the actuator lever points away from the hinge axis. Add a torsion hydro using the two lever ends and two axis nodes, with its travel limits set to the intended open angle.
4. Use a test vehicle signal or temporary control to open and close the powered hinge. Tune the direction and rate; if it moves the wrong way, reverse the input factor.
5. Add physical stops so the panel cannot travel through the frame. Check that the actuator does not push the panel through the vehicle body.
6. Test slowly, then at normal simulation speed. Check the hinge nodes, beam stress, actuator limits, and panel deformation.

Use the current triggers2 workflow: the trigger finds the handle, the interaction map defines the action, and the action changes an electric that drives the torsion hydro. This keeps the hitbox, action, and physical movement easy to debug separately.

1. Create a unique electric name for the canopy state, such as jack_canopy. Set the torsion hydro’s inputSource to that electric and tune its open and closed behavior first.
2. Add a triggers2 clickable area around the outside handle. Use the correct physics points to position it, then check that the game highlights it when you point at the handle.
3. Create a vehicle *.interaction.json file. This file gives the clickable area its on-screen action. Set "fileversion": 2 and give the action its own unique ID. Use onDown to switch the canopy signal between 0 (closed) and 1 (open).
4. Link the trigger’s action0 to that interaction action with triggerEventLinks2, and list the action in actionsEnabled.
5. Optionally add an interior trigger linked to the same action so the canopy can be operated from both sides.
6. Check the action title, trigger position, hydro direction, end stops, reset state, and damage behavior. Test with the canopy both open and closed during a light impact.

Your canopy already has an electric that changes when the trigger opens or closes it. Reuse that signal for a small status lamp so the interactive action and visual feedback stay connected.

1. Make a backup of the working canopy starter before changing it. Confirm the existing canopy electric changes to 0 when closed and 1 when open.
2. Add a small indicator mesh or material slot to your own canopy model. Give the material a unique name and keep the lamp away from the hinge and moving panel.
3. Add a glowmap entry for that material. Use the canopy electric as its input, with the off material for 0 and the on material for 1.
4. Load the vehicle and test the trigger. Open the canopy and check the lamp; close it and check that the lamp turns off.
5. If the lamp shows the wrong state, first check the vehicle signal value and then check the glowmap input and material names. Change one item at a time.
6. Test reset, vehicle reload, and both trigger locations. Ensure the lamp does not suggest the canopy is closed when it is still open.