AC Modding Questions Thread

Nope, CM showroom ignores them and if there is still AXLE/DWB code it'll draw the lines from those. The suspension dev app shows them ingame, same way as other types, but you probably need to view it in twilight & with the car stationary due to graphical issues.

Here's a front axle example
Code:
[FRONT]
TYPE=COSMIC
BASEY=-.55     ; Distance of CG from the center of the wheel in meters. Front Wheel Radius+BASEY=front CoG. Actual CG height =(FWR+FBasey)+(RWR+Rbasey))/CG_LOCATION%
TRACK=1.665     ; Track width in meters (from pivot 3D placement of the 3d model of a wheel)
HUB_MASS=35     ; masse sospese anteriori
TOE_OUT=0.005                    ; Toe-out expressed as the length of the steering arm in meters
TOE_OUT_L=0.0004
BASE_R_OFFSET=0.0,0.0,0.0 ; coordinates added to right wheel position for asymmetry (offset from basey, track, etc.)
STATIC_CAMBER=0.0                        ; Static Camber in degrees. Actual camber relative to suspension geometry and movement, check values in game
BUMP_STOP_RATE=120000                    ; bump stop spring rate
PACKER_RANGE=0.31                        ; Total suspension movement range, before hitting packers

BODY_0_NAME=AXLE            ; adding extra rigid objects to the simulation
BODY_0_MASS=110                ; pre-existing rigid objects are named HUB_L, HUB_R, and CHASSIS
BODY_0_INERTIA=1.6, 0.1, 0.1
BODY_0_POS=0.8325, 0.0, 0.0

ENGINE_TORQUE_BODY=AXLE        ; select where engine reaction torque applies (typically the body with the differential hard mounted to it. default is chassis)

J0=TOP_KINGPIN            ; J0= line has to exist, its contents is a descriptive comment
J0_BODY_A=AXLE            ; J0_BODY_A and BODY_B are the 2 objects this attaches to
J0_POS=0.198, 0.076, -0.010 ; .005        ; default is body0 = CHASSIS, body1 = "this" (HUB_L on left, HUB_R on right)
J0_KP=1                ; _KP=1 is the joint at the top of the kingpin, =0 is bottom.  Use on a joint where BODY_B=hub; tells the code which joints are WB_CAR_TOP and WB_CAR_BOTTOM for steering calculations

J1=BOTTOM_KINGPIN
J1_BODY_A=AXLE
J1_POS=0.1807, -0.076, 0.010
J1_KP=0

DJ0=TRAILING_LINK
DJ0_BODY_B=AXLE
DJ0_POS0=0.464,0.115, -0.805
DJ0_POS1=0.29,0.0,0.0

DJ1=TRAILING_LINK_U        ; controls axle twist
DJ1_BODY_B=AXLE
DJ1_PARITY=0
DJ1_POS0=0.464,0.115,-0.805
DJ1_POS1=0.29,0.10,0.0

STEER_JOINT_0=STEER_LINK
STEER_JOINT_0_BODY_A=CHASSIS
STEER_JOINT_0_PARITY=1
STEER_JOINT_0_POS0=1.355, 0.22, 0.166
STEER_JOINT_0_POS1=0.1304, -0.033, 0.166

STEER_JOINT_1=TIE_ROD
STEER_JOINT_1_PARITY=0            ; default -1, setting 0 or 1 makes this link part of left or right suspension.
STEER_JOINT_1_BODY_A=HUB_L            ; linking wheel hub to wheel hub is possible
STEER_JOINT_1_BODY_B=HUB_R
STEER_JOINT_1_POS1=1.5346, -0.033, 0.166
STEER_JOINT_1_POS0=0.1304, -0.033, 0.166
STEER_JOINT_1_STEERVECTOR=0.0, 0.0, 0.0    ; sets the direction this link moves when steered.  in this case it's 0 because it only changes length with toe, not with steering.

[FRONT_SPRING_0] ; vertical coil spring
RATE=70000; 52700
BODY_B=AXLE
PRELOAD=0.08
POS0=0.29,0.7,0.0
POS1=0.29,0.0,0.0

[FRONT_SPRING_1] ; lateral spring based on compliance
RATE=1200000
PULL_FORCE=TRUE  ; spring is symmetrical rather than the default of compression only
BODY_B=AXLE
POS0=1.201,0.115,-0.805
POS1=0.29,0.0,0.0

[FRONT_DAMPER_0] ; vertical damper
DAMP_BUMP=6000                        ; Damper wheel rate stifness in N sec/m in compression
DAMP_FAST_BUMP=850
DAMP_FAST_BUMPTHRESHOLD=0.075
DAMP_REBOUND=  12200                        ; Damper wheel rate stifness in N sec/m in rebound
DAMP_FAST_REBOUND= 4000
DAMP_FAST_REBOUNDTHRESHOLD=0.130
BODY_B=AXLE
POS0=0.29,0.5,0
POS1=0.29,0.0,0
MIN_LENGTH=0.355        ; suspension travel is limited by this
MAX_LENGTH=0.575
END_RATE=1000000            ; spring force of end limits
END_VTAPER=0.02            ; speed at which rate tapers off
END_VMAX=0.10            ; speed where end limit adds 0 force

[FRONT_DAMPER_1] ; lateral damping
DAMP_BUMP=69000
DAMP_FAST_BUMP=3000
DAMP_FAST_BUMPTHRESHOLD=0.6
DAMP_REBOUND=69000
DAMP_FAST_REBOUND=3000
DAMP_FAST_REBOUNDTHRESHOLD=0.6
BODY_B=AXLE
POS0=1.201,0.115,-0.805
POS1=0.29,0.0,0.0

[FRONT_DAMPER_2]  ; limiting steer lock for stability, only acts as hard bumpstop, no damping
DAMP_BUMP=0        ; req'd for it to read the section
BODY_A=AXLE
POS0=0.1, 0.0, 0.34
POS1=0.1304, 0.0, 0.166
MAX_LENGTH=0.28

[FRONT_DAMPER_3] ; steering damper connecting axle to hub to prevent speed wobble
DAMP_BUMP=5000
DAMP_FAST_BUMP=1000
DAMP_FAST_BUMPTHRESHOLD=0.1
DAMP_REBOUND=5000                ; Damper wheel rate stifness in N sec/m in rebound
DAMP_FAST_REBOUND=1000
DAMP_FAST_REBOUNDTHRESHOLD=0.1
BODY_A=AXLE
POS0=0.53, -0.033, 0.166
POS1=0.1304, -0.033, 0.166
thanks stereo, as always very kind..
I try to take a look:)
 
Hi guys! Got a question for you all. I'm working on this mod, a racing series, which'll include four generations of a certain model. Now I'm having some shading issues on on the tyres of three out of the four models. All use the same tyre model, textures and shaders, so my guess is it must have something to do with ambient shadows or something else within the data of the cars. I just can't seem to figure out what it is. Maybe one of you knows how to solve this?

This is the issue, this is the way the tyres are supposed to look:
20230209204029_1.jpg

20230209204009_1.jpg

This is the way the tyres show up on the other three models, with weird shading. It's like that in any lighting:
20230209202808_1.jpg

20230209203012_1.jpg

It's all still very much a work in progress, but I'm hoping someone can point me in the right direction regarding this. Thanks a lot in advance!
 
i While waiting for someone more knowledgeable than me to answer you, I'll try to give you some suggestions...
those shadows can also be generated by scripts inside ext_config.ini in your car's extension folder
 
Hi, does anyone know if there is a way, for example with CSP\EXTENSION to alter the spawn times for a car mod?
Let me explain..
I would like a specific mod, in case of rollover or other situation that generates the "automatic Spawn" not to be relocated to the start immediately after a few moments, but that the auto-Spawn time could be extended.
 
This is probably a stupid question, but...

Is there a way in CSP configs to globally rotate the track about (what is in Blender) the Z axis? I've gotten most of the way through modeling a fictional track but I want to match it to a real world location. The location I've picked requires me to change what "north" is.

This is important because if this is not set correctly the sun setting direction and the other fancy SOL/Pure features in terms of skybox won't be correct.

If it's not possible, what way would you guys recommend asides from parenting everything in the .blend to an empty and rotating that so north is +Y (in Blender format)?
 
Last edited:
This is probably a stupid question, but...

Is there a way in CSP configs to globally rotate the track about (what is in Blender) the Z axis? I've gotten most of the way through modeling a fictional track but I want to match it to a real world location. The location I've picked requires me to change what "north" is.

This is important because if this is not set correctly the sun setting direction and the other fancy SOL/Pure features in terms of skybox won't be correct.

If it's not possible, what way would you guys recommend asides from parenting everything in the .blend to an empty and rotating that so north is +Y (in Blender format)?
you should be able to rotate the kn5 inside models.ini:
INI:
[MODEL_0]
FILE=your_track.kn5
POSITION=0,0,0
ROTATION=0,0,0
 
The canonical way to set that is in data\lighting.ini, SUN_HEADING_ANGLE sets which direction is north (pitch sets latitude, although badly, for CSP purposes you also want lat/long to be in the ui_track.json)
 
Last edited:
The canonical way to set that is in data\lighting.ini, SUN_HEADING_ANGLE sets which direction is north (pitch sets latitude, although badly, for CSP purposes you also want lat/long to be in the ui_track.json)
Thanks! That's exactly what I needed to know.

I've run into another problem with how the car interacts with the simplified collision meshes surrounding higher-poly objects like Armco fencing. Here's a video of the odd behavior:
This seems like flipped normals, but I checked them and they're correct. The scale isn't negative either. They're named correctly (1WALL_etc.) What is the issue here? I'm out of ideas.
 
Last edited:
Thanks! That's exactly what I needed to know.

I've run into another problem with how the car interacts with the simplified collision meshes surrounding higher-poly objects like Armco fencing. Here's a video of the odd behavior:
This seems like flipped normals, but I checked them and they're correct. The scale isn't negative either. They're named correctly (1WALL_etc.) What is the issue here? I'm out of ideas.
Can you show the wireframe? Also how is it shaded? Flat or smooth?
 
It's probably better to go simpler for WALL objects, just a vertical face facing the track (even a small lean over vertical sometimes causes issues). Top or back of that could both be messing up how AC handles it.
 
Last edited:
It's probably better to go simpler for WALL objects, just a vertical face facing the track (even a small lean over vertical sometimes causes issues). Top or back of that could both be messing up how AC handles it.
I thought non-thick wall meshes caused sticky walls in AC?
 
Sticky walls are mostly an issue when the mesh only has one side I believe, the back side becomes a problem.

I’m almost sure the issue the guy above is having is due to the mesh being named wall and road

So to prevent sticky walls you can have a non-thick object as long as it has faces on both sides then (like we do for trees since AC doesn't have dual sided polys)?

Good to know!
 
Your collision objects might have a problematic name… don’t add the word “road” when it’s meant for it to be a wall. Since Road with a number in front is also interpreted as something else that’s physical.
Crap! Forgot about that. Was actually having a similar issue with another track, should have checked that out here too. I’ll test it in a bit and see if it fixes it.
 
So to prevent sticky walls you can have a non-thick object as long as it has faces on both sides then (like we do for trees since AC doesn't have dual sided polys)?

Good to know!
hitting the back side of a physical wall can make a car stick to it, but having walls too thin also causes problems; id guess for the same reason.
(also who's making walls out of y trees? that sounds really bad)
 

Latest News

Shifting method

  • I use whatever the car has in real life*

  • I always use paddleshift

  • I always use sequential

  • I always use H-shifter

  • Something else, please explain


Results are only viewable after voting.
Back
Top