Jump to content

raus

Members
  • Posts

    131
  • Joined

  • Last visited

1 Follower

About raus

  • Birthday 01/30/1980

Personal Information

  • Flight Simulators
    DCS Openbeta, falcon 4.0 bms 4.34
  • Location
    Germany
  • Interests
    Flight sims 🤪

Recent Profile Visitors

5531 profile views
  1. Sounds reasonable I did not consider the whole thing, as just realized those systems having different codes. Thanks for the feedback, anyway!!!
  2. Hey @Minsky great work!!! If I may ask for an addition... would it be possible to include a couple additional codes in the RWR Harm codes, for the High-Digit SAM Mod (very often used with Liberation nowadays) According to their thread: Thx!!!
  3. I have just set up a mission to test the GBU-31 against an ammo depot. Oddly enough, I found that I need two GBU-31 (v3 or v4, same effect) with the Hornet, but it is not enough with the viper... so I'd say something is not ok with this bomb for the viper
  4. @IvanK thx, that is what I thought, but wasn't sure if it was reported... Anyway, here I go with a couple tracks, just in case @NineLine please, have a look at these tracks, as they show two different behaviors, and I don't think it is completely OK... snakeeyes_CCIP.trk shows a low level (300ft) attack run at 550kts (GS). I select snake eyes, fuses (nose/inst) and retard option. I also configure the 10 bombs to be released individually with a 990ft spacing, trying to cover the runway. However, the pull-up cue stays consistently above the FPM. And you can see that I fly level and, sometimes slightly ascending. The bombs release and fuse correctly, though. Excuse the bad lineup, I configured a mission starting very close to the runway, and did not pay much attention to lining up, as I was focusing on the settings and FPM snakeeyes_AUTO.trk s the same configuration, just selecting AUTO. I use RALT and CPL autopilot modes to bring me to the runway threshold this time (lazy me!) but I disconnect the autopilot moments before the attack. You can see the pull-up cue above the FPM all the time, and the DUD cue in the HUD. Not all bombs get released, and those that are released, did not fuse properly (indeed, they were DUDs). I think this should have been a valid attack, maybe not with low drag bombs, but definitely with retarded bombs. snakeeyes_CCIP.trk snakeeyes_AUTO.trk
  5. No feedback? Nobody tried? Guess I‘ll get a track and file it as bug, as I have not been able to release retarded munitions flying low and level, and could not find any obvious mistake
  6. Checked, found and internally fixed The problem was due to a F/A-18C flight that was created without name or task, and that was causing an exception
  7. Difficult to pinpoint from there. If it is recurring, please give me a link to the .miz you are having trouble with. I will find the issue and try to fix it shortly, as there‘s a new update almost ready to be released, and I could potentialöy include this fix in it. BR raus
  8. Hi @BIGNEWY, thanks for the reply - While I can understand point 1, and I am not an AWACS expert, it seems odd that it is not covered in desing of the AWACS... anyway, thanks for the feedback. - I could accept the point 2 if it wasn't, as I mentioned that ALL datalink contacts disappear at once, not only the beaming ones. Is there any explanation for that? Thank you!!
  9. Hi, I've just been doing a little testing with Mk-82 Snake eyes and Mk-82 Retarded, trying to bomb a runway, old-style, low and fast. However, I am finding it impossible to get the pull-up cue under the FPM, resulting in a DUD cue and bombs not exploding. I have tried CCIP with a shallow dive, and also AUTO, flying level, 500kts at 500ft (and also tried lower), with the runway center designated (Incirlik FWIW). I set the apropriate release method, MFUZE nose, EFUZ inst (also tried DLY1), DRAG RET. I set in the UFC a QTY=10, MULT=1, INT=1000 (also tried 990, just in case) Nothing has worked. It is a shame, as if I want to release from altitude, I do not need retarded bombs... I guess it is bugged, and will provide a track later, but wanted to check first, in case I am missing something stupid, or if it is already reported. Thanks!
  10. Hi, I have been experiencing the following behavior regularly in online Liberation missions. I don't want to opn a report, as I am not sure if this would be a bug happening to other people as well, or related to our setup. The issue is that our datalink contacts come and go at intervals. All of them. I have thought several possible sources, but ruled them out: AWACS turning cold and losing contacts: to my understanding this would be nonsense, with the big rotating antenna of the AWACS, should not matter if he is hot or cold on the contacts, right? Contacts are on the beam, and are lost to either the AWACS or the contributor fighters. I see some heavy issues with this, as: I don't think we should always, 100%, lose all contacts that are turning, regardles of their relative altitude, size, speed, RCS... We even lose contact with tankers when they slowly enter a turn. And it is not only on fighter radars, also for AWACS (!). This would, anyway, be a radar problem We are not losing only the beaming contacts. Also datalink contacts that are hot are lost. And they are, suspiciously lost all at the same time. So we go from having 3 bandit groups (some hot, some cold, some entering beaming aspect) to suddenly, at the same time, having none. It is as if somebody swiched off the datalink completely It feels like we are having 1minute of MIDS followed by 1 minute of no MIDS (not measured, I don't even know if it is that regular, as same duration.... just the feeling) While this is adding tension to our BVR engagements, it is indeed very annoying. It also leads to a lot of broken radio calls, as the contact disappears from our SA page while we were reading the B/E position to coordinate. I would like to hear opinions on this issue. If it happens to more people, and it is considered a bug, but not yet reported (I did not find it, but might have been a bad search-fu on my side) I could try to create a track. Our online tracks are very large, and sometimes this starts happening mid mission, as we take off from a long distance. I would need to research if this also happens offline. BR raus
  11. @BIGNEWY I would have assumed the evidence could be found at the same place it was for TWS... isn't that the case? Then, wouldn't it be enough to check with your SMEs? Because every Hornet pilot I've spoken to (disclaimer: non US Navy nor Marines) has told me it is a real capability... and I would assume US jets are not lagging on such a basic feature. Furthermore... couldn't we just assume it is a feature independent of the radar AA mode selected? It does not look like this would hint towards use of any illegal doc, does it? I understand EDs approach to ITAR and classification, and it does make sense... although there are some "common-sense limits", there are things already implemented based on assumptions, and not needing hard evidence, and this looks to be 50% common sense, 50% known. I would assume a quick check with a SME should suffice to bring it back (IIRC it was present some time ago) BR
  12. @BIGNEWY I understand your point and, obviously, questioning the development every time is a hurdle to move forward. However, I would like to respectfully point to a couple misconceptions here: New information has come to light: you have been offered a thorough explanation of why does it look like the team did an incorrect implementation, and even a potential reason for the misconception. Not only that, but even sources to verify the theory have been ppointed to. The team are happy: well, it is important to us, and we value their expertise. However, when customers are repeatedly pointing a serious concern, and providing their evidence and know-how, I think happiness is not a strong enough argument to support the lack of explanation. So, in summary, a portion of your customers think a wrong implementation has been done. They point out why they do think so, contributing with explanation of the basic theory, and pointing to reference material, employing their own spare time in an attempt to improve the quality of the product. However, you are dismissing their valid concerns without even offering a well-deserved explanation. Fortunately, no harm is done, and there's still time to step back and set a healthy debate, isn't it? Excuse me the absurd comparison, but it sounds as if an user finds out he is able to take off with the engines off and files a bug, explaining that an F/A-18 cannot take off without power, and even referencing a physics book, but his complain is dismissed and he is asked to "point out to open-source documents where it clearly is stated that an F/A-18C Lot20 from US Navy or Marines, ca.2007 could not take off without power"... you see? Even valid arguments can be over-stretched, so I would kindly ask to reconsider this topic and offer an explanation. I think nobody asks for reverting a change with no explanation, but when the team's understanding contradicts everybody else's, and does not match with the theory backing the claim... an explanation would be really appreciated. BR raus
  13. Hey @BIGNEWY and @NineLine... First of all, I do not intend to start a fight here, just healthy curiosity. Therefore, feel free to delete if you believe this is not pointing anywhere constructive, no hard feelings. The reason to write these lines is the controversy about some Hornet capabilities not being implemented due to ITAR regulation putting them out of reach, to name two of them, the full MSI implementation and the EOM mode for AGM-88 Harm. Why not simulating the effects? I think there are other modules of the Hornet which are as much of a secret, or even more, than the two named above. For instance, the ECM suite is a complete secret, I think, and yet we are simulating its effects, with a lot of guesswork, to have an ASPJ in the Hornet, or the ALQ-84 of viper and hog... Then, why not just: Implement a simple EOM mode, take the viper mechanics for it, and call it a day Allow to lock non radar tracks, from the SA page and create L+S from there, and unbind the track lifetime from the brick timeout. These are two simple examples. They wouldn't be 100% correct, and the real systems are surely more involved but... better a simpler implementation than nothing. I mean, I would consider more realistic to have these capabilities "simulated" or not 100% true to RW operation, than having a Hornet lacking so important capabilities. We have lived and accepted simplified systems (remember the Harm TOO mode was said to be simplified, and to later inherit from viper... and it was accepted that way, so why not other systems? ) I understand there might be purists that want it binary: either exactly as real world counterpart, or nothing... but that could be done a setting (even a server enforced setting) to allow simpler implementations, or justdiscard them completely. Why not making clear what is accessible? A lot of the controversy comes from not really knowing what is out of bounds. Then, why not publishing which documents are used as reference by the team? If they are open-source, as claimed, listing them for everyone interested to have a look would settle a lot of misunderstandings. We could have a look at the references upon which systems are modelled and that would save from reporting bugs that aren't such. Thank you for taking the time to consider this idea and give some feedback
  14. Hi @MicMic god suggestions there. I am postponing the update, due to IRL workload at the moment, but I will try to get some of these in... Just a couple things from my side: - You mention the overwrite function breaking a .miz... could you please share that original miz to play with? I have not seen that behavior, and would like to debug it. - Changing the preset channels for agencies is a little involved, they way it is written now... I will definitely consider making it more flexible, but I can make no promise and would anyway come later (not in next update) - Sure, I can see if I manage to get some time to expose the parameters of the Bingo calculation. I could use the ones from now as default, but allow modifying the factors - Good catch on check-in time... I will add a double check to avoid times before mission start. Now it takes the mission start time + startup delay = takeoff time, and from there substract to have taxi time and check-in time (for radio checks), but if the startup delay is too short, it will shift those before mission start The formula I am using for Bingo right now is, roughly: Minimum fuel: 1000lb 250lb for pattern traffic (400lb if IMC) (Distance between recovery and Alternative, in nm)*10lb (Distance between recovery and furthest WP in the route, in nm) * 15lb (*20lb if low-level egress) Best regards, raus
×
×
  • Create New...