Steerpoints and increment/decrement switch
-
Have seen this one more than a few times now. At random points when I am using the increment/decrement switch to move between steerpoints it will not change to the expected steerpoint but to a completely other one. For example on a MP flight today I tried to increment from steer 10 to 11 and it went to steer 6. I have also seen it go to steer 1.
Edit: Forgot to say that this occured on 4.33 64 bit. I never saw this happen on 4.32. Stock campaign MP every time I have seen it but I haven’t messed around with SP action in awhile.
-
Have seen this one more than a few times now. At random points when I am using the increment/decrement switch to move between steerpoints it will not change to the expected steerpoint but to a completely other one. For example on a MP flight today I tried to increment from steer 10 to 11 and it went to steer 6. I have also seen it go to steer 1.
Happened to me today, too. MP in Balkans.
-
Happened to me today also in KTO MP. Strange.
-
Known (MP) issue.
ASUSTeK ROG MAXIMUS X HERO / Intel Core i5-8600K (4.6 GHz) / NVIDIA GeForce RTX 3080 Ti FE 12GB / 32GB DDR4 Ballistix Elite 3200 MHz / Samsung SSD 970 EVO Plus 2TB / Be Quiet! Straight Power 11 1000W Platinum / Windows 10 Home 64-bit / HOTAS Cougar FSSB R1 (Warthog grip) / SIMPED / MFD Cougar / ViperGear ICP / SimShaker JetPad / Track IR 5 / Curved LED 27'' Monitor 1080p Samsung C27F396 / HP Reverb G2 VR Headset.
-
Known (MP) issue.
Another steerpoint/target point issue I had during the same mission: while waiting on the taxiway for my takeoff sequence, I manually inputted the target point via the steerpoint key on the ICP, which the STPT was #5. After leaving STPT function on DED, I went back in and confirmed the coordinate was in correctly. It was.
When I turned towards the target from 4, the steerpoint had some coordinate I never put in, and it was way off the area I needed to be. Is this also a known and/or associated issue. This has happened to me before. I was nap of the earth, bad weather, night, and plugging the coords into the ICP again, and luckily made it before TOT.
Here’s how we were set up:
- Multiplayer Balkans; I was the host
- 4-ship strike flight, with 3 human players and one AI, which I sent home after takeoff
- all of the live players had the same target programmed, which was steerpoint 5
- CCRP with slick bombs, no TGP work…low-altitude delivery.
- LANTIRN
- two other flights in the package…SEAD and ESCORT, and I had them programmed into the datalink page so I could see them…21, 23, 31, 33…so I could see the leads for each element.
- Near as we could tell, neither of the other two human players had this issue.
- I was #3 in the flight, the other two human players were lead and #2.
- The only issue I had on this flight is when going from steerpoint 3 to 4, it jumped to 7, and I had to toggle back down to 4, and it all seemed OK until I went for 5, the target.
Known or?? Anybody having this issue?
-
All,
During any point in the mission did one of the humans, for any reason, exit the 3D world?Seems to be the common link for us. Therefore, players are to remain in 3D, at least until the package is “Miller time”.
-
Another steerpoint/target point issue I had during the same mission: while waiting on the taxiway for my takeoff sequence, I manually inputted the target point via the steerpoint key on the ICP, which the STPT was #5. After leaving STPT function on DED, I went back in and confirmed the coordinate was in correctly. It was.
When I turned towards the target from 4, the steerpoint had some coordinate I never put in, and it was way off the area I needed to be. Is this also a known and/or associated issue. This has happened to me before. I was nap of the earth, bad weather, night, and plugging the coords into the ICP again, and luckily made it before TOT.
Here’s how we were set up:
- Multiplayer Balkans; I was the host
- 4-ship strike flight, with 3 human players and one AI, which I sent home after takeoff
- all of the live players had the same target programmed, which was steerpoint 5
- CCRP with slick bombs, no TGP work…low-altitude delivery.
- LANTIRN
- two other flights in the package…SEAD and ESCORT, and I had them programmed into the datalink page so I could see them…21, 23, 31, 33…so I could see the leads for each element.
- Near as we could tell, neither of the other two human players had this issue.
- I was #3 in the flight, the other two human players were lead and #2.
- The only issue I had on this flight is when going from steerpoint 3 to 4, it jumped to 7, and I had to toggle back down to 4, and it all seemed OK until I went for 5, the target.
Known or?? Anybody having this issue?
I’ve never seen this one mainly due to not messing around with mission steerpoints while in the pit. If I wanted to modify a target steerpoint due to being assigned to take out a specific building I will do that modification pre-flight and save it to the DTC. If I want to add in an approach hold point for a minimum visibility ILS recovery with multiple aircraft I plug those points in after the normal mission steerpoints. Say at STPT 15 or some such where no other data was anyways.
As far as your specific problem the only thing I can think of right off the top of my head is an incorrect steerpoint modification/DTE load order. Performing a DTE load after the manual modification would overwrite that change and is realistic to what would happen IRL if done backwards.
-
–
Cheers,Mark.
-
Not to me…which would seem to be a problem, eh?? Repro case??
As far as I understand it, it is the bug of steer-point switching in MP … Bug report is in the bug-tracker.
-
As far as your specific problem the only thing I can think of right off the top of my head is an incorrect steerpoint modification/DTE load order. Performing a DTE load after the manual modification would overwrite that change and is realistic to what would happen IRL if done backwards.
Here were my steps:
1. Taxiway entry and setup…assume my <callsign.ini>and <mission.ini>are loaded.
2. Changed the target steerpoint (STPT 5, in this case) to more precise coordinate.
2.5 Flew to the IP for the next 20 mins or so in AA master mode.
3. Tangled with MiGs before going to STPT 5, so still on STPT 4…killed them.
5. Incremented to STPT 5
6. Went to AG master mode, and noticed HUD target marker for STPT 5 was not where I expected it…it was in front of me when it should have been behind me.
7. Entered STPT Mode on ICP…coordinates were not the ones I entered…50-60miles off.
8. Quickly entered proper coordinates from kneeboard and killed target.
9. Flew home with no other issues.Here’s another wrinkle…I was flying the same mission the other day, and had the same issue…STPT 5 was off in the distance, but not the same point as the last time it happened. However, I was in AA master mode, and the coordinates were wrong. I then went to AG mode, and went to input the right coordinates, and the proper coordinates were there. Each time this happens, I report to the flight, and we were all shaking our heads, which is great now that the Devs gave us the ability to see such things in MP mode (love it!).
Anyway…if you see anything wrong with that sequence, anybody, please let me know. Intuitively, it makes sense to me, but there might be some subtle nuance I’m missing. Appreciate any insight.</mission.ini></callsign.ini>
-
Anyway…if you see anything wrong with that sequence, anybody, please let me know. Intuitively, it makes sense to me, but there might be some subtle nuance I’m missing. Appreciate any insight.
The only thing I am still not understanding is why you are modifying your target steerpoint while in pit versus in 2D prior to take off. It is an easier process in 2D to set a specific building or a SAM radar or some such to steerpoints and save the DTC than it is to manually load them once in pit.
The only thing about this last post I found strange was when you said the coordinates were off in A-A but were fine in A-G. Unless you had cursor slewed at some point and not performed a cursor zero to reset the steerpoints to their defaults.
-
The only thing I am still not understanding is why you are modifying your target steerpoint while in pit versus in 2D prior to take off. It is an easier process in 2D to set a specific building or a SAM radar or some such to steerpoints and save the DTC than it is to manually load them once in pit.
The only thing about this last post I found strange was when you said the coordinates were off in A-A but were fine in A-G. Unless you had cursor slewed at some point and not performed a cursor zero to reset the steerpoints to their defaults.
Stubbies…for the first question: Because I can, not to be flippant, and sometimes, when I load from the 2D, that is also hosed more times than not (1 good to 3 hosed events).
Yeah…it’s strange indeed, and I’m not doing any other cursor zero, reset, or anything…we used to do this all the time in 4.32, with never an issue.
-
So…knowing a thing or two about the code behind this I would hazard a guess that this arises because of changes made (since 4.32) for one of the subpages below CNI. I’d imagine that having a particular DED page up and changing the steerpoint is how the HUD and DED would get out of sync. The rocker switch action is DED page specific.
One thing I’d like to know – does this happen with the DED page on the root CNI page??
In general the code will “home” the idea of current steerpoint based on the nav computer; well, it’s supposed to do that. The DED and HUD should both tie into that to fetch what is “current” and also to set a new “current”. I’m thinking there’s hole in the state machine some place that misses the step of coordinating with the NAV computer then you switch DED pages and mash “next/prev” and that page does refer back to the NAV computer and boom…surprise new STPT value.
The trick now is to find that hole.
It’s not impossible but I think quite unlikely that this problem would not be reproducible in the solo play mode. ICP/DED/HUD/NAV have relatively little interaction with the network.
-
Here were my steps:
1. Taxiway entry and setup…assume my <callsign.ini>and <mission.ini>are loaded.
2. Changed the target steerpoint (STPT 5, in this case) to more precise coordinate.
2.5 Flew to the IP for the next 20 mins or so in AA master mode.
3. Tangled with MiGs before going to STPT 5, so still on STPT 4…killed them.
5. Incremented to STPT 5
6. Went to AG master mode, and noticed HUD target marker for STPT 5 was not where I expected it…it was in front of me when it should have been behind me.
7. Entered STPT Mode on ICP…coordinates were not the ones I entered…50-60miles off.
8. Quickly entered proper coordinates from kneeboard and killed target.
9. Flew home with no other issues.Here’s another wrinkle…I was flying the same mission the other day, and had the same issue…STPT 5 was off in the distance, but not the same point as the last time it happened. However, I was in AA master mode, and the coordinates were wrong. I then went to AG mode, and went to input the right coordinates, and the proper coordinates were there. Each time this happens, I report to the flight, and we were all shaking our heads, which is great now that the Devs gave us the ability to see such things in MP mode (love it!).
Anyway…if you see anything wrong with that sequence, anybody, please let me know. Intuitively, it makes sense to me, but there might be some subtle nuance I’m missing. Appreciate any insight.</mission.ini></callsign.ini>
Hi,
Seems to me like you are unaware of the SPI functionality in 4.33, I strongly suggest to RTFM the SPI section in the 3-4.
-
Hi,
Seems to me like you are unaware of the SPI functionality in 4.33, I strongly suggest to RTFM the SPI section in the 3-4.
Negative. Aware. Haven’t used much of the associated art in practice. The missions we’ve flown are looking at precise targets, “mensurated” from the RECON pages, and entered manually. While we have enemy air defenses to penetrate and layer back, we aim to engage with pinpoint accuracy once we get into hostile territory. Appreciate your insight.
-
So it should be easy to eliminate at least one set of variables. If you are looking at the RECON windows, instead of writing down the coords, use DTC to store them and load to NAV computer in mission via the DTC LOAD. If you do that, do you see the same issue or not??
[It’s really not clear to me why it makes much sense to enter LAT/LNG data by hand when the DTC function is designed to work with the RECON window for precisely that purpose. Which is not a criticism of what you are doing so much as an observation that bears on how much testing has been done on the code path you are trying to exercise…DTC lots, manual entry, probably not much at all past the original coder smoke test…testers are often drawn to the “usual” path as opposed to pushing the envelope of what’s possible in all dimensions…nature of the task]
–
Cheers,Mark.
-
There seems to be two different issues here.
The one brought up by the OP and the later issued brought up by dawgboy.The former issue seems to occur when in MP a client disconnects from the 3D world.
Causing, seemingly, random changes to the next selected steer point by players that have remained in 3D world. -
So it should be easy to eliminate at least one set of variables. If you are looking at the RECON windows, instead of writing down the coords, use DTC to store them and load to NAV computer in mission via the DTC LOAD. If you do that, do you see the same issue or not??
[It’s really not clear to me why it makes much sense to enter LAT/LNG data by hand when the DTC function is designed to work with the RECON window for precisely that purpose. Which is not a criticism of what you are doing so much as an observation that bears on how much testing has been done on the code path you are trying to exercise…DTC lots, manual entry, probably not much at all past the original coder smoke test…testers are often drawn to the “usual” path as opposed to pushing the envelope of what’s possible in all dimensions…nature of the task]
Understood. Thanks for the clarity.
Three times before I started to manually enter the coordinates in v4.33, I used the target coordinates load from the 2D world, using the RECON, select target, select STPT, and ACCEPT workflow. It worked the first time only. The second and third times, it failed:
-
The second time, Lead and I went to the coord without realizing it was off, and we bombed an open field (night LANTIRN mission). Lead was worried about air defenses in the target area and by the time I had pickled my slicks, it was too late…I saw through the FLIR HUD view it as an open field, and I put them near his smoking holes.
-
The third time, mine was off, many miles off, and Lead’s wasn’t, which I then bombed the site manually
After that point, I wrote them down and entered them manually on the taxiway or on the way to the target area, which worked for me before in 4.32 without issue. I simply went back to what I “knew” worked before trying the 2D loads.
I know that doesn’t really narrow it down. We will try to replicate the mission, and I’ll FRAPS it, to see if I can observe anything else.
db
-
-
Understood. Thanks for the clarity.
Three times before I started to manually enter the coordinates in v4.33, I used the target coordinates load from the 2D world, using the RECON, select target, select STPT, and ACCEPT workflow. It worked the first time only. The second and third times, it failed:
Ok I think I see your problem. You are missing the save DTC after changing your steerpoint step. Do the above steps then after you have hit the accept you then open your DTC and save it which will plug it into the callsign.ini file. If you do that it will always work.
-
Negative. Aware. Haven’t used much of the associated art in practice. The missions we’ve flown are looking at precise targets, “mensurated” from the RECON pages, and entered manually. While we have enemy air defenses to penetrate and layer back, we aim to engage with pinpoint accuracy once we get into hostile territory. Appreciate your insight.
OK Thanx.
Can you reproduce the issue in some SP TE/Camp? if yes then please post here the files and the EXACT steps to follow in order to see the issue, if not and it is some random issue, then I guess we will need more details about what was happening before/after the STPT “changed” or “jumped”.
