FSUIPC Compiler/Interpreter

[JohnS737]

I am working on a compiler/interpreter that will execute FSUIPC commands. The language is based on C with a few extensions.

Here is an example

int Gear_Control at 0x0BE8; // See Pete's Programming Guide

GearUp(){

Gear_Control = 0; // Raise landing gear

}

//

// The 'Key' function is a built in language extension that

// allows us to respond to FS input. In this case, it executes

// when it receives a Control G from FS

//

key(Control,'G'){

GearUp();

}

So far, the language has functions, parameters, mixed integer and floating point arithmetic, program control (if then else). I'm adding more daily, and would like a full C implementation.

I have compiled and run a program that will fly a 737 (on autopilot) without touching FS at all except to type Control A to start. It takes off the brakes, runs up the engines, takes off and sets the autopilot parameters all the way up to finding the approach (it will do this if you set an approach in the GPS).

I intend to release this as freeware but at the moment do not have a website as I am working away from home.

Any questions?

Any interest?

If anything positive, I will tidy up the user documentation and release it.

[Pete Dowson]

I am working on a compiler/interpreter that will execute FSUIPC commands.

...

I intend to release this as freeware but at the moment do not have a website as I am working away from home.

...

Any questions?

If you want to release it as freeware for use on unregistered FSUIPC installations you will want an access Key. Check the FSUIPC SDK for the Access Registration document -- section 4 onwards. When you are ready, supply the details and I will make a key. Best to build it into the program for automatic access, as it saves users a lot of hassle. You'd be surprised how many ways there are of not entering an application key correctly! :wink:

Regards,

Pete

[airforce2]

I could envision a few uses for such a beast...

Cheers

[JohnS737]

Pete

I don't want to release this for use on unregistered copies of FSUIPC to protect you. It could act as a back door to FSUIPC, especially if I implement the interpreter as a DLL (which I'm planning to do). That way, you pass the compiled code to the DLL, which drives FSUIPC and provides text feedback via callbacks.

The program is in a workable state now. It doesn't have a full C implementation yet, but I'm working on it. It supports mixed integer/floating point arithmetic, printf (%s, %x, %f and %d only), if, else, while, pointers, arrays, functions (with parameters), returns, #include etc., but not much else.

One thing I have been doing with this is finding new GPS variables in the 0x6000 area. I have about eight so far. I'm updating your 'FSUIPC for programmers', and will release it when I've done sufficient changes.

I don't have access to a website because I am working in Kenya (as an IT contractor. I live in the UK). I have a UK website provided by my ISP but haven't used it and can't access it from here. Email works OK, but internet access is so unreliable that even the posts I put on here often fail. I'll be in the UK over Easter.

JohnS

[Pete Dowson]

I don't want to release this for use on unregistered copies of FSUIPC to protect you. It could act as a back door to FSUIPC, especially if I implement the interpreter as a DLL (which I'm planning to do).

Ah, yes. I see. quite right, and very good of you to look out for me! I should have thought of that. :wink:

One thing I have been doing with this is finding new GPS variables in the 0x6000 area. I have about eight so far. I'm updating your 'FSUIPC for programmers', and will release it when I've done sufficient changes.

Ah, that's sounds good. But I am constantly also updating that document too, so when you are ready could you send me the relevant section and I'll merge the changes? Thanks!

Regards,

Pete

[scruffyduck]

John

We seem to be working on something similar except that my 'language' is very high level and is interpreted. The program is in two parts - a development environment and a runtime program - not a dll. Mine is more of an adventure language interacting with the aircraft systems and the weather around the aircraft.

If you think we might have a common area of interest then drop me an email - jon@scruffyduck.co.uk

[JohnS737]

Pete,

Here are some FSUIPC variables in the GPS area

int GPS_600C at $600C; // Zulu time in seconds since midnight

float GPS_6068 at $6068; // Track Error (TKE), in radians

float GPS_60EC at $60EC; // Distance to next waypoint, in metres

float GPS_60F4 at $60F4; // Distance between previous and next waypoint, in metres

float GPS_610C at $610C; // Course to Set (CTS), in radians

char GPS_6137[5] at $6137; // Flightplan destination airport

char GPS_6140[8] at $6140; // Approach name

char GPS_6154[8] at $6154; // Approach transition name

int GPS_6190 at $6190; // Time when waypoint was crossed,

float GPS_61A0 at $61A0; // Route total distance, in metres

float GPS_61A8 at $61A8; // Estimated fuel burn, in gallons

int GPS_61B0 at $61B0; // Time of last update, see 61B8

int GPS_61B8 at $61B8; // Counter, incremented once every five seconds

Also, there are three floating point variables at 6178, 6180 and 6188. I haven't found out what they do yet, but when flying between waypoints A and B they have values of X, Y and Z for example. On the return journey, between C and B they have values -X, -Y and -Z.

Also, 6008 starts a flight plan as 12, and is incremented when the approach is loaded, not not incremented when the approach is activated, and incremented when VTF is activated. If you then select another flightplan, it gets incremented by six.

JohnS

[Pete Dowson]

Here are some FSUIPC variables in the GPS area

Thanks. I'll put the known ones into the doc and the FSI file.

Some easy questions for you though:

int GPS_6190 at $6190; // Time when waypoint was crossed,
int   GPS_61B0 at $61B0; // Time of last update, see 61B8
int   GPS_61B8 at $61B8; // Counter, incremented once every five seconds

Are those two Times in the 5 second units (else why the referral to 61B8?) or in the single "seconds since midnight" of the Zulu seconds value?

Also, there are three floating point variables at 6178, 6180 and 6188. I haven't found out what they do yet, but when flying between waypoints A and B they have values of X, Y and Z for example. On the return journey, between C and B they have values -X, -Y and -Z.

They aren't vectors based on world coordinates at all, are they?

Sorry I haven't the time at present to investigate this stuff more myserlf. Thank you very much for the data, I'll add the known ones as I say.

Best regards,

Pete

Also, 6008 starts a flight plan as 12, and is incremented when the approach is loaded, not not incremented when the approach is activated, and incremented when VTF is activated. If you then select another flightplan, it gets incremented by six.

JohnS

[JohnS737]

Pete

int GPS_6190 at $6190; // Time when waypoint was crossed,

int GPS_61B0 at $61B0; // Time of last update, see 61B8

int GPS_61B8 at $61B8; // Counter, incremented once every five seconds

6168 is a counter, it is incremented by one every five seconds. From what I remember, it starts at zero. When the counter is incremented, the time is copied into 61B0 (seconds since midnight).

6190 is the time the last waypoint was crossed. I don't know if this is set when 61B8 is updated or at the exact second.

I've sent a copy of the program to jon@scruffyduck.co.uk, and am aiming for a full release by early next week. I wanted to include versioning (which I have now done) and #defines. At present the keywords Control and Alt are defined in the language definition. I want to change them to integers so that we can add new definitions later via #defines (I believe you have added the Window and Menu keys lately), and ensure that all releases are backward compatible with my first release, so that no one is forced to change code when the compiler gets updated.

JohnS

[Pete Dowson]

int GPS_6190 at $6190; // Time when waypoint was crossed,

int GPS_61B0 at $61B0; // Time of last update, see 61B8

int GPS_61B8 at $61B8; // Counter, incremented once every five seconds

6168 is a counter, it is incremented by one every five seconds. From what I remember, it starts at zero. When the counter is incremented, the time is copied into 61B0 (seconds since midnight).

6190 is the time the last waypoint was crossed. I don't know if this is set when 61B8 is updated or at the exact second.

I'm still a bit confused. There is a "seconds since midnight" in 600C according to your first list. It looks like you are saying that 61B8 is the number of seconds since some arbitrary starting point, divided by 5, and 6190 and 61B0 are copies of this at specific described events.

I'll see if I have time to cross-check these so I get the descriptions right before updating the docs.

Thanks!

Pete

[JohnS737]

Pete,

Apologies for any confusion.

600C is seconds since midnight.

6190 is the time at which the waypoint was crossed (zulu time, in seconds since midnight)

61B8 is the number of seconds since some arbitary starting point, divided by 5

61B0 is the time at which 61B8 was last updated (zulu time, in seconds since midnight)

I'm confident that when 61B8 is incremented, some other variables are also adjusted, I just haven't yet found out which ones they are.

Cheers

JohnS

[Pete Dowson]

600C is seconds since midnight.

6190 is the time at which the waypoint was crossed (zulu time, in seconds since midnight)

61B8 is the number of seconds since some arbitary starting point, divided by 5

61B0 is the time at which 61B8 was last updated (zulu time, in seconds since midnight)

Ah, right. Thanks. At present, then, 61B0 and 61B8 aren't really of any use. I'll not included them (yet). Same for 6178, 6180, 6188 and 6008.

I'm confident that when 61B8 is incremented, some other variables are also adjusted, I just haven't yet found out which ones they are.

Rightthis may be important for some internal functions for the GPS/planner, but probably not for an external program. I'll leave them out of the dox for now.

Thank you very much!

Regards,

Pete

[JohnS737]

Pete

I missed your reply (in another post) on Friday afternoon, so I'll ask Enrico later in the week (and maybe extend the feature set in the meantime).

I can't post it here. Its 560Kb (including docs).

[Pete Dowson]

I'll ask Enrico later in the week (and maybe extend the feature set in the meantime).

I think Enrico said he was away from Wednesday, but I don't know if that means he won't be answering emails. He seems to answer them wherever he is, unlike me! (When I'm away I am totally disconnected! :wink: ).

Regards,

Pete

[JohnS737]

Pete

Enrico has already set up the web page. As he points out though, we probably need a good name for this project. I called it FSA because it's version A. Any better ideas?

http://www.schiratti.com/starkie

p.s. I don't know what to do about support yet. john.starkie at ntlworld.com will do for now.

[Pete Dowson]

Enrico has already set up the web page. As he points out though, we probably need a good name for this project. I called it FSA because it's version A. Any better ideas?

Well, I can see the trouble there being when you get to version B and so on. They'll all be different products that way. You'd need a name separate from the version.

But I'm afraid that I am exactly the wrong person to advise on names. Look at my terrible examples: FSUIPC (derived from the earlier FS6IPC by having a "U" for "Universal" instead of a version number), and WideFS, just because the original was piggy-backed onto WidevieW! And the confusion that has caused over the years :?

Best regards

Pete

[n4gix]

But I'm afraid that I am exactly the wrong person to advise on names. Look at my terrible examples: FSUIPC (derived from the earlier FS6IPC by having a "U" for "Universal" instead of a version number), and WideFS, just because the original was piggy-backed onto WidevieW! And the confusion that has caused over the years

Well, "FSUIPC" is certainly more euphonious than "PAUDEW"* :lol:

*"PetesAmazingUniversalDoEverythingWhizbang"

[Pete Dowson]

Well, "FSUIPC" is certainly more euphonious than "PAUDEW"* :lol:

I must admit I hadn't thought of that one. At least you can pronounce it, just. :D

Pete

[JohnS737]

On a related topic, according to popular legend, when Shell found oil in the UK North Sea, they named their first field AUK, and where planning to name subsequent fields, BUK, CUK etc..

However, in an amazing lack of foresight, nobody thought they'd get as far as F, and by that time it was too late, so since AUK was a seabird, and the oilfields were at sea, they decided to name the fields after birds (e.g. Brent, Cormorant, etc...)

[Pete Dowson]

On a related topic, according to popular legend,...

Nice story! :) Thanks.

Pete