theIRIEone Posted June 1, 2021 Share Posted June 1, 2021 Hi, ran into some issued trying to use O/S coordinates as STP for our SLAM-ERs, not sure if what we experienced is intended behavior. Given was a designated waypoint with multiple targets around for a 2ship - we set up an O/S from that in this order: 1. hit UFC from according HSI/DATA format 2. hit O/S on UFCP 3. entered 30NM range 4. entered 145MAG and 235MAG for BRG respectively as we wanted 45deg offsets from our inbound HDG of 010 to create separation between the missiles 5. We left the altitude blank as the intend was not to use the Offset as such, but to read the calculated O/S coordinates (GRID) from the HSI to use as creation for another waypoint in the sequence - which we then would use as STP for our SLAM-ERs. That's where things went wrong: While writing down the given O/S GRID from the HSI/DATA/WYPT sub-format, the coordinates actually where slowly, but constantly changing aka the offset was drifting and not a fixed point in space (it was still roughly correct according to tacview as the SLAM-ER still took a turn at roughly 30NM and correct-ish BRG from TGT). While i couldn't find any reports of this exact issue described on the forums, i found another user's entry that is marked 'solved' - their screenshots also show their O/S Grid drifting, but nobody in the comments mention this. The marked solution there was "Check O/S Altitude" - which in that case made sense as they where trying to acquire a specific point on the ground with ATFLIR using F10 map shenanigans. - I'll leave their topic linked here for the screenshots, since i don't have own recordings of the O/S drift so far unfortunately. Question boils down to: Should Offset always be a fixed point in space or start drifting when (deliberately) not entering altitude? Considering WPT creation does not necessarily require altitude to be entered for the GRID to be stable, i would assume same logic applies for O/S creation (with the addition of offset logic such as BRG/RNG)? Link to comment Share on other sites More sharing options...
oldcrusty Posted June 1, 2021 Share Posted June 1, 2021 (edited) Don't quote me on that one but I think the elevation for O/S, if left blank, would be automatically entered by MC when within ranging limits. I have no idea whether DCS models it this way or any other way. The 'other' sim did. Anyways, I don't think this would work with SLAMER's. As far as continuing from O/S, idk Edited June 1, 2021 by Gripes323 Link to comment Share on other sites More sharing options...
theIRIEone Posted June 1, 2021 Author Share Posted June 1, 2021 24 minutes ago, Gripes323 said: Don't quote me on that one but I think the elevation for O/S, if left blank, would be automatically entered by MC when within ranging limits. I have no idea whether DCS models it this way or any other way. The 'other' sim did. Anyways, I don't think this would work with SLAMER's. As far as continuing from O/S, idk Thanks a lot for your input. I would assume elevation blanks being filled by the MC would mean no drifting coordinates, but also an actual altitude input being present in the O/S data - i know that elevation data is not displayed when leaving elevation blank, but that doesn't mean it couldn't exist somewhere in the background. To be clear this has nothing to do with SLAM-ERs really, they're just here for context. Basically we wanted to write down the O/S coordinates, but that wasn't possible because they kept changing - and i am not sure what caused that drift, thinking it may be us not having entered altitude data - and if that would really cause the GRID to be drifting? Link to comment Share on other sites More sharing options...
oldcrusty Posted June 1, 2021 Share Posted June 1, 2021 6 minutes ago, theIRIEone said: ...and if that would really cause the GRID to be drifting? I don't think so but as you know, currently everything is 'drifting' in and around the Hornet 1 Link to comment Share on other sites More sharing options...
Recommended Posts