ATFLIR offset cursor

[LastRifleRound]

Looks exactly the same as LITENING. Wags used it to 'slew' the auto track, though it looks like just like LITENING, all it does is designate the spot you put the cursor. I thought this was incorrect behavior for ATFLIR? I remember seeing videos of the offset actually moving camera FOV. This thing looks and behaves identically to the LITENING save for the grid readout (which I believe LITENING is supposed to have anyway) and that you can slew its 'area' mode. Am I missing something?

Edited March 25, 2021 by LastRifleRound

[Harker]

Same here. Video evidence suggests that while in AUTO (PTRK) mode, enabling and slewing the offset cursor maintains the current track object in the picture, but allows the FOV to offset around the tracked object.

 

See here:

 

[oldcrusty]

1 hour ago, Harker said:

Same here. Video evidence suggests that while in AUTO (PTRK) mode, enabling and slewing the offset cursor maintains the current track object in the picture, but allows the FOV to offset around the tracked object.

 

See here:

 

 

The offset cursor can be useful of course but I still don't get it why I can't depress TDC then drag and drop 'AUTO' bracket somewhere else and let it do its 'auto' job.

I'm actually more curious about FLIR handoff of movers to MavF and how MavF handles its slave mode to FLIR.

[Harker]

 
The offset cursor can be useful of course but I still don't get it why I can't depress TDC then drag and drop 'AUTO' bracket somewhere else and let it do its 'auto' job.
I'm actually more curious about FLIR handoff of movers to MavF and how MavF handles its slave mode to FLIR.

About the last part, ED recently acknowledged that PTRK in the LITENING should update the designation as it follows a moving target. Check the Bugs section, it's a recent thread.

I assume the same thing is true for the ATFLIR.

[BarTzi]

4 hours ago, LastRifleRound said:

Looks exactly the same as LITENING. Wags used it to 'slew' the auto track, though it looks like just like LITENING, all it does is designate the spot you put the cursor. I thought this was incorrect behavior for ATFLIR? I remember seeing videos of the offset actually moving camera FOV. This thing looks and behaves identically to the LITENING save for the grid readout (which I believe LITENING is supposed to have anyway) and that you can slew its 'area' mode. Am I missing something?

 

I posted this video originally, and sent it to ED at the time. I hope it will make it in, since the current implementation is not correct.

[kengou]

The offset function of ATFLIR and Litening seems worthless and a hindrance more than a feature. Hope it does get changed if it is indeed incorrect.

[Bunny Clark]

Did we actually see the offset function in Wag's video? He demonstrated using the offset cursor to move the designated location, but that may not be the same as the actual offset track function, or only a partial implementation of it. We didn't see him track a moving target at all, so I'm thinking ATFLIR may not be fully feature complete yet. 

[BarTzi]

15 hours ago, Bunny Clark said:

Did we actually see the offset function in Wag's video? He demonstrated using the offset cursor to move the designated location, but that may not be the same as the actual offset track function, or only a partial implementation of it. We didn't see him track a moving target at all, so I'm thinking ATFLIR may not be fully feature complete yet. 

We did. It's exactly the same as the LITENING.

[IkarusC42B Pilot]

On roadmap thread it says wip 2.7. Maybe theyll correct it afterall

[Skysurfer]

Yeah currently it is implemented wrong (as per Wags' video) - the offset should be always screen centered and move the entire image with it, rather than just the cursor like a mouse on a computer. 

[med-taha]

45 minutes ago, Skysurfer said:

Yeah currently it is implemented wrong (as per Wags' video) - the offset should be always screen centered and move the entire image with it, rather than just the cursor like a mouse on a computer. 

+1

 

 

 

Edited April 4, 2021 by med-taha

[dorianR666]

12 hours ago, Skysurfer said:

Yeah currently it is implemented wrong (as per Wags' video) - the offset should be always screen centered and move the entire image with it, rather than just the cursor like a mouse on a computer. 

Wiki of The Other Sim says that ATFLIR should create an offset cursor on current designation, that can be moved to a new position and ATFLIR can then jump to that offset position on button press. It is unlikely both them and ED would get it equally wrong.

 

Perhaps the vids are of a different version.

 

On 3/25/2021 at 12:10 PM, kengou said:

The offset function of ATFLIR and Litening seems worthless and a hindrance more than a feature. Hope it does get changed if it is indeed incorrect.

Same.
I suspect the SCS action should only rotate TGP to offset and keep the current mode (point track etc.). Currently it does both, rotate and switch mode, simultaneously and inseparably, which makes absolutely no sense whatsoever and has zero usecases.

 

Edited April 5, 2021 by dorianR666

[Skysurfer]

6 hours ago, dorianR666 said:

Wiki of The Other Sim says that ATFLIR should create an offset cursor on current designation, that can be moved to a new position and ATFLIR can then jump to that offset position on button press. It is unlikely both them and ED would get it equally wrong.

 

Perhaps the vids are of a different version.

 

Same.
I suspect the SCS action should only rotate TGP to offset and keep the current mode (point track etc.). Currently it does both, rotate and switch mode, simultaneously and inseparably, which makes absolutely no sense whatsoever and has zero usecases.

 

 

 

False, another sim is never a reliable resource. Several SME's have already confirmed that this is wrong for our timeframe Hornet and pod.

[dorianR666]

What is "our timeframe hornet and pod"? We dont know which particular piece of ATFLIR ED has documentation for. Just like with Litening, which ED modeled after a particular Spanish version, because thats what they had documentation for, and is wrong for "our timeframe hornet and pod".

Edited April 5, 2021 by dorianR666

[IkarusC42B Pilot]

9 hours ago, Skysurfer said:

 

False, another sim is never a reliable resource. Several SME's have already confirmed that this is wrong for our timeframe Hornet and pod.

The referance video is an expedition from a year before then then what we got. Are you telling me the next year they decided to remove the feature and just live it like this?

Edited April 5, 2021 by IkarusC42B Pilot

[Skysurfer]

8 minutes ago, IkarusC42B Pilot said:

The referance video is an expedition from a year later then then what we got. Are you telling me the next year they decided to remove the feature and just live it like this?

 

 

No, ED had it wrong and basically copied the function over from the LPOD, which again, is a very ancient LPOD version used by the Spanish. El Podo. I trust my sources.

 

Pretty sure @Santi871 and @Jak525will also confirm this.

Edited April 5, 2021 by Skysurfer

[IkarusC42B Pilot]

3 minutes ago, Skysurfer said:

 

No, ED had it wrong and basically copied the function over from the LPOD, which again, is a very ancient LPOD version used by the Spanish. El Podo. I trust my sources.

 

Pretty sure @Santi871 and @Jak525will also confirm this.

 

We know this,the point is to atleast tell us how is the mode for our timeframe

[Skysurfer]

24 minutes ago, IkarusC42B Pilot said:

We know this,the point is to atleast tell us how is the mode for our timeframe

 

There shouldn't be any major difference to what you saw in said cruise video. Offset should work the same. Not that our Hornet really is a 2005 timeframe one anyway, despite what ED keep telling us. I's basically a frankenplane with different OFP  features mixed together, which is fine for a videogame like DCS.