TAGERT

Based off you quoting what I said, I can only assume you were talking to me.. But after reading what you wrote, I don't see anything you said that agrees with or disagrees with what I said, so, I will just assume you were talking at me and not with me. There is one thing you said that I would like to comment on, where you said There is always room for improvement! But one thing we have to keep in mind is that.. No flight simulation ever was, is, or will be perfect! Hence the title 'simulation of flight' as opposed to just 'flight'.

True Dat! ;) Exactly! That and the "huh" typically has more to do with the sim pilots 'expectations' than an indication of a FM error. For example, Johnny has read all sorts of books from all sorts of WWII pilots stories.. And in most if not all of those stories the WWII pilot airplane bested the enemies airplane.. Therefore Johnny concludes that 'he' should be able to fly the same in-game airplane that the WWII pilot was flying and also be able to best the same in-game enemies airplane. And when that does NOT happen and Johnny gets shot down by the enemies airplane.. Does Johnny take pause and admit to himself that the other pilot was simply better than he was? Nope! Must be a bug in the FM! ;)

The only thing I am sure about is until the game provides a way to log data during flight, as 1C did in IL-2 with DeviceLink, or as 1C did in CoD with C#, no one can say with any certainty how well the planes are matching the real world data. Just too many potential sim pilot errors can be made during testing that can corrupt the results. This statement is based on the hundreds of test logs I have reviewed over the past 10+ from several different flight sim. I found that most of the errors were in the way the user performed the in-game test, and not an actual error in the FM. For example, not taking into account the difference in the in-game atmosphere and the real world data, which is typically corrected/converted to standard atmosphere, but not always! Another example, in WWII some countries the beginning of a rate of climb test started from a dead stop on the runway, where as others the beginning of a rate of climb test started with the plane air born at a low altitude. Not a big impact on the rate of climb data, but it does affect the time to climb results. Little difference like that can have a big effect on the results. So, until we have a way to log the in-game data, any and all in-game testing should be taken with a grain of salt. As a bare minimum a video should be recorded during the test so others can review the methods used during testing. On a related note, Combat Pilot Accounts.. Combat Pilot Accounts are great source for information on the planes flying qualities of a plane, like ground handling, the sounds it makes when you do this, the vibrations you feel when you do that.. But.. Combat Pilot Accounts are worthless sources for information on the planes performance! Reason being combat pilot accounts are typically one sided stories that says more about the pilot vs pilot skill than plane v.s. plane performance.. That and the combat pilot accounts typically do not contain enough information to recreate the scenario in-game to see if you can obtain the same results, let alone the other planes state.. Than there is the human factor, with regards to pilot accounts years after the fact, the simply truth is memories change and are lost or become inaccurate over a period of time. And like the old fisherman telling us about the 'big one' that got away, they tend to embellish the facts over time, that is to say the fish gets bigger each time the story is told. That is just human nature found in us all... For example, take Brian Williams recent snafu! For example, for every German pilot combat account of his Bf109 being able to out turn a Spitfire, their is a British pilot combat account of his Spitfire being able to out turn a Bf109.. Yet to this day people still think some sort of statistical average can be gleamed from pilot accounts.. But that is a pipe dream IMHO, for so many reasons, but probably the most important reason being, you never get a chance to read the after action report from the pilots that were killed in action! ;)

Agreed 100% While we are on the subject, IMHO until the game provides a way to log data during flight, as 1C did in IL-2 with DeviceLink, or as 1C did in CoD with C#, no one can say with any certainty how well the planes are matching the real world data. Just too many potential sim pilot errors can be made during testing that can corrupt the results. This statement is based on the hundreds of test logs I have reviewed over the past 10+ from several different flight sim. I found that most of the errors were in the way the user performed the in-game test, and not an actual error in the FM. For example, not taking into account the difference in the in-game atmosphere and the real world data, which is typically corrected/converted to standard atmosphere, but not always! Another example, in WWII some countries the beginning of a rate of climb test started from a dead stop on the runway, where as others the beginning of a rate of climb test started with the plane air born at a low altitude. Not a big impact on the rate of climb data, but it does affect the time to climb results. Little difference like that can have a big effect on the results. So, until we have a way to log the in-game data, any and all in-game testing should be taken with a grain of salt. As a bare minimum a video should be recorded during the test so others can review the methods used during testing. On a related note, Combat Pilot Accounts.. Combat Pilot Accounts are great source for information on the planes flying qualities of a plane, like ground handling, the sounds it makes when you do this, the vibrations you feel when you do that.. But.. Combat Pilot Accounts are worthless sources for information on the planes performance! Reason being combat pilot accounts are typically one sided stories that says more about the pilot vs pilot skill than plane v.s. plane performance.. That and the combat pilot accounts typically do not contain enough information to recreate the scenario in-game to see if you can obtain the same results, let alone the other planes state.. For example, for every German pilot combat account of his Bf109 being able to out turn a Spitfire, their is a British pilot combat account of his Spitfire being able to out turn a Bf109.. Yet to this day people still think some sort of statistical average can be gleamed from pilot accounts.. But that is a pipe dream IMHO, for so many reasons, but probably the most important reason being, you never get a chance to read the after action report from the pilots that were killed in action! ;)

Dear Diary Today I fell off my chair.. End of story

I have seen this what i described on all different sorts of servers, dedicated with many players and single PC hosted with just a few players, each with solid pings. And before anyone says the common denominator is my PC and connection, allow me to point out that I am not the only one witnessing these events. Other in game have report the same anomalies. And before anyone says the common denominator is the HOST, note above where I stated I have seen this what i described on all different sorts of servers, dedicated with many players and single PC hosted with just a few players, each with solid pings. An added note, I have been flying online for 20+ years.. Started back in the day with Air Warrior, before the Internet, when the Genie network supplied the connections (modem) and it only cost $12/hr to play! So, I have seen my fare share of warping senarios and can typically spot the warping due to the one guy with the bad connection vs. something that is common to all. In either case, there will be times that the PC program has to estimate (predict aka interpolate) the location of the object in the 3rd based on the previous locations. Which is something the PC program has to do in between data point. This is where I suspect the problem is.. Or should I say 'specify what is broken'. What leads me to belive this is the way the program (DCS) recovers from a 'bad' prediction. For example, with regards to the example I provided, where a plan is sitting on the run way or in the process of taxi on the run way. 1) Data packet n: it is where I can see it, on my RHS about 20 ft away 2) Data packet between n and n+1: it is where I can see it, on my RHS about 20.5 ft away 3) Data packet n+1: it is where I can see it, on my RHS about 21 ft away 4) Data packet between n+1 and n+1: it 5k ft above me 5) Data packet n+2: it is where I can see it, on my RHS about 22 ft away The fact that the object location ultimtally recovers from the warp implies that once it receives 'real' object locations it knews where to render the object in the 3D world.. Where as the estimated (predicted aka interpolated) location code failed to predict a valid object location.. Which resulted in the object location being 5kft above me. Note my description above was only n to n+2 where as in reality there are many more data packets being collected in a second.. Which is why you can see the plane 'move' (being rendered) between ground zero and several points along the way up to 5kft. What this implies is the FIRST bad estimated (predicted aka interpolated) location did not recover immediately upon receiving a valid packet because that value is being filtered and thus takes it awhile to move through the filter before it fully recovers. At least that is how it acts, it could be caused by something entirely different. Which I suspect is the case, because it is pretty simple to add code to detect bad values like that and keep them from being used and thus never upsetting the filter. I just give that example for those that have worked with code like that to give them an idea of what it looks like is going on. As noted above I have seen this what i described on all different sorts of servers, dedicated with many players and single PC hosted with just a few players, each with solid pings. TCP is not the answer, granted the time stamp is useful, but not necessary. And UDP is not the problem, it is how the data is handled that is the problem. I get your point, and my point is I have seen this what i described on all different sorts of servers, dedicated with many players and single PC hosted with just a few players, each with solid pings. Because the latency of the data is NOT a problem! As long as the latency is consistent.. It is when the ping times vary that you can get the problems I described above. Granted there is a limit to the size of the latency, but you get my point Very true But as noted above, the problem is not so much with the 'real' object pos, vel, acc data contain in the actual UDP data packet as much as the estimated (predicted aka interpolated) pos, vel, acc calculations between data packets. That is where I suspect the problem lies in that the DCS netcode calculations even has trouble with planes that are not moving and just sitting on the runway wrt warping

That is a good question! And this problem has been around since LockOn.. So I fear they are not going to fix it any time soon Nothing pops your immersion bubble quicker than seeing a plane sitting on the runway one second.. warping to 10,000ft the next second.. than back onto the runway the next second As for jet missle kills, ie BVR kill it is not a real big issue.. Only because you can not 'see' a plane warping at BVR! But now with up close and personal gun kills type of fighting the P51 brings to the table The net code is going to have to be improved! You just can not have planes warping around as your lining up your gun sight If they dont fix it WWII gun kill stuff will never get off the ground (pun intended) Except for when it warps off the ground!

That is not exactally what I said.. Here is what I said With that said, the 'reality' is that the human senses can be easlly fooled.

There is a reason test engineers instrument planes.. Because pilots, even trained test pilots, 'perception' of what is going on can be very different from what is 'actually' going on.

Just like RoF than.. I like that aproach! :thumbup:

Hey droz I have a G940 too, and I have/had the same problem you discribed. I 'hope' this has something to do with the fact that the G940 is a FFB stick and FFB is still WIP.. But I have my doubts.. Not in the game but with the stick itself.. IMHO the G940 'system' is about the worst thing thing I have ever bought for flight sims.. The rudders and throttle were crap from day one.. And up to now the stick itself has been ok with other games (IL2, CoD, BS, etc).. So I hope this is not a case of this stick is just going to suck with DCS P51 (fingers crossed) But I digress The work around for now is to not move your still much.. That is to say don't even try to use the full X Y range of your stick.. I only use about 10% of the range now and have found that is all I need.. It takes some getting use too.. in the heat of a battle you want to keep pulling.. but don't and you won't wallow around like a stuck fish! ;)

Thanks Viper! By the way, was that you on last night with TX, Par.. hmm forgot his name? And you were flying mostly red? If so S! Good Flying!

Hey Wags.. I am dl the new beta version.. I didn't see it mentioned in the changes, but any word on force feedback support?

Im using the TH2G to combine 3 1280x1024 monitors into 1 3840x1024 In game I select the Shkval+Camera+ABRIS option which dedicates the Left monitor to the Shkval the Center monitor to your typical 1280x1024 view and the Right monitor to the ABRIS.. It is the coolest thing ever But I digress If I had to guess I think your problem might have to do with the bezel management? Try disabling that for now and see what you get.. And may I recomend that you try the Shkval+Camera+ABRIS option over trying to improve your peripheral vision with the wider screen.. in that there aint much to see left and right anyways what with the cockpit canopy.. But having a ZOOMED Shkval and ABRIS dedicated to a monitor does have its advantages!! ;)

Yup that is what I concluded when I pointed out it was a plesent suprise Only posiable down side to multi installs is when it comes time to un-install in that only one install is listed in the 'Uninstall or change a program' My guess is that the last install is what is registered So when that time comes I might have to manually del the 'other' installs and than run a good regestry clean up program All in all no big deal

Thanks Guys!

Hi Guys Anyone else have this.. problem? When I run the NVIDIA Control Panel and goto the '3D Settings->Manage 3D settings->Program Settings' NVIDIA does not detect Black Shark as a 'program found on this computer' I can add it But NVIDIA can not find it Yet NVIDIA finds Lock On FC 2 Any ideas?

Thanks guys.. Well I installed it twice.. and updated the 2nd install to 1.0.2 Everything seems to be working fine.. One thing I didn't expect I ran the 1st install v1.0.0 and activated it when prompted to do so.. Than I ran the 2nd install v1.0.2 expecting to have to use up another activation But it started and ran with no need to activate So that was a plesent suprise, that the 1st activation took care of both installs

Hey guys.. I think I know the answer to this allready.. But I thought maybe someone figured out a better way.. When I select training in v 1.02 it says the training films can not be played back in this verison, thus uninstall v 1.02 I have not tried that yet in fear of messing up my current settings that took me oh so long to get setup I was wondering if there was a way around this? As in maybe two installs of black shark on my HD One the orginal version where I can view the training films and the other with the most current patch Like I said I think the answer is no But just wondering if anyone came up with a better way? Anyone?

Never mind.. Turns out it was not a LCFC2 thing It was a TIR thing To fix it you have to open up your TIR 5 software and in the top left hand corner click on the TIR button.. From that select the 'Check for Game Updates" option after doing so you will have to stop and restart the TIR software

Oh I forgot to mention.. It still works in BlackShark So something changes with the 1.2.1 patch, just not sure what

Hi guys INFO I have TIR 5, and it worked fine in LockOn Flaming Cliffs 2 (v1.2.0) but after I installed the 1.2.1 patch my TIR stopped working.. Any ideas?

Correct me if I am wrong.. But is this not the Problems and Bugs forum? The forum where customers can come and post thier Black Shark problems.. While at the same time read others.. All in the hope of finding a common cause.. And thus a solution.. If that is not the cause.. You and yours may want to consider changing the name of this fourm.. In that it is very misleading. Maybe.. Maybe not.. In light of the fact that no one.. Including you could explain what is causing my bug.. My only option is to talk with other customers.. For all the reasons I listed above.. The only FACT we know thus far is my bug and Segwin's are simular in that they both produced a LOG file that indicated lua.dll caused the ACCESS_VIOLATION.. Also note that I have asked Segwin to expand on his discription of the bug to see if it is simular to my bug.. But keep in mind.. I only did that becuase I though this was the Problems and Bugs forum where customers can come togther to try and help each other out.. And provide feedback to the ED/DCS team.. Again.. If that is not the case and this forum where all thread get deleted that the ED/DCS team does not have an answer for.. By all means let me know ASAP! And please consdier renaming the forum to refelct that! Allow me.. You dont understand completly.. Segwin has two Crash Log posts up.. One for offline crashes One for online crashes (this one) Since my Black Shark bug happened both offline and online I decided to pick one of the two to post in.. Or would you rather I post in both?

Not sure what you mean? Can you go into more detail? What I found useful.. Too see how repeatable this BUG is.. Repaly a track file.. To see if the error happens at the same time each time.. Mine did.. I really thought the ED guys could make use of that info.. But they pretty much blew it off.. I know yours happened during online.. You should try it offline too.. If it does.. Play back a track and see if it happens at the same point/time in the track as mine did.. You mean that standard widows thing when a program crashes and it asks you if you want to send (ie via the internet) the error? I thought that too.. But the ED guys here told me that is not the case.. You can un-install and re-install as many times as you want.. without having to de-activate re-activeate BS! It is the number of activates that are limited.. At least that is what the ED guys here said.. I wish they would put up a sticky thread to make that more clear.. In that I still find it kind of confusing

I got that same lua.dll error twice.. But.. What was your symptom? Can you expand on what you were doing when it happened? The following links contains my description of the bug symptom http://forums.eagle.ru/showthread.php?p=628782&posted=1#post628782 Be interested to know if you had a similar situation Sadly they locked that thread.. Falsely thinking the problem was solved by a re-install.. At first it seemed to fix it.. But just last night I got the same error again with the clean install.. So all the clean install does is make this bug happen less often