OLD CROW

Modules in conflict: F-14B , Supercarrier module Map: Syria DCS version: 2.9.19.13478 MT Reproduction Steps: 1- Start a mission with the F-14B CAG positioned to taxi toward CAT 3 while an E-2 is already spotted on CAT 3. 2- E-2 on CAT 3 spools up engines. 3- F-14B CAG begins taxi to CAT 3. 4- The first marshaler transfers control to the marshaler positioned behind the jet blast deflectors of CAT 3. 5- F-14 begins its 90-degree turn toward CAT 3 while the jet blast deflectors are still lowering. 6- The marshaler signals “hold” (closed fists). 7- The F-14 hesitates briefly, then continues attempting the turn despite the “hold” signal. Expected Result: - F-14 should hold position until the jet blast deflectors are fully lowered and the marshaler gives the appropriate “taxi forward” signal. - After proper signaling, the F-14 should complete its 90-degree turn smoothly and line up with CAT 3. Actual Result: - F-14 continues to attempt the 90-degree turn toward CAT 3 while the marshaler keeps signaling “hold.” - The aircraft stutters through the motion and ends up stuck in a perpendicular position relative to the CAT 3 axis. - F-14 remains locked in place indefinitely, preventing normal carrier operations. Additional Notes: This seems to be caused by a conflict between the F-14 module, the scripted takeoff trigger chain and the Supercarrier’s marshaler logic. Issue blocks mission progress since the F-14 never clears the taxi path or launches. Is there any possible interim solution until you add the definitive solution to any next update, like editing any launching position of any aircraft (E-2 or F-14 CAG) in the mission editor, just to let me progress in the mission? I'm not worried about campaign statics, I'm only interested in flying the mission. Thanks for advance.

Hello ED Team, Three years ago, I reported that the P-51D Mustang pilot model was missing an oxygen mask, which at the time was accepted as a bug. I understand that recently it was mentioned that this issue would be considered more of a “model improvement” rather than a bug. To avoid further confusion for both sides, I would like to confirm: Is this issue still listed under the bug category, or has it been formally reclassified as an improvement? If it is now considered an improvement, is there a public record or tracker where the community can verify its current status? My only goal is to clarify the status of the report and avoid misunderstandings in the future. Thank you for your clarification.

But some of the moderators/producers of this forum, even today and after everything that has been seen and said about the bugs of DCS “track files,” insist on using it as an excuse to dismiss certain bug reports—because for ED these are the elephants in the room (some problems have been around for so long in the game that the people responsible have grown so attached to them that they’re now incapable of killing the beast/bug). Needless to say, the method of having to come to the forum, make a report that’s open to discussion, seems absurd to me—because in 100% of cases, the first response always comes from a non-official “someone.” Then, after some time, a moderator shows up in that thread, usually 2 or 3 months later, and the most sensible thing they can think of is to ask you to create a short “track file” (as short as their reasoning) so they can start analyzing issues that have been reported here for many years. All this tells us is that they don’t feel like spending resources to fix certain bugs/problems/elephants. So the moderators/producers dedicate themselves to diluting problems: someone posts a report in the forum; outsiders jump in to say the OP is wrong, doesn’t know what they’re talking about, or hasn’t provided enough technical data to justify their complaint. Three months later, the producer in question asks for “proof” based on a corrupted file that’s completely useless. Some OPs waste their time generating that proof and attaching it to the thread. Another three months later—or maybe not—the producer gives an explanation in which, 99% of the time, they say they were unable to reproduce the OP’s error. And so the report sinks to the bottom of the programmers’ priority queue—in other words, it was never a high priority, but they never outright say no, they just completely ignore it, because for them it’s a problem they don’t want to face.

I'm going to resume it to you in nine lines: Of course! I’ll spend the same amount of time making that short track file as ED's spent improving the FM-DM of this specific model (and of all warbirds in general) over the past decade. With this I’m not saying I won’t do it…I’m just copycatting ED’s philosophy: never say no to any complaint and just postpone a solution (something that’s been working for more than ten years). In any case, and as possible reference material to work on, I recommend you take a look at all the end user complaint posts since the much-hyped new DM was implemented quite some time ago. With nothing further, please accept my best regards and I’ll be waiting for further news (though I’ll take a seat, since this issue has been in “the priority queue of a small group of talents doing what they can for so long that hardly anyone here even remembers anymore”). ....and by the way.... your bug queue is too much full from too much time, give to anything the queue fixing priority it needs.

So... After several years (more than a decade) suffering this UFO model and its lack of link in its FM-DM let's see if anyboby from that small but very capable group of dev's can polish it (I said polish it cause I don't believe in a fix after all this time), just not to get the wrong idea once you fight against it that you need to bomb it to get a kill cause shooting it with the 50 cals. iIt's almost like tickling him... the more you do it, the more he laughs. Thanks for advance (my thanks go 10 years in advance). I've just only attached the debriefing, cause track it's too long (don't blame me, blame the 109 FM-DM or lack of it). UFO_109.log

Listen, Mister “History and Respect for the Fallen,” you have absolutely no idea what really happened there… and you never will — not even if a survivor explained it to you. So please don’t go assigning yourself merits that are far beyond your reach and completely unrelated to the matter at hand, just to distract readers. This is a simulator — one with its strengths, technical flaws, and limitations, all of which are part of the package. Disclaimer: any resemblance to real events is purely coincidental — and with your insistence on mission timings and darkness settings, all you’re doing is reinforcing that disclaimer and diving headfirst into a totally absurd loop, where your so-called “reality” collides with the actual reality of this game. (Yes — it’s a game.) Just because I pay for a book that tells me who won the Battle of Waterloo doesn’t mean I have to believe that the “Royal Scots Greys” charged under Genghis Khan, just because the author was feeling playful that day — even if the final outcome is correctly stated. If we carry that analogy into a sandbox environment, then we find a much longer list of historical errors and inconsistencies than actual accuracies. So, as I said before: if you and ED want to keep doubling down — thumbs up. Seems to me you’re going to have to self-publish a book on Amazon just to feel proud of your historical “rigor”… and of your selective lack of it, whenever it suits you.

Alright, fair enough — I’ll concede that you're determined to stick to historical accuracy by insisting on keeping Z+2, even though you're well aware that DCS has a technical issue with moonlight rendering, and so on. You refuse to change the mission’s start time, yet you’re willing to suggest adjusting the Gamma settings as a temporary workaround until DCS delivers a proper fix… Honestly, I don’t understand you — especially not you — or Eagle Dynamics. I get that for them, it’s a matter of allocating resources to address a technical issue. But what I can’t understand is why you won’t agree to simply change the time from Z+2 to Z in this mission as an interim solution. Worse still, you've even argued with people who paid for your product — people you couldn’t or wouldn’t help, all because of a historical detail that ends up making the mission unforgetable by been virtually unplayable from the first second. Well, I suppose you know what you're doing to grow your business. Oh, and by the way... I guess this is just one more historical technicality among many, right? The real question isn’t whether the spoon bends — it’s whether the spoon even exists.

We're not starting the mission at 03:15 like it is shown in the briefing.... or maybe Local time in London Zulu +2, or Zulu -2.... who knows it?

Let the developers respond. They are not your children that you need to protect. They are adults with responsibilities, and if they are asked uncomfortable questions, then they should answer as professionals. "We" are not talking… "You" are talking… and that thing you’re trying to downplay was acknowledged as a bug report by them over a year ago, and to this day, it remains unresolved. Is that so hard to understand, or did you also have Mr. Newman as a teacher? Besides, I don’t have to convince anyone of anything. The report process is simple: You come to the forum and submit a report. If the developers acknowledge there is a bug, then they should fix it in the best way possible. I couldn’t care less how they fix it, but what cannot happen is that, after more than a year of admitting there's an issue—and supposedly reporting it internally—they now come and imply that there are more pressing matters on the list and that this isn’t even worth a proper response that satisfies the customers who took the time to come here, report the issue, provide tracks, and have been waiting for a solution for over a year. There will always be an indefinite list of more important things to fix... ALWAYS. If the module has other issues that you think need to be fixed prior, then, I recommend you submit other reports, and quoting a "wiseman": -prepare for a long wait, and move on.-

After more than 13,700 post and you hadn't learned to do a reading conprehension before writting anything? Well "Amigo", let's draw a foolish veil over this. I'll pretend that you're telling the truth, and you'll pretend that I didn't get your joke and that we're really "friends." Deal? Indeed it is, but this is a not resolved bug report... not a poll

Don't get me wrong, but if you look at when the first report in this thread was made, it was over a year ago (a year and four months, to be exact). If this issue had been added to the work list back then, we wouldn't have any complaints today. As you rightly said, the operator would have spent a day programming, another day testing, and maybe another fixing any resulting issues—long ago. Instead, after ignoring some customers' complaints, we now get a vague response from you. I know perfectly well that this isn't a priority, and I'd bet an entire paycheck that it never was. But since your response has been quite diplomatic (if not effective), the least you could do is provide an ETA for the implementation of Jester 2.0 for the F-14. It's as simple as that. You seem to contradict yourself when you suggest that implementing an advanced AI system like Jester 2.0 is easier than simply placing a static patch where there used to be a real-time animation, which is now just an empty space. A suggestion: you don't need to spend three days giving vague answers—use those three days to work some magic and fix the issues with your product. I'm just throwing out possible suggestions in case they help in a brainstorming session. But I speak from the ignorance of a consumer, not as a Heatblur employee or insider. However, thanks to that ignorance, I put my money into your product so you can make a business out of it—because if I weren't ignorant, I'd save my money and program my own mod. Anyway, thanks for sending my suggestions straight to the bottom of the pit. Very kind of you to waste your time responding instead of actually programming—perhaps to put the Heatblur logo right in the middle of the target, so everyone knows who proudly made this product. The PERSPECTIVE in your VR's has been lost: the gap in the middle of the Jester's roulete 100% should match with the sweet point of you googles, otherwise you prior NEED should buy a new ones. I'm just suggesting, just suggesting but you know where to throw my suggestions: same place as the bug report.

Easy, cause they're not going to implement their definitive solution tomorrow... neither in this year. I'm becoming too old (also too crow) to believe in miracles. Sure it will be fix but, we will have to wait 15 days at least. Also, Yes you're mistaken... you can only see air (or a gap) where it should have been the rear cockpit and/or Jester. An static customizable space is more elegant than what we had have all this time IMAO

Alright, I’m on board with the idea. But no one on the team can waste time on: 1- Informing customers about an ETA for the implementation of Jester’s new interface (see Phampton) and, if that’s not possible... 2- Spending several hours of work filling the space that should be occupied by the back of the cockpit and Jester with some generic static image, or even a customizable one—like a pin-up, my dog's face, etc. I think after one year of MT implementation should be enough for finding an interim solution, don't you?