DISS 15 - Map trigger issue / snapstate / moving paper map not working

[rogorogo]

With the recent patch DCS 2.7.14.23966 Open Beta (and maybe the one before) the Paper Map indicator for the DISS-15 has stopped working in Multiplayer while the DISS-15 itself is working reliably.

The map indicator is not moving after takeoff, even with Airspeed2Doppler on (which causes drift), no movement.

Any takeoff, fresh airframe, no damage, green OPER light, DISS-15 directional readout working, Doppler "Hover and Low Speed Control indicator" working correctly.

If the airframe is moved above a certain "trigger" altitude at any point during a sortie, the map indicator will suddenly "snap" into the correct positon (which is technically impossible) at the time and move.

If the "trigger angels" are a fixed AGL or ASL altitude is unclear at this point, especially as terrain masking seems to also influence bug manifestation. Which does not make sense in a systemic context but hints as a coincidental bug manifestation maybe related to DCS "radar" odditities overall.

If the airframe is moved back into usual Crocodile angels (treetop, below treeop, terrain) at correct attitude for the DISS-15 to work, the indicator will stop moving again.

The "snap" can be repeated then in a different position.

This means that the module has currently lost its only means of navigation (since placeable beacons, radio truck NDBs are bugged for years by now on all available terrain modules) and the airframe has to operate in VFR, a correctly preset DISS-15 oneway Doppler and a maybe available ARK-15 beacon direction to find a FARP, a target, a destination. 

Edited May 24, 2022 by rogorogo

[AeriaGloria]

11 hours ago, rogorogo said:

With the recent patch DCS 2.7.14.23966 Open Beta (and maybe the one before) the Paper Map indicator for the DISS-15 has stopped working in Multiplayer while the DISS-15 itself is working reliably.

The map indicator is not moving after takeoff, even with Airspeed2Doppler on (which causes drift), no movement.

Any takeoff, fresh airframe, no damage, green OPER light, DISS-15 directional readout working, Doppler "Hover and Low Speed Control indicator" working correctly.

If the airframe is moved above a certain "trigger" altitude at any point during a sortie, the map indicator will suddenly "snap" into the correct positon (which is technically impossible) at the time and move.

If the "trigger angels" are a fixed AGL or ASL altitude is unclear at this point, especially as terrain masking seems to also influence bug manifestation. Which does not make sense in a systemic context but hints as a coincidental bug manifestation maybe related to DCS "radar" odditities overall.

If the airframe is moved back into usual Crocodile angels (treetop, below treeop, terrain) at correct attitude for the DISS-15 to work, the indicator will stop moving again.

The "snap" can be repeated then in a different position.

This means that the module has currently lost its only means of navigation (since placeable beacons, radio truck NDBs are bugged for years by now on all available terrain modules) and the airframe has to operate in VFR, a correctly preset DISS-15 oneway Doppler and a maybe available ARK-15 beacon direction to find a FARP, a target, a destination. 

 

It works fine. The difference is that since last patch the Doppler switch under the map defaults to being off, where it used to default to being on.  You just have to flick the switch under the map from OFF to ON and it will work fine. Took a few flights to really make it a habit in my cold start procedure now. 
 

I don’t know why it would start working at certain altitude and not below, since patch I’ve only flown to 2,000m AGL/ASL. And when I did, it still worked fine provided i had turned the switch on below the Map. If it happenned ar 3,000m AGL for you it would make me think there is some sort of trigger reversing it’s state. As as 3,000m AGL is suppossed to be the altitude limit 

Edited May 25, 2022 by AeriaGloria

[rogorogo]

vor 2 Stunden schrieb AeriaGloria:

It works fine. The difference is that since last patch the Doppler switch under the map defaults to being off, where it used to default to being on.  You just have to flick the switch under the map from OFF to ON and it will work fine. Took a few flights to really make it a habit in my cold start procedure now. 
 

I don’t know why it would start working at certain altitude and not below, since patch I’ve only flown to 2,000m AGL/ASL. And when I did, it still worked fine provided i had turned the switch on below the Map. If it happenned ar 3,000m AGL for you it would make me think there is some sort of trigger reversing it’s state. As as 3,000m AGL is suppossed to be the altitude limit 

 

Well.. again thank you for pointing that out.. this is extremely relevant, especially for the glancer-in-passing and fellow product user in dire straits.

So addendum ->after noticing for some time, I just tried to finally report that.. and failed to be precise beyond ambiguity again...

So brace, here comes the kicker...
yes, the power switch has now a different (and "better", more realistic, more fidelic) default state. Which is a good thing. Which is also a thing that should have been a thing from the start. 

 

But so would have been any sort of actual documentation (no.. neither community contributions nor marketing skids count.. they are equally dismissable, regardless of their excellent quality and positive intent [for the former]).

So do your checklist and don't forget to turn your map "on"!  (those of us that do not press a magic diaper button  )

BUT!
That bug also manifests with the map power "on" if the aiframe never goes above a as-of-yet undefined "trigger angels" after takeof AND.. and that is the real weird thing... the "snap" manifests even when the map was NEVER turned on. Sou you can trigger an instant magic GPS like "snap" with a map that is OFF and was never ON.

Now how utterly weird is that?

Coming to think of it, I finally made that report on a Tuesday... how.. fitting :).

I would provide a lot of trackfiles.. but as of now it should have become clear to everyone (translation: cannot be longer subject to "spinning") that they do not reliably reproduce bugs, or flights correctly by technical reality and even less so in the current especially unreliable state of the track-replay system (which has been a thing for.. 1, 2 years now?).

And I do not run screengrab video... and there is no function to create proper debug-logs unfortunately.

I have also not made that report on a whim... I started to notice that bug before the last patch.. but seemingly only under conditons I could not systemically identify - and more often to almost permanently after the last o-b patch.

With the "trigger angels snap" manfesting almost permanently more often if I keep the map off (which again.. who does that.. and our fakeflight time is or should be limited after all).

So there is something going on.. and as stated not necessarily with that functional keylog... it might be a more foundational issue just bleeding through.. again.

Edited May 25, 2022 by rogorogo

[AeriaGloria]

32 minutes ago, rogorogo said:

Well.. again thank you for pointing that out.. this is extremely relevant, especially for the glancer-in-passing and fellow product user in dire straits.

So addendum ->after noticing for some time, I just tried to finally report that.. and failed to be precise beyond ambiguity again...

So brace, here comes the kicker...
yes, the power switch has now a different (and "better", more realistic, more fidelic) default state. Which is a good thing. Which is also a thing that should have been a thing from the start. 

 

But so would have been any sort of actual documentation (no.. neither community contributions nor marketing skids count.. they are equally dismissable, regardless of their excellent quality and positive intent [for the former]).

So do your checklist and don't forget to turn your map "on"!  (those of us that do not press a magic diaper button  )

BUT!
That bug also manifests with the map power "on" if the aiframe never goes above a as-of-yet undefined "trigger angels" after takeof AND.. and that is the real weird thing... the "snap" manifests even when the map was NEVER turned on. Sou you can trigger an instant magic GPS like "snap" with a map that is OFF and was never ON.

Now how utterly weird is that?

Coming to think of it, I finally made that report on a Tuesday... how.. fitting :).

I would provide a lot of trackfiles.. but as of now it should have become clear to everyone (translation: cannot be longer subject to "spinning") that they do not reliably reproduce bugs, or flights correctly by technical reality and even less so in the current especially unreliable state of the track-replay system (which has been a thing for.. 1, 2 years now?).

And I do not run screengrab video... and there is no function to create proper debug-logs unfortunately.

I have also not made that report on a whim... I started to notice that bug before the last patch.. but seemingly only under conditons I could not systemically identify - and more often to almost permanently after the last o-b patch.

With the "trigger angels snap" manfesting almost permanently more often if I keep the map off (which again.. who does that.. and our fakeflight time is or should be limited after all).

So there is something going on.. and as stated not necessarily with that functional keylog... it might be a more foundational issue just bleeding through.. again.

 

That is interesting that it happens even if map on. I like pushing that altitude and will Try and replicate. If I do I will post a track file here for you. 
 

I also agree it would be nice to have had that change in patch notes, they have done patch notes for smaller things. I also agree it should’ve been that way since the beginning. It took me a couple flights of “WHY THE HEL ISNTHIS THING NOT WORKING” to realize it was a switch I only ever used to accurately make map corrections/use for location fixes. 

So I will lookout for the bug and post a track here when possible! The time is now to report Mi-24 bugs while they seem to be in the final finishing push for it 

[rogorogo]

vor 6 Stunden schrieb AeriaGloria:

That is interesting that it happens even if map on. I like pushing that altitude and will Try and replicate. If I do I will post a track file here for you. 

well.. if you want the bug to manifest you have do do the following:

MAP POWER ON:

• never exceed treetop level, preferably stay below treetop
• follow terrain ditches down to stay at low AGL and map level 0 (which is not  0 ASL but some random ASL value per map seemingly)

will result in Map not moving, even with correct nose attitude and DISS-15, all other Doppler features working. If you have exceeded an undefined AGL value (I guess 40+ AGL but I was never able to systemically pinpoint and replicate, and tbh... I also did not have the time to "labtest" that) at any point, the map will work as intended (including stopping and drift if attitude too extreme, drift if airspeed-to-doppler turned on aso aso aso) even if you return below treetop. 

There is no reliable way to trigger a "snap"... but it has happened and can happen

MAP POWER OFF:

• fly randomly around
• climb very high, really high, notice "SNAP"
• go down to "normal" envelope angels, notice map not moving (which is correct)
• change position and climb very high, notice "SNAP"

which is the really weird manifestation. You also seem to have some speed and fly level at angels for some time (few minutes) for the "snap" to occur it seems.
 

On an entirely unrelated note but topically fitting (so added as a general note of awareness for any glancers):

That map corrections via the two adjustment wheels result in completely arbitrary drift that do not follow the rules of the "intended" behaviour of that functional keylog is also something that is sub-optimal

P.S. But about any trackfiles.. they are currently at their most unreliable state for replicating anything on a any different system..
 

Edited May 25, 2022 by rogorogo

[AeriaGloria]

7 hours ago, rogorogo said:

well.. if you want the bug to manifest you have do do the following:

MAP POWER ON:

• never exceed treetop level, preferably stay below treetop
• follow terrain ditches down to stay at low AGL and map level 0 (which is not  0 ASL but some random ASL value per map seemingly)

will result in Map not moving, even with correct nose attitude and DISS-15, all other Doppler features working. If you have exceeded an undefined AGL value (I guess 40+ AGL but I was never able to systemically pinpoint and replicate, and tbh... I also did not have the time to "labtest" that) at any point, the map will work as intended (including stopping and drift if attitude too extreme, drift if airspeed-to-doppler turned on aso aso aso) even if you return below treetop. 

There is no reliable way to trigger a "snap"... but it has happened and can happen

MAP POWER OFF:

• fly randomly around
• climb very high, really high, notice "SNAP"
• go down to "normal" envelope angels, notice map not moving (which is correct)
• change position and climb very high, notice "SNAP"

which is the really weird manifestation. You also seem to have some speed and fly level at angels for some time (few minutes) for the "snap" to occur it seems.
 

On an entirely unrelated note but topically fitting (so added as a general note of awareness for any glancers):

That map corrections via the two adjustment wheels result in completely arbitrary drift that do not follow the rules of the "intended" behaviour of that functional keylog is also something that is sub-optimal

P.S. But about any trackfiles.. they are currently at their most unreliable state for replicating anything on a any different system..
 

 

Wether track files are helpful or not, they help the report get taken more seriously by ED. At the minimum, they record the mission parameters and all player inputs. So at minimum those can be checked. 

What about the map adjustment wheels is wrong? I’ve used them recently and had no issues. Is it using them a certain way that doesn’t work out? I use them al the time after landing to reset to FARP position. Or set them to a location for an in flight alignment

[rogorogo]

vor 7 Stunden schrieb AeriaGloria:

Wether track files are helpful or not, they help the report get taken more seriously by ED. At the minimum, they record the mission parameters and all player inputs. So at minimum those can be checked. 

What about the map adjustment wheels is wrong? I’ve used them recently and had no issues. Is it using them a certain way that doesn’t work out? I use them al the time after landing to reset to FARP position. Or set them to a location for an in flight alignment

If you use them this way.. all is fine.. but you should fly a repeatable pattern - you will notice more drift with the map than would happen if you did not readjust.

If you ever change map scale after you have readjusted map scale (which in itself is kind of weird.. it would be an exchange of the paper map.. and a different readout of th dopper logic, which that system can do... but not in flight and that much "on the fly" - also there should be some sort of animation and longer "pause filler" to represent what would actially happen irl for fideltiy) this drift becomes way more noticeable.. to the point where finding your way home if you do not happen to know the terrain features very well by heart can become an issue.

So again the issue is that if you have a repeatable scneario - the functional behaviour changes after an event (in this case, re-adjusting the map).

Which defeats the purpose of this function.. you do not have this feature modelled in-game for the "moving map" to become less precise after needing more re-adjustmen. The "moving map"   imprecision behaviour should not be affected by this.

Again the source-issue is not necessarily in the keylog of the "map module" itself, it could be anything stacking or downflowing or something foundational.

So the personal default behaviour to have the least manifestation of this not so noticeable bug is to just re-adjust when stationary (landed, not even hover) and never change "map scale".  

The manifestation is more imprecision - more drift (repeatable sortie/route, noticeable relevant difference).

The triggers for manifestation are re-adjustment, re-adjustment underway, change of "map scale".

 

P.S. offtopic - about the tracks... again.. it is what it is.. so ofc we keep supplying them, which usually results is its own communication minigame of "needs track" / "track too long, create track with only bug" (???) / "track shows nothing" with inevitable certainty, especially when it comes to actual bugs, so something that is not looks, not minor, something that is functional or at worst exposes a global issue (of which there are many) or a lack of standardization and practices (which would be needed for many many things). Which has no merit except inevitably reducing contributions and the likeliness of "new" contributors. But again, you cannot change mentalities and realities, it is what it is.   

[AeriaGloria]

5 hours ago, rogorogo said:

If you use them this way.. all is fine.. but you should fly a repeatable pattern - you will notice more drift with the map than would happen if you did not readjust.

If you ever change map scale after you have readjusted map scale (which in itself is kind of weird.. it would be an exchange of the paper map.. and a different readout of th dopper logic, which that system can do... but not in flight and that much "on the fly" - also there should be some sort of animation and longer "pause filler" to represent what would actially happen irl for fideltiy) this drift becomes way more noticeable.. to the point where finding your way home if you do not happen to know the terrain features very well by heart can become an issue.

So again the issue is that if you have a repeatable scneario - the functional behaviour changes after an event (in this case, re-adjusting the map).

Which defeats the purpose of this function.. you do not have this feature modelled in-game for the "moving map" to become less precise after needing more re-adjustmen. The "moving map"   imprecision behaviour should not be affected by this.

Again the source-issue is not necessarily in the keylog of the "map module" itself, it could be anything stacking or downflowing or something foundational.

So the personal default behaviour to have the least manifestation of this not so noticeable bug is to just re-adjust when stationary (landed, not even hover) and never change "map scale".  

The manifestation is more imprecision - more drift (repeatable sortie/route, noticeable relevant difference).

The triggers for manifestation are re-adjustment, re-adjustment underway, change of "map scale".

 

P.S. offtopic - about the tracks... again.. it is what it is.. so ofc we keep supplying them, which usually results is its own communication minigame of "needs track" / "track too long, create track with only bug" (???) / "track shows nothing" with inevitable certainty, especially when it comes to actual bugs, so something that is not looks, not minor, something that is functional or at worst exposes a global issue (of which there are many) or a lack of standardization and practices (which would be needed for many many things). Which has no merit except inevitably reducing contributions and the likeliness of "new" contributors. But again, you cannot change mentalities and realities, it is what it is.   

Interesting. I have had issues with the map before when changing scale, and making adjustments after changing scale, but that was a long time ago and I always assumed it fixed. Doesn’t help that I have mainly flown in Syria, where we only have one map scale. But I’ll keep a lookout!

I am fine with the map transitioning scale instantly. I think their development choices were, make it instant or actual animation of opening the glass frame, exchanging paper maps, resetting the position marker. I am happy the way that aspect is as long as we get both scales for all maps eventually, but I understand your point of view

One thing I have noticed with the map, airspeed to doppler seems to work as a backup mode? Not the switch. Can’t get the switch to ever work like always. But when someone shoots my doppler, it seems to use airspeed + heading to still move the map marker. Even for example if I land and my doppler was previously shot out, while waiting for repair my map marker will continue to move along my current heading at the rate the pitot tubes are getting speed signals from the wind. Might be to nice have that work.

   I also never lose CCIP accuracy after doppler loss, but I have a feeling that’s harder to model, unless it’s as simple as ED removing the wind correction. as I think that’s all the doppler does for auto CCIP, just find wind direction and strength by looking at x/y ground speed and comparing it to the other sensors