542 replies to this topic

[uglydisease]

Couple of things, first off the latest update increased the CD on the UAC5 to 1500ms (just like AC5). The rapid fire is still useful as it gives you more control over when to risk a jam. Secondly I've been having some trouble trying to set up multiple weapon groups for different weapon systems. Ex: 2 UAC5s and 2 AC2s each requiring there own keybinds. I thought I could solve this by opening multiple copies of firecontrol but they seem to interact with each other causing all the weapons to fire even though the firing keys are set to different keys in each program instance. I would suggest that you add the ability to set up multiple fire sequences and fire bind keys. I might be able to implement this my self, but I'm unfamiliar with the ahk gui support. Right now I'm either using dakkaDictator with firecontrol or a simple custom script with firecontrol to solve the problem.

[Epic Fail]

So is this legal or is this a macro that is considered an advantage in game?

[evilC]

Yes, it has been confirmed as OK.

There is a quirk with chain fire in MWO. If you have two weapons in a group in chainfire, hitting the button faster than the rate of 1x reload speed often does not speed up the fire rate. Use one group per weapon to solve this.

For example, my current fave dakka mech is 2xAC5, 2xAC2.

I fire AC5, AC2, AC2, AC5, AC2, AC2

I have the AC5s in one group (3) in chainfire - this is OK because I never fire two AC5s in a row (see above).
I put the two AC2s in their own group (so one in 4, one in 5)

Settings for FC for this build:
Fire Rate: 190 with fast fire, else use 210
Fire Sequence: 3,4,5
Limit fire rate: ON

Edit: It is also 100% possible to run more than one copy of FC at a time.

Just run a second copy, be sure to select a different profile in each copy, and make sure none of the bindings are the same in each profile.

Edited by evilC, 30 September 2013 - 12:04 PM.

[evilC]

New version up

2.13 30th Sep 2013
= Sorted a problem with toggles (Arm Lock and Weapon) - when you exited or tabbed out of MWO, the key you bound to this function would be "held".

[uglydisease]

There is definitely a problem with multiple fire binds run from multiple copies:


The notepad file demonstrates the behavior I'm encountering.

[evilC]

OK, I have replicated your issue.

It only happens with the EXE version, if you run the AHK version, it behaves as expected.

I will have to ask on the AHK forums as to why this would be the case.

So for now, please download ADHD from here and perform the "LIBRARY METHOD" instructions in the README.TXT file to install the AHK version.
You will not need to use the firectrl.ahk from inside the ADHD zip - it will be an older version than the firectrl.ahk you have from the Fire Control download.

Hope that makes sense.
Ignore. Problem solved.

Edited by evilC, 01 October 2013 - 06:49 AM.

[evilC]

Actually, I think you have uncovered a more fundamental flaw in ADHD.

It seems that when you changed profile, I did not unbind the keys from the old profile.

Therefore, when you started the second copy, it was double-binding the current profile, and when you switched profile on the second copy, it left two bindings in the first profile.

I think I have fixed this bug, will upload a new version in a minute.

This may also explain some weird behaviour I was seeing myself occasionally.

[evilC]

New version up.

ADHD version 1.15
= Fixed bug with profiles. When you changed profile, the old bindings were not being removed properly.
This could cause some very odd behaviour, especially if running two copies of an ADHD macro

Fire Control is still v2.13, but ADHD is now v1.15

[uglydisease]

The ahk version has the same issue, however I figure out how to fix it. The problem isn't with running multiple copies its with running multiple copies from the same firectrl.ini file simply creating two copies of the program in different directories solves the issue. Interestingly this problem does not occur at all if you set one (or both) of the fire binds to mouse buttons instead of key board keys, which might be why you had trouble replicating the issue. I've noticed in other scripts that the way ahk handles mouse buttons doesn't allways map perfectly to the way it handles keyboard keys. Anyway thanks for expressing an interest in fixing the problem.

[evilC]

The reason having two copies of the ini would not see the issue is that when you fire up the second copy, it would jump right to the correct profile - ie with two copies of the ini, you would never have two copies of FC using the same profile.

1 copy of ini:
Load first instance, it is on "Dakka UAC5".
Load second instance, it is on "Dakka UAC5" as that is what the 1st copy set as "current".
"Dakka UAC5" is now bound TWICE.
In 2nd instance, select "Dakka AC2" - "Dakka UAC5" was NOT UNBOUND before binding "Dakka AC2"

2 copies of ini:
Load first instance, it is on "Dakka UAC5".
Load second instance, it is on "Dakka AC2" already.
No issues.

Moot now anyway, as I fixed it.

Edited by evilC, 01 October 2013 - 06:58 AM.

[uglydisease]

Cool thx for the fix

[Liquid Leopard]

Hi, evilC.
At present, I'm just trying to use your TAG toggle script.
I've changed "MButton" to "7", and added a line for "~u::" to the chat section.
But, with or without those changes I can't get it to work. I also tried running AHK in Administrator mode.


Do I have to use it with Fire Control? Or, should it work by itself?

[ArmageddonKnight]

Alternativly for toggle fire. Buy a Madcats RAT 7 and use the action lock buttons on the left and right buttons

[evilC]

Liquid Leopard, on 02 October 2013 - 02:34 PM, said:

Hi, evilC.
At present, I'm just trying to use your TAG toggle script.
I've changed "MButton" to "7", and added a line for "~u::" to the chat section.
But, with or without those changes I can't get it to work. I also tried running AHK in Administrator mode.


Do I have to use it with Fire Control? Or, should it work by itself?

You mean the old tagtoggle script? Should still work, but I don't support it any more.
Do basic AHK macros work for you?

Honestly, I would try Fire Control instead, there is code in there which should make it more reliable, plus you shouldn't need to edit files to change key bindings.
The chat box detection in the old version was experimental at best, about the only thing the old script has on the new one was it handled holding TAB a little more gracefully.

[Liquid Leopard]

The TAG toggle, from your web site, is the first AHK macro I've ever tried. I have no idea if any others would work.
I'll try downloading Fire Control. Thx.

EDIT: It worked! I can has TAG!

Edited by Liquid Leopard, 07 October 2013 - 01:58 PM.

[Liquid Leopard]

Fuerchtegott, on 19 September 2013 - 03:07 AM, said:

Use your macro tools... ...for some short chat commands.

"Stick together"

"2 brawler wanna follow me through tunnel?"

"I'm an awesome lrm boat, please use "R" key"

"I spotted their main group"

"2-3 fast mechs back to base, they are going to cap"

"Sorry for friendly fire"

I'll bet you can come up with useful stuff too.

Tell new players to visit the forum...

^
Hey, this might be a good idea. How can we do this?

[evilC]

Yeah, I was thinking about this, it would be quite easy to do using my ADHD library - you could have 4 or 5 actions and bind each one to the key of your choice. Could probably use the profiles to give you different settings for each map.

If I have time I may get around to it, but if anyone fancies giving it a go I could probably help - the sample template for ADHD basically does exactly this (Types a predefined string) - you could probably expand the example and have it working in 20 minutes.

[evilC]

Liquid Leopard, on 07 October 2013 - 02:02 PM, said:

^
Hey, this might be a good idea. How can we do this?

I have now written this macro.

See here.

[evilC]

New version up: Fire Control 2.14

BIG CHANGES!

The old timing routine was inaccurate. The actual fire rate would be 50ms or more longer than what you set it to.

The new timing routine is more accurate. As such, your old values for Fire Rate might be too quick, especially if you aggressively tuned them. If you just used values calculated from the actual fire rates, you should be OK but you will be firing a little faster.

If you need any help, just ask.

Edited by evilC, 25 October 2013 - 09:44 AM.

[evilC]

Interestingly, with the new more accurate timing, I have started to uncover something very interesting about ghost heat.

2xAC2 (Grp 5,6)
Firing at 255 ms (To make 100% sure you should NOT hit ghost heat), you do hit it after a couple of seconds.
So 2 shots in half a second and you are hitting ghost heat.
Even firing at 350ms, you still hit ghost heat.

1xAC5 (Grp 3), 2xAC2 (Grp 5,6)
Firing 3,5,6,5,6,5,6 (AC5 once followed by AC2 6 times) @ 255 ms
No ghost heat whatsoever. Note that the AC2s are firing at the same rate, but every 6th shot is an AC5, but there are still 500ms windows where the AC2s have fired just as much as above, yet still no ghost heat. The 250ms gap where an AC5 fires seems to make all the difference.

Hell, if you remove the AC5 from the sequence, and slow the AC2s down so that they still fire the same amount of times in the given period, you still hit ghost heat!

I think that the rules for ghost heat are actually not what they said they were.

What PGI implied:
For any given 500ms window, look at the number of weapons fired in that window and apply ghost heat as applicable.

What I think is actually happening:
Any time you fire, it looks at what happened in the last 500ms, and adds a tally to the ghost heat for each weapon.
The tally only resets 500ms after the LAST fire, not the FIRST fire.

For example, you fire an AC2 at 0ms, 250ms, 500ms, 750ms, 1000ms
5 Shots, spaced by 250ms each.

In theory, for any given 500ms, there are two shots within 500ms of each other, so you would only ever expect to go to 2 on the ghost heat scale.

In reality, each time you fire, you are resetting that 500ms window - so ALL the shots count, moving you to 5 on the ghost heat scale.

By making the middle shot (500ms) an AC5, and the timing 255ms, you can "break the chain" so to speak.

Edited by evilC, 25 October 2013 - 10:01 AM.