Jump to content

LastRifleRound

Members
  • Posts

    1145
  • Joined

  • Last visited

About LastRifleRound

  • Birthday 10/28/1982

Personal Information

  • Flight Simulators
    DCS
  • Location
    United States

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yup, we're on the same page here. You shouldn't have to make a mark point at the designation, then set the O/S on that. In your example, you should be able to apply the O/S to the waypoint, designate and refine on the JTAC, then hit O/S and be staring at the target with no other steps needed.
  2. Yeah it's weird. When you give a waypoint an O/S it becomes an OAP, because you are supposed to be aiming at it. When you have the OAP designated, and then refine it, say with TPOD and designating with TPOD, hitting O/S should apply the offset to that new, designated position. Instead, designating the OAP, then refining the aim point, then hitting O/S makes the O/S overwritten with the designation, instead of applying the O/S to the designation.
  3. That's part of what makes what I'm decribing necessary, but it is not itself what I am describing. Also offsets are DEFINITELY involved with INS drift. Please read Hornet tacman, see W-OF function in Harrier tacman, watch linked videos in A-7 forum, or reference dash manual for the Viper for OAP/VRP/VIP if you don't understand. Could also be a scenario where you have a great relative reference but poor absolute coordinate positioning.
  4. Use FRZ mode to avoid the snap-back issue for now, works well
  5. It's my understanding from the TACMAN that offsets in the Hornet should work like this: Let's say we set up a waypoint on a prominent feature, like a radio tower. Let's say our offset will be a target that is a known bearing and distance from that tower. Let's say by drift, the waypoint is displaced a bit. When I have the tower in sight, I designate the waypoint, then slew either the HUD or sensor over the tower. I hit offset, I should be looking at the target. Instead, any slewing or designating I do on the waypoint changes the offset to what I designated, and no offset is applied when hitting offset. Am I wrong here? The current implementation makes no sense. There was this comment in the November update, but it doesn't seem to work. Fixed: OAP designation is incorrect with CCRP - fixed calculating relative TD OAP position
  6. There's a bug burried in an intentional (though possibly not correct) change. AUTO target handoffs are bugged. The handoff is only attempted the first time you TMS up on the TGP, whether successful or not. SOI then changes to WPN. If you undesignate (TMS aft), then DMS down to make TGP SOI again, any subsequent TMS ups will NOT engage the handoff, and will instead only change SOI. The only way to get it working again is to cycle the modes to VIS and BORE back to PRE EDIT: just read the post above about TMS right...maybe intentional then? Will check it out tonight.
  7. Same here, can confirm order does not matter. If you set VRP to MSEL, THEN change bombs to CCRP the crash happens immediately upon clicking CCRP. Also was not online, was just a single player mission I made up in the ME.
  8. No way the Hornet still has bombing issues? It's only been 4 years and it's early access so you deserve it. Oh, it's released? Well it's your fault because open beta. It happens in the stable version, too? Ummm....bombs aren't that accurate. Real pilots don't use auto or something. Need more tracks, thread closed because we can't reproduce and if we can it's supposed to do that anyway. You don't know it's a bug because you don't know the exact version, revision and favorite kool-aid flavor of everyone who worked on this Lot Hornet's software. Go TOO ripple 43 JDAMs or something. In all seriousness, try making sure the temperature in your mission is 20C, there is a glaring error in certain designations at lower temperatures that I'm not sure is throwing the aimpoint off (it's always short when using radar and waypoints). Probably not the issue as in the Viper you can correct the designation in the hud by slewing on target before release but it will at least prevent the two bugs from compounding on one another, as the temp bug is a universal DCS issue at the moment. I've posted 4 or 5 bug threads about this issue in its many forms throughout the years. I'll tool around tonight and see if I can't add more tracks for you, though at this point I'm not sure it will help. It's been years of the same issue.
  9. Did you have LGB's or Mavericks, too? Even though they're at 0 if you already used them, you can still see them on the SMS page. If LGB's, use DTOS, if Mavs, use VIS. TMS up long to make HMD SOI, look at target, TMS up short, DMS down to get the TGP to be SOI. It's not much different than the A10 except the part where you have to pick a delivery mode. If you think you'll need to save that point for reference, hit MARK, then SEQ right to TGP as source, TMS up. If you want your new MARK to be active Steerpoint, hit MSEL while still in the MARK page. I really don't think it's that hard and the debate on who made it and why I think is based on the entirely subjective suppositions on how "clunky" it is when doing DCS stuff. Even for DCS stuff, it's not any harder than the Hornet is, and the A10 was purpose made for DCS stuff so you can't expect other airframes to be as good at loitering and plinking. In fact, you could argue DCS itself was built around the KA50 and to a lesser extent the A10, so DCS was built around this kind of mission. Give it some more time and I'm confident you will all will get in the flow in now time. I never thought it would be, but the team on the Viper has done an excellent job in my opinion and it's probably my favorite at the moment.
  10. The confirmed issue is that bearing entry isn't working and is always 0 no matter what you enter. Are offsets being moved as a result of designation also reported? I didn't see it.
  11. You're misreading it. It says an offset aimpoint is a waypoint with an offset associated with it, meaning OAP is the waypoint that has the offset as opposed to the Viper where the OAP is the offset itself. Further reinforcing this, it says OAPs can be entered using map slew, but the offset must still be entered through the UFC. Therefore, in the Hornet, OAP is just another name for a waypoint, except that waypoint has an offset associated with it. Further, NATOPS actually supports my assertion when describing how nav updating works. "Also, the next waypoint in succession becomes designated or, in the case of an OAP, the offset becomes designated. There is no ACPT/REJ display in the AUTO update mode." When updating an OAP with an overfly, the offset is designated, NOT the OAP itself. This is describing the same process as the Viper's VIP, and more similarly to the Harrier's W/OS procedure (same manufacturer, unsurprising). Then there's the description of NAVDSG, which says you should designate the OAP position (easily recognizable feature) then press "O/S" to add the offset to it, which will then indicate the target position. It appears right now, doing a nav designation designates the waypoint, when you slew to something else and then hit "O/S", you will find that the offset has been changed to match the designation, so it will appear in your sensors as if nothing has happened. This is backwards and appears to be a bug. According to NATOPS, you waypoint designate, slew to where your OAP should be, then hit O/S and you should be looking at the target, as the O/S should be applied to whatever you have designated. Instead, you'll find if you watch the data page it simply changed the offset position to match what you just designated. @Hulkbust44 are you seeing the same thing? I'm going to make a bug report if that's the case. We can't source TACMAN, but I'm pretty sure we can source NATOPS on here.
  12. How do you know that? I ask because that would be counter to every other implementation of offsets, including those in other Navy aircraft and other aircraft made by the same manufacturer, it disagrees with the TACMAN for the Hornet, and it doesn't pass the common sense test. At this point, I would have to say unless there is strong affirmative evidence suggesting otherwise, my assertion is the most likely to be correct. Every other instance of offsets (just look at old youtube videos to confirm) was assumed to be for CAS scenarios and it wasn't true. That just turned out to be backwards rationalization, and not sourced from any documentation (I'm talking Mirage, Tomcat, Harrier and Viper). I'm guessing the Hornet likely isn't the only aircraft that's going to buck this trend.
  13. The point of an offset is to resolve a target or waypoint location using an easily referenced feature relative to that waypoint/target. Right now in the Hornet, offsets just act like waypoints you access differently. If you have bombs loaded, Offset designated, shouldn't the ASL point to the target?
  14. This isn't exactly correct. 1. Standard procedure in the viper is to switch to CCIP once a pre-planned target has been visually acquired, which is why the NWS cycling order is the way it is (CCRP->CCIP->DTOS->CCRP). CCIP does not necessarily equate to an attack on a TOO. Not a problem in and of itself. 2. The problem isn't that the reference point slews persist in VIS modes, it's that they bleed over into PRE modes (again, not necessarily a problem, might be the way it works) and can only be zero'd by hopping into a PRE mode (this is the weird part). You should be able to zero VIS slews in VIS, since every other SOI and modality demands it be zero'd by itself in its own mode. (HUD slews must be 0 in the HUD, TGP in the TGP, FCR in the FCR, so VIS is a HUD slew and should be zero'd in the HUD in VIS mode). The procedure breaks the logic presented in the write-up. Either the write-up is wrong or this procedure is, they can't both be right.
×
×
  • Create New...