It’s not a good idea for my project. In my game I will have one big map and shop with lot of cars (example: gta style). All of these elements must be physically integrate together in one scene. Overlay scenes screen for all vehicles is not convenient method and not help in my problem.
Ok. I give up 
This is shitty. I researched the whole google,documentations and nothing :ba: even use the print(dir.function) :mad:
I am going to start writing the own drive system as my “plan B” and f**k this.
Well, the vehicle wrapper is very old code (dating from Blender 2.40) and may not have all of the features that a person may want for a car (no drifting ect…). I do agree that writing your own system utilizing physics constraints might be better, then you can truly fine-tune it to your specifications.
I thought of removing the constraints of the wheels first, before removing them from the scene. For this I had to add constraints to the wheels because there are no references to them. But to no avail. Blender still crashes.
Could someone of the devs maybe have a look at this? Is it been reported as a bug yet?
Additionally I think the wrapper could be better if following features would be added:
- a fix for the wheels when they don’t touch the ground, keep them rotating
- material friction recognition (so the bottom of the car can have minimal friction and the top higher friction levels)
Finally I think having lots of cars in your scene wouldn’t cost in performance, as long as you suspend dynamics whenever they are not used. As already mentioned the cars could be positioned in a location, unavailable to the player, so maybe it wouldn’t be necessary to remove them from the scene.
But there’s also another solution with a save and load system if it doesn’t take long for the scene to be loaded. It also depends on what you are willing to compromise. Replacing the car you are driving with another car may take a couple of seconds if you ask me. When you are driving a car and pause to go to the selection menu you have the opportunity to save the scene, when you have selected a car the scene will be reloaded with the new car. I think it’s doable.
I searched the bug tracker for commits, but found none relating to the crash. So I added it to the bug tracker: vehicle wrapper removing wheels crash.
Just for your info, I found another commit, relating to the friction issue. KX_Vehicle_Wrapper doesn’t react to Anisotropic Physics Settings nor to the Material Friction Physics Settings! In my previous post I mentioned this issue, but didn’t know it is a bug.
@Raco
Thanks for interest in this problem :o Maybe They finally fix it or not.
Alluding to yours idea It’s not so bad but I don’t like the hidden “mess”. Player who will play long time this could pull down framerate and he don’t want reload game. For the replacing cars is not so comfortable and not so easy: I must change the setup script to other values (lots options values) and options and change also lots of thinks ( I tried this).
In this time I am creating a drive system of constraints and This looks pretty good.
“In this time I am creating a drive system of constraints and This looks pretty good.”
have you done also the constraint for the sunspesions? (how many rigid body there for one car?)
the car is stable with high velocity ?
Me neither. As for performance, I really don’t think much will be lost, that is, if you first suspend physics on the vehicle and then remove the vehicle, so only the tires remain in a suspended state. Also, the bounding box mesh of the tire shouldn’t have more than 46 vertexes anyways (since you could parent the display mesh to it and remove these children afterwards). The mesh won’t be visible, as you can hide it and when parenting the tires to a ‘dustbin’ empty with setParent(empty, False, True), you can set to ghost even. So only thing that remains is 46X4 vertexes that are not calculated for display and not for the major part of the physics engine as well. The wheels still could be detected though. I think I’ll make a test file to illustrate how many ‘removed’ vehicles would cause a performance issue.
Can you do replace mesh on the wheels with a “empty mesh” ? change the bounds to triangle mesh?
this way it’s “undetectable”?
If it’s radius is .1 and it’s collision is undetectable, and it’s out of the way will it in fact be almost negligible to CPu cycles??
Here is the test blend. It seems that my guess was wrong. I also tried to replace the mesh, like you said, BPR, but it’s no use. For now, it seems there’s no descent workaround.
Edit: Maybe there is another fix. Use the same wrapper over and over again. But replace all meshes and properties, reposition the wheels, … I will look into that later.
Attachments
@Raco
mhm You right. I wasn’t expecting so good efect but after 200 vehicle (self.count=200) game have the same framerate. Wow :eek:
You’ve convinced me to that. I’m sure you have provided the best idea for that. This “mess” is even good 
I think the replace wrapper is not necessary now but good if will be. In my old Idea I working on change setup values.
This works not good because the script of suspension wrapper must be probably use one time in one object (not on True Sensor).
Cause using few times suspesnion create multi constraints is blocking/stiffenig the chassis (one object method)
“Use the same wrapper over and over again”
I think possibly by targeting wheels constraint to new body car. But How …
@MarcoIT
Yes. But no with hi velocitys. When vehicle turning chains can’t stand the force friction of ground and wheels concorting.
Setting to ghost seems to reduce Physics usage by half. But I think it is still too high to call it a good solution. It’s a workaround ‘with disadvantage’.
I guess you’re right. I didn’t think of the fact that most properties (wheel, attachPos, attachDir, axleDir, suspensionRestLength, wheelRadius, hasSteering) are all set during the adding of the wheels.
Good news, everyone! :yes: The bug is fixed!
Moguri, you rock!
http://developer.blender.org/rBc73f82b6f07c76705be52d7bb40ee866aea98b9c
Well if the vehicle wrapper code is going to be revisited, how about adding some drifting capability as well, because I remember that this ability was not really found in the initial version from 2.40 and it could allow for much more widespread use of it.
Prior to that I think first another bug should be fixed: KX_Vehicle_Wrapper doesn’t react to Anisotropic Physics Settings nor to the Material Friction Physics Settings!
Preferably I had seen some other things after that. Wheels are not always spinning when engine force is applied, more particularly when the wheels lose contact with the ground. If this could be fixed, I think a general audience would like the vehicle wrapper very much.
Drifting would be great of course, don’t get me wrong.
Anyway I’m greatful for the effort put into this to get rid of this annoying deletion bug. Thanks dev(s)!
very good , thanks Raco for the info and tanks to the developers!!
for the driftin is doable with some trick , manipulating the constraint tire friction in some how, (not automatic)
i guess need a a good big class to wrap all , avoiding many argument , as position axis that can be extrapolated using the efffective position/orientation of wheel.
and put it as argument optional
then some method to manage the car (i noticed that when the steer is active the breaks not work (the car not stop) or very bad)
some formula for the air friction (more accelleration and less max velocity)
Could this maybe be because you have a different setup? Maybe I don’t know what you mean exactly. Are you saying that setSteeringValue() is causing applyBraking() to malfunction? (I haven’t had this problem).
Great ! Finally something just new appear from 2.4x series times at Vehicle driving model.
Thanks a million Moguri !!!. Now we can build modular games with cars, like GTA etc…
And thanks Raco for reporting to the Dev. for friction bugs.
I thinking that wasn’t a bug with the wheels doesn’t react for friction.
The inventors haven’t predicted it in script by design (skidding).
I suppose that worked not correct and stable.
Maybe i guess wrong thinking that. However Friction in V.Wrap can
give new features in a blender and refresh reputation for bge race games.
In my opinion this is good and possible to create.
sorry for the lag :rolleyes:
yes the mistake was in my (very strange) setup … for get some drifting .
drifting that is not solvable really even with good trick , now i got where is the problem.
the best setup i found is friction extra high , roll influence low (0.1)
Hey Janek, I had that problem several time ago as well!
There is no need in seperating all vehicle objects!
A way to do this is to save all your wheels in a list as a property of you car object while adding the wheels.
If you want to remove everything, start removing the constraint, then iterate through the wheels list and delete them all and finally delete the car object.
Hope this was clear enough to understand 