P3Dv4 ground friction

[jeehell]

Hello Pete,

 

In the FSUIPC5 announcement you state P3D v4 is handling ground friction in a different way then earlier versions.

I have been looking into that myself as I have an application which changes the friction in real-time, and it seems to me there are no differences, except the address in the Sim1.dll. Everything seems to work just as before. 

I also looked into the SDK and no clue in that direction. Do you have any official information on this different handling??

Regards

Jean Luc

[Pete Dowson]

10 minutes ago, jeehell said:

In the FSUIPC5 announcement you state P3D v4 is handling ground friction in a different way then earlier versions.

I didn't say that! I said "P3D improvements to ground friction will possibly make these facilities reducndant". Maybe it was pure hope, but L-M have said they were working on improved flight modelling and so on and I would assume they'd look at frictions too. But maybe no one has ever asked them, has never pointed out the need. Or maybe improvements are to follow.

Pete

 

[jeehell]

Ok, thanks for the answer.

Well then you'll be "happy" (or not...) to know that there seems to be no change whatsoever in air files, the way they are loaded and used  in process memory, all aerodynamic computations, as well as ground friction, based on my research so far and also others such as Hervé Sors.

 

[kand]

Hi Pete, does this mean the FSUIPC4 SIM1.DLL dynamic patching is a possibility for FSUIPC5? really hope so as I have written my own airfile for my 777 based on rw thrust values, I then reverse engineered the friction coefficient to "ball park" the real GE90 engines, 

Taxiing in P3d v4 is like trying to roll in treacle !!

 

regs Keith

[Pete Dowson]

2 hours ago, kand said:

does this mean the FSUIPC4 SIM1.DLL dynamic patching is a possibility for FSUIPC5?

Only with L-M's help. It has been requested, among other things.

Pete

 

[kand]

sorry to keep harping on about this! would the LUA dynamic friction still work or is that also dependent on LM? 

[Pete Dowson]

31 minutes ago, kand said:

e LUA dynamic friction still work or is that also dependent on LM? 

You mean in P3D4? No!!!! The friction tables are NOT (repeat NOT) available!

Pete

 

[kand]

Ok thanks, will get my hex editor out and adjust sim1.dll in the interim

[Pete Dowson]

2 hours ago, kand said:

will get my hex editor out and adjust sim1.dll in the interim

Have you located the tables in the 64-bit module?

Pete

 

[herve_sors]

P3Dv4 Sim1.dll (4.0.23.21468) rolling friction coefficient tables (with scalars) are at offset 0x148580. Braking coefficient tables are at offset 0x149840. As far as I could see, structure is similar to that of previous P3D versions (and FSX)

Hervé

 

[kand]

sorry Pete, I made an assumption that you were already aware the Sim1.DLL offsets were the same, was reason I couldn't come to terms with the loss! Completely understand how the move to 64bit could have changed the addresses but as Hervé says it seems to be the same.  

[Pete Dowson]

1 hour ago, kand said:

I made an assumption that you were already aware the Sim1.DLL offsets were the same

For 64-bit I don't really understand the code -- it looks very different from the assembly code I know (and can actually code reasonably fluently as it was my original langiage, "rising" to BCPL (the predecessor to C, invented in Cambridge, England), and C quite late in life).

Therefore I've not disassembled any of the modules. I've only looked at the exports so I could still call some of the functions (e.g. to delete AI, get and set traffic settings and display on screen).

It surprises me enormously that tables would be in the same place, or even look the same, because SIM1.DLL is not just data, there's a lot of code there, and that most certainly won't be the same size. 

In most of the versions of P3D (every release and most Betas) things like the locations of those tables changed each time. I really don't want to start having to search each time. I would prefer folks apply pressure on L-M to get these things made accessible instead, in whatever way is appropriate to their methods. Even exporting the address of the tables would be sufficient, something which would not be any effort for them.

Pete

 

Pete

 

 

[JB3DG]

The only change I can tell as far as x64 ASM goes is that all your 32bit registers (EAX, EBX, EDI etc) have the E replaced with an R for QWORD registers. (ie for a 64bit int, EAX becomes RAX).

Otherwise, the asm format remains the same. You also cannot do inline ASM anymore but have to resort to masm files in Visual Studio.

[jeehell]

1 hour ago, Pete Dowson said:

For 64-bit I don't really understand the code -- it looks very different from the assembly code I know (and can actually code reasonably fluently as it was my original langiage, "rising" to BCPL (the predecessor to C, invented in Cambridge, England), and C quite late in life).

Therefore I've not disassembled any of the modules. I've only looked at the exports so I could still call some of the functions (e.g. to delete AI, get and set traffic settings and display on screen).

It surprises me enormously that tables would be in the same place, or even look the same, because SIM1.DLL is not just data, there's a lot of code there, and that most certainly won't be the same size. 

In most of the versions of P3D (every release and most Betas) things like the locations of those tables changed each time. I really don't want to start having to search each time. I would prefer folks apply pressure on L-M to get these things made accessible instead, in whatever way is appropriate to their methods. Even exporting the address of the tables would be sufficient, something which would not be any effort for them.

Pete

 

Pete

 

 

You have much better low level knowledge than I have so I can't tell you what's really happening between code/compiler/machine code etc...

But, my "research" in P3D V4 on all data formats is that they used double precision floats almost everywhere already, and they kept that. This means most "constant" data (friction, idle fuel flow factor, and probably other stuff) has been moved around (usually "further down"), but all constant data is the same, and packed in memory the same way (double float length).
In my own app, I have made it "easy" to switch to another version by storing the entire table and just searching the in-process sim1.dll memory area for the same memory "blob". I actually do not know where the data is, but once my module launches it knows, which is good enough for me. I only had to recompile for 64bits and check I used cross-compiler friendly pointer maths (I can totally see THIS may take a while, particularly if you do many stuff in ASM...).

Also, I agree if LM would export more data in their DLL (actually read "export" instead of " export more") this would help a lot... Unfortunately they probably expect people to use their external sim API instead of hacking ground friction tables...

[Pete Dowson]

3 hours ago, Naruto-kun said:

The only change I can tell as far as x64 ASM goes is that all your 32bit registers (EAX, EBX, EDI etc) have the E replaced with an R for QWORD registers. (ie for a 64bit int, EAX becomes RAX).

Otherwise, the asm format remains the same.

Really? It all looks very different to me. Maybe I got too easily frightened! ;-)

Pete

 

[GSalden]

With Amy Prosim aircraft I could not "feel" improved friction in P3Dv4.

So I use the Fsuipc 4 ini + lua friction file in Fsuipc v5..

[Pete Dowson]

6 minutes ago, GSalden said:

With Amy Prosim aircraft I could not "feel" improved friction in P3Dv4.

So I use the Fsuipc 4 ini + lua friction file in Fsuipc v5..

Neither of those will owrk in FSUIPC5. The facility to change the friction tables is not implemented, as stated.

I use the Prosim 738 and have no problems with friction in P3D3 or FSX-SE. it seems perfect, and others who've flown my cockpit agree, including those with experience in "real" simulators.

Do you have Prosim working well in P3D4? Is that the A320 version?

Pete

 

[herve_sors]

There was a mistake in my previous post regarding Sim1.dll table offsets
P3Dv4 Sim1.dll (4.0.23.21468) rolling friction coefficient tables (with scalars) are at offset 0x148500. Braking coefficient table is at offset 0x1497C0. Structure is identical to that of previous P3D versions (and FSX). All tested values are also the same.
Full data are available here
http://www.aero.sors.fr/documentation/Friction_Coefficients_Sim1_P3Dv4.xlsx

Hervé

[Pete Dowson]

Okay. I may look again and possible relent on this and implement via offsets, but there will be a limit on how many times I do this. I expect P3D4 to keep developing and I doubt that these offsets will stay the same. That's the main problem.

And it would still be better if folks would apply pressure to L-M for such things to be accessible either via functions or simple exported pointers (the latter only if they never expect the structure to change).

This wll wait till I return though, after the 20th.

Pete

 

[kand]

On 6/13/2017 at 1:44 PM, Pete Dowson said:

Neither of those will owrk in FSUIPC5. The facility to change the friction tables is not implemented, as stated.

I use the Prosim 738 and have no problems with friction in P3D3 or FSX-SE. it seems perfect, and others who've flown my cockpit agree, including those with experience in "real" simulators.

Do you have Prosim working well in P3D4? Is that the A320 version?

Pete

 

CFM56 thrust tables are readily available on the web, if the airifle was recreated using enginesim based on the rw data (nasa jet model) you would find that there wouldnt be enough thrust to move until a very high TLA/N1 was achieved (much like default ac). The only way to overcome this "default" issue is to set table 1506 of the airfile to an artificially high thrust level at 0mach/sea level idle N1.

So of the engines max rated thrust, it is already pumping out something like %50 at idle to overcome fsims poor modelling (this thrust range would normally be seen towards the 60-70%N1).  For some this isnt an issue, but I am a perfectionist and having spent quite a few hours in the BA 777 sim at Cranebank, i want my airfile to handle as close as possible to the real sim experience I have including fuel burn, this means using enginesim to model the engine and rewriting a pure airfile in the knowledge the sims friction will need to be adjusted.   

I suspect LM and MS wouldnt change this SIM1 value because no doubt it will break all of the 3rd party aircrafts "shared" airfiles, therefore it has been left to the table 1506 trick to keep all the addons working across the platforms.

The real dilemma for us is what is the actual rolling coefficient needed? I have my own numbers from reverse engineering "known" variables but its till a ball park really. 

[WebMaximus]

Being late to this party I just wanted to ask what the current status is?

I just got P3Dv4 and realized I'll need to buy FSUIPC5 but will I then be able to use the DynamicFriction.lua I've been using in P3Dv3 for the PMDG NGX?

I also found this thread where people seem to fix this themselves by editing a dll file. It's starting with this post.

[Pete Dowson]

59 minutes ago, WebMaximus said:

I just got P3Dv4 and realized I'll need to buy FSUIPC5 but will I then be able to use the DynamicFriction.lua I've been using in P3Dv3 for the PMDG NGX?

Sorry, this facility is still awaiting action by L-M. Please post your request on their P3D support site to help emphasise this. I've already done so on the developers Beta feedback site, to no avail so far. I think they really assume this area is not of any consequence, or maybe that it is up to the aircraft makers to get their aircraft right in the first place.

Yes, folks are patching the sim to achieve these changes. That is how it started with Microsoft's FS, but by then FS was no longer being developed, so there was no alternative.

Pete

 

[WebMaximus]

OK, thanks for the quick reply.

Haven't had the chance to install the NGX in P3Dv4 yet but hope I will the next coming days being able to do some testing. I read someone said it was a bit better in P3Dv4 vs in P3Dv3 so no reason to start messing around with hex editors unless absolutely necessary.

About LM and posting in their support forum I'm not really sure what to say in such a post to make them understand what I'm talking about since I barely understand this myself :D

[efpg0708]

Hi guys;

Sorry to dig up this post, but has there been any development on this ?

IMO, the ground friction tool was one of the best tweaks ever for FSX, and it still is the reason I still haven´t moved up to P3D4.

 

Thanks

 

Eduardo

[Pete Dowson]

2 hours ago, efpg0708 said:

Sorry to dig up this post, but has there been any development on this ?

IMO, the ground friction tool was one of the best tweaks ever for FSX, and it still is the reason I still haven´t moved up to P3D4.

No, and I don't think there will be. L-M state categorically that (a) there should be no need to change these tables, and if think they implied that if something needs adjusting for an add-on  it should be done in the modelling and (b) they don't want to provide programmatic access to the values because it will restrict development in this area in the future.

I am not going to start hacking into P3D4 code as I used to for the 32-bit sims. I was asked not to by L-M and I don't want to in any case, as it makes FSUIPC very version-dependent. I know I always hacked into previous versions (right since FS98 days) but FSX and FSX-SE were not under continuous development, and it was easy to convert the FSX hacks for P3D1-3 because the code was almost identical in all the areas I was dealing with.

P3D4 is 64-bit, and much more difficult (for me) to hack) and it is subject to continuous development, including up to 20 odd Beta releases to keep up with between regular user releases, plus the odd HotFix release.

If it is so important I would have expected there to be more of a clamour for something to be done about it on the L-M Support Forums, but there has been very little. I think there was one thread about it which died long ago. L-M do take notice of feedback there, so that is how to get attention.

Pete