thanks for the reply lordpantsignton. I found these two threads which offer some clues (below). Need to process them a bit more and look at the files to know for sure. http://isiforums.net/f/showthread.php?t=259 Getting the suspension and wheels to move in unison http://isiforums.net/f/showthread.php?t=21237 Suspension / spindle problem I gather that the graphical animation can be a bit limited which leads me to believe the game wouldn't be capable of positioning the graphical wishbones accurately from full droop. Although I suspect you'll likely have much better success with a traditional a-arm suspension rather than a rocker type mentioned in the thread. I'm getting close to this step so I guess I'll know soon enough. BTW: When you say "uni-ball joint" are you referring to a point half way between the two inboard pickups? Basically the rotation axis for the kinematic curve on each wishbone? It appears that the suspension on each corner, including both upper and lower wishbones, would only have one pivot point unless they can somehow be in two separate gmts. If it can only be one gmt per corner I'd choose the top wishbones rotational axis over the lower to move both since it would be more noticeable (assuming that's the proper pivot placement). It sounds like there will be some compromises with whatever method but fortunately my suspension won't move much. May have to look closely at the legends era cars to see how their suspension arms move in game. May provide some clues. If anyone has sorted this already your insight would be greatly appreciated.
The context for that statement was assuming each link had its own gmt (and own pivot). As if there would be 5 gmt per corner. But I've not gotten to this point yet. I thought I had opened up a mas early on in rf2's life, and this was the case, but maybe not? I just checked and both the trainer and the skippy have a single GMT per suspension corner (these are still basic chassis versions, no flex).
Man, I sure wish the attachments had survived the forum migration... any chance someone still has them?
I don't, nor do I remember what they show. What is the problem you are experiencing that the attachments may help with?
No problem that reading the thread doesn't solve. Just takes longer than looking at a picture in this case.
Hi, I found this tread, which is quite useful and interesting. However, it doesn't explain everything I'm dealing with right now. The thing is: I would like to have a full explanation (step-by-step), how an rF2 car is loaded, based on existing *.PM and *.hdv files. I started a new tread for this, which you can find here: https://forum.studio-397.com/index.php?threads/vehicle-model-questions.62923/ The major goal would be to obtain the same ride heights as seen in telemetry, based on the physics and the car setup. Is it possible to provide some help here? Kind regards, Laurent Keersmaekers
I guess that none of the normal users will be able to help you out with that. For an exact step by step explanation, like you call it, you would have to know the games code, in my opinion. So this propbably can only be answered by S397 and i fear that they won't do that.
Well, a vehicle model should not be a secret. It's just physics and mathematics, which everyone can apply. The only thing which is not so trivial is the initial state: I can think of multiple ways to define the initial state, which all would yield good starting points. But when trying to understand the behaviour of the vehicles in the game, I need the 'only good' initial state, as defined by rF2.
Maybe it's language related, but i did understand what you want to have, in a different way. If you want to know a valid starting point, i would agree with what @lordpantsington has written: The car up on jacks, wheels not loaded. And then, as the reference plane, the bottom of the carbody. And do you use the ISI/S397 physics spreadsheet?
Keep in mind that the quoted list was pre-ultrachassis, It may have changed if using the ultrachassis approach. This might also be helpful (also dated info), but shows the link between different files and sort of the order of operation. http://operation.arma.free.fr/VehicleCreation.shtml
Yes, language is not my greatest asset. I understood the steps that were provided by @lordpantsington, but there are still some gray areas. As far as I understood things correctly, I get the following steps: Car is up on the jacks, which yields the suspension points as defined in the *.pm file (or chassis.ini). The location of all the suspension points are defined with the wheel center as local origin. Questions: What happens if the spindle and wheel center are not aligned in the *.ini or *.pm file? What happens if the wheelbase as defined in the *.hdv file, as well as the track width, are not the same as defined in the *.pm/*.ini file? At this point, the 'vehicle' only has 4 tyres/wheels and the location of all the suspension points. What will now happen to the remainder points such as the undertray points? (undertray00-04 form my reference plane) I guess that the garage ride height setting becomes important here? From here on, I suppose that all points are now well known (this means that all the suspension points as well as the undertray points are now uniquely defined w.r.t. the reference plane). The car is released from the jacks, causing a tyre deflection and spring compression. Due to the tyres/springs, the ride heights will now change: This causes a different initial ride height for different spring stiffness and tyre pressures? And yes, I used the physics calculator, but the model I build is a theoretical multibody model. It's fully dynamic, just as the vehicle on the simulator.
OK, i'm out then. Sorry, but i don't understand what the problems are. If you use the spreadsheet and put in the correct values, a lot of the things get "solved" automatically. And the final car normally don't uses a pm file anymore, only the chassis.ini. And so on. I also don't understand what 'a theoretical multibody model' means. Maybe some other people can help you out.
I want to assume that the UC.ini operates in the same way as the pm did, but I don't have enough time working with an UC.ini. "What happens if the wheelbase as defined in the *.hdv file, as well as the track width, are not the same as defined in the *.pm/*.ini file?" A-1b: It is moved to where it should be. (This is why the pm locations are located from the wheel center, this is so all of the pickup points come with, without changing kinematics.) The default pm files were modular in that aspect, built to be able to be used with many different mods. So what defines where it should be? Not sure, I didn't have an issue with wheel location to warrant further investigation. A-1a: Are you asking ini vs pm? if yes, ini values take priority. If no, and you are asking within each file (like you have a single corner out of whack, see A-1b. A-2a,b: I believe that is correct, undertray is set @ R.H 0 and moved with garage setting. A3: Good question, but no. The ride height IS the ride height, spring rate will determine the amount of droop (before bumpstop interaction). If you log data this will show by looking at the damper position vs ride height. RH should stay unless adjusted in garage, damper position with move with spring rate change.
Just a quick question regarding CISH: Is the CISH calculation performed with the ride height @ axle, or undertray points 00-04?
Don't think it matters as long as you are consistent in your approach. Directly from the spreadsheet: CISH =Static loaded radius-Wheel Center height [in the pm]-Design Ride Height.
