Flagrum

Your guys really don't get what "optional" means.

As I said, I like to have options - to explore "what if" scenarios. The nice thing about options is that they are not mandatory. You (and the server, the mission maker) can choose to use or not to use it. A "reasonable" indication that a system or weapon would technically work would be good enough for me to have such an optional feature. The Sea Eagle might be debatable, but as for the LGB, I would have no issues at all. But for you, everything that gets implemented, has to be documented in official papers beforehand, right? No options, no educated guesses. You would probably also not allow to strap thermal coated navy MK-82s under a A-10?

That is not necessarily a direct consequence of the tests - we don't really know the actual outcome of the tests, do we? Maybe the decision was not made as a direct result of some negative technical tests. Maybe they decided to not use it as, i.e. the whole system of airframe and missile was not suitable for the needs (range? costs? doctrine?). I mean, if we want to be precise with what we have in our sim, we should also be precise with our argumentation! :smilewink:

What do you do with C# in DCS? Without the SDK you won't be calling any API functions anyways, be that in C# or more likely C++.

I don't know if that is the official stance of ED in this matter, but you are right, the DCS Viper can not load MK-83. I don't know anything about the missiles, but if the only reason why nothing, of what you mentioned, is available for the DCS Viber "because the USAF never used it", then something is wrong with this sim, imho. If there are technical restrictions/incompatibilities, I fully support to not allow such fantasy loadouts. The moving map requires a different software version, the missiles also need specific software and probably different rails? And even the MK-83 might require a software change to accomodate for slightly different ballistics compared to MK-82 and MK84. If not, then I would find it disappointing to not have it included for the DCS Viper. In general, I am "pro options", as long as this doesn't contradict the physics/technical reality and I can't understand why someone finds it desireable to artificially restrict the capabilities of what could technically be done. And btw, the argument "XY never used it" is really flawed: the Viper was also never used with Flagrum on board - and yet I sit here, 5000 ft. above Georgia ... :smilewink: edit: the C-101 does not have any CCIP/CCRO capabilities, no software involved. All there is to it is to hang the weapon under the aircraft. It can carry the weight, it can release the weapon - all technical requirements fullfilled, correct? edit2: one could argue, that it is technically possible to strap a pig under the Viper so we want that implmented! Yes, somewhere someone has to draw a line of what will be implemented and what won't. If ED says, we can not implement every weapon that one can think of, even if they would be technically feasible, then that is a valid point. It would have to be discussed, if a certain unconventional loadout should be available or not. But MK-83 and LGBs are not really that uncommon ...

It seems that you missed the real life part here: DCS simulates the aircraft, not a specific airforce or their doctrine of how to use it. So if it is technically possible, what is wrong with letting us do it?

Do you think that people who don't bother to look up what has changed when an update was released will care about it more if they find it in their mail inbox?

I was asked if I were being sarcastic. Well, I thought I was - until I saw this: I think, Razbam should reconsider this. They don't have to work on the Public Bugtracker, but to save some work, the community manager could import it to their official bug tracker. ... erm, o wait ...

How does a downwind approach (i.e. with the wind) mask your audibly? The wind will transfer the noise towards the target, making the helo easier to hear, right?

You just killed an innocent wife and child instead of the evil war lord. ¯\_(ツ)_/¯ It means that it is dangerous, when it comes to weapon systems.

I went through the mentioned threads, but I might have missed it: what function does the FLIR/FOV switch perform with an MAVE? What Harker said, makes some sense to me: but does not apply to MAVEs, as there is no FLIR and afaik no FOV (maybe search pattern/volume?) that could be changed?

I know. But back in the day, we also had to walk to school, with bare feet, through the snow storm, uphill on both ways - to and back from school!1

+1 for Syria map on cassette tape for my SCSI Datasette!

Yes, perhaps the system was not perfect, but maybe it was not the idea behind it that was wrong. Maybe it was just lacking some balancing, i.e. to avoid "rep tanks" with 100 times the rep power than any average community member. Iirc many of such rep tanks got their ... fire power in the early days when gaining rep points was easier / too easy. But ok, maybe balancing all aspects of the old rep system would be as much as a task as balancing PvP in DCS ...

That was a part of it, imo, yes. And I liked it that way. But I considered myself as, hrm, "responsible repper". I tried to spread +rep generously and -rep only very deliberately in very special cases. The idea behind this was to make it easier to recognize posts of members that have proven to be an asset to the community - and to warn people of trolls and other kind of overboarding negativity before they spend too much time of not only reading but maybe even trying to argue with such individuals. Even for the poster himself it sometimes seemed to be a wake-up call when they saw their own rep and realized that maybe they were it who were on the wrong track ... In the end, a red box or a green box was never a dead end road. But, yeah, for proven trolls it sometimes involved a bit of work to get rid of that embarrasing red dot and others didn't really care. Unless they were so embarassed of themselfs, anyone could still keep posting anyways. It had in the end no real consequences.

Ok, that makes at least some sense then. Thanks for clarifying!

why does PTRK not update the designation? That makes it completely useless - what is the point of having the TGP watching a target move around if I can not do anything with that? If I PTRK a stationary object (i.e. building, whatever) it does not matter much as the AG designation and the PTRK reticle coincidence. But how would I, if not drop an LGB onto a insurgent scooter, but lase it for a MAVE?

Considering that your question is off-topic in this thread, you're probably right. :thumbup:

It's a structured collection of issues that were reported. If they are actual bugs, fixed bugs or "[CORRECT AS IS]" remains to be evaluated. For that, an organized list is in any case far better than just scattered forum posts in different sub-sections, many of them burried many pages deep in the forum's past.

Thanks for that! The splitting of the Bugs forum into "Problems and Bugs" and "Resolved Bugs" several months ago resulted in a huge mess. Many unresolved and even not acknowledged bug reports were dumped into "Resolved" and never made their way into the public bug tracker. Then bkthunder pulled off the enormous feat of collecting and organizing these bugs and provided the community with their own bugtracker: https://forums.eagle.ru/showthread.php?t=269108 Please use this as your starting point. And if you require help, support or really anything from the community, just say so. I am pretty sure that here are still Harrier fans here around that are willing to help. All it needs is some ... communication. ;)

Check the public bug tracker - seems that there is not much left to do for the Harrier ......

Just use your mouse?

Thanks for the reply, Bignewy! But I am not sure I understand what you mean here. How do I "change the offset(cursor?) to ATRK or PTRK mode"? Earlier you said "The offset cursor should only ground stabilise once designated." and I confirmed that this was infact the case. What you see in the .TRK is: - I slew the TPOD to the taller building - I designate with TDC depress - I switch to PTRK mode - TDC depress to get the offset cursor - slew offset cursor to the shorter building - TDC depress to designate Result: video feed remains stabilized at the point of the PTRK reticle (as I would expect), but the offset cursor is fixed to the absolute position on the MFD. It does not remain at the designated point as the aircraft gets closer and the video feed gets enlarged due to the changing aspect(?, FoV?). While the TPOD's video feed is stabilized (ATRK/PTRK), I end up with an offset cursor that does not coincidence with the designated target (and nor does the PTRK/ATRK reticle any longer). This can not be the intended way of how the offset cursor works, right?

Ok.