Paul Henty
-
Posts
1,652 -
Joined
-
Days Won
74
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by Paul Henty
-
-
No luck unfortunately. I installed it and run your code a number of times. I saw constant lVar updates and I changed lots of knobs and switches. Then flew around for about 15 minutes. No crashes at all.
Paul
-
I've followed your instructions for the stock CJ4 - changing the panel brightness quickly from 0 to 100. No crashes. Tried 5 restarts of your test app.
I also tried the stock a320 using the upper and lower display brightness and also no crashes.
Paul
-
I got MSFS for a month so I can test this properly here. Sadly I can't reproduce the access violation at all. I've tried with my test code and your exact code from three posts up and it runs flawlessly. I did a few 30-minute flights with no problems. I've tried a few different aircraft but I can't see any CRJ so I guess that's in a better version of MSFS or it's third-party. So it could be something with so with the CRJ.
Do you also get access violations with the built-in aircraft?
Paul
-
Quote
Changed call from _LvarsSvc.Init() to _LvarsSvc.Init(this.Handle),
Okay - well I guess John was wrong that you can just pass 0 or any other value. I'll remove this from the next version.
QuoteThe program '[18140] MSFSLvarsWinformsApp.exe' has exited with code -1073741819 (0xc0000005) 'Access violation'.
I'll look into this over the weekend.
Paul
-
Everything looks okay to me.
I suggest using FSUIPC to log the A000 offset. This will take my DLL and your C# application out of the equation.
In FSUIPC7 select Log->Offsets and log A000 as S32 (signed 32bit) a the MSFS Title bar:
With your Lvar to offset set up in the ini file. you should see the value of A000 appear on the title bar. If it's 0 there then the problem is with your FSUIPC setup. You can go back to John with this logging result and without any C# code.
If you can see a good value there then it's something in the C# side of things and we can continue here.
Sorry this is frustrating for you, getting passed back and forth from me to John, but hopefully this strategy will make it clear where any problems are and you can go to the right person. Once you can see valid values in the offset with the FSUIPC7 logging then you can bring the C# part back into play.
Paul
-
Ah so the CRJ isn't resetting the LVar itself. That's a pain, so yes you'll need to do this yourself.
The delay requirement is likely to be down to a timer somewhere. Maybe the CRJ code checking the LVAR value, maybe FSUIPC checking the offset value. If you change it to 0 and then back to 1 too quickly (between another component's timer tick) then it won't notice the change. That would be my guess.
There is also a whole chain of communication from my DLL to FSUIPC to the WASM module to SimConnect to the CRJ code so there are a number of places it could get missed if you change values too quickly.
Paul
-
Quote
1) Reset the offset back to 0 after setting it to 1 previously to initiate the toggle.
Yes, normally offset values are read from the sim when you call Process(). They only write if the value has changed. So setting the value to 1 when you have previously set the value to 1 won't trigger the write.
Your code would be fine if the LVar took an explicit value for each state (which is usually the case), but since it's toggling with a 1 you'll need to use a write-only offset. These write on every process() even if their value has not changed. Because of this it's advisable to put them in their own group so you can control when they are written.
var offset = new Offset<byte>("ToggleHeading", 0xA000, true); // write only
Then your code will only need this:
offset.Value = (byte)1; FSUIPCConnection.Process("ToggleHeading");
QuoteOut of curiosity, when I set the Lvar with your api call:
FSUIPCConnection.WriteLVar("ASCRJ_FCP_HDG", 1);do you clear the offset after?
This uses a special offset that instructs FSUIPC to send the LVAR value. It's write only and clears itself internally after each request. So every time you call this method the Lvar gets written regardless of the previous value.
Paul
-
I can't test this myself as I don't own MSFS.
Your c# code looks fine. I don't think the problem is there.
I notice you're using a profile called crj. Are you sure you've set this up properly in FSUIPC? Are you sure it's being used (active)?
You could try it without using profiles - just change the section to be global:
[LvarOffsets] 1=L:ASCRJ_FCP_HDG=UB0xA000
If that works then your crj profile isn't set up properly or isn't being activated.
If it still doesn't work then John is really the person to help you on this. If you show him your full fsuipc.ini file he might be able to spot the problem.
It's working via all the other code methods so the problem will be somewhere in your FSUIPC configuration.
Paul
-
Version 3.2.9 BETA is now on NuGet. (Tick 'Include Prerelease' to see it).
This might fix the access violation problems. I've changed the way the incoming strings are handles from the C dll. It was technically wrong before so I'm hoping this will fix the problems.
Also there are new overloads for Init() so you don't need to pass a window handle. The DLL will handle this internally.
Paul
-
Quote
I just don't think there is anything I can do at the moment with the info provided.
Understood. It's most likely a problem on my end.
I think I've found a mistake with the way I'm marshalling the strings into the managed code so hopefully that will sort it.
@activexI'll update the thread in my sub-forum later today when I have a new version for you to test.
Paul
-
2 hours ago, John Dowson said:
if its an issue in Paul's client dll then he would look into that.
It could be, but since the error was from the WAPI dll I said to ask you.
There are 2 users experiencing this exception intermittently but I can't reproduce it. I was hoping you might be able to shed some light on it with a line number of something.
I'll take another look at my code and see if there's anything I've missed.
Paul
-
Quote
Exception thrown at 0x00007FFA8FD7722C (FSUIPC_WAPID.dll)
If the exception is thrown by the FSUIPC_WAPID.dll then you need to ask John about that as it's his dll.
QuoteLvars log: [TRACE]: Config data requested...
Same here. The log messages are produced by John's WASM module so I couldn't tell you what this means or if its a problem or not.
Paul
-
Quote
and I have no access to the Window handle.
I don't think it actually uses it to access your window. I think it's just a unique ID that the WASM module uses to keep the requests from multiple clients separated. You can probably just create an IntPtr from a random Int32 value and pass that instead.
QuoteCan you abstract away the requirement of window handle?
Yes, if the random pointer works I could add a constructor without the handle parameter and make a random ID inside the dll.
Quotethe actual lvar was not changed since in the Sim the CRJ lvar was not affected.
[LvarOffsets.crj]
1=L:ASCRJ_FCP_HDG=SD0xA000SD is signed double word which in C# would be a normal 4 byte 'int'. So check your A000 offset is declared as 'int'.
If you don't mean to be working with a c# int you'll need to change SD to the appropriate size:
c# -> size in ini file sbyte -> SB byte -> UB short -> SW ushort -> UW int -> SD uint -> UD double -> do not specify a size.
Paul
-
Quote
Where can I get "You must use FSUIPC-WASMv0.5.0.zip or a later version."
Sorry for the broken links - things are still in development and are getting moved around. I'll amend the post. The latest is 0.5.2. Here is the link:
http://www.fsuipc.com/download/FSUIPC-WASMv0.5.2.zip
If your browser blocks this direct link, goto:
and search for 'WASM'.
QuoteOkay, found a version here:
That's the .lib file, not a dll. Please use the DLL from the zip file above.
To use the dll to your project in Visual Studio:
In Visual Studio you can add this DLL to your project as a normal project item and set the property "Copy to Output Directory" to "Copy if Newer".
QuoteDo you support Read/Write Lvar in FSUIPCClient v3.2.8 out of the box
Yes, FSUIPC7 now supports this legacy method of reading and writing LVARS. It was designed back in the days of FSX and is provided now so that old applications using FSUIPC will now work on MSFS.
You can use this feature if you like (it's a bit easier) but it's significantly slower than using the new MSFSVariableServices. Each LVAR read/write takes up a whole IPC exchange to itself. If you're accessing 10 variables this might be okay. If you want to read 30 or more in real time, this method is going to be too slow.
Paul
-
Quote
As far as I understand, Fsuipc does not provide this data directly. Is it true?
That's true. FSUIPC cannot tell you which airport you are at, or are near to.
Paul
-
If you're using my Client DLL for .NET languages you can use the AirportsDatabase service for this. It reads the files generated by Pete Dowson's MakeRunways program.
For details and examples, please look in the Example Code application available on my Website:
http://fsuipc.paulhenty.com/#downloads
Go through the examples under the section called "Airports/Runways Database" to see how to use the database.
Example "DB003 Finding Airports In Rage" shows you how to get the nearest airport to the player. You can use this to find out if the player is at an airport and which one it is.
Paul
-
Quote
Is it an issue with the .NET Client DLL?
No, this works fine in the .NET client DLL.
Are you using the UpdateExtendedPlaneIndentifiers() method like I told you in the other thread you posted?
Have you tried the AI Traffic Examples in the "Example Code" application? You can download it from my website here:
http://fsuipc.paulhenty.com/#downloads
Run this and go to "AI003 Getting Extended Information" under "AI Traffic".
If it works in the example app, please see the code in the form for how to get the extended information.
If it doesn't work in the example app then it's a problem with FSUIPC7. Please report this to John in the FSUIPC7/MSFS sub forum.
Paul
-
Quote
An offset that tells us the actual status of the connection between FSUIPC and MSFS would be indeed a niceToHave.
I recommend asking John for this in the FSUIPC7/MSFS forum. He's unlikely to see this thread.
https://forum.simflight.com/forum/183-fsuipc7-msfs/
Paul
-
Versions prior to FSUIPC7 all ran inside the Flight Sim process, so FSUIPC could never be left running on its own, so this was never a problem.
I don't know if John has added an offset to FSUIPC7 to know if the Flight Sim connection has been lost. I can't see anything on the spreadsheet. It might be a good feature to request.
For now, you could try something like reading offset 0x0230 (Double) which is a timestamp in seconds. If this doesn't change for a while then you know the connection to MSFS has been lost.
Paul
-
These are extended identifiers. You need to enable them using the AITrafficServices.UpdateExtendedPlaneIndentifiers() method. The way FSUIPC works, it can take a while to get the extended information which is why you need to opt in. The info is cached so the delay is only noticeable when you first update the AI Traffic and when new planes come in to range.
Paul
-
Quote
Will I need to change any existing code for the CDUs?
No, the fix was all within the dll.
Paul
-
Hi Jason,
The CDU class was using the same offset group between multiple instances. I've changed this so each instance will now have its own offset group. This should fix the problem.
Version 3.2.8 is now on NuGet.
Paul
-
MSFS is still under development so many functions are not yet exposed for developers to use.
If you have questions about MSFS specifically, it's best to ask John Dowson in the FSUIPC7/MSFS sub-forum.
https://forum.simflight.com/forum/183-fsuipc7-msfs/
Paul
-
On 7/19/2021 at 1:36 PM, kingm56 said:
That was the first thing I checked, my friend
I don't know what else to suggest, sorry. I've been trying here but I can't reproduce the error and no other users are reporting it. It looks to be something specific to your setup.
Paul
Strange behavior while reading offsets
in FSUIPC Client DLL for .NET
Posted
Your code looks fine. These offsets are new for FSUIPC7 so it looks like a problem specific to FSUIPC7. The historic string offsets like 0x3D00 work fine.
Please report this to John Dowson in the MSFS support sub-forum.
https://forum.simflight.com/forum/183-fsuipc7-msfs/
It looks to me like the 0 terminator at the end of the strings isn't being written. It also looks like there are double quotes in the string which shouldn't really be there.
I guess you could find the end of the string by looking for the second double quote, but that's not really how it's meant to work. There should be a 0 terminator which my DLL will handle for you.
Paul