Tiramisu

The hours I have spent flying the F-14 is by far more than with any other module. I am glad that Heatblur worked on this complex aircraft. Even at full price it is almost a steal to get so much content.

If you are in the RIO-seat yourself, it can be very quick, but I don't think there is a Jester command that makes him do what you are describing. If we could simply ask him for IFF in the crew contract menu, then we would also be able to get a quick respond.

I am not able to open your trackfile, but I think it is because usually a Doppler search on the DDD has a higher range than the TWS search on the TID. So this may be no bug.

I hope the new clouds will be able to merge with the horizon, when they are far away. At the moment the problem is that the curvature of the earth is not simulated and thus there is a gap between clouds and the horizon.

I have observed many times that the aircraft AI changes its goal in the middle of a fight by either going to another waypoint or pursuing a far away bandit while there is still another bandit nearby. Maybe it is because the AI looses sight on that bandit, but it can even happen when the AI has AWACS support. So what is the reason for this behaviour and how can you avoid it? I have tried out different AI settings, but nothing seemed to work with certainity.

Yes, it has happened every time I tried it and in different missions. You can reproduce this bug easily: First lock a target, then Jester will usually use PD-STT. Afterwards you tell him in the command menu to go to P-STT-mode and then you can tell him to go to PD-STT again. Once you have chosen that PD-option yourself, he will not revert back to the P-STT option as long as the radar lock exists, even when you tell him to do so. :thumbup:

+1 I think some of the sticky threads should be merged or put into more general threads. A content-thread with links in it might also be a good idea.

First of all I have found a bug: Once you have told Jester to go to PD-STT mode, he will refuse to go back to P-STT mode, even when you tell him to do so or even when you get so close to the bandit, that Jester himself says "Ok, switching to P-STT", without actually doing it. I have found this bug after checking the settings in the RIO seat myself. Secondly, I think we need three options to choose between P-STT, PD-STT and auto-mode even before we get a lock. At the moment you can only change the modes only once you have a lock. I would suggest to replace the "WVR"-menu with a "Aircraft Settings"-menu, where you can set those STT-modes. Also the "Aircraft Settings" menu would be a good place for the radar elevetion and azimuth as well for radar-bars- and radar-width-options, which are currently missing in the F-14, because the BVR-menu does not have much space left at the moment.

You could simply add a Jester command to make him immediately tell if a radar lock is friendly or not. Sometimes he really takes a long time to tell you. In case you have put him into silent mode, it would be also very handy to enforce him to give IFF information.

Use late activation for your groups first. Then activate them using a script with random values. So let's say you have 40 groups called "SpawnMe #001", "SpawnMe #002", "SpawnMe #003", ..., "SpawnMe #040" and you want to spawn each of them with a 3% probability. Then your code could look like this: for i = 1, 40 do local sNumber = "#" if i <= 9 then sNumber = sNumber .. 0 .. 0 .. i end if i > 9 and i < 100 then sNumber = sNumber .. 0 .. i end if math.random(1,100) <= 3 then Group.getByName( "SpawnMe " .. sNumber ):activate() end endI have not tested this code, so excuse me, if there are any errors in there.

You can try a workaround. It is possible to check how much flares/chaff an aircraft has. When it has too many of them you can send out a warning message that the aircraft will be deleted or respawned, if it continues having too many countermeasures. You need lua scripting to achieve this.

Can we check, whether the RWR of an aircraft detects a search- or a lock-radar signal?

Hopefully Heatblur will reduce those trashy callouts from Jester. It is so annoyingly unnecessary.

I am getting this when I use flaps and slats during combat. Not sure if it is because of the over-g or because of the overspeed. Would be nice to have more information about this, because I think it may be intentionally simulated.

Da sich Jester dauernd weigert selber zu radarlocken, setze ich einfach den horizontalen Dogfight-Search ein. Eigentlich sagt Jester einem bei solchen Dogfight-Locks fast immer automatisch, ob es sich um einen Feind handelt. Aber dass er dieses Mal so lange gewartet hat, bis er mir das IFF verraten hat, habe ich bisher noch nie erlebt. Es sollte auch vollkommen egal sein, wie man den Lock bekommt. Beim Buddyspiken sollte Jester sofort etwas sagen, vor allem weil er normalerweise bei Dogfights o eine Labertasche ist.

Normalerweise gibt Jester einem Infos über das IFF, aber dieses Mal hat er bei mir total versagt. Er sagte zu mir die ganze Zeit über seelenruhig: "Target 20 miles... Target 10 miles... Target 5 miles..." und erst als wir ganz nah dran waren und Augenkontakt hatten, hieß es "we locked a friendly". Zum Glück habe ich selber mit der TV-Kamera von weitem erkennen können, dass es ein allierter A10-C war. Hätte ich mich auf den blöden Jester verlassen, wäre wieder ein Unglück passiert. :( Hattet ihr sowas ähnliches auch? Oder ist das ein genereller IFF-Bug?

Not sure how to contact the authors of the scripting guide on Hoggit, but there is a typo on this page: https://wiki.hoggitworld.com/view/DCS_func_getDetectedTargets It should be Controller.Detection instead of Conroller.Detection. For people who copy stuff from that site, it may save some time. ;)

Maybe you could add more AAA and some prespawned AI fighters that fly around the base to protect it. There is a MOOSE script that automatically sends the AI towards bandits within a certain range, when a radar system sees them. I would also like to see more AAA around the AO to make low level flights more dangerous.

Oh, there are a lot of helpful things in those mission files. Hard to believe that I did not check them out earlier. :D

My mission files dont seem to be readable with the editor, but the structure in your pylons-table seems to work. Thanks! :)

Could someone give me an example with full pylons, please? I do not know the structure of ["pylons"] = {} from your example. I have tried to use ["pylons"] = pUnit:getAmmo() using an existing pUnit unit, but it did not work. The spawned aircraft did not have any weapon on its pylons.

Hat jemand schon probiert für Multiplayer Missionen "Begin Play Actor" zu verwenden, damit ein Spieler in der Tomcat schnell zwischen dem Pilot- und dem RIO-Sitz wechseln kann? Wenn das durch eine Radio-Option getriggert wird, könnte man mit Voice-Attack-Befehlen vielleicht problemlos die Sitze wechseln.

Is it theoretically possible for modders to make Russian mid fidelity aircraft cockpits clickable? It is just a matter of convenience for me.

Yes, absolutely! I have tried to takeoff with 14 soldiers, full fuel weight and full armament, but I could not do it, because I was too heavy. Then I disembarked them and suddenly my Huey was able to take off much easier. Maybe the center of gravity is also changed by loaded troops, but I have not tested it, yet.

On one of the servers I have noticed that its missions automatically detects which loadout you have after takeoff. So I was thinking: Why can't a mission take the financial value of the loadouts into account as well, when computing the losses for the team score? You could grant each player a certain amount of money per mission, which they could use for their loadouts. Once a player or a team is bankrupt they cannot get valuable loadouts like AMRAAMs any more. That would help to stop spamraams while still allowing this weapon at a fairly limited amount. I think the technical possibilities for such missions already exist for DCS, so I hope someone will take care of it. It would be epic having a flight and economy simulator in one game!