Flagrum

:huh: Click at Aircraft icon on the left hand side, select A-10C II from drop-down on the right hand side, click at map to place it?

For me it really depends. Ka-50: flies really nice, but it is not a "typical" helo. I love systems and avionics in general and the Ka-50 has also plenty of that. Fighting in the Ka-50 is awesome. Huey: iconic helo, flies very nice. Not many systems, easy to learn. Fighting is different here than in the Ka-50, but tons of fun as well. Mi-8: also iconic, flies very nice like a bus :-). Can hand out a punch as well and the magnitude of different avionic systems is heaven for me :D Gazelle: some unique and interesting weapon systems, avionics are quite straight forward. Flying characteristics: I won't comment on that until Polychop implements their promised rework of the FM. I can't, for myself, really distinguish between "fun to fly" and "fun to fight in". It goes all hand-in-hand. But if you insist ... most fun to just fly is probably the Huey and the Mi-8 - one being much more nimble and "hands-down" and the other more like a school bus - whith all it's own interesting peculiarities.

Yeah, a different name is a serious requirement which would make them, without it, totally inoperable. Probably the whole aircraft would blow up. Or maybe it is just to help the pilot to select the correct variant if also regular rockets were loaded? Or perhaps even to tell the SMS that auto lase is an option for this kind of weapon? There is still no technical necessity to have anything of that available on the aircraft, but of course it makes life easier. (btw, noticed how the RKT reticle is still the original one? The rest of the SMS and the aircraft still sees them as dumb rockets ...)

Are you confident that your delivery procedure is correct? By that I mean are you using the correst/best method for determining target elevation? We now have AGR and if that is not used, over uneven terrain, BALT or RALT might (now) result in a less accurate weapon solution.

Problematic here is that those internal definitions are carried outside and are applied to, i.e. the product status on the ED shop page. This is where internal defintion and external definition clash the most prominently. I fully agree here ... except with your very last sentence. Things are even more confusing, as there is even a mismatch of what the "normal" definitons of these terms, outside of Razbam, mean. Even ED uses them somewhat in an unconventional way... Perhaps it is really not feasible to expect the DCS devs to use the "usual" terms - even ED can not jump over their own shadow and apply them to their own products properly. Thus we now have "Early Access" and "Sustainment" of which neither defines the milestone "feature complete". But at the very least, the same terms and metrics should be used across all DCS devs - as their producs all apper side by side on the ED shop page.

I don't know the exact differences between how the real Viggen radar works and how the real Hornet radar works. But the term "raycasting" refers to the software technology used to simulate the Viggen radar in DCS, it has nothing to do with the real Viggen. I don't know the details, but raycasting is probably trying to replicate to some extend how radar waves work in RL. It projects/casts a virtual "beam" to one point on the ground and if that beam intersects with either an object or the ground, it is represented on the radar screen visually as some sort of "radar return". Then the next beam ist cast to the next point on the ground, etc. until all points that are within the radar limits are tested.

Maybe because OP is interested in a West & East Germany map.

Es ist nicht so sehr die Frage, wie die Wetterdaten in die Simulation kommen, sondern was die Simulation damit macht.

Building your own random number generator is a bad idea. It will break the track file replayability as your mission scripting code will behave differently when you fly the mission and when you replay the track. I bet, there are solutions for this, besides the various randomizing methods that the mission editor itself already provides. You might want to research the DCS mission scripting in LUA capabilities in general and the existing scripting frameworks, for example using MIST.

Wags states in the feature list that the AN/ARC-210 will come later after the initial release of A-10C II. This indicates, that the new radio is more complex than just a few selecors/dials and LCDs to set the desired frequency. I assume, it is pilot-programmable of some sort? Where can I find more details about this radio and it's capabilities?

Erm, that is a given, isn't it? Elmo, that IS a given, right? You do work internally with a bug tracking solution?

I assume, Elmo wants to establish a procedure for the future. The Community Bug Tracker is a good starting point, but needs to be replaced with something more, hrm, usable. Bkthunder put an enormous effort into collecting and structuring the existing bug reports, but an Excel list is not really maintainable in day to day operations.

I would assume, that the bomblets are simulated all the same, no matter if visible or not. To observe visually the outcome if you set effect = count might be difficult. Even if your computer can handle it (slideshow during the explosions was the reason ED reduced the visual effects back then), the visual effects are quite large and will probably obscure the actual hit point quite a bit. But maybe it's worth trying to investigate it further with TacView? Does TacView show individual bomblets? If so, only the visible ones or all? Maybe try this (or I will this weekend, hrmmm): build a target area with targets tightly packed so that every bomblet should hit something. We should get a hit count per target/vehicle and could calculate the actual bomblet density if we know the (top)surface area of each target/vehicle.

Afaik the visual effects are reduced to 20, but simulated are still all 247 bomblets. That is at least how I interprete the bombs_table.lua: cluster = { [color=Red] count = 247, effect_count = 20,[/color] wind_sigma = 50, impulse_sigma = 2, moment_sigma = 0.0001, }

Ok, now I put some thoughts into this. My suggestion: Keep it as it is - but better. Bug reports of other modules are tagged with something like [reported], [no bug], [investigating], etc. When this was established a few years(?) ago, it was a substancial improvement, but it was and still is not perfect. Good is, that one can see right way if a thread was seen by the testers/developers. Also good is, that a tag like [reported] helps the community to shift to other issues, knowing that this bug report is already being taken care of. But other module bug forums still have some inconsistencies. For example, sometimes nothing but a tag is added to a bug report thread. That is not enough. Tagging a thread should always be accompanied by a respective posting in the thread. That way, the chronolgy of what happened is preserved. For example if new evidences for a bug appear after the thread was tagged [no bug], or if a .TRK was provided after the tag [track missing] was added. Without preserved chronology it is even harder to get the attention of the testers/devs back to such bug reports. Also, in other bug forums, threads get sometimes closed after receiving a "final" tag. This is also very contra-productive (see example above). Helpful would also be a reference to the internal bug tracker - not for us, but for the testers/devs. If a bug report is tagged [reported], it should be accompanied with a posting in the thread, stating the bug tracker id. This makes it easier to cross-reference them (as opposed to some probably obscurely abbreviated bug report titles). You can jump directly to your bug tracker entry from a bug posting and you can also navigate from the bug tracker to the posting by using the forum search function with the bug tracker id (if you haven't copy&pasted the url). And finally, for now, define a consistent set of tags and use only those. For example, use only one of [track required], [track missing], [no track], etc. Using consistent tags and preserve the chronolgy within the threads is way better than moving threads around between subforums as more information is preserved. Use bkthunders community tracker as a starting point. And once trust is re-established in this procedure and bug reporting in general, people will dig up older bug reports that might now get overlooked in the initial phase of reorganisation... I can imagine, this is a huge task, looking into every bug report and so on, but this has to be done either way. Hopefully the backlog of bug reports gets smaller fast so that everything will be a bit easier to handle.:thumbup:

I have not yet made my mind up on this topic. But I want to urge very strongly that nothing gets deleted here! If the "clean slate" approach is to be established, then only move the old bug reports to a (read-only) subforum so that they still can be searched and referenced. Do not delete anything.

Der Bugtracker spiegelt nur die Situation wider, wie sie in den verschiedenen Bug-Subforen vorzufinden ist. Es kann doch niemand erwarten, dass jemand, der viel Zeit und Mühe investiert, um dort etwas Struktur und Übersichtlichkeit hineinzubringen, auch noch dafür verhaftet wird, auch ja jeden einzelnen Report zu verifizieren und regelmäßig nachzutesten. Es war und ist Razbam's Aufgabe, da für Ordnung und Fortschritt zu sorgen, und eigentlich nicht die von freiwilligen Helfern der Community und Kunden. Ein Bug ist gar keiner, sondern ein DAU Fehler? Kein Ding, einfach "[NO BUG]" getagged und gut ist. So, wie es in den allermeisten anderen Bug Subforen auch passiert, wo auch alle Nase lang Nicht-Bugs geposted werden. Oder wie immer Razbam das sonst organisiert hätte (Decoy alleine hat da leider auch nicht viel gebracht, tbh). Der Bugtracker war nie dafür gedacht - und mMn auch nie dafür benutzt worden - um Razbam schlecht dastehen zu lassen. Die Bug Reports an sich und wie Razbam damit umgegangen ist (oder eben nicht damit umgegangen ist), sind es, die Razbam schlecht dastehen lassen. Und ob da nun von 190 Einträgen nur 180 oder vielleicht nur 100 noch echte offene Bugs sind, ist da nichtmal so wichtig. Auch 100 echte Bugs wären noch 10x mehr, als zuletzt noch im Razbam Bugtracker als offen gelistet waren. Wir haben nun also den Bugtracker als Zusammenfassung des Chaos, das Razbam in den Bug-Foren hat entstehen lassen. Hätte es den ach so schlimmen Bugtracker nie gegeben, dann hätten wir jetzt was? Das Chaos, das Razbam in den Bug-Foren hat enstehen lassen! Und das wäre dann so viel besser?

Ticket Alter ist eine durchaus nicht unübliche Metrik. Was hilft es z.B., wenn bei gleicher Schwere eines Fehlers immer nur die neu reingekommenden abgearbeitet würden (z.B. weil's einfacher ist da man sich nicht so lang zurückerinnerm muss, etc.) und damit die alten Bugs aber nie gelöst werden? Du sagst also, was bkthunder da gebaut hat, war eine gute Idee, nur er und/oder der Rest der Community haben es verkackt und zu einem "hate tool" verkommen lassen. Richtig so in etwa? Wäre es dann also besser gewesen, keine Initiative zu zeigen und Razbam unkommentiert weiter vor sich hin wurschteln zu lassen, nur damit ja niemandes Gefühle verletzt werden? Ich sagte bereits, dass der Community Bugtracker nicht perfekt ist. Aber deine Sicht, es würde nur hate gegenüber Razbam fördern halte ich immer noch für eine polemische Übertreibung von dir. edit: gepatchte bugs werden vermutlich nur nachgetestet, wenn es einen Hiweis darauf in den Patchnotes gibt. *shrug*

Der bugtracker war has hilfsmittel gedacht, mal ein MINIMUM an struktur in die über zwei subforen verteilten bug reports zu bekommen. Nicht um mit Fingern auf Razbam zu zeigen "bäh, guckt mal, alles kaputt!", sondern um sie dazu zu bringen, endlich mal farbe zu bekennen. Zuletzt war im Razbam Bugtracker etwa 5-6 offene Bugs für den Harrier verzeichnet. Klar, da ist es einfach zu sagen "wir sind so gut wie fertig". Mit dem Community Bug Tracker wäre es nicht mehr so einfach möglich, die hälfte offenen Bugs in "Erledigte Bugs" subforum zu verstecken und den Rest nur widerwillig in den Razbam Bugtracker aufzunehmen (hab sogar bisserl Verständnis dafür - wer will sich schon duch den seit monaten angehäuften wirrwar von bugs und postings durchkämpfen? Na, außer bkthunder vielleicht ...? Der community bugtracker ist bei weitem nicht perfekt, ganz klar. aber 100 mal übersichtlicher und besser, als das, was wir bisher bei Razbam hatten. Das manche dort gemeldten Bugs gar keine sind - klar hätte das z.B. von dem meldenden - oder jedem anderen in der community, der darüber stolpert - später per update an bkthunder korrigiert werden können. Hast du bkthunder zu deinem lieblings nicht-bug eine PM geschickt?

Hate Tracker? Das ist doch ausgemachter Blödsinn, sorry. Dein erster Link zeigt auf einen "Correct as is" Bug-Report der vor offenbar einer Woche geklärt wurde. Beim zweiten Link hat sich das Problem anscheinend vor 2,5 Monaten geklärt. Das bkthunder nicht jedes Posting in all den momentan 192 erfassten Bug-Reports einzeln durcharbeitet, nachtestet - und nach Möglichkeit auch noch tagesaktuell nachzieht - ist für dich "hate"? Oder meinst du hier eher, dass ein Anfänger besser keine Probleme ("hate"?) reporten und besser still sein sollte?

It might sound alien to you, but there are people out there who love to read, especially if it is about something they like and love. "Studysim" is actually a thing. How can you tell the operating limitations of your aircraft? Without a manual, this academical nerd question will become quite interesting quite quickly if you try to land on a carrier with dry tanks and yet some ordnance under the wings? Good luck finding a YT video for that. Also please consider, while it might be ok for you if product features are not delivered, others might have a different view on this. (semi-OT, @mods: can we have the rep system back ... please?)

But you know that DCS is a flight sim, right? (yes, I know that there is Combined Arms ... ) Anyhow, map is too big, that's probably the first time that this was said on these forums...

Advertised was a manual and a pocket guide. There is currently no manual, only the pocket guide exists - which is lacking a lot of details and complete chapters to be considered a proper manual. (and is probably too exhaustive for a mere pocket guide).

The thread was only a tool to help bkthunder managing the Community Bug Tracker. The Community Tracker is only listing bug reports that are already posted here on the forums and the thread was sometimes used to help focussing on what is going on on the forums. No bugs were (exclusively) reported directly in that thread. That said, if now proper handling of forum bug reports will take place, then this might not be much of an issue (time will tell, I guess), but it would also not do any harm if the thread could be reopened again. (PS / OT: thanks & BIG props to bkthunder for putting so much efford into this! VERY much appreciated!)

Thanks for the assistance here, but unfortunately that is not correct: The actual manual is missing, only that so called Pocket Guide is available The existing documentation lacks a lot of details and even whole chapters. The TPOD consists only of a few sub-headings and is otherwise completely empty! It has 125 pages in total. To put that in perspective: the Fw-190 manual has 181 pages, the (ea!) manual for the P-47 has 216 (201 without the sponsors list) and the CC-101EB has less pages, 118, but that aircraft has no combat related system (C-101 has 155 pages).