LastRifleRound

Just did a several runs. The "phase 2" pipper is definitely strange. It forces you to guess the correct attitude to maintain throughout the pass. The "phase 3" steering order is excellent and bang on and does provide the necessary corrections. I can attach a track of a very simple mission I ran where I do a simple pop-up at about 10km out from the target, set the sight on the target, unsafe when radar ranging is available. The sight jumps low, so I engage a climb to compensate. The sight isn't quite on target yet (still low), but when I hold the trigger I'm commanded to drop the nose slightly. I follow the steering order and the bombs come off at exactly 400m and are a direct hit on the target, an ammunition depot. Safety altitude here was the default 400m. Again, not a huge deal, the sight is probably my favorite bomb sight in any jet, I find it intuitive and accurate, but the phase 2 sight should probably be on target when the proper nose attitude is reached, as the phase 3 steering order does.

I think the sight actually should jump. The issue is the behavior after. Phase 2 should behave just like phase 1 and 3. The jump is to be expected as triangulation is used until trigger unsafe so the solution must be updated for the new slant range. It would probably works similarly to the steering order in phase 3, wherein when proper pitch (not altitude) is achieved, the pipper is on target and moves down the sight glass along with the target. I think you got it near perfect save for this one minor tweak. Phase 1 and 3 are intuitive and it makes this one of my favorite profiles to fly. EDIT: it just dawned on me the slowness to respond might be the target coming closer at the same time the adjustments are made. You might already have this working right and i'm just rushing the flight corrections. Let me test this more this evening and I'll report back

I think a slight tweak is necessary for the PLAN bombing sight. It is very intuitive and useful except in one phase. When ANF is engaged, the sight, when pointed at a point on the ground, will guide you to the safety altitude set in the mission planner assuming a correct QFE setting. This works perfectly. Let's call this phase 1. If you wait until the vertical fin appears to trigger unsafe, often times the sight will "jump", as more accurate slant range is acquired. If the sight moves low off the point designated, a climb is commanded, and vice versa a dive would be required. However, this sight does not move like the sight in phase 1. Instead of responding to your pitch to guide you to the safety altitude, it seems to respond to your altitude, meaning the pipper won't be over the target point until you've climbed to the safety altitude. This doesn't seem accurate. Let's call this phase 2. Phase 3 would be holding the trigger. When you do this, you're given a steering order. The steering order behaves like the phase 1 sight, in that if you pitch up, the pipper will be in the order such that by the time you get to the target, you will be at the safety altitude. This is why most youtube videos you see the trigger is depressed late (on flash of the range bar or when the sight falls below the nose, as the instructions indicate). However, they should have already adjusted their pitch attitude, so it becomes impossible to "chase" the steering order as there is no pitch that would achieve the safety altitude at that point. I believe that the "phase 2" sight should behave as the "phase 1" sight. This seems very intuitive and would cause the instructions to be perfect. As of right now, if I see the sight jump, I immediately hold the trigger and use the steering order to get me on target. If the phase 2 sight (after trigger unsafe) behaved like the phase 1 sight (before trigger unsafe), when the sight "jumped", you would adjust pitch to bring the pipper on target the same way. If maintained, when the trigger is held in, the pipper would be right in the middle of the steering order. I hope this makes sense. TL:DR, after trigger unsafe in PLAN mode, I believe the pipper's vertical positioning should respond to pitch, indicating the correct pitch to arrive at the safety altitude when the target is reached, just like the pipper before trigger unsafe. Right now, it appears after trigger unsafe to respond to altitude, not pitch.

Does anyone know which in map and placeable structures have a radar reflection model? I'm making some strike missions up and would like to place some as fix points as well as strike targets.

That's just it, don't try to guess where it is over the ground, just nose down a few taps after launch. When the flare is superimposed on the target, nose up to stabilize. Now it's just minor corrections in either direction, one or two taps at a time. Don't worry about altitude just keep the flare over the target. The closer to the target, the easier it gets.

It helps if you stack the odds by dropping the whole stick of 8 bombs :D

Ok just ran a bunch of missions with the Mirage. I turned off the INS requiring alignment (NOT gyro drift, which was already disabled, meaning the box in the "special" settings was checked), re-ran one of my test missions, and the waypoint cross was right where it should be! Of course, it was below the target, but that's the normal parallax stuff that happens in DCS. No problem. Bombs on target. I then enabled drift again and required INS alignment, started another in-flight mission, and bang-on again after an OBL alignment. I then took the same mission, did a ramp start, aligned the INS according to the kneeboard, went to the waypoint and did an OBL and good again. I don't know if turning on not requiring INS alignment and loading up a mission fixed something, but I swear the waypoints were way off before. I've flown all 3 of my test missions, one including a PI profile and everything was working. I can routinely hit my target now. Thank you very much guys. Not sure if I would have kept trying if you all didn't help. To anyone out there experiencing waypoint mis-alignment, check both boxes in the special settings re. INS, load up a mission and it should be fixed from that point forward.

Nevermind just saw 33's reply. Quigon, drift isn't core dcs but waypoint placement in ME is. That is what I was testing. It seems Steph had the same issue. Could there be something wrong with my module specifically? I'll post those images so you can see I'm not crazy.

I will post screenshots. Perhaps this is isolated to the caucuses? It's the only map I currently have. You appear to be at Nellis or the Gulf. Also are you on stable or beta? I am running stable. I will post images tonight. Maybe there's something wrong with my module. It def has NOTHING to do with drift. I even OBL update to eliminate the possibility. The cross is still off.

I think before they worry about putting in a pilot model and polishing some of the interior, they should fix: 1. TWS breaking lock randomly 2. Waypoints in the wrong spots 3. INS updates not functioning properly 4. CCRP bombing falling way too long My .02

I know there's a youtube video out there showing the improvement in accuracy for the A10 with the laser vs without with the same bombs and the same type of target (dumb bombs of course). The Viggen models this sort of thing, too, with the PLAN mode, since this uses HUD designation which is the same principal. If you wait until radar ranging is available, your bombing solution is far more accurate. Not sure what magic is under the hood there, but there you go. You're bang on about the INS. If it's degraded all your solutions, even with accurate slant range will suffer. The Harrier doesn't model INS drift at all (even if it did, you'd have to take it out of IFA to observe drift) so I don't think we'd ever encounter it.

I'll test this and come back tonight with the result

MAN what a rush! when you finally get it down and hit something with one of these it deserves a holiday! Love the Viggen. Target was an ammo depot. I use a hat switch (non-axis) to control, and I found I had a nasty habit of holding the control input to change course instead of tapping a bit, letting the missile drop to the target level, tapping to nose up a couple times, until impact. Once I got it down I can repeat it about 80% of the time (I hit 8 out of 10 I tried). Now on to vehicle-sized targets.....

The waypoint is NOT where it should be. Please perform the experiment. Iam not complaining about bomb accuracy. The accuracy is quite good in PI mode. It hits wherever the cross ends up. That cross is in the wrong position because the IP waypoint (and every other waypoint) is wrong. Please. I've given you a way to repeat the error. Before you conclude it works please perform the experiment. It takes 5 minutes to do and only rudimentary skills in the mission editor

Tpod infers slant range by assuming tgt altitude is the same as ground level underneath aircraft. It combines this with gimball depression and solves the resulting trig equation. Basically it does this almost how the ARBS calculates a firing solution. This assumption is removed when target is lased as actual slant range is known at that time. Not sure if the a10c uses it's elevation maps when tpod designate is used without laser. If it does it would be more accurate than the harrier in this regard.

Precision bombing (mode "PI") DOES require coordinates. Your BAD is only as good as the IP's coordinates. It should be accurate to within 30m, less if you loft. That is not the issue here. The Viggen was simply a control for the experiment to determine if the issue was DCS or the Mirage module. In the Viggen the QFE must be manually set, so it's navigation system DOES care about temperature, but that is a tangent and not related to the Mirages issue. Please perform the test outlined above to see for yourself. It is definitely broken. Your waypoints are not where they should be. Drift has nothing to do with it.

Got another one. Waypoints lose elevation with mission ambient temperature. Doesn't effect bombing accuracy, but the waypoint ring will not render in the right place the colder your mission is, as it is actually below the surface somewhere.

Ok just did a whole lot more testing on this. This issue is definitely isolated to the M2000C. The Viggen's waypoints sink "into the ground" with TEMPERATURE. The colder the ambient temp, the more below surface the waypoint goes. However, this is just a parallax issue. If you go run a NAV bombing profile, your bombs will be bang on. The waypoint ring will appear to be closer to you than the object you put it over, because it is actually LOWER. However, none of this is the case with the Mirage. The waypoint is actually wrong. It is not in the same place as it was set in the ME. At least as far as the Mirage's computer thinks. Your bombs will ACTUALLY miss. Since NAV updates don't really work there is no way around this. Your coordinates will match up to the object, but the Mirage computer thinks they exist somewhere else. Again, this is NOT BECAUSE OF DRIFT. The Viggen drifts, too (no GPS), and these problems do not exist with the Viggen. So, add this to the list of things that need to be fixed. It's a rather big thing, too, as no INS bombing profiles are possible with any degree of accuracy whatsoever as long as this issue exists.

It's not ins drift tests run with it disabled. Try it yourself. Very easy test to run. Also PI bombing requires fix to be done which are currently 100% accurate. Target is just over 5nm from IP. See for yourself. Place an object or select a building in the ME. Zoom all the way in and drop a waypoint on top of it. Spawn your Mirage about 9nm away. Disable INS drift. Observe the waypoint cross. You will see it is well off. Now make a BAD to some other object close by. Observe that is way off, too. There's a large thread partially about this from a year back. No conclusions drawn and no one's mentioned it since. Can someone run this test and tell me if it'a just me?

I don't think it's parralax as the bomb drop guidance cues and the viggen ag radar would ignore it. I think it's a translation error when the world is rendered. Though the grid is 2d the world exhibits some "magic" to render curvature to simulate radar horizon and such. This throws the map grid out of sync with the "real" world. At least that's my theory. Perhaps someone with knowlege of the engine could tell us how to compensate to get bombs on target.

I noticed that every time I place my waypoints directly over objects in the ME, when I run the simulation the actual waypoint is way off from where the objects are. I usually using something from the "Warehouses" menu (like the ammo depot) or an existing building on the map. I've even tried it over a TACAN transmitter. The effect is the same every time. Even stranger, the coordinates of the object on the F10 map correspond to the ones entered into the navigation system. I believe this is an ED issue, because the same thing occurs with the Viggen. The only reason I posted it here is the M2000C has a bombing mode that relies on this being accurate. When I input the information for a BAD to do precision bombing, the waypoint cross and bombing symbology are way off from both F10 and ME, usually about about .30 or so nm, enough to make a big miss. However, I've seen 3 videos on youtube showing this procedure used successfully, including a thread where Zeus (the dev) nails a bridge dead center. That thread had a forum user (Frederf I believe) who threw some pretty complex math, but I didn't understand any of the conclusions. My question is, is there a way I don't know of to get waypoints where they are supposed to be and get precision mode to work properly?

Lurking this thread is an exercise in watching people talk past each other in idioms as opposed to actual issues. Statements like "Camp A always hates dev X and Camp B gets it" and "it's the same 10 people complaining" are very irritating to read, as they don't address the actual discussion at all. Instead of talking about how someone is talking, or talking about what you think they must be like, address the external thing to which they are referring. I find the M2000 one of the most fun aircraft to mess around with. However, the most optimistic among us cannot deny the state of the INS and CCRP bombing and TWS after 3 years is unacceptable. These aren't ancillary features. They are features advertised to be in the aircraft, with training missions and flight manual chapters dedicated to them even though they don't work. It is one thing to leave bug fixes so you can work on something else. It's quite another to gut mission capabilities and walk away. This is common sense. I don't have to discuss who is like what as a person to say this. It is plain truth. Instead of thinking like "Well I don't care about X so I have fun" think about it this way. If someone sold you a Ferrari, and told you "Hey man. You'll love this Ferrari. It's really fast, it'll corner well, and has a real Italian leather interior". You accept delivery. It looks like a Ferrari. You open the door and pop the hood. The engine is 120hp 4 cylinder because they didn't have time to finish the 10, it can't take left hand turns, and the interior is all plastic and is purple. Your neighbor happened to buy the same car. You complain to your neighbor. "Hey, this sucks! I ordered a Ferrari and they gave me a monstrosity that can't do any of the things they said it would! I gave them 3 years to fix it. But all they did was repaint one of the quarter panels and stick a knob on the shifter, and now they won't even call back or commit to fixing any of my specific issues relating to the selling points THEY gave me!" how would you feel if your neighbor said "Well I don't really like going fast anyway, and just make a bunch of rights to work around not turning left and I just imagine the plastic is leather"? What if he told you "Everyone I know is happy with their jalope Ferrari, it's just the same guy I always hear complaining about his" Does that make the guy complaining any less TRUTHFUL? You might not like him, BUT IS HE LYING? I think RAZBAM is committed to finish the modules to address OP's concern. But flexing your superior imaginative capabilities or superior optimism is silly. The Mirages core systems should have been fixed years ago. They should have been because RAZBAM said they would, and the average person would not know they didn't work and would not assume a 3 year time frame. It's dishonesty to say you will do something then not do it. You can have all the fun in the world, but that doesn't change the fact that people should keep their promises. Leeway is great and necessary. I'm a developer myself. Timing complex software is virtually impossible, and I've launched several enterprise applications. But my God man. Do your unit and integration tests. And 1 year is acceptable for a project like this. 3 is awful. 3 and you launch another software then another is inexcusable. If you can't get your software off the ground with the minimum function set without a Madoff-like scheme of EA titles to keep you going, you have no business promising delivery of the software in the first place and you should in no good conscience accept a dime for it until you can meet that set. If you break where bombs fall, not noticing then walking away from it is not a good development strategy. Not knowing/not caring about the Harrier ASL for that long is bizarre. I look at the change log and it mystifies me. The idea we'd add damage modeling before core mission sets is strange to me. Regardless of how much you can imagine it away, it doesn't change this fact. Please keep that in mind. With all that said, they seem to be coming alive. I question their priorities (as in the order they seem to want to fix things seems odd to me), but it doesn't seem like these guys are going to fold. They have day jobs for God's sake, so it's not like it's DCS or bust. Plus who knows what's going on personally for them. I hope nothing bad happened but you never know. They're a small team. S*it happens. I'm thinking about learning myself some lua and offering them a free hand doing nothing but squashing bugs if they take it. If nothing else they have awesome choices in aircraft and some decent bones. I would follow this priority list for features: 1. Features/Bugs for core mission sets (can a Harrier/Mirage drop bombs? Lock on and track aircraft? Takeoff? Land?) 2. Features/Bugs that break immersion/defy reality in egregious ways: INS updates, INS aligning no matter what, etc 3. Features/Bugs for ancillary tasks (Eclair system auto modeled, auto countermeasures, ECM auto, IFF) 4. Convenience features: Having to turn a knob to get manual radios to work, cockpit lighting, other quality-of-life-type enhancements (button sounds, cosmetic things that don't fall under category 2) The problem I'm seeing is most fixes are falling under category 4, a few in category 2 (damage modeling), and almost nothing in cat 1 (ASL fix in March was it for years). I'm of the mind until cat 1 and most of cat 2 is finished, you shouldn't be touching a new module. Anyway, my update just finished so I'm going to go fly the plane I just spent a half hour bitching about, because it IS fun and the campaign is excellent.

I doubt it. The MLU doesn't show any fixes to INS fix or changes to CCRP accuracy. These things shouldn't have to wait. 3 years to fix a bug you introduced is just lazy. I'm a developer myself. I have no idea how something like breaking where bombs land passes an integration test and ever sees light of day all the way to production. It's not like they broke the color of the lights, they broke a whole mission set. 3 years ago. Then just left it. Well rant over. We'll see what happens. I get the feeling they need more than one systems dev. These things are just so complicated.

Wow. It's not even on the update roadmap. Bombs are very inaccurate, precision mode release doesn't work right, tws is messed up. I don't think I'll be buying any more RAZBAM modules. 3 years later and critical systems don't work right. I took my time and researched, read the whole manual, watched a bunch of videos, lurked hoggit and this forum. I had no idea this stuff was all still broken. I feel mislead. Why are there training missions showing me this procedure as if it isn't broken? I spent 40 minutes trying to get that damn cross under the bridge only to find out there was nothing I could do. It's like the devs knew they couldn't get it right so slid this mechanic in hoping we wouldn't notice. They should have to be up front with what they know is broken. I've been with ED since LOMAC and IL2. I have the a10C and BS2. I'm coming from Heatblur's Viggen which I love. My expectations I guess were too high. I'm putting this one down and jumping to the Tomcat. Until they fix these things I'm not touching anything RAZBAM.

I've seen several posts referencing INS being messed up back in 2016. It isn't clear to me what is still screwed up and how. It seems like no matter what I do the INS updates are largely ignored. I can purposely designate a spot well off target and it will not make any difference. I am well within the 15nm limit for an update, btw, the REC button is not flashing, VAL is lit up and the LED's read out a delta distance and bearing. Pressing VAL seems to have no effect at all. I have tried overflight and OBL modes. Radar altimeter is on, radar is EM and in TAS mode for OBL. This can't possibly be screwed up for 3 years? INS updates are a bread-and-butter task of flying this aircraft.