Menu

#183 Aircraft fall througn Carrier deck on startup

Fixed
nobody
carrier (1)
2011-06-05
2010-11-24
Anonymous
No

Originally created by: vivian.m...@lineone.net
Originally owned by: vivian.m...@lineone.net

What steps will reproduce the problem?
1. select --carrier=Nimitz
2. select --parkpos=cat-4
3. select --aircraft=buccaneer

start fg

What is the expected output? What do you see instead?
Ac will start at catapult #4

Instead ac falls though deck

What version (or GIT date / Hudson build number)?
Git
data am 24/11/2010
source am 23/2010

What operating system and graphics card?

Win Xp nVidia GTX285

Please use labels and text to provide additional information.

Investigation has shown that any start position where

  <x-offset-m>99.0</x-offset-m> > 99.1

will cause this bug. Visual examination of the sequence of event indicates that the AI carrier may be instantiated after the ac model. It is possible that when

<x-offset-m>99.0</x-offset-m> < = 99.1

the carrier is still under the ac and prevents this bug from being seen.

Discussion

  • Anonymous

    Anonymous - 2010-11-24

    Originally posted by: zakalawe@mac.com

    Vivian, for the benefit of those people who knowing nothing about the AICarrier, can you suggest when this last worked, and what areas might affect it? The description about the x-offset-m implies it's a model geometry issue, but presumably that hasn't changed. You mention instantiation order, again I'm clueless about which machinery instantiates which pieces and when, so and hints would be good.

    One obvious thing - did it work in 2.0? If so we could do a bisect, to get down to a week of commits.

    Labels: carrier

     
  • Anonymous

    Anonymous - 2010-11-24

    Originally posted by: vivian.m...@lineone.net

    Hmm, I haven't tested this bit of code in some time(er ... years). I assume that it worked in 2.0, and indeed until recently. There are no previous bug reports. So it's either local, or recent. It's a fairly obscure feature, so I'm not entirely suprised. The desciption of Issue 159 has some similarity, but the proximate cause of that one was an incorrect command line entry.

    AI Carriers, are instantiated by the so called "demo" file in data/AI. The naming convention is historical, but the scenario which instantiates the AI must live in data/AI.

    You can _almost_ see this one happening here in the start sequence - the ac falls through a non-existant deck, then the AI carrier appears.

    It's not a recent change in any of the code which directly affects the carrier, model, etc. - there are none. The most likely candidate is the recent changes to the startup sequence/procedure. However, the x-offset is a bit odd - I can't see atm why the value of this should control the bug - but it clearly and repeatably does. That of course might be a symptom rather than a cause.

     

    Related

    Tickets: #159

  • Anonymous

    Anonymous - 2010-11-25

    Originally posted by: bre... (code.google.com)@gmail.com

    Might be connected to scenery loading/priorization. There are checks guaranteeing inner scenery/scenery models are loaded prior to releasing FDM/groundcache processing. But I haven't seen any such check for AI models. In this scenario (plane starts on top of AI carrier), we'd need a check the AI carrier model is actually loaded prior to releasing the FDM - or we would need to ensure the AI model is loaded with highest priority (higher than inner scenery).
    => I'll be looking into this issue.

     
  • Anonymous

    Anonymous - 2010-11-25

    Originally posted by: zakalawe@mac.com

    It would be really good to ascertain when this last worked, since it would immediately rule in (or out) Thorsten's tile manager changes.

    Status: Accepted

     
  • Anonymous

    Anonymous - 2010-11-26

    Originally posted by: vivian.m...@lineone.net

    Works here for a build I have just done for fg/fg/data 08/11/2010. Does that help?

     
  • Anonymous

    Anonymous - 2010-11-26

    Originally posted by: bre... (code.google.com)@gmail.com

    I've narrowed it down and have a very simple fix which seems to solve the issue. But I'm still looking into why this actually triggers it.
    Will be pushing something soon...

    Status: Dev

     
  • Anonymous

    Anonymous - 2010-11-26

    Originally posted by: bre... (code.google.com)@gmail.com

    Fix is pushed. This increases the area where models are "force-loaded" by a specific method prior FDM release. This restores the model loading behaviour to the same as for FG2.0 and fixes the start-up on an AIcarrier.
    => Vivian, please check if it works for you.

    The root cause is more complicated: There is a check for loaded scenery around the aircraft prior to FDM release. This checks scenery models by calculating their distance in 3D space, though we do not know the initial elevation yet (and we can't, since models aren't loaded yet...). Hence it should check the distance in 2D space only: load everything within a circular range around the initial lat/lon position - same as we do for scenery tiles. This issue has always been there though (<=FG2.0). May not be an issue unless we had exceptionally large models. Could also be fixed - but is more complicated since models have geocentric coordinates. Back to math... :)

    Status: Testing

     
  • Anonymous

    Anonymous - 2010-11-27

    Originally posted by: vivian.m...@lineone.net

    That patch to have fixed it here. I've reverted the temporary change to the scenarios

     
  • Anonymous

    Anonymous - 2010-11-27

    Originally posted by: bre... (code.google.com)@gmail.com

    (No comment was entered for this change.)

    Status: Fixed

     
  • Anonymous

    Anonymous - 2011-06-05

    Originally posted by: bre... (code.google.com)@gmail.com

    (No comment was entered for this change.)

    Status: Temp

     
  • Anonymous

    Anonymous - 2011-06-05

    Originally posted by: bre... (code.google.com)@gmail.com

    (No comment was entered for this change.)

    Status: Fixed

     

Log in to post a comment.

MongoDB Logo MongoDB