okopanja

Hi All, As promised elevation profile has been implemented. Feedback in form of bugs/improvements/ideas is appreciated. v1.2.0 What's Changed Added elevation profile chart by @okopanja in #50 Shows elevation profile along lines connecting waypoints. Green area represents ground, blue represents sea. Elevations are sampled at 1m step Averaged for display reasons with math.max function. we can not show each m of route, so for given minimal display interval the highest value is selected. At least one waypoint must be added (or 2 in case CA JTAC) Each waypoint is represented with vertical dashed white line with: Ordinal number at top Altitude (m) below top Distance (km) at bottom Automatically updates on add/remove reset waypoints. This process takes a second on my PC, please let me know if delays are to severe. Displays maximum elevation line with altitude in meters (red line) Displays minimal elevation line with elevation in meters (red line) Displays thousands of meters up to the next above maximal elevation Limitations: Text may overlap if waypoints are placed to close, while having many times more remote waypoints Made waypoint list more readable by adding shadow to the text #52 Made experimental button permanent, but concealed (not for end users) in #49 Full Changelog: v1.1.0...v1.2.0

There are old abandoned railroad tracks that re not in use in Paris anymore. it is not easy to access them nowadays, but they still exists.

I would expect that core 2011 works including slewing. I did not ask for iglas, although they provide certain fun to use. I hope the devs will find the way for this to work without endangering the realism levels.

I would not mix IRL and BS3 to draw analogies. For first we do no have actual block diagrams or really solid set of data on it. To me it actually feels as module itself was never finished fully. As for the BS3, nobody expects it to outperform Apache, but this is after all a $70 module, if there is a feature it should work within reasonable levels with limited period of time. It would certainly not step away from realism, since INU will cause the drifting and therefore decreased accuracy of slewing. At present this works properly only near the coast and at altitudes of 40-70m.

You can slew the to 0, and them move it up until laser designator shows expected range... You can also asume based on altitude...

Yes, this appears to be Rubikon originated, which makes me wonder why it has some features that do not work at all or not properly. E.g. steering shkval based on navpoint location to 0m is totally senseless. I do not expect to have the target locked, but at least it should be in the FOV of shkval, and not under ground. ABRIS actually looks into ID-6 device: "electromagnetic detector" and it looks into Rubikon K-041 See svg by downloading and opening into web browser (it has tooltips) for what I have gotten from lua files. google translate: Да, это похоже на Рубикон, что заставляет меня задаться вопросом, почему некоторые функции не работают вообще или работают неправильно. Например. рулить шквалом по местоположению навигационной точки на 0м совершенно бессмысленно. Я не ожидаю, что цель будет захвачена, но, по крайней мере, она должна быть в поле зрения шквала, а не под землей. АБРИС реально смотрит в прибор ИД-6: "электромагнитный детектор" и он смотрит в Рубикон К-041 Посмотрите svg, загрузив и открыв в веб-браузере (у него есть всплывающие подсказки), чтобы узнать, что я получил из файлов lua. ka-50.svg

FUD

Original: If this is true, why is then yellow designation showing incorrect ranges compared to IT-23, when the system knows precise position and ABRIS angles, I would expect to be able position yellow mark on top of target in ABRIS and have target roughly within the view of IT-23. Interesting it gets worse the higher the altitude is. Surely this is a bug? Google translation: Если это так, то почему тогда желтое обозначение показывает неправильные дальности по сравнению с ИТ-23, когда система знает точное положение и углы ABRIS, я ожидаю, что смогу разместить желтую метку поверх цели в ABRIS и получить цель примерно в пределах вид ИТ-23. Интересно, чем выше высота, тем хуже. Это точно баг?

Here a longer text on Yugoslav (Royal) Airforce within RAF. https://acesflyinghigh.wordpress.com/2016/01/02/yugoslav-air-force-combat-aircraft-1941-to-1952/

As far as I know, there was one change in damaged model, and things got improved. Still you can not hope to kill a target with a single shot. I made some "trolling" attacks on GS server some 2-4 weeks ago by sneaking undetected near Kutaisi. On average you need 2 to shoot down eagle (got one igla, got finished with vikhr), tomcat (survives single igla very well), warthog (took 2 iglas and crashed), hornet (can be killed by a single but usually 2 are needed). Sometimes even one works. E.g. the following did not work, but some 2-3 minutes later the dude did hit ground and kill got attributed. 4

Update: failed to fully reproduce with replay TRK file. 1. Failure: around 04:06 the high flying bandit to the right side was flashing at 2 Hz interval without being locked, in a replay this did not occur. You can see I flipped ranges while this was going on, in original it kept flashing. TRK is 40-50MB. 2. Partially success: at 09:10 you can see friendly F-16 making rapid turn. At some point it will point toward me, then briefly toward old azimuth (09:16-09:17) then back to normal. This could be also a lag artifact. In short: inconclusive, needs more careful watching... Forgot the video:

This bug is related to the bug with flanker DL, introduced with MT introduction. All airports disappear and even cycling through the selected airport does not help. Attached is the TRK-file demonstrating the issue in all NAV modes. @Flappie@BIGNEWY@BlackPixxel@PVNK@plasma1945 Bug-NAV-Server_1_Operation_Urban_Thunder_V7.4.5-20230520-225219.trk

The change is good only it needs to come from ED. Btw, stop behaving like a lynch mob.

Hi All, Maybe I am imagining this but I think we still have a problem. Please consider this unconfirmed until at least someone else confirms... I flew high and fast and had hot fast bandit (was f-16) flying high toward me and AWACS(I was 30-40 degree right off his axis, and awacs was on left of his axis). The Bandit kept appearing and disappearing at roughly 1-2Hz without changing aspect, but with position updates. Prior to that I had similar issue with other hot aircraft, but I attributed that to nearby furball activity. I engaged the high flying F-16 and killed him On the way back I saw friendly showing and disappearing all the time. Then it started showing different azimuths on each appearance. those were close to 180 degree, so I do not think he was turning. I have the TRK from GS server from about ~ 15 mintues and will replay and capture the video of it. It would be nice if someone could confirm if they have also also seen this behavior. I will try to replay the trk in the morning and recheck against what was actually going on with tacview. Also: the nav modes still glitch very quickly, I think I managed to capture 5 min trk for that, but need to replay it first.(will be reported separatly, just mentioning since it is related).

It depends, reality is not much different from your tacview. There was a longer version of video showing that last 2 launches were unsuccessful, but I can not find it now. The one before last did start flying and fell on ground. The last one ignited on ground but failed to fly. 6 persons who were publishing videos were arrested, so I guess there is an effort to remove the video from internet.

Presently for elevation map I am trying to figure out the way to optimally select vertical scale. Things to consider are: - 0m ALT line - minimal terrain altitude along route line - maximal terrain altitude along route line In addition I could consider some features that might be overkill, so no warranty I will actually do it, since they may have CPU impact. - Minimal safe altitude (e.g. terrain vs objects + measurement errors) - "safe" terrain following altitude - route corridor width (e.g. we can not expect perfect adherence to route plot, hence it would actually need to calculate several height profile in order to pick the maximal altitude on each distance).

For common flier: yes, this is loft. From the point of engineer: a rather interesting selection of proportional and dampening factors. If you look carefully into the graph it you will notice asymmetric shape of climb and descend section. nullnull

Dude read carefully what I wrote here. there is an explicit line in the manual.

Very nice article. It would be nice to publish a comment on each future significant update you make.

While I agree the drag was likely too high, but I kindly ask you to remain civil and stick to both the topic and the facts. Do you have some actual data on performance of these missiles? Since 90s I am listening about magic bullet that ends under-performing every time. In reality these systems did not prove themselves against the price they were sold to a number clients. https://www.airandspaceforces.com/article/1092scud/ https://www.cnbc.com/2017/12/04/patriot-defense-system-likely-failed-in-saudi-ballistic-missile-attack.html

LOL, looks consistent with IRL performance. It did not shine in 90s, and in recent Saudi-Hutis conflict. Although against aircraft it looks to have worked well, except IFF did not quite work as expected, so for better realism we may need that modeled as well.

Center-line: likely less drag.

You are correct in terms of end effect, but from pure technical point of view, this should not be called loft, and besides will usually work only in certain scenarios. Before the change that roughly coincided with HOJ fix, ER had been a guidance law which I would describe as used a simplified proportional navigation with range dependent proportional factors. After this change it appears the missile is actually using PID controller (proportional, integration, derivation factor). The guidance law defines the desired trajectory as a function. In case of the R-27 this is a straight line between missile and target. In case of AMRAAM/SD-10, depending on range this is either ballistic trajectory or direct line. What happens next is that PID controller measures the deviation from expected trajectory which is used to apply the correction based on P-I-D factors. Since R-27 originally had only P component(s), the end result was that any attempt at faking loft would result to immediate rapid correction and therefore rapid energy loss with no benefit. So back then we had to make sure we actually to but the dot into the circle. However, by selecting I and D component you can control how quickly the missile returns to the desired path and this is how lofting effect was produced with R-27ETER. It is worth to note that ET still uses the old system. so no lofting is recommended here. Here is not too much technical explanation:

Yes, thank you @Flappieand developers...

I played yesterday single session GS and it worked normally. Need one or more time to be absolutely sure. I did not realize how much this issue made things more difficult. Basically I was constantly switching radar ranges(and using radar on HUD), so I get briefly somewhat correct situation. Yesterday it was so easy. Meanwhile NAV glitches are more often(all airports are gone), but I will try to study that closer and file new issue.