Conversely, I'm not too clear what damage might occur when then rotors are at 100% and the rotor brake switch is is turned on. A lot of heat and grinding metal noise? A nasty letter from the Boeing company? Currently I just have it decay the RPM to zero under a constant until I get a better answer.
I added more realism options to the config.xml for control over individual items like startup, targetting, flight model.
OOOH, I just remembered why I was really happy today. AD fixed the road physics problem by using displacement mapping in 3DS MAX. So no hacky hacks may be required for road driving afterall. Well done sir. I knew I was feeling buoyant for a reason. If you want to know what the hacky hack means, the road surface was aligned to the terrain with a vertex shader which moves each point on the model level with the ground (relatively) but physics engines don't know what vertex shaders do to geometry, as far as they are concerned the model is unchanged. So there's a disconnect between what the physics engine updates and what the 3D card renders on screen. Using displacement mapping with our heightmap as source, the road meshes are baked at the right elevations to fit, the physics model and visual model are now united and traffic may now use the roads without any problems.
So, way to go AD. Another cracking solution.
This comment has been removed by the author.
ReplyDeletewould think that the Rotor break switch would not engage until a certain RPM is reached if it was to cause problems. Then again if the procedures manual says don’t then obviously there is going to be a consequence. If it was that important not to switch it on then I am sure the switch would have a red toggle cover on it just in case you drop your lunch box on it. You probably find that engaging to early will reduce the effective life of the breaking system. I am sure they use something like a carbon fiber disc brake for this as it would be light and can withstand extreme temperature if an emergency rotor shut down would be required. Let us all know what you find out, I would be interested to know for some obscure reason.
ReplyDeleteHi Flex,
ReplyDeleteFrom experience not all aircraft that have a rotor brake can operate it with the engines running. Those that can only allow operation of the rotor brake at ground idle, anything above that you will cause damage to the brake assembly and if prolonged use will cause a fire. On the S76 we used to have the brake on and start one engine, when at ground idle we released the brake and advanced the throttle to 70% then started the second engine. We sometimes, but rarely, started both to ground idle then released the brake. On shut down you could on engage the brake with one engine off and the other at ground idle. Only a very few helis allow for the brake to be engaged with engines running!
Rich Price
Hi Rich aka Blade, thanks for commenting.
ReplyDeleteOK, re-reading the abbreviated start-up procedure I was sent, it states "During start with RTR BK set to LOCK, if blades begin to rotate, set to OFF".
After getting some clarification here's what I was told:
You only use the rotor brake during "lock starts" which is for starting in high winds and not normal procedured. And also during rotor coastdown, during shutdown when Nr < 50% move the switch to brake.
Normal startup allow the rotors to turn freely. The Apache will prevent bonehead moves on the part of the pilot and will LOCK the power levers past idle until the rotor brake is set to OFF.
So that's how it'll work in game. I'll block the power levers past idle till the RTR BRK is OFF.
The brake when on is hydraulically pressurised to 300psi, then the brake is in the LOCK position it's pressurised to 3000psi.
So it looks like the system can handle the brake up to idle speeds. Beyond that, either the power levers lock or the switch won't engage. So it's not a problem so long as I code the switch logic to behave like that.
Sorted! Always a failsafe for numpty pilots!!
ReplyDeleteI added the above logic into the CockpitInput() message processor.
ReplyDeleteSeems to do the trick. It will respond to messages if throttles are advanced with the brake on and force the levers to stay at the idle position.
Conversely if either levers are at the FLY position OR RotorRPM > 50% then the RTR_BRK switch = disabled. The switch doesn't move or click at all. I think that's reasonable enough.
Gave me a chance to add some additional VirtualCockpit SwitchMap functions that will be handy in future.
Putting the logic into the Helicopter VirtualCockpit message handler should work for network transmission too. Also the logic only gets processed on message receipt so it doesn't waste cycles checking for this stuff all the time.
Numpty pilots, I like that. Describes me perfectly :)