Macro with Lvars

[Mike...]

My problem at the moment is that the macro control I want to assign to a joystick button does not appear in the list of controls in FSUIPC (3.989s).

My FSUIPC.ini file has this section:

[MacroFiles]
1=QW757

There is indeed a macro file in my Modules folder, called QW757.mcro, and it contains the following:

[Macros]
1=L:apleft=Tog

The Lvar apleft was listed in FSUIPC's log file after using that particular function and I also verified it in FS Panel Studio (value of 0 or 1, hence Tog). It may or may not work, but why isn't it showing up as a selectable control?

I've read various parts in the user guide and advanced user guide. I also did some searching on this forum and found this thread interesting. It may be the late hour, but I can't see what I'm missing.

:wink:

[Gypsy Baron]

My problem at the moment is that the macro control I want to assign to a joystick button does not appear in the list of controls in FSUIPC (3.989s).

My FSUIPC.ini file has this section:

[MacroFiles]
1=QW757

There is indeed a macro file in my Modules folder, called QW757.mcro, and it contains the following:

[Macros]
1=L:apleft=Tog

The Lvar apleft was listed in FSUIPC's log file after using that particular function and I also verified it in FS Panel Studio (value of 0 or 1, hence Tog). It may or may not work, but why isn't it showing up as a selectable control?

I've read various parts in the user guide and advanced user guide. I also did some searching on this forum and found this thread interesting. It may be the late hour, but I can't see what I'm missing.

:wink:

Try changing "Tog" to "TOGGLE" or "Toggle". I don't see "Tog" listed as an ACTION in the Advanced Users guide.

Paul

[Pete Dowson]

The Lvar apleft was listed in FSUIPC's log file after using that particular function and I also verified it in FS Panel Studio (value of 0 or 1, hence Tog). It may or may not work, but why isn't it showing up as a selectable control?

It looks like a bug in FSUIPC3. I can reproduce it here. It works find in FSUIPC4, so I'll take a look to see what the difference is internally.

Back soon ...

.. actually it's getting a bit late here, so I'll tackle this in the morning. Sorry.

Regards

Pete

[Mike...]

LOL! Today is fine, I do not expect you to work through the night.

:D

Try changing "Tog" to "TOGGLE" or "Toggle". I don't see "Tog" listed as an ACTION in the Advanced Users guide.

From the Advanced Users PDF: "Where ACTION must be one of: Set, Inc, Dec, Cyclic or Toggle (but only the first 3 letters are needed)". So I assume Tog is fine.

;-)

[Pete Dowson]

LOL! Today is fine, I do not expect you to work through the night.

Okay. Fixed in 3.989t, available now in the Download Links subforum. There was a chunk of code actually missing! I've no idea how that happened!

Regards

Pete

[Mike...]

It's working fine now and my macro is having an effect on the panel, just not what I was expecting, but we can work on that.

Thanks a lot, Pete!

;)

Edit: Just dropping by to say that L:apleft_clicked did the trick instead. Woot!

[Mike...]

Still working fine, but I had a question about combining macros/actions.

I currently have a joystick button that does Shift D when pressed. That triggers the above macro just fine, as Shift D has been assigned the macro in FSUIPC. What is now the best way to have Shift D do two things? The above one and a new one I have successfully generated. So far my (trial and error) tests have failed.

I have a PMDG.MCRO with the following:

[Macros]

Module="PMDG_737NG_Main.GAU"

1=CMD=RX32c0*X6a90

Which works fine on its own, but how do I merge that with QW757.MCRO, which looks like this:

[Macros]

1=L:apleft_clicked=Tog

I've been through the user guide and advanced user guide, but I'm none the wiser. I suppose I could assign one to press and the other to release, but I have a feeling they can be combined and assigned as one, but how?

:???:

[Pete Dowson]

I currently have a joystick button that does Shift D when pressed. That triggers the above macro just fine, as Shift D has been assigned the macro in FSUIPC.

What a roundabout way of doing things. Why not simply assign the macro to the button directly, instead? What's the reason for going via the keyboard? It's very inefficient and adds extra messaging through Windows for no good reason.

What is now the best way to have Shift D do two things?

With a button you can have multiple entries in the [buttons] section of the INI file for any button. The action in the order listed. Or you can put multiple actions into a macro, as documented.

I have a PMDG.MCRO with the following:

[Macros]

Module="PMDG_737NG_Main.GAU"

1=CMD=RX32c0*X6a90

Which works fine on its own, but how do I merge that with QW757.MCRO, which looks like this:

[Macros]

1=L:apleft_clicked=Tog

As it shows in the Advanced User's guide, any macro can have multiple actions in it. That's the original and main purpose of macros, and, in fact, why they are called macros (as opposed to 'micros' <G>).

e.g something like:

[Macros]
Module="PMDG_737NG_Main.GAU"
1=Combined CMD
1.1=RX32c0*X6a90
1.2=L:apleft_clicked=Tog

I've been through the user guide and advanced user guide, but I'm none the wiser.

Then how did you miss the section entitled "Multiple actions in one macro control" in the part about macros, page 39 (ish) in the Advanced User's guide?

Regards

Pete

[Mike...]

What a roundabout way of doing things. Why not simply assign the macro to the button directly, instead? What's the reason for going via the keyboard? It's very inefficient and adds extra messaging through Windows for no good reason.

LOL! I knew you were going to bring that up and so you should, but I do have my reasons.

Then how did you miss the section entitled "Multiple actions in one macro control" in the part about macros, page 39 (ish) in the Advanced User's guide?

Who said I missed anything? Trust me, I went through it all several times, but the old brain (it recently turned 30) simply couldn't connect the dots this evening. What confused me the most was that I would be combining different types of macros. The example you've given, the role of the gauge name, by looking at it one could assume 1.2 is associated with that specific gauge, but obviously it isn't. I wasn't sure how to merge that together.

In retrospect, it may also be good idea to look at the "aircraft specific" features. After all, Shift D must do different things in different aircraft, for now. And not necessarily different things in the same aircraft. Ah, it used to be so simple, flying default aircraft around...

:lol:

Anyway, thanks for the example, I'll take a fresh look at it tomorrow and decide which way I want to go.

;)

[Pete Dowson]

The example you've given, the role of the gauge name, by looking at it one could assume 1.2 is associated with that specific gauge, but obviously it isn't. I wasn't sure how to merge that together.

Gauge names are only relevant to mouse macros, because they point to the code the mouse intercept found and hooked into with the offset listed. If you have more than one module referred to in a macro file they'd have numbers, and the number would be part of the mouse macro encoded for it -- but that's line by line. A multiline macro can contain any mixture, including keypresses, mouse macros, L:vars, FS controls.

Regards

Pete

[Mike...]

Future proofing the above would then give something like this?

[Macros] 
Module1="PMDG_737NG_Main.gau" 
1=CMD 
1.1=R1:RX32c0*X6a90 
1.2=L:apleft_clicked=Tog

Edit: that doesn't work. If I leave out 1 and R1:, it does work. Thought just 1: instead of R1: then, but no go either.

There's something about that R that doesn't make sense.

ModuleN="name of gauge or DLL"

Otherwise it is simply N:, referring directly to the module.

where 'N' can run from 1 to 99

So, Module1 > 1.1=1:RX32c0*X6a90, but that doesn't even get recognized by FSUIPC.

But there are various examples, a bit further down in the PDF and in the main FSUIPC zip (PMDG OH sample), where there is an apparent relation between Module<number> and R<number>. Module1, all R1, Module 2, all R2, etc...

I should've waited until tomorrow. Maybe I forgot to reload all keys between tries...

:D

[Pete Dowson]

Future proofing the above would then give something like this?

[Macros] 
Module1="PMDG_737NG_Main.gau" 
1=CMD 
1.1=R1:RX32c0*X6a90 
1.2=L:apleft_clicked=Tog

Edit: that doesn't work. If I leave out 1 and R1:, it does work. Thought just 1: instead of R1: then, but no go either.

There's something about that R that doesn't make sense.

You are reading the description incorrectly. The "R" must be the first letter, defining a Rectangle. Then you either get the offset (X...) or the module number and offset (1:X...). You've got two "R"s.

In other words, the "R" defines what's coming. The module number and offset go together. You''ve separated them every time with an R.

Pete

[Mike...]

So it should be R1:X32c0*X6a90?

Well, that misunderstanding is because of page 41, where <rect#> is defined as "Rn" or "RXxxxx*xxxx" (shouldn't that be "RXxxxx*Xxxxx"?). Instead of keeping both, you're essentially inserting something in between. Going to "R(N:)n" and "R(N:)Xxxxx*xxxx". I think.

;)

[Pete Dowson]

So it should be R1:X32c0*X6a90?

Yes. Only the one 'R'. It is that which defines what is coming, much like K for keypress, C for control, etc.

Well, that misunderstanding is because of page 41, where <rect#> is defined as "Rn" or "RXxxxx*xxxx" (shouldn't that be "RXxxxx*Xxxxx"?). Instead of keeping both, you're essentially inserting something in between. Going to "R(N:)n" and "R(N:)Xxxxx*xxxx". I think.

Hmm. Yes. The base format is defined earlier, in about the 3rd para of the "mouse macros" section. It's shown there, clearly, as

R<module>:<rect#>,<mouseflag>

and then it expands on each of those parts. You'll see that "<module>:" is defined as one optional part -- module number and : together.

But I do see what you mean now, that the "R" is being repeated in the definition of the Rectangle itself. Sorry about that -- i'll remove those Rs. They stood there now for several years!

Regards

Pete

[Mike...]

You've provided a wealth of info in those docs as it is.

;)

Okay, so the below:

[Macros]
Module1="PMDG_737NG_Main.gau"
1=CMD L
1.1=R1:X32c0*X6a90
1.2=L:apleft_clicked=Tog

1.1 works fine, 1.2 doesn't. Must FSUIPC be able to execute 1.1 before it can do 1.2? In this case, the gauge is not loaded (different aircraft), so one expects it to then do 1.2. Hmmm... In a hurry now, so I'll have to look closer into that later.

[Pete Dowson]

1.1 works fine, 1.2 doesn't. Must FSUIPC be able to execute 1.1 before it can do 1.2? In this case, the gauge is not loaded (different aircraft), so one expects it to then do 1.2. Hmmm... In a hurry now, so I'll have to look closer into that later.

Ah. I don't know without going through the code. I suppose it is possible -- it may abandon the attempt to execute this if that module check fails. Does it work if you swap them round?

If so I might be able to change it. But why would this happen? Wouldn't you be using different macros for different aircraft?

Regards

Pete

[Mike...]

[Macros]
Module1="PMDG_737NG_Main.gau"
1=CMD L
1.1=L:apleft_clicked=Tog
1.2=R1:X32c0*X6a90

Continues to work for X32c0*X6a90, even though the Lvar is not present. So I'm thinking that doesn't matter. 1.1 itself though, doesn't work.

Standalone, this does work:

[Macros]
1=L:apleft_clicked=Tog

:?:

Wouldn't you be using different macros for different aircraft?

Yeah, I know, I am pushing it a little. I need to rethink my strategy, but I would still like to figure this one out.

;)

[Pete Dowson]

[Macros]
Module1="PMDG_737NG_Main.gau"
1=CMD L
1.1=L:apleft_clicked=Tog
1.2=R1:X32c0*X6a90

Continues to work for X32c0*X6a90, even though the Lvar is not present. So I'm thinking that doesn't matter. 1.1 itself though, doesn't work.

Standalone, this does work:

[Macros]
1=L:apleft_clicked=Tog

That's odd. It should work. It must be a bug. I'll do some tests here. Can't do it till tomorrow though. Sorry.

Pete

[Mike...]

In the mean time I've tried the aircraft specific feature, with ShortAircraftNameOk set to Yes. Everything seems to work and in one go! I think I was overcomplicating it a bit.

That latest oddity doesn't have to be looked at urgently, if at all, when you have some spare time, that will be fine. It remains just that though, odd.

Anyway, thanks for all your help and patience, I really appreciate it. I'll try and do some flights soon and think about what else I can turn into macros.

:grin:

[Pete Dowson]

That's odd. It should work. It must be a bug. I'll do some tests here.

:oops::oops::oops:

I feel like a right dummy. There's a very good reason why it doesn't work, and can't work without a bit of a re-design internally.

In the normal one-line macro:

1=CMD L=R1:X32c0*X6a90

the name of the macro, as seen in the assignments, is "CMD L". The rest, after the = is the 'action'.

When you make a multiline macro, the name is split from the line and the actions are listed:

1=CMD L

1.1=R1:X32c0*X6a90

BUT when the L:var facility was 'shoehorned' into this arrangement:

2=L:apleft_clicked=Tog

the name, that you see in the assignments, is "L:apleft_clicked", and the action follows the = after it, BUT now the name is actually also very relevant to the action, because it gives that vital information, the name of the L:var to be changed!

A multiline L:var macro could theoretically exist, like say:

2=L:apleft_clicked

2.1=Tog

2.2=Cyc,5

but it probably would never really make sense.

The only way I could get the combination you wanted to work would be to add more structures to the internal tables. I don't think I want to complicate it further really. Especially when the same things can be accomplished via either multiple assignments to buttons, or, perhaps much more flexibly, with Lua plug-ins. I am more interested in expanding plug-in facilities than the rather arcane and less user-friendly formats of assignments in the INI files.

I hope you understand, and sorry for being so forgetful about my own designs. I put is down to senility and too much good wine! ;-)

Regards

Pete

[Mike...]

LOL! I do understand, so it's probably best to leave it as is.

Thanks again.

;)