Jump to content

Feedback Thread - F-14 Patch 11th Aug 2021


Spurts

Recommended Posts

On 8/15/2021 at 5:37 PM, DoorMouse said:

Still a massive number of game breaking issues with the Phoenix.

 

  • New as of this patch: Phoenix RCS is Excessive and is intercepted by missiles with alarming accuracy.  https://youtu.be/zU7kSd2r3R4
  • Old: TCS sync between multi-crew RIO and Pilot is poor. The camera bounces around for the pilot, rendering it useless
  • Old: TCS and Radar slaved sync between multi-crew RIO and Pilot can create a situation where the pilot is locking a target, but the RIO's client did not get that information
  • Old: TCS and Radar Sync between multi-crew RIO and Pilot can create a situation where the Lock Diamond is placed off the Hud, or locks an area of blank space behind the target
  • Old: Phoenix Hold Tracks still do not always pitbull. Extremely frustrating when this happens 1 or 2 seconds before pitbull and there is no way they have moved 3 miles away from last known in a few seconds (Which is the currently implemented work around) 
  • Old: TWS Shots often show no TTI after firing 
  • Old: TWS Shots often drop (X) immediately after firing at non maneuvering targets

I Love the Tomcat and its flight model is amazing -Weapons operation has consistently gotten worse every patch it seems though 😞

Phoenix RCS has been dictated to us by ED. We're looking into how to ameliorate this situation.

 

TCS sync between RIO and pilot is on our issue tracker, but non-trivial to fix unfortunately. That said, the next two locking TCS sync issues you mention are not known to me (not on our issue tracker).

 

Phoenix: this is in the process of being converted to the new missile API, hopefully this will solve many or all of the sync problems (although there are also reports of similar issues with AIM-120, so time will tell).

 

The two TWS shot issues are not known or on our tracker AFAIK.

____________

Heatblur Simulations

[sIGPIC][/sIGPIC]

Link to comment
Share on other sites

1 hour ago, gyrovague said:

 

AFAIK, these issues have not been reproduced or logged as issues on our side.

For real? There's been a thread in the bug forum since at least February and a thread pops up about it at least once a month. We can get you tracks if you need them. 

 

 

1 hour ago, gyrovague said:

Hopefully (🤞) now that we're using the ED AIM-7, the behaviour of them will always at least be the same as the AIM-7 on the other aircraft. This should be available in the next openbeta.


If I can supply my entirely suppositional and mostly uninformed opinion: I don't think the lofting and ECM issues with between the Tomcat and Sparrow have to do with values in those files. The F, the M and the H are all defined as HOJ capable, the F and M can't engage anything with ECM, and somehow the ACM switch position determines whether or not the MH can. Likewise the ACM switch no longer affects whether or not the MH lofts. These issues seem to have appeared when ED implemented their big rework of the AIM-7 seeker logic back at the beginning of the year. It seems that some sort of data is not getting passed from the F-14 to the AIM-7 at the time of firing that would tell it to HOJ or loft.

 

I'd like to be wrong and hope the unified sparrow fixes it 😄

EDIT: actually, extremely silly thought without evidence: The F and M aren't supposed to loft, and the MH isn't supposed to loft when the ACM cover is raised. Currently the F and M don't HOJ, and the MH doesn't HOJ when the ACM cover is raised. Is it possible whatever tells the missile to loft got mixed up with whatever tells the missile to HOJ?


Edited by near_blind
silly ideas
  • Like 5
Link to comment
Share on other sites

49 minutes ago, near_blind said:

Is it possible whatever tells the missile to loft got mixed up with whatever tells the missile to HOJ?

Yes, yes it is possible. 😉 and should now be fixed.... 🤦‍♂️ Looks like this .. 🪛 ⬆️ .. got introduced when we added a wrapper to the missile APIs to cater for both types (since we're in the process of converting the phoenix to the new). Look for this in next openbeta.

 

50 minutes ago, near_blind said:

For real? There's been a thread in the bug forum since at least February and a thread pops up about it at least once a month. We can get you tracks if you need them. 

I don't personally (have time to) monitor that forum thread unfortunately (or fortunately, as the case may be), but I've not seen issues logged about it in our tracker 🤷‍♂️ Will follow up about it, but usually that means it's not locally verified or so...  however, perhaps (most likely) this hoj/loft snafu explains and fixes it all, as you mentioned 🤞

  • Like 4
  • Thanks 2

____________

Heatblur Simulations

[sIGPIC][/sIGPIC]

Link to comment
Share on other sites

4 hours ago, gyrovague said:

Phoenix RCS has been dictated to us by ED. We're looking into how to ameliorate this situation.

 

TCS sync between RIO and pilot is on our issue tracker, but non-trivial to fix unfortunately. That said, the next two locking TCS sync issues you mention are not known to me (not on our issue tracker).

 

Phoenix: this is in the process of being converted to the new missile API, hopefully this will solve many or all of the sync problems (although there are also reports of similar issues with AIM-120, so time will tell).

 

The two TWS shot issues are not known or on our tracker AFAIK.

First - Appreciate you responding! 

I will get together some tracks and build a video compilation and tag you in the post in this thread once I have it. 

If you will allow me, there is one other Item that people said has been reported that I want to make sure you are aware of. Apologies if it is redundant:

  • Steps to Reproduce: 

    1)RIO must select Missile Option: Phoenix Active setting pre launch 
    2) Shoot pre pitbull range, higher the range higher the desync. Keep tracking the target with TWS till the missile goes active ( Could work without keeping track) . Can only be seen visually if its going for the target
    3) Once the missile is within pitbull range (Range being dependant on the Target Size switch) and the target is still being tracked in TWS it will snap on them and there is around 2 second difference between the shooter and targets client. Meaning the position and angle of the missile is different on each client.  Higher ping could increase this dysync due to client side netcode. 

Link to comment
Share on other sites

On 8/17/2021 at 2:28 AM, DoorMouse said:

First - Appreciate you responding! 

I will get together some tracks and build a video compilation and tag you in the post in this thread once I have it. 

If you will allow me, there is one other Item that people said has been reported that I want to make sure you are aware of. Apologies if it is redundant:

  • Steps to Reproduce: 

    1)RIO must select Missile Option: Phoenix Active setting pre launch 
    2) Shoot pre pitbull range, higher the range higher the desync. Keep tracking the target with TWS till the missile goes active ( Could work without keeping track) . Can only be seen visually if its going for the target
    3) Once the missile is within pitbull range (Range being dependant on the Target Size switch) and the target is still being tracked in TWS it will snap on them and there is around 2 second difference between the shooter and targets client. Meaning the position and angle of the missile is different on each client.  Higher ping could increase this dysync due to client side netcode. 

OK, thanks for the report, this sounds bizarre... we'll need to reproduce these steps to see what's going on, but with Phoenix Active selected prior to launch, it should be launching active from the start, and not get sent active command later (and tgt size switch shouldn't be a factor then).

____________

Heatblur Simulations

[sIGPIC][/sIGPIC]

Link to comment
Share on other sites

On 8/12/2021 at 4:10 AM, Naquaii said:

 

No they didn't. The F-14 only had full flaps or maneuver flaps, nothing inbetween. IRL the flaps handle couldn't be used for anything other than up or full flaps.

 

I currently have flaps bound to a slider axis on my Virpil throttle - will setting this to, say, 40%, now deploy maneuvering level flaps? Or do they automatically deploy when used for maneuvering? 

On 8/12/2021 at 6:40 AM, IronMike said:

 

Cycling the hook at throttles idle was simply how it was done irl - kneeling had nothing to do with it, and you could still use it when kneeled. Hence the change.

 

 

Just so I'm clear on this - when I steer up to the shuttle, I then use the squat lever to drop into position. This usually disengages NWS. Are you saying we have to drop the tail hook now to disengage NWS? Or can I use my NWS button on the grip?

Intel 11900K/NVIDIA RTX 3090/32GB DDR4 3666/Z590 Asus Maximus motherboard/2TB Samsung EVO Pro/55" LG C9 120Hz @ 4K/Windows 10/Jotunheim Schiit external headphone amp/Virpil HOTAS + MFG Crosswind pedals

Link to comment
Share on other sites

6 hours ago, GunSlingerAUS said:

Just so I'm clear on this - when I steer up to the shuttle, I then use the squat lever to drop into position. This usually disengages NWS. Are you saying we have to drop the tail hook now to disengage NWS? Or can I use my NWS button on the grip?

You can use the nws button too. The automatic nws off after cycling the hook is just a handy feature since IRL you would always cycle the hook on deck before launch. 

i5-8600k @4.9Ghz, 2080ti , 32GB@2666Mhz, 512GB SSD

Link to comment
Share on other sites

10 hours ago, gyrovague said:

OK, thanks for the report, this sounds bizarre... we'll need to reproduce these steps to see what's going on, but with Phoenix Active selected prior to launch, it should be launching active from the start, and not get sent active command later (and tgt size switch shouldn't be a factor then).

What about flight model?

 

Link to comment
Share on other sites

11 hours ago, GunSlingerAUS said:

 

I currently have flaps bound to a slider axis on my Virpil throttle - will setting this to, say, 40%, now deploy maneuvering level flaps? Or do they automatically deploy when used for maneuvering? 

 

Just so I'm clear on this - when I steer up to the shuttle, I then use the squat lever to drop into position. This usually disengages NWS. Are you saying we have to drop the tail hook now to disengage NWS? Or can I use my NWS button on the grip?

 

As it currently is in open beta the full flaps will deploy when you pass a certain threshold and fully retract when moved back past that point. Our SME later corrected us so they will be incremental again next patch.

 

The maneuvering flaps are controlled to extend when needed by the CADC, when we're back to incremental next patch you need to have the lever fully up for that to work. The flap handle is separate from maneuverflaps and overrides it. The only way to manually control those is the dlc wheel.

 

The automatic NWS disengagement was changed to be correct and for that to work you need to cycle the hook which is done during pre-flight checks IRL anyway. But you can still disable it using the NWS button as always.

3 hours ago, maxsin72 said:

What about flight model?

 

 

Me and Gyro do not work on the FM so unfortunately can't update you on it. But it is being worked on.

  • Like 1
Link to comment
Share on other sites

2 hours ago, Naquaii said:

 

As it currently is in open beta the full flaps will deploy when you pass a certain threshold and fully retract when moved back past that point. Our SME later corrected us so they will be incremental again next patch.

 

The maneuvering flaps are controlled to extend when needed by the CADC, when we're back to incremental next patch you need to have the lever fully up for that to work. The flap handle is separate from maneuverflaps and overrides it. The only way to manually control those is the dlc wheel.

 

The automatic NWS disengagement was changed to be correct and for that to work you need to cycle the hook which is done during pre-flight checks IRL anyway. But you can still disable it using the NWS button as always.

 

Me and Gyro do not work on the FM so unfortunately can't update you on it. But it is being worked on.

Anyway thx for the answer

  • Like 1
Link to comment
Share on other sites

On 8/19/2021 at 6:00 PM, gyrovague said:

OK, thanks for the report, this sounds bizarre... we'll need to reproduce these steps to see what's going on, but with Phoenix Active selected prior to launch, it should be launching active from the start, and not get sent active command later (and tgt size switch shouldn't be a factor then).

This is "the bug" preventing people from flying Tomcats in SATAL

Id love an official response on this one

Im still working on compiling a video of the TWS tracks trashing instantly. I SUSPECT it has to do with server/player/rio latency and the AWG9 in game is TOO sensitive to server latency. If a target-client's aircraft lags, if your rio lags, even a little - it trashes your track. Probably because its tested/optimized in single player. 


Edited by DoorMouse
  • Like 2
Link to comment
Share on other sites

11 hours ago, DoorMouse said:

This is "the bug" preventing people from flying Tomcats in SATAL

Id love an official response on this one

Im still working on compiling a video of the TWS tracks trashing instantly. I SUSPECT it has to do with server/player/rio latency and the AWG9 in game is TOO sensitive to server latency. If a target-client's aircraft lags, if your rio lags, even a little - it trashes your track. Probably because its tested/optimized in single player. 

 


All calculations are done from the Pilots client , what the RIO sees is what the server thinks the missile is doing , so RIO gets the same missile as the target aircraft. Its an issue if the Pilot laggs as then all four : Server , Pilot, Riot and target aircraft will have different missiles on their clients. Off the top of my head if the RIO laggs the pilots client doesn't register the changes ( I could be wrong or have been lucky ) it just halts getting updates from the RIO until he has stabilized and starts giving input again.

The other is issue is the overall desync of the pheonix. Its related to the delay of the server receiving the data from the pilot. Just that 1 second or so of delay due to the fact of there being no post launch syncing of the missile from the server and the 14 pilot client creates this issue. Its not just the Aim 54 that suffers from this , features had to be removed in December/January from the 120 missile scheme to resolve some big desync issues with the 120's and SD-10's. The threshold of desync is much higher on the 54 due to its speed , it covers more ground in that delay when its takes action. This is especially true when you essentially maddog a Aim 54 or use the PH ACT and while having a track on a target in TWS above 10NM.

Overall its not just about the 54 and ultimately its up to ED to negate this issue not HB, as even with HB updating the 54 to the new scheme wont remove these issues. ED need to transition from a client sided netcode to server sided, clientside netcode is very outdated and causes issues like this.
 

On 8/19/2021 at 11:00 PM, gyrovague said:

OK, thanks for the report, this sounds bizarre... we'll need to reproduce these steps to see what's going on, but with Phoenix Active selected prior to launch, it should be launching active from the start, and not get sent active command later (and tgt size switch shouldn't be a factor then).


This was reported and confirmed in the testers section so ED do know about it. I have to say its weird if you guys have had nothing from ED relating this topic at all as its been 8 months since this has been reported. I'll have to dig up the things Sauvuer and me reported to ED and then send them to you. Although the tracks are going to be old , nevertheless its not had to reproduce yourselves. Would of gladly done them myself for you but I'm currently away abroad.

 

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

3 hours ago, DarksydeRob said:

The threshold of desync is much higher on the 54 due to its speed , it covers more ground in that delay when its takes action. This is especially true when you essentially maddog a Aim 54 or use the PH ACT and while having a track on a target in TWS above 10NM.

This is what I suspected.  The phoenix does not have any "specific" issues, its just that EVERYTHING has desync issues and since the Phoenix is faster it can travel more time during that interval. 

In which case this will never be 'fixed'

  • Like 1
Link to comment
Share on other sites

On 8/21/2021 at 5:12 AM, DoorMouse said:

This is "the bug" preventing people from flying Tomcats in SATAL

Id love an official response on this one

Im still working on compiling a video of the TWS tracks trashing instantly. I SUSPECT it has to do with server/player/rio latency and the AWG9 in game is TOO sensitive to server latency. If a target-client's aircraft lags, if your rio lags, even a little - it trashes your track. Probably because its tested/optimized in single player. 

 

I spent a bunch of time trying to reproduce this TWS with PH ACT issue in SP and MP, to no avail. As far as I can tell, the logic all operates correctly, so I'm also surmising that the issue is due to packet loss or reordering over internet MP. We don't have any control over the netcode of course, we simply launch a missile with an API, and call another API function to set it to go active. If that packet indicating it must go active is lost or reordered (e.g. arrives before the missile creation packet for instance), then of course one side will think the missile is active and the other side will not. We'll ask ED whether there is some way we could improve this, e.g. perhaps calling active periodically (I suspect right now it would only send a packet if active changes, so repeatedly setting it active most likely won't do anything) or calling it only a while after the missile has launched instead of immediately etc.

  • Like 6
  • Thanks 1

____________

Heatblur Simulations

[sIGPIC][/sIGPIC]

Link to comment
Share on other sites

Sorry if I do this wrong this is my first post lol.... but just wondering if anyone has brought up the "rough" looking wing sweep? It used to be very smooth when sweeping, but now it seems that it has a roughness or a jitter to it as they sweep. This applies both to the A and the B

Thanks HB for the constant updates!

Link to comment
Share on other sites

On 8/22/2021 at 1:52 PM, Kracicot77 said:

Sorry if I do this wrong this is my first post lol.... but just wondering if anyone has brought up the "rough" looking wing sweep? It used to be very smooth when sweeping, but now it seems that it has a roughness or a jitter to it as they sweep. This applies both to the A and the B

Thanks HB for the constant updates!

 

I didnt notice anything like that, but will take a look.

Heatblur Simulations

 

Please feel free to contact me anytime, either via PM here, on the forums, or via email through the contact form on our homepage.

 

http://www.heatblur.com/

 

https://www.facebook.com/heatblur/

Link to comment
Share on other sites

On 8/15/2021 at 4:31 PM, maxsin72 said:

 

Hmmmmm.... I asked my question last thursday at 10.27 AM and they answered to others questions asked after mine.... hmmm...... 

 

 

Sorry, been a bit away from the forums. The FM is nearing completion, but it can still take a while. ATM I would rather not give you an estimate, but will hopefully be resolved soon. Thank you for your kind patience.

Heatblur Simulations

 

Please feel free to contact me anytime, either via PM here, on the forums, or via email through the contact form on our homepage.

 

http://www.heatblur.com/

 

https://www.facebook.com/heatblur/

Link to comment
Share on other sites

6 hours ago, IronMike said:

 

Sorry, been a bit away from the forums. The FM is nearing completion, but it can still take a while. ATM I would rather not give you an estimate, but will hopefully be resolved soon. Thank you for your kind patience.

Thank you for your answer

Link to comment
Share on other sites

On 8/22/2021 at 9:59 AM, gyrovague said:

If that packet indicating it must go active is lost or reordered (e.g. arrives before the missile creation packet for instance), then of course one side will think the missile is active and the other side will not. 

I'm not sure that's how TCP works ... 'TCP provides reliable, ordered, and error-checked delivery of a stream '. If packets arrive out of order or get lost, then the transport stack will request a resend or pass them up the stack in order. If this 'lost packet' theory was the case, why does this impact the 54 so much more than say the SD-10? I can't imagine DCS uses UDP!


Edited by Kula66
Link to comment
Share on other sites

20 minutes ago, Kula66 said:

I'm not sure that's how TCP works ... 'TCP provides reliable, ordered, and error-checked delivery of a stream '. If packets arrive out of order or get lost, then the transport stack will request a resend or pass them up the stack in order. If this 'lost packet' theory was the case, why does this impact the 54 so much more than say the SD-10? I can't imagine DCS uses UDP!

 

 

Using TCP in multiplayer games (and a lot other time sensitive applications) is not really something you want. If some packets get lost, client/server would need to resend them and only after receipt of those packets have been confirmed you can move forward.

 

That's a big NO-GO in MP games so UDP-like connection is what you want. You need to have some mechanism to make sure the continuity of the action is not lost, but also you must not rely on all packets getting to a destination as that is virtually impossible and would quickly deteriorate game experience.

Link to comment
Share on other sites

  • 2 weeks later...
On 8/22/2021 at 4:59 AM, gyrovague said:

I spent a bunch of time trying to reproduce this TWS with PH ACT issue in SP and MP, to no avail. As far as I can tell, the logic all operates correctly, so I'm also surmising that the issue is due to packet loss or reordering over internet MP. We don't have any control over the netcode of course, we simply launch a missile with an API, and call another API function to set it to go active. If that packet indicating it must go active is lost or reordered (e.g. arrives before the missile creation packet for instance), then of course one side will think the missile is active and the other side will not. We'll ask ED whether there is some way we could improve this, e.g. perhaps calling active periodically (I suspect right now it would only send a packet if active changes, so repeatedly setting it active most likely won't do anything) or calling it only a while after the missile has launched instead of immediately etc.

 

https://www.dropbox.com/s/2s5x660zgrx6krj/Public Release Missile Test.docx.pdf

 

I have lots of documentation on this now, and a weird edge case that I've tracked down that may explain it. I have a version which I want to send you and anyone on the HB/ED teams that wants it, which has the methods section, as well as video documentation of how to reproduce this. I do not want to disseminate that information in such detail publicly. Please let me know if you have any questions. I'm happy to help track this down.... but the TLDR is that this is not due to net-code.  The shooter and the target are being given different sets of information, and it's easily reproducible. 

 

I am now working on getting you some videos/trackfiles of non-maneuvering hot targets with 1000+ knots closure having their tracks drop. 

 


Edited by DoorMouse
Link to comment
Share on other sites

Hello, something has been on my mind for a bit. The Sparrows all use the same 3D model and texture, meaning no matter the version, they all look like F (easy way to tell difference - F has 2 windows on the nose section, M has 4). What I didn't notice until just now however is that the Phoenixes have the same issue. Apparently the texture can be changed via livery, however then it again can only represent one Phoenix visually.

 

Could it be looked at?

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...