Padlock wishlist

[Cromewell]

As for what should be done to the padlock, at this point I believe the minimalist aporach would be best because of the programming complexity involved in this.

...

So I think right now the best thing to do is to jsut give it the ability to calculate LoS, that's all.

 

You do realize that you could implement every single other padlock idea we have mentioned in this thread all together, and it wouldn't approach the programming complexity of LoS calculation?

 

-SK

 

The radar and eos already does a LoS calculation, wouldn't it be a realitively simple matter of adjusting the code to work with the padlock function?

[Galaad]

Cromewell wrote

 

The radar and eos already does a LoS calculation, wouldn't it be a realitively simple matter of adjusting the code to work with the padlock function?

 

Very good idea !

[GGTharos]

As for what should be done to the padlock, at this point I believe the minimalist aporach would be best because of the programming complexity involved in this.

...

So I think right now the best thing to do is to jsut give it the ability to calculate LoS, that's all.

 

You do realize that you could implement every single other padlock idea we have mentioned in this thread all together, and it wouldn't approach the programming complexity of LoS calculation?

 

-SK

 

I disagree. LoS computation is already implemented in this sim. All they have to do is call the function and get true/false.

 

Mandella, that's a nice idea.

[SwingKid]

You do realize that you could implement every single other padlock idea we have mentioned in this thread all together, and it wouldn't approach the programming complexity of LoS calculation?

 

-SK

 

I disagree. LoS computation is already implemented in this sim. All they have to do is call the function and get true/false.

 

Every other padlock feature we have thrown around is also already implemented - all they have to do is change a number.

 

I'm not saying LoS is necessarily complex, just that to not assemble a padlock wishlist because it "can't" be made more realistic, or because "it's too complex" to do so, or because there is "no reason" to do so - these are not arguments but rather evasions of the discussion. I would like to include your input, but you don't seem to leave very much room for flexibility towards those of us who are struggling with keyboard head control in single player. I had only 4-way hats on my old joystick which were even worse than keyboard control, you had to re-center the hat before you could move from "right" to "up" - and it was really preferable to just quit and start the mission over than to try to turn the pilot's head with the keypad and then look down to find the little Del key - by which time when you look back at the screen the target has already moved out of the FOV.

 

As for remapping the "Del" key to "Esc" or vice versa - ok sounds good. I'm generally dissatisfied with the default keyboard layout (e.g. the radar cursor and trim controls defaulting to the awkward ;,./ -keys, while the cursor arrow keys sit idle for anyone with a joystick) and am trying to assemble something more convenient and logical with multiple re-assignments, to free up as many HOTAS buttons as possible. As the avionics model becomes more advanced we are already starting to see new commands being mapped to esoteric key combinations as we run out of user interface real estate. If you like using the Del key to padlock, you're going to love where they put new features on the keyboard map for v1.1. :)

 

-SK

[GGTharos]

Well, SK, perhaps you have point ...

 

I favor the minimalist aproach ebcause it works for me - I have a hatswitch which I use to pan the view, and I have the un/padlock key mapped to my HOTAS which makes htis relatively easy - planning is another thing ... I rarely have to padlock someone at close range, I usually have it done before entering the merge.

[Galaad]

Madella wrote

 

How about if F5 could only be used on a target you have already detected and padlocked?

 

Why not, but what becomes the interest of F5 Then?

[Cromewell]

I actually use a combination of the keyboard and joystick hat to look around and then padlock with the del key and am quite happy with the way it works.

I agree there are some issues with the padlockability of planes which are clearly in sight but are outside the 20deg padlock envelope, maybe a radar style scan cone could work here, where padlock has a large detection area close in and it decreases at a defined rate to where at max range you need to be looking almost straight at the target.

[wsoul2k]

You do realize that you could implement every single other padlock idea we have mentioned in this thread all together, and it wouldn't approach the programming complexity of LoS calculation?

 

 

The radar and eos already does a LoS calculation, wouldn't it be a realitively simple matter of adjusting the code to work with the padlock function?

 

Yes but doing this you are double-working the cpu process do do it.....because your cpu will have to calcule the LoS of your Radar it could be pointing to the rigth and will have to the it again to your padlock it could be pointing to the left - DOUBLE WORK to the cpu

[GGTharos]

Yeah, but it's just one calculation every cycle, so it's not really 'double' ... you're not ihugely increasing calculations because you're only tracking a single target.

[wsoul2k]

Yeah, but it's just one calculation every cycle, so it's not really 'double' ... you're not ihugely increasing calculations because you're only tracking a single target.

 

But GGTharos every calculation use ONE SINGLE cicle after that it go back to the queue waiting it time to enter in CPU cicle again and do a NEW calculation...so it is double work ..because the QUEUE wating to enter in cpu cicles will be 2 times bigger to calculate LoS :D

[Cromewell]

It's not that cpu intesive, it's only 1 check per time you press the padlock key, you dont need to check if somethings in LoS all the time.

 

edit: it is a lot of checks while the target is padlocked but its certainly not double the workload. any time nothing is padlocked there would be no check

[GGTharos]

Yeah, but it's just one calculation every cycle, so it's not really 'double' ... you're not ihugely increasing calculations because you're only tracking a single target.

 

But GGTharos every calculation use ONE SINGLE cicle after that it go back to the queue waiting it time to enter in CPU cicle again and do a NEW calculation...so it is double work ..because the QUEUE wating to enter in cpu cicles will be 2 times bigger to calculate LoS :D

 

I know how CPUs work better than you, obviously ;)

 

Don't worry, it won't double the work-load. In fact you could have it check LoS once every 10 Sim frames if you were really worried about this. Thismeans LoS would get checked several times a second.