Flagrum

Huh? :huh:

I think, I understand your explanation, but I am not convinced that this is unavoidable. The different speeds over ground - isn't that something the CCIP logic should take into account? I mean, isn't exactly that what the C for Computing stands for in CCIP? This seems a bit more plausible to me, but still, the delay between pressing weapon release and the actual separation of the weapon from the airframe - these are known parameters that CCIP should be able to take into account as well.

That is very interesting. (I hope, nobody minds if I test it here right away? There should be one empty line above this one, right? And no blank line above this.) edit: Thanks Frederf:worthy: Consider yourself +REPed! :thumbsup:

13lb is only the weight of the motor, according to wikipedia. So the weight difference is probably not that much, but yeah, still exists. But how difficult is it to configure the software of a modern aircraft to take a different weight into account? Is it more difficult than for the technican to enter two values (SMS id and weight) into the device that uploads the stores config to the aircraft? Or has the jet have to get a ROM and RAM upgrade, a new processor and flashing a new "SMS operating system" which will leave the aircraft grounded for 2 months? No, genuine question, what techniques are used to update the SMS information?

Happy Birthday, Deutsche Einheit!!

Post your DCS.log from your Saved Games folder here, please...

Are you trying to report a bug or have you just mistaken this sub-forum for the chit-chat forum?

May I suggest an improvement over OPs solution? How about a button instead of the input field for the laser code. Pressing the button opens a new window that allows to configure the settings of the weapon(s!) on the respective pylon: laser codes, pre-planned JDAM coordinates, and in general all kind of fuze settings (--> CBUs!). A separate window is probably easier to implement for the devs as the implact of such a change on existing code should be minimal and also allows for far more flexibility.

But you guys are using the latest Open Beta of DCS World, right?

: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: