LastRifleRound

Op is correct, Viggen wind correction is backwards. See the posts re. BK90 wind correction in this same forum section.

Yes, at low ambient temperatures with correct qfe set, the target waypoint will appear under the target vertically. You can tell it's under the target as when you fly over, the waypoint and target will align as the parallax resolves itself. You can tell it's a bug in display only because if you bomb the target in NAV mode, the bombs will land dead on. I can furnish a track or video if need be.

Known issue. Toss will always fall long. If you look at the youtube tutorials that are out there you will see that they all fall long, too. Been trying to get stuff like this stickied.

Correct. This is a known issue I'm trying to have stickied among others

Very cool

Viggen puts the string dead center with 16 bombs

God bless. Hope all turns out well for them.

Holy crap you have that modeled way deeper than I would imagine. That's top work. ::thumbsup::

Still think this forum and the other devs should have an incomplete feature list and a bug list. Even if it isn't tracked any more than done/not done. It's annoying piecing together what actually works in a module before purchase. It's almost impossible to know for sure what it is you're getting and I think that leads to a lot of frustration. These guys have really picked up the pace, though. I think bringing on another dev is bringing good things to RAZBAM and I'm excited to see what the next few months bring.

Good stuff. Does the bug tracker have CCRP falling long and INS update behavior on it? I never saw it mentioned anywhere as an official thing that needs fixing, but they are well-known bugs that definitely need correcting and have been with us for years. Not being able to bomb level is an issue.

Not everything in the bug tracker needs to be public. I would allow for some features/bugs to be private.

I will have to test those switches. I had some out of town meetings today so didn't have time to fire up the Viggen and test these out for myself. What exactly is the issue with the radar at 60km? You say "graphics", do you mean frame rate, actual screen artifacts, or some other thing?

I think a standardized forum format, maybe make a bug tracker with an API into the forums to standardize how bugs and missing/incomplete feature are tracked would be great for devs and clients alike. Basically, whenever you log a bug in your internal bug tracker, or set up your initial feature list, you add some DB columns for the public-facing component, that automatically gets posted to the forums or some other official DCS area. Kind of like an easier to swallow kanban board. We are using this approach for our software applications and have seen a positive response from our users. I agree, social media is NOT the place for this sort of thing. Not everyone is on FB and even if there were the competition for wall space is fierce. I for one loathe the platform and only exist on there because my business dictates I be there.

I'm not sure why most of the forums here don't have a sticky for the planned, yet missing features or bugs. I see many bug reports or questions on these forums for things that either aren't yet implemented or have been acknowledged as known bugs. I think it would also help those making a purchasing decision on deciding whether or not they want to dive in to an aircraft by seeing a complete, honest assessment of what has yet to be added. I will list some things here, and as users post updates I will keep it up to date. I will wait a day before adding anything posted to allow time for testing and other users to confirm something really is indeed a bug or missing feature, as false reports are inevitable. Further, I will try to logically categorize these things as best I can, but the categorization will change as things are added to better suit the totality of the reports. Weapons delivery -Toss bombing drops long every time regardless of G pulled or other flight parameters -BK90 wind correction is backwards -No wind correction for PLAN, DYK, NAV, RDR bombing modes -Cannot set BX8 point for RB15f in multiplayer -DYK sight now exhibits odd behavior, "crawls up screen" as opposed to allowing stable designation. Need developer confirmation if this is intentional, as it doesn't seem like it, and that update only listed changes to PLAN, not DYK. See this video for it's implementation before the July update that changed PLAN bomb sight behavior and compare it to current behavior. Also note the steering order starts from the bottom and moves up like it should. Now it starts from the top, making it useless: Skip to 4:39 Switches -Magnetic Declination does not move -Roll Trim Center inoperable -Rudder trim pin missing I know I'm missing a lot, just trying to get this started. I'd like to start on of these for the AV8B next once we stabilize the Viggen. With the recent announcement of the Viggen coming out of EA in Q4, I think it's important we track what is going on. I will check this thread twice daily and hopefully if the mods think it useful they'll sticky it for everyone's benefit.

I was thinking about picking up the NTTS map, and the red flag campaign for it. One of the things about the Viggen is, if you fly low in the Caucuses, you never really have to update your nav system. The terrain is so varied I rarely am ever out of status 5 for very long when flying < 800m (I'm usually at 200m or less anyway). I am wondering if the desert maps require more careful planning, as there are expanses I'm sure that are relatively featureless as far as terrain is concerned. Is this your experience? It would be a cool challenge to have to wrestle with the radar to get an accurate nav fix.

Radar can be pretty accurate in DBS2 if you have a prominent enough known offset to the target. Rarely are you lucky enough for your target to present well on non-SA radars, but DBS does make prominent features easy to target such as bridges, large structures, prominent geographical features, etc. much easier to spot and precisely designate. Not as good as SAR but it should work in a pinch.

I'm with Harli on this one, I think it's a long way off, but there are enough features now to require a comprehensive manual that can be updated as new features are added.

I can confirm this. All retarded bombs fall long. Also if AUTO is entered from CCIP the same thing happens.

I'll throw my thoughts in here, and I believe they mirror a fair amount of other users around here. I want to be clear I'm quite happy with the Harrier, I think it's in FAR better state than the Mirage. It can actually accomplish most of its missions without hitting a single bug or incomplete feature. The JDAMS looks incredible and far more detailed than I expected, very impressive. However, we have no idea when we will see it, and you just said other fixes are in a holding pattern. Since we have CCRP bombing, why not FINISH CCRP (or AUTO) and do dive toss and make sure it hits moving targets? Why abandon it to start an entirely new module? As a developer, it is often far faster and makes for a much better UX to FINISH a feature, before moving on to another. There may be some bugs, but actually FINISH the feature. It doesn't seem like development is broken up this way, and it causes this perception that the development is progressing in a haphazzard manner. I'm not saying it is, just that it LOOKS that way. The Mirage may be having an MLU, but I know for a fact that horror show of an INS update system will be abug with the new systems. That is an ugly, ugly bug that will need to be fixed no matter what the ADA tells you, same goes for the bug in CCRP delivery. Why would you redesign the radar, when 3 whole mission sets are impossible without sim-breaking bugs in this aircraft? To an outsider, sans an explanation, it's just illogical. Anyway, I'm pleased with the changes RAZBAM made this summer. Getting Elwood onboard, the big bug purge of the Harrier earlier in the year, were all great moves forward. I just think much of this could be avoided with either a different communication strategy or a different implementation schedule. Again, great work so far and I can't wait for those JDAMS. Looks like a hardcore recreation. :thumbup: PS If the dev team would like to PM me, I'm happy to help for free should they need someone to squash some bugs. I'm well familiar with versioning (git) and .lua scripting, though my experience these days is mostly in web applications.

@zeus, this looks really well researched, and your aircraft is the only one with simultaneous drop modeled. Kudos to you and your team for this. It's much more than I expected when you said you were going to implement JDAMS. My question is on terminal attack parameters. You said the pilot is only able to select fuzing. Is it possible to set the attack parameters in the mission editor, or will this feature not be modeled?

Relative mode is a different JDAM mode altogether. As long as the target's position relative to the aircraft is accurate, a resulting bomb drop is accurate, despite any errors ownship has in it's own positioning. This is the data a JDAM COULD use. JDAM doesn't JUST use absolute coordinates. It is capable of using translational data to cover a known slant range and bearing from ownship to the target without knowing the absolute coordinates of the destination. The problem with the Harrier is a programming error in TPOD integration means some versions of the Harrier do not generate relative data, rather uses the TPOD to infer a set of coordinates and uses absolute targeting, meaning ownship errors are carried through to the targeting solution, and JDAMS are used in an absolute manner. All aircraft when generating realtive targeting info suffer this inaccuracy, not just the Harrier. Corrective measures now allow TOO type (relative) operation of JDAMS. Since we do not really have a specific variant of the Harrier modeled (it's a "FrankenHarrier" we have modeled), it's difficult to predict whether this feature will be implemented. Here's a great paper I found on the subject if you're ok with some academic reading. https://pdfs.semanticscholar.org/2915/792e3b6b0e3772bb61c35e3a336311e7887a.pdf EDIT: Jeese I just read the post before mine and saw the same two links shared. Consider my post supplemental and I apologize for the redundancy

I'll repeat my Hornet post here, since I believe it's relevant. Does the Harrier support programming azimuth and impact angle, and the resulting dynamic launch zones?

Yeah rockets in general (especially MPCM types) would be fare more useful if DCS did a better job modeling this kind of damage.

This is my main gripe with these EA programs. I'm hopeful for the JF17 as it seems they went the opposite direction

It's a little more involved than that, but yes. The impact heading and angle need to be finished first, or the concentric circles are the correct symbology. Here is a video of the WIP JF17 from Deka Ironworks. At about 4:12 in you can see the pilot enter the azimuth and impact angle, and the symbology in the HSI reacts accordingly. My understanding is this is exactly how it works in the Hornet.