Jump to content

Fire Control - "proper" Chain Fire For Mwo / Tag Toggle / Jump Jet Spam [Fc 3.0.7 - 30Th Jan 2017]


542 replies to this topic

#21 kuangmk11

    Member

  • PipPipPipPipPipPipPip
  • Veteran Founder
  • Veteran Founder
  • 627 posts
  • LocationW-SEA, Cascadia

Posted 11 July 2013 - 07:17 PM

This is nice evilC. Your scripts are great, I have co-opted several from my own use. I have a question:

when building the GUI can I call a subroutine when a value is changed in your formatting?

Example:

Regular AHK way:
Gui, Add, DropDownList, x22 y76 w60 h120 vNumWeapons gCalc, 1||2|3|4|5|6


ADHD way:
ADHD.gui_add("DropDownList", "NumWeapons", "xp+120 yp-2 W30 gCalc", "1|2|3|4|5|6", "1")

Edited by kuangmk11, 11 July 2013 - 07:18 PM.


#22 Sniper Behind Ya

    Member

  • PipPipPip
  • The Hunter
  • The Hunter
  • 57 posts

Posted 11 July 2013 - 07:29 PM

Kudos!

#23 evilC

    Member

  • PipPipPipPipPipPipPipPip
  • Legendary Founder
  • Legendary Founder
  • 1,298 posts
  • LocationLondon, UK

Posted 12 July 2013 - 05:10 AM

View Postkuangmk11, on 11 July 2013 - 07:17 PM, said:

This is nice evilC. Your scripts are great, I have co-opted several from my own use. I have a question:

when building the GUI can I call a subroutine when a value is changed in your formatting?

Example:

Regular AHK way:
Gui, Add, DropDownList, x22 y76 w60 h120 vNumWeapons gCalc, 1||2|3|4|5|6


ADHD way:
ADHD.gui_add("DropDownList", "NumWeapons", "xp+120 yp-2 W30 gCalc", "1|2|3|4|5|6", "1")


Seeing as all controls call the same subroutine (adhd_option_changed), you do not have to pass the g-label to gui_add for it to be able to add it.
Which you can see by examining gui_add:
gui_add(ctype, cname, copts, cparam3, cdef){
; Note this function assumes global so it can create gui items
Global
Gui, Add, %ctype%, %copts% v%cname% gadhd_option_changed, %cparam3%
this.ini_vars.Insert([cname,ctype,cdef])
}

The purpose of the adhd_option_changed function is primarily to alter the INI file so as to preserve user settings between runs.

Also, It is not actually that obvious from the AHK documentation, but you can alter the g-label of a control after you add it.
You can use something like
GuiControl, +gmy_new_subroutine, NumWeapons

So if you wished to do some of your own processing after the control changed, but before writing to the ini, you could do something like this:
[...]
ADHD.gui_add("DropDownList", "NumWeapons", "xp+120 yp-2 W30 gCalc", "1|2|3|4|5|6", "1")
GuiControl, +gmy_new_subroutine, NumWeapons
[...]
 
my_new_subroutine:
; insert your code here
; ...
 
; Call the option_changed routine afterwards to handle saving of options
Gosub, adhd_option_changed
return

Edited by evilC, 12 July 2013 - 05:13 AM.


#24 evilC

    Member

  • PipPipPipPipPipPipPipPip
  • Legendary Founder
  • Legendary Founder
  • 1,298 posts
  • LocationLondon, UK

Posted 12 July 2013 - 05:16 AM

By the way, what feature / change are you trying to add?
I would much rather people altered the code and fed back their improvements, than have their own personal versions.
That way, as each person improves the code, everybody benefits.

#25 kuangmk11

    Member

  • PipPipPipPipPipPipPip
  • Veteran Founder
  • Veteran Founder
  • 627 posts
  • LocationW-SEA, Cascadia

Posted 12 July 2013 - 10:19 AM

View PostevilC, on 12 July 2013 - 05:16 AM, said:

By the way, what feature / change are you trying to add?
I would much rather people altered the code and fed back their improvements, than have their own personal versions.
That way, as each person improves the code, everybody benefits.

Thanks for the explanation evilC. That will allow me to do what I need. I wrote my own chainfire script a bit ago and I have been slowly improving it. I could never achieve a fire rate that was as stable as I liked though. I'm still an AHK novice so my methods are a bit rudimentary sometimes. The fire rate on your script seems much more stable.

The thing I added to your firectrl script was a simple calculator that would allow you to select your number of weapons/groups, type, and fast fire efficiency and feed the correct fire rate into the the "Fire Rate" field. I'll clean it up and send it to you with the glabel changes.

One of the other things I tried to do with my script somewhat successfully was to time the actual fire rate and if it was higher than the "Ideal Rate", adjust the rate. Another approach was to just hold the keys after the first cycle ensuring the ideal rate, but unless the timing was perfect on the first round you would get a funny pattern.

#26 evilC

    Member

  • PipPipPipPipPipPipPipPip
  • Legendary Founder
  • Legendary Founder
  • 1,298 posts
  • LocationLondon, UK

Posted 12 July 2013 - 11:00 AM

Right, I had meant to add something at some point to calculate that for you, but it was a bit down the priority list to be honest.
If you feel like setting up the controls and populating the data, I would be happy to include it.
I would make a recommendation though - have it grab the data from an INI file, that way the implementation is not MWO specific and can be integrated into FireControl (Which tries to be as game agnostic as possible to make it useful with as many games as possible).

Also a hint regarding MWO's quirky handling of rapid fire:
Say you map LButton to press 1 rapidly.
If you do not send an Lbutton up straight after an LButton down, then no matter how fast the script sends 1, MWO will behave as if 1 is held down. It matters not if LButton is not programmed to anything in MWO - as long as the "originating" key is held, the "sent" key cannot properly generate keyup events in MWO it seems.

#27 evilC

    Member

  • PipPipPipPipPipPipPipPip
  • Legendary Founder
  • Legendary Founder
  • 1,298 posts
  • LocationLondon, UK

Posted 12 July 2013 - 11:05 AM

Oh, and by the way, I forgot that I had catered for a user's need to hook into the option changed event.
You do not need to change any ADHD code to hook into the option changed event.

In Fire Control, the line:
ADHD.config_event("option_changed", "option_changed_hook")
specifies that any time an option is changed, the option_changed_hook() function (Which is a "user" routine - ie part of Fire Control not ADHD) is called in addition to the normal adhd_option_changed routine.

So whatever your changes are, you should be able to put them in there and not need any changes to the ADHD library to achieve the desired result.

Edited by evilC, 12 July 2013 - 11:06 AM.


#28 evilC

    Member

  • PipPipPipPipPipPipPipPip
  • Legendary Founder
  • Legendary Founder
  • 1,298 posts
  • LocationLondon, UK

Posted 14 July 2013 - 02:46 AM

New versions up, some bugfixes and a fluff improvement.
I am now recording current versions etc in the SECOND post (Not the OP). I will always bump the thread when a new version comes out though, so subscribing to the thread will always keep you abreast of changes.

#29 New Day

    Member

  • PipPipPipPipPipPipPipPip
  • Veteran Founder
  • Veteran Founder
  • 1,394 posts
  • LocationEye of Terror

Posted 23 July 2013 - 01:45 PM

Brilliant.

#30 evilC

    Member

  • PipPipPipPipPipPipPipPip
  • Legendary Founder
  • Legendary Founder
  • 1,298 posts
  • LocationLondon, UK

Posted 02 August 2013 - 05:16 AM

Some people reported that the EXE version of Fire Control was not working for them.

This appears to be related to UAC and the fact that MWO runs as admin.

I added some instructions to the second post that should help users being affected by this work around the issue.

I am looking into better solutions and will keep y'all posted.

Plus I also have a question in the latest "Ask the Devs" thread about chain fire, mouse wheel zoom and a bunch of other stuff related to this and other macros I have written. If you feel like helping me get some answers as to when these issues will be fixed properly, please vote for my question here.

#31 Punk Oblivion

    Member

  • PipPipPipPipPipPip
  • The Scythe
  • The Scythe
  • 352 posts

Posted 09 August 2013 - 10:06 AM

Just started playing with this today and it's great! A great option for broke people like me who can't afford expensive mice/keyboards. Hopefully PGI will just add something like this into UI 2.0.

I do have a question/comment though. When you have "limit fire rate" checked, you have the program makes a "Dong" noise when it prevented a click. But if you make some super long chains out of say, UAC5's and AC2's and hold down the button, after you let the button go you get a long chain of these Dong noises, I assume because it's "preventing" the clicks from you just holding down the fire button.

Is there a way you can just disable this sound, or a way to put in this option in the future? It's only slightly annoying, but I guess I just notice those kinds of things.

Edited by Punk Oblivion, 09 August 2013 - 10:07 AM.


#32 evilC

    Member

  • PipPipPipPipPipPipPipPip
  • Legendary Founder
  • Legendary Founder
  • 1,298 posts
  • LocationLondon, UK

Posted 09 August 2013 - 02:13 PM

Hmm, not heard of getting a long chain of dong noises after you release.
Can you reproduce this out of game (ie in notepad)?
Can you tell me settings to use to reproduce this?
If you wish to disable sounds for now, you could use the AHK version of the script, and edit firectrl.ahk
put a ; at the start of line 241 - so it looks like this:
;soundplay, *16

#33 xXBornOfFireXx

    Rookie

  • Elite Founder
  • Elite Founder
  • 7 posts

Posted 09 August 2013 - 05:06 PM

Hey, loving your program, but I have a small problem. I use shift to focus my arms and torso weapons. When I do this it doesn't allow me to fire. Any way around this?

#34 Punk Oblivion

    Member

  • PipPipPipPipPipPip
  • The Scythe
  • The Scythe
  • 352 posts

Posted 09 August 2013 - 08:30 PM

View PostevilC, on 09 August 2013 - 02:13 PM, said:

Hmm, not heard of getting a long chain of dong noises after you release.
Can you reproduce this out of game (ie in notepad)?
Can you tell me settings to use to reproduce this?
If you wish to disable sounds for now, you could use the AHK version of the script, and edit firectrl.ahk
put a ; at the start of line 241 - so it looks like this:
;soundplay, *16


It does NOT reproduce in notepad.
Setting are:
Fire sequence: 3,5,6,4,5,6
Fire rate 250
weapon toggle group none
Limit fire rate IS checked
Fire: spacebar
change fire rate: none
Weapon toggle: none
Limit application to CryENGINE

I am running this with 2 AC5's and 2 AC2's on a Jm6-DD

#35 evilC

    Member

  • PipPipPipPipPipPipPipPip
  • Legendary Founder
  • Legendary Founder
  • 1,298 posts
  • LocationLondon, UK

Posted 10 August 2013 - 03:22 AM

Thanks for doing the tests.
Can you reproduce the issue using a different fire button?
Could you maybe comment out that line and see if it still makes a noise?

This has me really curious, I can see no reason why the macro would make a load of noises at once *after* you release a key.
The only time it is programmed to make a sound is when you press a key, and only once, and only if you pressed it too soon.

Could you maybe try editing out that soundplay line I mentioned and see if you still get the sound?

#36 Punk Oblivion

    Member

  • PipPipPipPipPipPip
  • The Scythe
  • The Scythe
  • 352 posts

Posted 10 August 2013 - 09:14 PM

Well for starters I am not that awesome at advanced programming stuff and don;t have a ton of free time, thus why I use the firectrl, and NOT mess around with AHK modding.

BUT I switched it from spacebar to right mouse button and the noise did NOT happen, so it seems to be linked to only the spacebar.

Other issues with using the space bar:
typing in chat puts in a number every time you use the spacebar.
Hitting shift to unlock your arms, then hitting space to "rapid fire" won't allow the weapons to fire until you release shift.


Using spacebar may be weird to some people, but mouse button 5 has always "been push to talk", and mouse button 4 has always been "jump" (or in MWO, jempjet). I would gladly use shift alone for a fire option, but the program wants you to input shift+"anotherbutton" to work as a fire key.

Also sorry for typos, I am a bit inhebri... inebriat.... drunk :-P

#37 RG870

    Member

  • PipPip
  • 33 posts

Posted 10 August 2013 - 10:25 PM

I followed the instructions from the 2nd post. Still, it is not working for me in MWO (Win7_64bit). Works fine in Notepad. Any ideas besides from disabling UAC (which is no option for me)?

Edited by RG870, 10 August 2013 - 10:25 PM.


#38 evilC

    Member

  • PipPipPipPipPipPipPipPip
  • Legendary Founder
  • Legendary Founder
  • 1,298 posts
  • LocationLondon, UK

Posted 11 August 2013 - 06:12 AM

Punk - thanks for the heads up, this info should give me a reasonable chance of fixing it.

View PostRG870, on 10 August 2013 - 10:25 PM, said:

I followed the instructions from the 2nd post. Still, it is not working for me in MWO (Win7_64bit). Works fine in Notepad. Any ideas besides from disabling UAC (which is no option for me)?

Can you turn off UAC temporarily to find out if it is the solution, or are you on a locked down machine or something?

#39 evilC

    Member

  • PipPipPipPipPipPipPipPip
  • Legendary Founder
  • Legendary Founder
  • 1,298 posts
  • LocationLondon, UK

Posted 11 August 2013 - 06:44 AM

View PostPunk Oblivion, on 10 August 2013 - 09:14 PM, said:

BUT I switched it from spacebar to right mouse button and the noise did NOT happen, so it seems to be linked to only the spacebar.

I have now reproduced this issue. It happens with all keys.
It seems that the problem is that when you hold a key in AHK, it auto-repeats, whereas mouse buttons do not.
Looking into fixing this right now.

View PostPunk Oblivion, on 10 August 2013 - 09:14 PM, said:

Other issues with using the space bar:
typing in chat puts in a number every time you use the spacebar.

Hmm, this is a tough one to solve. The only way to properly solve it is to somehow "teach" the game how to recognize it is in chat mode. The only reliable way I can think of doing this is pixel detection (Look for the dark background of the chat box on the screen) and that is opening a can of worms I am not sure I wish to open.
This would happen with any keyboard mapping.

View PostPunk Oblivion, on 10 August 2013 - 09:14 PM, said:

Hitting shift to unlock your arms, then hitting space to "rapid fire" won't allow the weapons to fire until you release shift.

I think I know how to solve this one.

View PostPunk Oblivion, on 10 August 2013 - 09:14 PM, said:

Using spacebar may be weird to some people, but mouse button 5 has always "been push to talk", and mouse button 4 has always been "jump" (or in MWO, jempjet). I would gladly use shift alone for a fire option, but the program wants you to input shift+"anotherbutton" to work as a fire key.

My solution to this was to put an xbox controller on the floor and click the right analogue stick with my toe for push-to-talk
I find this is a good solution because you can use the same method in all games and only if you need VOIP do you need to use the controller on the floor. You can then use the same control layout for all games regardless of if they use VOIP or not.
But whatever, your bug report is welcomed and I will do what I can to solve as many of these issues as possible.

#40 evilC

    Member

  • PipPipPipPipPipPipPipPip
  • Legendary Founder
  • Legendary Founder
  • 1,298 posts
  • LocationLondon, UK

Posted 11 August 2013 - 06:52 AM

Oh, and one more thing Punk...
How do you have your other fire buttons programmed?
For example, you should have Left mouse and Right mouse programmed to weapon groups 1 and 2.

If for a given build you do not need weapon group 2, you can bind Fire Control to Right Mouse.

So your fire sequence is 3,5,6,4,5,6
Make sure there is nothing in weapon group 2.
Bind Fire to RButton.

Now you can happily use the right mouse button for the rapid fire.
Were you aware of this?





2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users