|
Author
|
Topic: Detaching canopy
|
bjorn
Pilot
|
posted 05-15- 04:44 PM
  
A while ago there was a discussion about detaching openable canopies, and I was one of the fellows who thought it couldn't be done for one reason or another. Well, I was wrong, it can be done, and I've done it.First, the error and why it failed. The ideas was that the canopy is given a child object with an airfoil. The DOF that slides the canopy back and forth has a dofOscBeginDisabled for that child, which cancels the effect of the airfoil. This sorta works. In fact it does work. When you open the canopy the airfoil is active, and when you close it it's not active. The only catch is that when you first start the game, with the canopy closed, it's still active, despite the DOF being in the begin position. You have to open it a close it again for the airfoil to be deactivated. Thus, the idea failed, because of something that seems like a bug in SDOE. The correction: A very small airfoil, a cylinder about the size of a thumb, is always active, regardless of the canopy being open or closed. The difference here is that when the caopy is opened, the airfoil is pushed up some distance from its origin, I arbitrarily chose 10'. At this distance, some torque is generated when you travel fast, when compared to when the airfoil is at its origin. So... there's another DOF too, a rotational spring DOF that breaks. When the canopy is open, the drag airfoil is far away, generating lots of torque, making the DOF break at relatively low airspeed. When the canopy is closed the drag airfoil is at its origin, causing no (or very little) torque, so the DOF doesn't break even at very high airspeeds. Piece of cake 
_
/Bjorn. IP: Logged |
Spanky the Mad Dog
Pilot
|
posted 05-15- 04:51 PM
Spanky here... I don't get exactly what the original problem was? If you did it with the gear then why was the canopy any different? Is it because of the way the gear lod is treated? Great work but does this mean that the canopy airfoil will always be adding a bit of drag even when its closed? This could be really coool BTW why not just make it so the canopy is always open when you start a mission to avoid that bug?
IP: Logged |
Snickers
Pilot
|
posted 05-15- 05:21 PM
OK, now could you apply this same concept to make it so damaging a certain item causes one of the landing gear to lower (simulating hydraulic fluid line break...)? Difference is this is caused by damage (gunfire) vs airspeed. You would need to do this on each gear.------------------
Snickers
=FC= IP: Logged |
bjorn
Pilot
|
posted 05-15- 05:27 PM
The difference with the gear is that they always start lowered, with the airfoil active. When you start the plane in the air, they start off lowered and are retracted before the simulation begins (start a mission with *MANY* planes, and you'll actually see it.) Since the DOF is ran towards its endpoint, the airfoil is disabled. If you had one that was disabled in its starting point (i.e. with the weels lowered,) it'd have the same problem.
_
/Bjorn.
IP: Logged |
jedi
Pilot
|
posted 05-15- 05:45 PM
Perhaps an airfoil/dofspring combo which acts on the gear, only the force from the airfoil keeps the gear EXTENDED. Disable that airfoil when you retract the gear. Enable it when either the gear gets extended OR when damage level X is reached, call an obFunc that "activates" the airfoil, overcoming the spring and forcing the gear down. Alternatively, you could always have a "hidden" LOD of the extended gear, which gets unHidden at damage level X, and replaces the "real" gear. Put a very weak spring on it so it collapses on touchdown. This one wouldn't actually appear to extend, but would just "blink" into existence unfortunately, but from dogfight distance, the effect wouldn't be that much different. ------------------
--jedi-- IP: Logged |
charmstar
Pilot
|
posted 05-15- 06:33 PM
The landing gear is hidden when its retracted, so I don't think your first idea will work Jedi. :-( However, the second idea seems like it might work. First you'd have to obdetach the existing gear, so that it wouldn't be able to be lowered anymore. Then you'd have to obunhide a second model which would be a child of the wing/fuselage, and you would have to add an obBodyPt to that model so that when it hits the ground, it would break off. Basically, I think that you would be doing it with 3 obFuncs.
1: in the wheel strut (obdetach)
2: in the fake wheel strut model (obunhide)
3: in the fake wheel strut model (obBodyPts (...))Then, you would have an obProb statement in the onDmg for the wing/fuselage which would give a certain percent chance of obExec(1 2 3). charm IP: Logged |
bjorn
Pilot
|
posted 05-15- 07:29 PM
I'm not quite sure I follow your thoughts here, but I see some problems. To begin with, airfoils are active even for objects that are hidden. It's only for disabled objects that airfoils are deactivated, and you can only disable airfoils through dofOscBeginDisabled and dofOscEndDisabled. Second, DOFs are static. Once defined, you cannot alter them at runtime (or so at least it seems, no one has yet succeeded in altering them at runtime.)
_
/Bjorn.IP: Logged |
Spanky the Mad Dog
Pilot
|
posted 05-15- 11:14 PM
Spanky here... AH ok Bjorn, Now I get it.
IP: Logged |
charmstar
Pilot
|
posted 05-16- 01:47 PM
Yes, I agree with Bjorn. However, the model replacement idea might still work. Of course you wouldn't be able to model the drag caused by the wheel coming down, it would purely be a visual effect. However, there's nothing wrong with cool visual effects in my book! :-)It is too bad though that we don't have some way of running/editing a DOF by adding a proplist. It would be much cooler if we could slowly lower the gear, causing some drag. We'd also greatly weaken its shock spring so that it would collapse when landing. charm IP: Logged |
Snickers
Pilot
|
posted 05-16- 02:31 PM
From everything I have read, swapping out the model would be the way to go. I haven't considered at imitating the drag effect, but the newer model could have low enough hits that it would collapse on landing.I seem to recall a thread from long ago mentioning the need for events.... This would be the type of thing that an event could trigger. (sigh...) ------------------
Snickers
=FC= IP: Logged |
bjorn
Pilot
|
posted 05-16- 03:17 PM
Hmmm... others are far better than me on this, but I've had the impression that model replacement isn't really model replacement, just using another set of LODs.  All properties of the original model are still in place.
_
/Bjorn.IP: Logged | |
FSIC Messageboard
UBBFriend: Email This Page to Someone! 
