Raffson

I believe this thread can be closed as this was fixed about a month ago.

Hi @Flappie, I just ran my mission again and it seems the issue has been fixed. Thread can be closed

I'd like to elaborate a little further on Biggus' post so that we're all on the same page here. Afaict the issue starts manifesting itself with uncontrolled aircraft as Biggus mentioned, but the issue starts before activation/start of the group. It always starts with the aircraft rotating (not "flashing", afaict the "flashing" isn't causing any real issues) 180 degrees around its Y-axis (iirc X-axis is north/south, Z-axis is west/east & Y-axis is up/down) some axis (see video). This happens almost instantaneously and speeds up at some point, after which the rotation becomes so fast, the aircraft eventually disappears into thin air. Please note that at this point, the aircraft is still uncontrolled, but once it has disappeared it seems to be in a totally bugged state (telemetry of the unit goes all over the place) which can induce the freeze. Yesterday I cooked up a mission in the ME (so not a Retribution generated mission) which seems to consistently trigger the freeze, given you run it on a dedicated server and connect as client of course:bird-flipper.miz The mission will run for roughly 20mins before freezing, i.e. the point where the first MiG-29S from Min-Vody gets shot down by the F-15C CAP flight, which triggers the freeze within seconds of the kill. This was confirmed to also cause a freeze on @Biggus' end, and I believe @Drexyl also confirmed this, whom I'd like to thank for their extensive testing because there's no telling how much extra time I would've spent on this before being able to put my finger on the issue. Obviously I took it a couple of steps further, and so I started going deeper down the rabbit hole w.r.t. uncontrolled aircraft on the ground, to see whether they also cause issues, and interestingly enough they do cause issues, but not a freeze. The next mission is basically a copy of the bird-flipper, but had additional aircraft parked at Sochi which remain uncontrolled: bird-flipper+uncontrolled.miz On my end this resulted into a graphical bug as soon as the first bomb of the B-1 hits the first Viper, which should've turned invisible by the time the B-1's GBU hits the ground. My screen basically turns black for a moment, then I get a picture again but only on the sides of my screen. Gradually the graphical bug fades out and things go back to normal, despite having "interacted" with an aircraft that got into this bugged state, which sort of suggests the freeze will only occur with bugged aircraft that were activated after getting into this bugged state, although at this point it's still an educated guess. Thus, next up I thought I'd put this theory to the test, which is basically another copy of the mission, but instead of having a bunch of Vipers parked at Sochi I decided to go with one & drop the second bomb on "Aerial-1-4", which is a Su-24M that also seemed to bug out, yet at some point becomes visible again. Strangely enough, bombing the Su-24M didn't induce a crash, but then when looking closer it also seems like the Su-24M never loses telemetry, which may explain why it's not causing a freeze: bird-flipper+uncontrolled2-(bomb-on-ground).miz That said, there's definitely another test I could run, because knowing that the MiG-29S is causing a freeze, I might want to try to bomb that instead and see if it still doesn't cause a freeze. Finally, as proof of the pudding, the same mission but without uncontrolled aircraft awaiting startup will work just fine: bird-flipper-fix.miz PS: here a screenshot of an aircraft that went invisible, but take note of the telemetry: Currently my guess is that that is the root cause of the freeze, i.e. once such a unit interacts with other units (like getting shot down) it will induce the freeze within seconds. Also noting that the freeze does not occur on the server's side (the server remains running just fine) but only on the client's side, which never disconnects. In fact, yesterday I noticed something interesting in one of my tests during such a freeze, i.e. if you wait long enough, you might actually see the frame change once or twice, so it seems like some very heavy processing is triggered on the client's side which is somehow the result of this "bad telemetry". Last but not least, here's a small clip of an aircraft that's about to bug out: Su-27_bugging_out.mp4 Hopefully this'll be enough data to track down the root cause of the issue

Having seen the last changelog I noticed the following: I assumed this would also fix the issue where helicopters would not respect their AGL altitude above water, though this didn't seem to be the case. For airplanes this issue doesn't present itself. The following mission demonstrates the issue:AGL-test.miz I'm assuming this is a bug, but please let me know if this is intended behavior

And that's exactly what makes me think this is rather an issue on Liberation/Retribution's end. I've been trying to systematically rip certain pieces out of a Retribution mission to see if it suddenly stops flickering, and thus hopefully stop the freezes that most people are experiencing (the two seem to be related, though it's merely an educated guess at this point). So far I think I've ruled out that it's a script issue, but I might need to double check because it's easy to miss the needle in this haystack Liberation/Retribution uses MIST, not MOOSE, nor do we use AIRBOSS afaik. Supercarriers is an option, but somehow I doubt that it's related. But if you can point me to a non-Liberation/Retribution mission that exhibited these issues, I might be able to narrow the search... That said, the issue seems to be originating from a feature in the mission generator that is common between Liberation & Retribution, but I still can't put my finger on what it might actually be

Good day, I'm not sure if this was already reported in the past, but I found that the Voice Callsign Label & Number initialize incorrectly (see attached screenshot) when the aircraft-group's callsign consists of two words. As far as I can tell it's only applicable to both versions of the S-3B, i.e. the tanker & non-tanker. I would think the fix is easy, i.e. simply remove the space in "Navy One" which I believe is also done for the Apache (e.g. "ArmyAir"), though I can't seem to figure out where the callsigns for the S-3B are defined Please let me know if I can be of any further assistance. Kind regards. Furthermore, I noticed a fix was implemented in the assignment of STN numbers since they used to contain non-octal digits before (one of) the last update(s), however for SADL this is still not fixed (A-10C/A-10C-II). Just thought to mention this though I assume ED's already aware of this given the fix that was implemented for L16...

Apologies for the late answer, but I believe the issue has been solved in yesterday's patch, more specifically the fix regarding double kill events. I can imagine how that would explain the behavior we've noticed, and I've also received some feedback from a Retribution user that the error is indeed gone. In case the error presents itself again, I'll make sure to follow up more thoroughly with a .miz file attached Kind regards.

After the release of 2.9.6.57650 I've noticed issues w.r.t. Object.getTypeName while processing a kill-event in a custom event-handler that's attached to the "world" Singleton. Specifically this happens with small caliber weapons, where a call to `event.weapon:getTypeName()` crashes with the failure message "Object doesn't exist". I've checked that `event.weapon` actually has a function called `getTypeName`, and it does, so that makes me think it might be an issue in the method itself. The strange part of it all is that the kill-event has a property called `weapon_name` which holds the same value, so I'm not sure whether this is the result of an intended change, or a bug that made it's way into the scripting API. Please let me know if I can be of any further assistance. Kind regards.

Interesting, thanks for pointing that out

A temporary solution adding copies of original weapons would be much appreciated. I’ve noticed the AI will fire off ED’s counterpart of the weapon, if it exists obviously. I’m hoping for the Kh-31 A/P at least, as that would allow me to create default payloads for the Su-30 for all different tasks. I need this for integrating the Flanker-H into Liberation, without having to nerf its capabilities. The MKI variant is an example of what I’m trying to explain, i.e. it has 2 versions of the Kh-31P, one custom and one original. I’ve tested both and the original seems to work with AI. So if that could be applied to other variants then SEAD is handled. Another thing I tried with was changing the CLSID of the Kh-35 to the original one, though I did that in my payload file so the pylon didn’t show up but aside from that it also worked. Of course the ideal solution would be the AI firing off the custom AG weapons as well, that would allow me to customize the payload accordingly, e.g. let the MKI variant use the Rudra-M1 instead for SEAD. But until then it would be of great help if I’d have access to original KH-31s, both A & P models. I can do this myself, but that’s not a valid solution for integrating the Su-30 in Liberation

I've been trying to get AI to do some SEAD and anti-ship strikes, however I'm having trouble with custom AG weapons. The AI doesn't seem to be able to use them, which I find really weird because custom AA weapons work fine. Any change I missed something?

Deadzones might help with that. Also, I’m trying to imagine in which situations you need this and what means you have at your disposal, i.e. what stick are you using etc. I’ve tried it out myself and find this to be more accurate than making corrections with the stick when it comes to finetuning. Even though I keep the default bindings on the keyboard cause in the situations that I’ve used this I’m already in a “controlled attitude” which allows me to take my hands of the stick for these tiny corrections.

Try out what’s already available, just map buttons for cyclic up, left, right and down. Depending on how sensitive you want the buttons to be, this could be your solution.

In that case you might as well fly exclusively with a human CP/G… imo, if you’re flying with george, you’re already messing up the realism part anyway.

+1 on a more detailed target list. Also, when there’s a lot of targets, the list can get pretty long, a “parent sub-menu” with categories would be handy, definitely speeding up the process of picking out specific targets.