I wonder if this has anything to do with what Peter M had found in his recent post. http://www.cbfsim.org/cbfsim/cbfsBB/vie ... =8&t=20802
Are any of you starting in the PM cold and dark or just setting on the ramp with you doors open?
A big Thank You ....
Moderators: Guru's, The Ministry
Re: A big Thank You ....
Nice screenshots of the aircraft flying. Good to see the Meteor in there also.
-
- Concorde
- Posts: 1459
- Joined: 30 Aug 2006, 18:21
Re: A big Thank You ....
Most likely, if they're using the same custom variable name it'll affect all animations that use it. In FSX I used that to control the crash barriers on the Vic by having a custom variable to raise them and then adding a gauge in any suitable aircraft that reads the tailhook position across to that variable.
- nazca_steve
- Concorde
- Posts: 787
- Joined: 18 Nov 2005, 17:38
- Location: South Orange County, California (ex-pat from Cambs.)
- Contact:
Re: A big Thank You ....
I think that explanation is bang on the money, and makes sense from MS developers' standpoint - why code in seemingly unnecessary data? Unfortunately it's a bit of a drawback when doing parked parts. I suppose one alternative would be doing a VC switch to toggle them on and off, assuming MP/FSR would not have a problem with that custom variable.SkippyBing wrote:The problem with the Canberra and others in multi-play and FS recorder playback is that variables that aren't set default to 0. FS Recorder doesn't record all possible variables so I'd imagine that's the problem there and MP probably doesn't pass the other aircraft's hydraulic state to reduce band width, it really only needs things like position, heading, gear, flaps etc.
The same also applies to the preview window now I think about it, where everything is set at zero or it's neutral position.
Steven Beeny, repainter and modeller. New Canberra series for FS9 out now.
http://www.flyingstations.com