Position Altitude issues

[almondega]

hi

i'm doing a copilot programm to the Level-D 767 under tcp/ip and level-d's SDK

all the control of the level-d are done and working (except fmc)

now, i'd started the sincronization of the aircrafts position using FSUIPC

but i got some problemms about altitude

possible cause: weather and local hour

so, me and the copilot set the same weather in the fs: no-weather and same clock, same QNH

some times after the takeoff, or near the crz level, the altitude has a difference between the aircrafts around 200~1000 feets

this is what the position sincronization do:

the pilot sends every 1ms yours aircraft's position to the copilot's aircraft

this position include: hdg, bank, pitch, altitude, longitude, latitude and trim

all works except this little error to set the same altitude

any ideia whats going on?

tks

FS9, FSUIPC 3.75, Level-d 767 SP3

this programs are in C language

[Pete Dowson]

i

i'm doing a copilot programm

...

now, i'd started the sincronization of the aircrafts position using FSUIPC

Let me understand this a bit more. You are trying to have two PCs running FS with both pilots flying the same aircraft?

You know that if you move to FSX you have this facility already built into FS? It's called "shared cockpits", and was one of the big selling features of FSX, according to MS, yet few seem to have noticed it!

but i got some problemms about altitude

possible cause: weather and local hour

so, me and the copilot set the same weather in the fs: no-weather and same clock, same QNH

Not sure what weather, time and QNH have to do with an aircraft's altitude. Care to explain a little more? Obviously the QNH will affect the altimeter read-out, but not the actual aircraft altitude.

this is what the position sincronization do:

the pilot sends every 1ms yours aircraft's position to the copilot's aircraft

this position include: hdg, bank, pitch, altitude, longitude, latitude and trim

And how are you imposing this onto the receiving copy of FS? Is that running in slew mode, pause mode or simulation rate x 0 mode? If none of those things, I'm not sure it even works as you are constantly fighting the FS simulation engine.

all works except this little error to set the same altitude

any ideia whats going on?

None at all, sorry. If the rest works the altitude should be easy. Sounds like you have an error somewhere. Have you checked what you are writing by using the facilities available -- e.g. FSUIPC Logging? And why do you think weather and time have anything to do with it? They most certainly should not! A difference in QNH will affect the altimeter, but not the actual altitude.

Regards

Pete

[ftse]

And how are you imposing this onto the receiving copy of FS? Is that running in slew mode, pause mode or simulation rate x 0 mode? If none of those things, I'm not sure it even works as you are constantly fighting the FS simulation engine.

what is this? how can i put the sim in that mode?

Thanks!

[Pete Dowson]

And how are you imposing this onto the receiving copy of FS? Is that running in slew mode, pause mode or simulation rate x 0 mode? If none of those things, I'm not sure it even works as you are constantly fighting the FS simulation engine.

what is this? how can i put the sim in that mode?

Thanks!

Pause is by using pause control or setting paused in the FSUIPC pause offset. Slew is by setting slew on, or again writing to that FSUIPC offset. Sim Rate 0 is by writing 0 to the Sim Rate offset.

Have you never made FS run at 2x or 1/2x normal rate, for example?

However, if you are using none of these modes yet still have everything working well except altitude, I think you should find out what you have wrong with that first, don't you?

Regards

Pete

[almondega]

Let me understand this a bit more. You are trying to have two PCs running FS with both pilots flying the same aircraft?

You know that if you move to FSX you have this facility already built into FS? It's called "shared cockpits"

yes, the level-d 767 aircraft, each one in your computer and fs, but like a pilot and copilot

i dont think that "shared cockpits" in fsx works to the level-d commands, like the buttons in the overhead, fmc and this stuffs

i'd created two programs: 1. 767 commands and 2. aircraft position sincronization, the command are all done as i'd said, still the problem of the altitude

but, the level-d's fsx user can use the number 1 (commands) to the panel, oveheads and this stuffs, also the "shared cockpit" to sincronization of the aircraft

but i have FS2004, and lots of peoples too, and except FSNet, that do the same work of the shared cockpit, i dont know if has another 3rd party freeware programs to sincronization position, if has will be very good.

Not sure what weather, time and QNH have to do with an aircraft's altitude. Care to explain a little more?

in some tests i'd did, the latitude or longitude still changing every second, in some airports this doesnt change, so, i think that the "fs world" slides, also the position of the aircraft (just a guess), and i'd tried test with the copilot at the same time clock, and no weather (because winds, QNH and others changes), the altitude problems remain

And how are you imposing this onto the receiving copy of FS? Is that running in slew mode, pause mode or simulation rate x 0 mode?

both aircraft are in the same mode, normal rate

the pilot get yours geografic's position, if it has any change (every time), send to the copilot the data with the position.

this is the struct i'm using at the moment:

typedef struct LVLDPOS {
    int altitude;
    int bank;
    int hdg;
    long long latitude;
    long long longitude;
    int pitch;
    short int trim;
} LVLDPOS;

the pilot's altitude refresh is in 1ms "Sleep(1) (i dont saw any changes in the fps), also the copilot are every time listening any data to receive

so, the FSUIPC Write all this values in yours FS, and do the Process

Sounds like you have an error somewhere

i did some local tests, same FS, Read and Write the altitude and others structs data, so, i'm getting the correct value from the fsuipc

Have you checked what you are writing by using the facilities available -- e.g. FSUIPC Logging?

no, i dont, i'll find were is it right now

so, this is all at the moment

i'll keep trying fix it

[Pete Dowson]

yes, the level-d 767 aircraft, each one in your computer and fs, but like a pilot and copilot

i dont think that "shared cockpits" in fsx works to the level-d commands, like the buttons in the overhead, fmc and this stuffs

No, not unless their FSX version has been written with shared cockpits in mind. There are some add-on FSX aircraft which work fine that way, I'm told, such as those from Eaglesoft.

i dont know if has another 3rd party freeware programs to sincronization position, if has will be very good.

I don't know about Freeware, but Luciano Napolitano's WidevieW program does a good job.

in some tests i'd did, the latitude or longitude still changing every second, in some airports this doesnt change, so, i think that the "fs world" slides

Uh? Sorry, I don't understand. The latitude and longitude identify the scenery location. There's no other way it is identified, so how does it "slide"?

also the position of the aircraft (just a guess), and i'd tried test with the copilot at the same time clock, and no weather (because winds, QNH and others changes), the altitude problems remain

Of course. I did ask why you thought time, wind and QNH could possibly affect altitude. You still seem to think it is some environmental factor. Why?

i did some local tests, same FS, Read and Write the altitude and others structs data, so, i'm getting the correct value from the fsuipc

Sorry, please clarify. You say you write, through FSUIPC, an altitude value, and that the user aircraft in FS goes to the WRONG altitude? I really find that very difficult to believe. Sorry. All those things are very heavily used and so well tested.

Regards

Pete

[almondega]

I don't understand. The latitude and longitude identify the scenery location

some tests i'd did, the latitude or longitude stay changing a little and i dont know why

but Luciano Napolitano's WidevieW program does a good job.

i'll take a look

if it is a good program to aircraft sincronization, then i'll finish my project with the level-d 767 commands sincronization ^^

its prety good fly the level-d with a copilot or pilot

You say you write, through FSUIPC, an altitude value, and that the user aircraft in FS goes to the WRONG altitude?

yes, i send my altitude position to the copilot, and he stays around 200 ~ 1000 feets under or above me, really very strange

anyway, i create this project to fly (only) the Level-D 767 with a copilot, but theres no software like "share aircraft" from the fsx to get and set the values of the level-d's variables, and i did it, but i need too sincronizate the aircraft, so, i'll test the Napolitano's software =]

tks

[Pete Dowson]

some tests i'd did, the latitude or longitude stay changing a little and i dont know why

It can only be because the aircraft is moving. As I said, unless you pause it, set it in slew mode or set the simulation rate to zero, the simulation engine in FS is still operating. Things don't stand still.

yes, i send my altitude position to the copilot, and he stays around 200 ~ 1000 feets under or above me, really very strange

The value you are writing to FSUIPC is wrong, then. Check it with the logging.

Regards

Pete

[almondega]

i'd downloaded the WidevieW, are you sure that this program sincronizate the copilots aircraft geografic position with mine aircraft?

seens its only to aircrafts gauges

i'll still searching for others sincronization programs

tks

[Pete Dowson]

i'd downloaded the WidevieW, are you sure that this program sincronizate the copilots aircraft geografic position with mine aircraft?

I don't use it, but its job is to synchronise any number of copies of FS on separate PCs on a Network so that the outside view can be shown on multiple screens without jeopardising frame rates. That is its purpose. Therefore its main job is to synchronise position and attitude.

I don't think it necessarily replicates all the correct gauge values, but as you said, that is what your (other?) program is for.

Did you find out what was wrong with your program's writing of the altitude? Did you use the GSUIPC logging? I assume you are writing the altitude to offset 0570 (a 64-bit int with 32 bit fractional part)?

Regards

Pete

[almondega]

that is what your (other?) program is for

yes, two programs, one to the level-d commands and other to syncronize the aircrafts

Did you find out what was wrong with your program's writing of the altitude? Did you use the GSUIPC logging? I assume you are writing the altitude to offset 0570 (a 64-bit int with 32 bit fractional part)?

my mistake, reading again the .doc and doing some tests...

the meters are in 0574 (int) and the fractional 0570 (int)

so, i have to get two variabels to read and write, its correct? or read/write all the 8 bytes in a "long long int" ?

i was sending only the fractional part and writing into the fractional part

so, the metric part was independent of the refresh and resulting in that "bug" altitude

i'll make some changes here

tks Pete

[Pete Dowson]

my mistake, reading again the .doc and doing some tests...

the meters are in 0574 (int) and the fractional 0570 (int)

so, i have to get two variabels to read and write, its correct? or read/write all the 8 bytes in a "long long int" ?

If you have a 64-bit integer in your compiler's facilities (in VS 2005 C/C++ I can use _int64), then that is easiest. Just take your floating point value for altitude (in metres) and multiply it by 2^32 (i.e. 65536 * 65536), convert it to a 64 bit integer, and write all 8 bytes of it to 0570.

Otherwise, yes, you have to deal with the fraction and integral parts separately -- just be careful of the sign (there are places in the world with negative altitude).

Regards

Pete

[almondega]

i was searching for an aircraft share cockpit software, but found only fsnet and wideview

and the wideview server needs serial...

so, i'll keep my own software sync

its working, altitude, latitude, longitude, pitch, bank, hdg, velocities, elevator, rudder, trim, alieron

but its not perfect like a slide movement, the copilot's airplane changes yours positions with a little lag (like a pitch 0 going to 10 instantly, without passing by 1, 2, 3...)

then, i'd created some functions to do this "slide"

current pitch: 0

new pitch: 10

then, go 1 per 1 until 10

isolated tests its working perfect, but, when i went to test with the level-d, i got a problem, maybe a overload os FSUIPC process, cuz the engines dont had started, the position dont had refreshed. (i'm talking about the copilot, cuz only the copilot receives the positions)

here is the slide code:

void pos_slide(DWORD flag, int pos_nova) {
    int value, pos_atual;
    FSUIPC_Read(flag,4,&pos_atual,&result);
    FSUIPC_Process(&result);
    if (pos_nova < pos_atual) {
        value = pos_atual - pos_nova;
        value /= 20;
        while (pos_atual > pos_nova) {
            Sleep(10);
            pos_atual -= value;
            if (pos_atual < pos_nova) pos_atual = pos_nova;
            FSUIPC_Write(flag,4,&pos_atual,&result);
            FSUIPC_Process(&result);
        }
    }
    else if (pos_nova > pos_atual) {
        value = pos_nova - pos_atual;
        value /= 20;
        while (pos_atual < pos_nova) {
            Sleep(10);
            pos_atual += value;
            if (pos_atual > pos_nova) pos_atual = pos_nova;
            FSUIPC_Write(flag,4,&pos_atual,&result);
            FSUIPC_Process(&result);
        }
    }
}

pos_atual = current position

pos_nova = new position to set

what i do: i got the new value, get the difference, and divide by 20, to set the inc/dec rate, so, all slide refresh will have 20 iterations

but this did the fsuipc "block" or had some lag, as i'd said, engines dont starting, position dont get refreshed

has a better way to do this slides, like a fsuipc offset to do it?

this is the copilot code that receive the positions

FSUIPC_Write(0x0BB2,2,&position.elevator,&result);
FSUIPC_Write(0x0BB6,2,&position.alieron,&result);
FSUIPC_Write(0x0BBA,2,&position.rudder,&result);

FSUIPC_Write(0x3098,8,&position.late_speed,&result);
FSUIPC_Write(0x3090,8,&position.long_speed,&result);
FSUIPC_Write(0x30A0,8,&position.vert_speed,&result);
FSUIPC_Write(0x30B0,8,&position.roll_speed,&result);
FSUIPC_Write(0x30B8,8,&position.yaw_speed,&result);
FSUIPC_Process(&result);

pos_slide(0x0578,position.pitch);
pos_slide(0x0580,position.hdg);
pos_slide(0x057C,position.bank);
FSUIPC_Write(0x0570,4,&position.altitude_lo,&result);
FSUIPC_Write(0x0574,4,&position.altitude_hi,&result);
FSUIPC_Write(0x0560,8,&position.latitude,&result);
FSUIPC_Write(0x0568,8,&position.longitude,&result);
FSUIPC_Write(0x0BC0,2,&position.trim,&result);
FSUIPC_Process(&result);

tks

[Pete Dowson]

i was searching for an aircraft share cockpit software, but found only fsnet and wideview

and the wideview server needs serial...

Serial? WidevieW? Not last time I looked. TCP/IP, and I think IPX/SPX was added. Or was it the other way round? There's no way it uses a seriasl port, it's a Netwrok program.

but its not perfect like a slide movement, the copilot's airplane changes yours positions with a little lag (like a pitch 0 going to 10 instantly, without passing by 1, 2, 3...)

Yes, a lot of people have said that. It's the FS sim engine taking over. Try a sim rate of zero.

isolated tests its working perfect, but, when i went to test with the level-d, i got a problem, maybe a overload os FSUIPC process, cuz the engines dont had started, the position dont had refreshed. (i'm talking about the copilot, cuz only the copilot receives the positions)

Overload? Sorry, don't know what that means. If the processor is too heavily loaded, your FS frame rate will suffer, but things don't just stop working.

here is the slide code:

I really don't want to examine code. I've never tried to do what you are trying to do. If it works except with the LevelD you might need to find out what the LevelD is doing differently.

this is the copilot code that receive the positions

FSUIPC_Write(0x0BB2,2,&position.elevator,&result);
FSUIPC_Write(0x0BB6,2,&position.alieron,&result);
FSUIPC_Write(0x0BBA,2,&position.rudder,&result);

FSUIPC_Write(0x3098,8,&position.late_speed,&result);
FSUIPC_Write(0x3090,8,&position.long_speed,&result);
FSUIPC_Write(0x30A0,8,&position.vert_speed,&result);
FSUIPC_Write(0x30B0,8,&position.roll_speed,&result);
FSUIPC_Write(0x30B8,8,&position.yaw_speed,&result);
FSUIPC_Process(&result);

pos_slide(0x0578,position.pitch);
pos_slide(0x0580,position.hdg);
pos_slide(0x057C,position.bank);
FSUIPC_Write(0x0570,4,&position.altitude_lo,&result);
FSUIPC_Write(0x0574,4,&position.altitude_hi,&result);
FSUIPC_Write(0x0560,8,&position.latitude,&result);
FSUIPC_Write(0x0568,8,&position.longitude,&result);
FSUIPC_Write(0x0BC0,2,&position.trim,&result);
FSUIPC_Process(&result);

Erdid you find you needed to write to those 3xxx offsets too? Normally the whole position and attitude is set directly via the 05xx values, they represent the structure used inside FS, LLAPBH (Lat Long Alt Pitch Bank Heading).

And why separate Process calls? You need to write everything you need to write in one Process per iteration.

Regards

Pete

[almondega]

Serial? WidevieW? Not last time I looked. TCP/IP, and I think IPX/SPX was added.

sorry, my english aint's so good x)

i mean this software needs a key, serial, password to work, at last the server needs, the clients dont, so, i cant test it

Yes, a lot of people have said that. It's the FS sim engine taking over. Try a sim rate of zero.

is this the Normal ou Slowest rate?

Overload? Sorry, don't know what that means. If the processor is too heavily loaded, your FS frame rate will suffer, but things don't just stop working.

i dont know what happend, when i'd used the pos_slide, the 767's engines dont had started, then, i'v seted the Sleep of the pos_slide to 200ms, and the engines begins to start, but with some lag, then i stop the pos_slide and the engines starts perfectly, so, i think that the pos_slide uses too much the fsuipc, and the level-d cant start your engines (a guess again)

If it works except with the LevelD you might need to find out what the LevelD is doing differently.

i'll test the sync program with pos_slide actived with a default aircraft to see if hav the same problem

did you find you needed to write to those 3xxx offsets too?

i tried it to minimize the copilots "lag" position refresh, i'll try too without it

Normally the whole position and attitude is set directly via the 05xx values

if i write the entire position struct (only one write, starting from the first position offset, writing the entire position struct), will be better then set offset by offset?

And why separate Process calls?

cuz the pos_slide uses Process too, so, i put it after the engines/position dont had refresh, to see is solve, but not x)

tks pete

[Pete Dowson]

i mean this software needs a key, serial, password to work, at last the server needs, the clients dont, so, i cant test it

I thought I told you right at the beginning that it was payware, not free?

Yes, a lot of people have said that. It's the FS sim engine taking over. Try a sim rate of zero.

is this the Normal ou Slowest rate?

It's a zero (i.e. stopped, no simulation, nothing), rate. I mentioned this before. You've forgotten already? I said "Sim Rate 0 is by writing 0 to the Sim Rate offset.".

i dont know what happend, when i'd used the pos_slide, the 767's engines dont had started, then, i'v seted the Sleep of the pos_slide to 200ms, and the engines begins to start, but with some lag, then i stop the pos_slide and the engines starts perfectly, so, i think that the pos_slide uses too much the fsuipc, and the level-d cant start your engines (a guess again)

Sounds more like you reduced the FS frame rate so much nothing much was happening. I'm afraid that might be the case with zero sim rate -- that effectively stops the FS simulation altogether. The client copy of FS just becomes a dummy worked by the server. Isn't that what you want? I think that's what WidevieW would do too.

if i write the entire position struct (only one write, starting from the first position offset, writing the entire position struct), will be better then set offset by offset?

Well, a little -- that's why the LLAPBH ones are contiguous. They are a struct inside FS. But the main thing is to do it in one Process call. The loop inside FSUIPC is pretty tight anyway.

And why separate Process calls?

cuz the pos_slide uses Process too, so, i put it after the engines/position dont had refresh, to see is solve, but not x)

Yes, well, I don't understand all that "position slide" stuff. Sorry. Not got my head around that at all.

Regards

Pete

[almondega]

I thought I told you right at the beginning that it was payware, not free?

yes, but i bet in a trial test, but the server needs a key, no trial or try version

It's a zero (i.e. stopped, no simulation, nothing), rate

The client copy of FS just becomes a dummy worked by the server. Isn't that what you want?

yes, i'v tested the rate 0 here, if the cliente/copilot set to 0, the pilot will have to send many others offsets, like N1%, fuel

I don't understand all that "position slide"

i'v created this to try avoid the "jump" in the copilot aircraft's position, i.e: the pilot is at pitch 0, and goes to the pitch 40, in yours fs its works perfectly, so, the pilot sends to the copilot: pitch 40. The pilot receives the 40 and refresh your fs, so your pitch goes from 0 to 40 in one frame (ugly), then i'v tried this "manual slide", the pos_slide function do (40-0) / 20 and increase the pitch 2 per 2, until 40 (the new value), like the pilot's aircraft or a solo flight did.

i dont know other way to avoid this refresh jump

[Pete Dowson]

i dont know other way to avoid this refresh jump

Oh, I see. This is interpolation, to get around some delay or lack of good frame rates over the Network. You did your own TCP/IP code, didn't you? Are you using TCP or UDP? UDP is faster -- less checking, no repeats on error and so on.

What sort of update rate are you achieving from the Server to the Client? You should be able to maintain the visual frame rate FS is achieving. If you can set the frame rate limiter in both Server and Client to, say, 25 or 30, so they are both updating at the same rate, and you send new positions at that rate, you should get no jerkiness (what you call "slide", as I now understand it). Certainly WideFS can achieve this on every system I've seen.

BTW, did you not think of using WideFS and only doing the software for the client end? You should be able to run WideClient next to FS if you change the Window class name it uses so that it doesn't clash with FS's "FS98MAIN". There's a parameter for that you can add to the INI file -- it is documented. Then you have to interface to it using the new Class name instead of either FS98MAIN or UIPCMAIN (the two names built into the FSUIPC SDK library code I provide -- you can see this in the source, also provided).

Regards

Pete

[almondega]

You did your own TCP/IP code, didn't you? Are you using TCP or UDP? UDP is faster -- less checking, no repeats on error and so on.

i'm using the winsock lib to get TCP/IP sockets. i'll read something about UDP, cuz i only found server/client tutorials using tcp/ip

What sort of update rate are you achieving from the Server to the Client?

the last test i'v did online, the pilot sends to the copilot every 200ms, should i decrease it to the minimum that dont changes the fps?

If you can set the frame rate limiter in both Server and Client to, say, 25 or 30, so they are both updating at the same rate, and you send new positions at that rate, you should get no jerkiness

i'll do it, but i think that my friends uses the same fps I.

did you not think of using WideFS and only doing the software for the client end?

are you saying that widefs can do this what i'm trying to do? this is great!!

I didnt understand the rest of your message, u mean that i can run my FS and also run a server of widefs to the copilot get my position?

[almondega]

i'v changed the class name and the WideFS opens and connect, ok, also have read the users guide

but, i still dont understanding what to do..

the server will send what to the client? and what the client have to do to move your aircraft, like the server's aircraft?

[Pete Dowson]

i'v changed the class name and the WideFS opens and connect, ok, also have read the users guide

but, i still dont understanding what to do.

You have to revise your program, the one controlling the client aircraft (copilot?) to obtain the data from that WideClient instead of via your TCP/IP connection. That's all.

the server will send what to the client?

WideServer sends to Wideclient whatever WideClient wants.

and what the client have to do to move your aircraft, like the server's aircraft?

The same as what you are doing, except that now WideFS is doing the transfer between PCs for you.

Pete

[Pete Dowson]

i'm using the winsock lib to get TCP/IP sockets. i'll read something about UDP, cuz i only found server/client tutorials using tcp/ip

The thing called loosely "TCP/IP" is not one protocol,. There are at least three protocols in there. The two dealing with sequenced packets are TCP and UDP. TCP is a "connected" protocol whilst UDP is called "connectionless". The differences program-wise a quite minor. If

you've looked at the WinSock documentation you've seen details of both.

TCP is heavily checked and sequenced as it is designed for transmitting data all over the world. It has layers of complicated red tape for navigation and error checking. All that is good for reliable world-wide communication but an big overhead for a reliable short piece of wire to a PC next to you. UDP does the same job but without checks and retries. It also doesn't guarantee the correct order of arrival -- but that isn't relevant if you only have one route between the PCs concerned.

the last test i'v did online, the pilot sends to the copilot every 200ms, should i decrease it to the minimum that dont changes the fps?

Only 5 fps? Goodness me! No wonder it is jerky! You try flying on FS with 5 fps. Ugh.

You should be running it at the same frame rate as FS if possible. You may need to limit FS (both copies). So, set the frame rate limiters to, say, 20, then use 50 mSecs as your interval. There's no point in going faster than the FS frame rate because the data your program is receiving won't be updated quickly enough.

I didnt understand the rest of your message, u mean that i can run my FS and also run a server of widefs to the copilot get my position?

No. WideServer runs in the Server. You'd have to have WideClient running alongside FS on the Client. You discard the prgram you wrote for the Server end and instead amend your client program to give it TWO FSUIPC interfaces: one to the FSUIPC inside FS (as now), and the other to the same interface in Wideclient. You read from WideClient and write to FS.

To do this you cannot use the FSUIPC library itself. You will need to use the source code I supply instead, and modify it to use the different ClassName for that WideClient and, obviously, a different set of FSUIPC_... () calls. Alternatively you can add another parameter to the calls to identify which interface to use. Each one will need its own memory mapped file (part of the Open() actions.

But this is not trivial work. Why don't you try to get your program working first? Do without that "slide" stuff, have only one FSUIPC_Process call per cycle, and try to equalise FS frame rates and your cycles, save 20 fps and50 mSecs.

Regards

Pete

[almondega]

UDP does the same job but without checks and retries

i'd changed to UDP, now the pilot program conect direclty to the client/copilot side, without passing by a server

set the frame rate limiters to, say, 20, then use 50 mSecs

i'd seted to 40ms / 25fps, works fine without autopilot, but still somes "fight" when using autopilot at the copilot side, cuz the aircraft autopilot's try to do a thing, and receive a refresh position a little diferent, i'll try fix it...

WideServer runs in the Server. You'd have to have WideClient running alongside FS on the Client. You discard the prgram you wrote for the Server end and instead amend your client program to give it TWO FSUIPC interfaces: one to the FSUIPC inside FS (as now), and the other to the same interface in Wideclient. You read from WideClient and write to FS.

ok, I understand now what widefs does, but, my position programs reads only few offsets about position and send every 40ms to the client, the widefs reads much more offsets then it, right?

To do this you cannot use the FSUIPC library itself. You will need to use the source code I supply instead, and modify it to use the different ClassName for that WideClient and, obviously, a different set of FSUIPC_... () calls. Alternatively you can add another parameter to the calls to identify which interface to use. Each one will need its own memory mapped file (part of the Open() actions.

ok, only have to change the FindWindowEx func in each new FSUIPC_Open function, in this case will need two, and modify the others funcions to know what m_hWnd have to use

Do without that "slide" stuff: done

have only one FSUIPC_Process call per cycle: done

equalise FS frame rates and your cycles, save 20 fps and50 mSecs: done

but i still got a problemm in the level-d at the copilot's side

the copilot receives the new positions every ~40ms and refresh yours FS offsets

then, when going to start the engines, the N2% increases too slowly, so, i have to stop the position refresh, start the engines, and start the position refresh after this..

i dont know why the N2% got lag, almost stop to increase, with a high offsets refresh rate, so that the engines do not start

all the others stuffs works well

tks

[Pete Dowson]

i'd changed to UDP, now the pilot program conect direclty to the client/copilot side, without passing by a server

What Server did it go via before? With all my TCP/IP programs the route taken by the data is the same whether I use TCP, UDP or SPX protocols.

i'd seted to 40ms / 25fps, works fine without autopilot, but still somes "fight" when using autopilot at the copilot side, cuz the aircraft autopilot's try to do a thing, and receive a refresh position a little diferent, i'll try fix it...

You should really not have both autopilots operating. Can't you make your program on the copilot side stop the A/P switching on?

I understand now what widefs does, but, my position programs reads only few offsets about position and send every 40ms to the client, the widefs reads much more offsets then it, right?

No, it reads whatever is asked of it. The client sends the request to the server, just the once. The server remembers each client's data needs and watches the data in FS for changes. It then only sends changes. The data is compressed and sum-checked. It is very efficient -- it has to be as it is used on cockpit networks with as many as 10 client PCs (my own has 6 just to run the instrumentation, then the one running FS for the projected scenery display, and up to 3 others runing ancillary programs for stuff like weather, ATC, moving map and instructor station. WideServer has to serve them all at the FS frame rate without slowing FS down!

WideClient keeps all the data it receives in memory and supplies it to its client programs on request. This is actually described in the documentation.

ok, only have to change the FindWindowEx func in each new FSUIPC_Open function, in this case will need two, and modify the others funcions to know what m_hWnd have to use

Yes, that sounds about right.

but i still got a problemm in the level-d at the copilot's side

the copilot receives the new positions every ~40ms and refresh yours FS offsets

then, when going to start the engines, the N2% increases too slowly, so, i have to stop the position refresh, start the engines, and start the position refresh after this..

i dont know why the N2% got lag, almost stop to increase, with a high offsets refresh rate, so that the engines do not start

Sorry, I've no idea why that would be. You'd need to talk to the guys in LevelD. Does the start-up work okay with other aircraft?

Regards

Pete

[almondega]

What Server did it go via before?

a server with same protocol to manage the connections

the command program uses it, client/server/client, but the position now is direct client/client

You should really not have both autopilots operating. Can't you make your program on the copilot side stop the A/P switching on?

yes

but turn a/p on and off is a work of the copilot...

has a way to turn the "autopilot engine" off?

i mean, all the lights and panels indicates that AP is on, but the FS dont process the ap?

i had searched here in the offsets, but without success..

it reads whatever is asked of it. The client sends the request to the server, just the once. The server remembers each client's data needs and watches the data in FS for changes. It then only sends changes.

very good

so, i read the offsets that i need and send to FS ;)

Does the start-up work okay with other aircraft?

i'v made a test here with a 737 default

and the N2 and engines starts ok..

i'll talk with the level-d's team whats going on