ACTIVE S45 Siletz Bay collision near beacon during takeoff

[DAVIDF4]

Hello, 

I know this is an old topic and I've found other (still active) threads about it, but posting on those threads hasn't gotten any traction, so I'm opening a new thread here, since the problem still exists.

I'm having the previously reported collision problem with the Siletz Bay airport beacon (possibly the light beam itself ?).

The problem is exactly as described in this thread:
http://www.orbxsyste...con#entry456914

It only happens when the beacon is on (dusk 'til dawn) and when you draw level with the beacon.

Please don't suggest turning crash detection off. I have no problems with it else where and It is not an option I am willing to take. The actual problem here is to do with the scenery, which is otherwise delightful.

The old thread seems to peter out with a suggestion that the problem would be fixed by a coming ORBXLIB update (but without actual confirmation of success from those affected), but it doesn't look like it ever was (or the fix was subsequently undone by more recent changes perhaps).
In any case I definately have this problem now.
I'm using FSX (with the DX10 fixer if that is important). The version of S45 I have installed is from a file called OrbxFTXNAS45105 down loaded from the FlightSim Store at the weekend.
I have the latest ORBX libraries installed (FTXORBXLIBS_150331) and PNW is patched up to the lastest version (008).

Thank you for your time,
Dave.

[DAVIDF4]

Anyone?  This is a bit of a serious shortcoming seeing as the airfield currently doesn't work from a flight sim functionality point of view.
If it's impossible to stop collisions with this object (or its light effect), then perhaps a simpler replacement light that just flashes but doesn't throw a beam is needed.

[John Dow]

I guess if you're not prepared to turn collision detection off then you'll have to wait for one of the devs to take time out to put his in a list for a future update.

 

Is there a reason that you don't want to disable  crash detection, given that it is unrealistic, and normally you know when you've crashed, and you can activate a manual crash detection?

[GlennH]

The crash detection in FS is pitiful at best in terms of realistically determining a crash.

Turn it off. You should know when you have pranged the aircraft.

It also uses cpu cycles, or so I have been told.

[DAVIDF4]

Succumb rather than overcome?  Never, I tells ya!
 

I’d consider the various FSX realism options as analogous to stabilizers on a bicycle.
Having any of those options turned off allows you to practice in a more forgiving environment, but ultimately the stabilizers are taken off.
 

The thing with FSX collision detection is that you just have to be realistic about how you implement crash boxes into your scenery design.  Since we can’t really differentiate between heavy and light collisions, the onus is on the developer to implement sensible crash boxes for obvious no go areas like tree lines, and unyielding field objects, but let the player off with running over something like a runway edge light, or running a few inches too close to a parked aircraft wing.
There’s no need to suck all the fun out of things by being too draconian and punishing every minor infraction, but at the same time you keep things as realistic as possible within reason. In this way everyone is catered for.

So if you want to consider yourself crashed if you run over a runway light, then you can do that or not depending on your simulation mind set, but the obvious boo-boos like dropping off the end of a runway and heavy landings are managed for you. Constantly referring to an internal rule set of how to manually manage collisions is a proper immersion breaker for me. Looking after that stuff is what simulation/game logic is for.

I have very few problems with crash detection in FSX in general. It actually appears to work properly in the majority of cases. It’s individual sceneries that can present the problems.
Sometimes scenery is either made without care, or the developer doesn’t understand or realize the necessary compromises to make to make the scenery usable.

The Siletz bay problem does NOT fall into the lack of care bracket. It’s obviously been put together with much care and attention to detail. However it does appear to be running up against an unusual situation (probably an FSX bug – there are many), that is making the scenery actually unusable within the full (and as originally intended) simulation environment.

So rather than throwing the baby out with the bath water and turning collision detection off for every part of the world for everybody, I don’t think it unreasonable for the scenery to compromise a little here (adjust the beacon object – FSX has millions of lights that don’t present collision hazards after all), so that it’s inclusive for both those with and those without collision detection on.

And that’s all I ask.

 

[John Dow]

Your request is reasonable however I would venture that the workload of the devs and the time and effort to produce a fix (it's not just a 5 minute process, it's actually quite involved by the time all factors are allowed for, a bgl is generated that incorporates the fixes needed, tested and distributed) mean that it will probably go into a list of things to be incorporated in to a service pack down the road.

 

I don't want to be too picky about your analogies regarding what should and shouldn't cause a crash, in the real world, running over a taxiway light means back to the workshop for an inspection... ie it's a crash, plain and simple, and will probably put the plane out of action for a day or more.  To act as a simulation then, FSX crash detection should activate when lights are run over, when heavy MTOW aircraft leave the hard surface, etc.  But it doesn't.  So where exactly should the line be drawn?  Where it suits you or where it reflects reality?

 

I know this won't sway you but if you think about all the variables in the crash detection system, it really does make just as much sense to turn it off and set your own personal limits as to when and where you know you've compromised your aircraft (or yourself).

[dominique]

I don't seem to have this problem with the Prepar3D version which was revamped by Alex Goff last year. To check, I went back to one of my favorite strips and flew three times along the taxiway through the beacon light without crashing.

 

I suppose that flying very close to the tower may induce a crash as the crash bubble is generally too large (for my taste) in FSX/P3D.  I find the crash detection useful too. It helps when landing on a short strip hemmed in trees to tell whether the gear touches the trees or not, when landing on a normal runway to be sure that the landing gear tolerance was not exceeded (vertical speed) and lastly as an "incentive" to avoid obstacles on the field (like these wretched concrete blocks they have all over  in AU  !).

[DAVIDF4]

Thanks for your replies.

And to be sure I understand that things like taxiway lights can cause real damage.
That’s why I pointed out that you can decide on your own level of simulation in that respect (I guess you must already be doing that if you have collisions turned off).
But if a scenery is created in such a way as to allow a taxi light collision (for example), but not a concrete block or tree collision, then you can play your way and I mine.  So daft crash boxes too close to legitimate access ways don’t ruin flights and yet difficult short field landings for example (as Dominque mentioned) are properly rewarded or punished by FSX as an arbitrator with a better view.

It is a game at the end of the day though, so yes, I guess I'm prepared to let a few things slide to suit my play style...it's about enjoying yourself after all...but some level of realism is still important and the crashing consquences of clumsy coordination are closer to that reality for me than the alternative.
I do worry sometimes that capitulating to unruly scenery by turning off collisions, is in effect endorsing that scenery and possibly perpetuating the problems for us colliders 

I appreciate that development schedules are tough and software distribution not trivial, but I hope at least that continued developer awareness of this issue might yield a fix at some point down the line.
Then I'll be able to slip out of Siletz as the sun drops below the Pacific and wing over to Hobby for a night landing.