Flagrum

Nice! Embedding YT Vids now works without any special handling - just copy&paste the complete link into the editor!

I can't edit my old postings made prior to the forum engine update. But maybe I can edit at least newly created ones? edit: yes, I can!

When an issue is reported, they are tagged by Elmo to assign them to a certain category. Most of those tags are self-explanatory: [REPORTED] = a bug is acknowledged and is scheduled for fixing; [uSER ERROR] = this is not a bug in the module, but the user was using the feature in a wrong way or under wrong assumptions. And so on. But there are a few others where I am not so sure that I understand them the same way as Razbam. Specifically I struggle to understand the difference between [NO BUG], [AS INTENDED] and [FUTURE IMPLEMENTATION]. NO BUG seems obvious: the reported problem is not caused by a bug, but the feature is working as in the real aicraft - which might be very well be a bit quirky. And FUTURE IMPLEMENTATION means for me, the reported problem is due to the fact that the feature is not finished, yet. It is WIP, but will be working as in the real aircraft at some point in the future. But now, how does AS INTENDED fit in-between(?) here? How I read it: the feature is working the way Razbam want it to work. But it might not be the way it works in the real aircraft. Otherwise it should be tagged NO BUG. But as it is also not tagged as FUTURE IMPLEMENTATION, I am now worried, that it might never be working as in the real thing. Which, for certain type of problems, may be very well be acceptable of course. For example when it comes to certain technical (or legal) limitations of what can be done in DCS. But there are many problems reported and tagged like that, where I struggle to see any valid reason. So, is my interpretation of what the tags mean correct? And if it is, can we have at least a brief explanation of the decision to not implement a feature, as it would be in the real aircraft, in the respective problem report threads? Or did I get it all wrong and AS INTENDED is just a different wording for WIP/FUTURE IMPLEMENTATION? Some clarification from i.e. Elmo, would be greatly appreciated!

No. Ask again in 10 years.

You want your VR recorded tracks as if they were not recorded in VR? Why? I mean, perhaps VR is not the best option to begin with if you want to record some Glowing Amraam style footage? Changing the environment for the replay is problematic, be that an other aircraft in the same flight (you, flying formation with the recorded aircraft) or different weather. It potentially or actually changes the flight parameters that the recorded aircraft has no knowledge of. It will crash into you, or be blown off course, or whatever ...

It's better now as now progress is visible - thanks to Elmo, but also very much thanks to the devs.

Are we confident that the missile should not loft - at all? I mean, it should be possible to get at least a rough estimate of the range as the slant angle and current altitute should be known. Also it should not be necessary to go straight down to the target. Instead the missile could try to keep the target near the lower edge of the seeker FOV and align more precisely as it gets closer to the target (i.e. as the rate of the slant angle change increases; similar to ARBS).

I had experienced something similar, but haven't had the time to investigate it futher. But at that moment, it seemed to me, that slewing the TPOD was using the world coordinates of the target point as reference, and not the screen coordinates of the display. This was very confusing, because as you fly the relation of target point and aircraft was constantly changing and thus was the direction of the TPOD movement when using the same slew control.

One aspect might be, that this content has to be mainainted. As DCS evolves, things change and this community content has to be adjusted as well in order to function properly. Skins depend on the 3D models, 3D models themselfs need skins/textures, which also depend on the rendering engine, etc. Who will, reliably, maintain this content, once it is included into the base game?

This thread started in the FA-18 subforum? Now it is under the Mods & Apps subforum?? --> This belongs into Chit Chat, tbh.

In theory (I am only guessing here), gyro stabilized should keep the vertical and horizontal axis of the sensor fixed in relation to the earth(horizon?). Ground stabilizes then should keep the sensor pointing at the same spot at ground elevation. The difference would be the moving aircraft. When ground stabilizued, the horiz. and vertical angle of the seeker would compensate for aircraft movement, but gyro stabilized would not. Example: you point the seeker directly in front of you, 45 deg. downwards. Gyro stabilized would keep that 45 degree angle and your pipper would move as the aircraft moves forward. When Ground stabilized, the initial angle of 45 degree would get bigger as the aircraft moves forward, keeping the pipper at the initial point all the time. Depending on the course of the aircraft, the position + distance of the target and the duration you are observing this, it might be plausible that you would not notice much of a difference.

I would assume that this behaviour is correct. You don't assign the TDC to the DDI, but to the sensor that is currently active on that DDI. I would therefore also assume (but haven't verified this, yet) that after you switched to a different sensor and then go back to the first sensor, the TDC should still be available there.

It's all less functional than before. With the old style, you could see everywhere which thread in which subforum was posted in last that you haven't read yet. Now you have always to navigate to at least the thread list to see that. In the forum overview, you see the last posting in that section, but you don't actually see in which sub-forum it was made. That's a bit pointless, imo. I used to skim over all subforums by just looking for the latest posings in thread that I might find interesting. Now I have to navigate in and out of each sub-section ... Directly jumping to the last not yet read posting is not available everywhere. I guess, this will be fixed soon...ish. In the News section and here in Customer Support, you only see the name of the last poster in a forum or thread, but you have to hit a 4x4 px icon to go there (instead of just automatically getting there by clicking the thread name link).

No mobile-style giant icons, true. But several features that were previously available automatically are now only available by clicking a tiny icon. For example, accessing the last not-yet-read posing in a thread was the default for the link behind the thread title. Now you have to hit that - what is it 4x4 px icon in front of the thread title. :( Why would anyone want to default to go to the beginning of a threat? "last not read posting" was soooo much more usefull ... Or the last posting in a thread was accessible at the forum list and the thread list by clicking at the last poster link. Now this is also available by clicking an other tiny icon. edit: "first not yet read thread"-link is actually available like it was, but not everywhere. It does not work in the "News" section and not here in "Customer Support".

This. Afaik the WCMD are INS guided. That means they actively steer towards the designated tgt - even if wind tries to blow them off course. But once they released the submunitions, there is no INS anymore, only dumb bomblets.

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?