Jump to content

Can someone else confirm they broke the sensor select switch again? (post hornet)

Thrud

By Thrud
in Resolved Bugs

 Share

Recommended Posts

xBuzz

xBuzz

Posted
Posted

Broken for me too post update.

 

 

 

How is it broken?

 

 

It just doesn't work, when you hit sensor select forward nothing happens. Checked if there were any conflicting keybinds, but there are none.

SierraFox

SierraFox

Posted
Posted

Reports over on Hoggit about it too.

 

Guess i'm not doing the update yet then.

Saitek X-52 | Track IR 5 w/ TrackClip | DSD "Trackzilla" Button Box



Flaming Cliffs 3 | F-5e | Mirage 2000 | A-10c | Harrier AV-8B

[sIGPIC][/sIGPIC]

Zeus67

Zeus67

Posted
Posted (edited)

Hi folks.

My mistake. The Mavs are not bugged, nor is the Sensor Selector Switch.

The device that is bugged is the Target Altitude Source Selector. It checks which sensor the aircraft is used to determine target elevation.

 

 

 

I upgraded it but wrote one question wrong:

Instead of this: if (Selected_Sensor == SENSOR_ARBS), meaning **if the selected sensor is ARBS**

I wrote this: if (Selected_Sensor = SENSOR_ARBS) meaning **set the selected sensor to ARBS**

 

 

One of the dangers of c++: it allows ambiguous statements.

 

 

In other words, instead of asking if the sensor you are using is ARBS, it is actually always setting the sensor to ARBS.

 

 

There is a quick fix until the patch comes out: Turn off the DMT when you are going to use the AGM-65G.

 

 

 

The switch is in the center console. That way ARBS will be disabled and you will be able to set the sensor back to Mavericks. This fix has been tested to work.

ARBS does not affect the 65Es, since those use a laser spot detector that is not handled by the aircraft.

Sorry about the goof and I hope the fix gets out really quick.

 

 

Don't forget to turn on the DMT if you are going to use ARBS.

Edited by Zeus67

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

"The three most dangerous things in the world are a programmer with a soldering iron, a hardware type with a program patch and a user with an idea."

tn_prvteye

tn_prvteye

Posted
Posted

I'm having an issue un-caging the AGM-65Gs...It'll keep"caging" itself without input. Sometimes it won't un-cage at all (yes it's RDY). Is this related, or is something borked on my install?

Zeus67

Zeus67

Posted
Posted
I'm having an issue un-caging the AGM-65Gs...It'll keep"caging" itself without input. Sometimes it won't un-cage at all (yes it's RDY). Is this related, or is something borked on my install?

 

 

I know of another person who has the same problem.

I will suggest a reinstall first and if it does not work then send me a track file.

Because I am unable to reproduce this problem.

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

"The three most dangerous things in the world are a programmer with a soldering iron, a hardware type with a program patch and a user with an idea."

Thrud

Thrud

Posted
  • Author
Posted
I'm having an issue un-caging the AGM-65Gs...It'll keep"caging" itself without input. Sometimes it won't un-cage at all (yes it's RDY). Is this related, or is something borked on my install?

 

 

I noticed that too.

When using the TPOD and the target was out of view of the DMT, it would not uncage. However, if I put the target within the view of the DMT (I never use that thing, maybe after they finish it) it would then uncage the MAV.

tn_prvteye

tn_prvteye

Posted
Posted
I know of another person who has the same problem.

I will suggest a reinstall first and if it does not work then send me a track file.

Because I am unable to reproduce this problem.

 

Seems to happen during cold starts. I just flew a "Fast Mission" starting on the Runway and they would uncage. I'll investigate further tomorrow.

Zeus67

Zeus67

Posted
Posted

Track please so I can see if it reproduces in my machine.

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

"The three most dangerous things in the world are a programmer with a soldering iron, a hardware type with a program patch and a user with an idea."

RED

RED

Posted
Posted

Yeah, if there is a target designated (by a wp/ dmt) the 65G only uncages with the target in it's FOV. Same logic as DMT.

xBuzz

xBuzz

Posted
Posted
Hi folks.

My mistake. The Mavs are not bugged, nor is the Sensor Selector Switch.

The device that is bugged is the Target Altitude Source Selector. It checks which sensor the aircraft is used to determine target elevation.

 

 

 

I upgraded it but wrote one question wrong:

Instead of this: if (Selected_Sensor == SENSOR_ARBS), meaning **if the selected sensor is ARBS**

I wrote this: if (Selected_Sensor = SENSOR_ARBS) meaning **set the selected sensor to ARBS**

 

 

One of the dangers of c++: it allows ambiguous statements.

 

 

In other words, instead of asking if the sensor you are using is ARBS, it is actually always setting the sensor to ARBS.

 

 

There is a quick fix until the patch comes out: Turn off the DMT when you are going to use the AGM-65G.

 

 

 

The switch is in the center console. That way ARBS will be disabled and you will be able to set the sensor back to Mavericks. This fix has been tested to work.

ARBS does not affect the 65Es, since those use a laser spot detector that is not handled by the aircraft.

Sorry about the goof and I hope the fix gets out really quick.

 

 

Don't forget to turn on the DMT if you are going to use ARBS.

 

 

Thanks for workaround on that Zeus, appreciated. :)

Zeus67

Zeus67

Posted
Posted

Thanks fort your comments. I know where the problem is:

 

I enabled a function that when the IRMV sensor head is at gimbal limits it will cage itself. This is an extrapolation of the DMT sensor head that does the same when gimbal limit is reached or the TPOD that places itself on standby upon reaching gimbal limits (the TPOD's gimbal limits are quite large). This is done in order to protect the gimbals. So I thought that the IRMAV should have the same mechanism.

 

I did not take into account that the seeker could be slaved to the DMT and since the DMT has a larger arc the target could be outside the IRMV sensor limits.

 

Unfortunately the documentation I have says nothing about sensor head behavior when reaching the gimbal limit, and I don't like having the sensor locked at some point in space.

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

"The three most dangerous things in the world are a programmer with a soldering iron, a hardware type with a program patch and a user with an idea."

Flagrum

Flagrum

Posted
Posted
Unfortunately the documentation I have says nothing about sensor head behavior when reaching the gimbal limit, and I don't like having the sensor locked at some point in space.

 

Fwiw, the MAVs of the A-10C are not automatically caged, but get boresighted when they reach the gimbal limits.

Zeus67

Zeus67

Posted
Posted

I decided to add an "approaching gimbal limit" warning. The cross will start blinking very fast (5 times per second) so you will now that it will cage very soon.

 

 

If you try to uncage it and it goes to gimbal lock, it will wait 5 seconds before caging. The cross will blink fast.

 

 

That way you will be aware that the missile sensor is outside its working parameters.

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

"The three most dangerous things in the world are a programmer with a soldering iron, a hardware type with a program patch and a user with an idea."

 Share
Go to topic listing

  • Recently Browsing   0 members

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