considering learning to code for this - need help

[Rotodyne]

I'm ultimately looking to make a program that displays DirectX models of a panel and a set of dials. I've seen others that do this and they don't quite do it how I envision doing it.

My FS panel comes close, but in 2d, and I require 3d, it does show the dials very crisply and clearly though. It did that on a few machines so it's seemingly no fluke.

Project Magenta is OGL and from what I saw in the demo is not of a high enough visual quality, as it is not crsip and clear. To my mind this defeats the whole point of having a panel of instruments since they are not ALL clear enough to be useful. I've tried this one on a few machines now (just to be sure) and the same basic problem remains with it. It seems possible that this is because OGL is fast becoming an "also ran", whereas DirectX still gets work done on it to make it better. That's mostly a Microsoft thing by the look of it.

I can't actually code (presently), and can't find another who can and will either, so I'm left filling the gap on my own; I'll probably have to learn to code. Any help I can get in travelling from here to there will be seriously appreciated!

The package I have does not appear able to do what's required to work with widefs.

The reason I think that is because as far as I have been able to discover it requires the coder to "link" a dll at compile time? My current package sadly can not do this as far as I can discover.

I've got two other chances of working this out, one solution might be able to "link" although it is not good at doing what I need it to though.

The other solution (upgrade from currently owned basic) might go some way to doing what I need, but I don't know how to find out if it can do this "link" thing anyway yet. But it might be that it can. I really need to find out what it actually is that I need to find out now! ;O) If I knew more about the link requirement, then I'd have a better chance of finding out if that one can do this.

I felt the best thing to try and find out here is whether or not the requirement to link is still current?

I could maybe manage basic, but other languages are likely to be a non starter as they seem to be quite firmly over my head and quite probably over my wallet too.

I did send some stuff via TCP and although I could not get wide FS to see it, FSUIPC on the other machine did and made it count among the valid connections - I just could not see how to convert that into a valid disconnection as well, to make the set as it were. ;O)

[Pete Dowson]

The package I have does not appear able to do what's required to work with widefs.

Does it interface only to FSUIPC? If so then it should have no problem at all through WideFS.

The reason I think that is because as far as I have been able to discover it requires the coder to "link" a dll at compile time? My current package sadly can not do this as far as I can discover.

I don't understand what you mean here. Certainly nothing of mine requires any application to link a DLL.

I felt the best thing to try and find out here is whether or not the requirement to link is still current?

You need to explain what you mean. Any application written to interface to FSUIPC on the same PC as FS should certainly have no difficulty connecting via WideFS, as the interface is identical. That's the whole point. There is no application DLL necessarily involved in any of that.

I did send some stuff via TCP and although I could not get wide FS to see it, FSUIPC on the other machine did and made it count among the valid connections

That does not make sense. FSUIPC has no Network code in it whatsoever. And "sending stuff via TCP" is not ever going to get WideFS interested. It has its own complex protocol in the interaction between Server and Client. This is independent of the Network protocol, which can be TCP/IP or SPX/IPX.

Regards

Pete

[Rotodyne]

Setting a lot of the above aside:

I have Blitz3D basic, when I pointed it at the right port on the machine that was running FS, FSUIPC said it had one client connected. I'm now guessing that meant the wide server saw it and reported it back?

Would that make sense so far?

When I tried pointing it to the machine I was working on, but with wide client running it did not work in that way. That struck me as odd, since I felt this might be the right way to go about it. I used a port monitor to see what ports were being used in each case, but could not see a method by which to use the wide client as a means of doing it, only direct to the main FS machine seemed to get any response at all. I probably don't fully understand what's required here yet.

Since there is no coding example for Blitz3D then I'm having to feel my way through it all. (No complaint here it's just what I am up against.)

Some places I've seen it written (not by you Pete I hasten to add) that this linking business was required if you want to develop stuff for FS using FSUIPC. I'm guessing this may not have been entirely good advice based on what you are saying. It's intention was so that you could use libraries to call the functions in your software I think, and may have been language specific, but without saying so.

I'm sorry but I'm not enough of a coder to know what to tell you to make it much clearer than this.

[Pete Dowson]

I have Blitz3D basic, when I pointed it at the right port on the machine that was running FS, FSUIPC said it had one client connected. I'm now guessing that meant the wide server saw it and reported it back?

FSUIPC doesn't have any such message. WideServer does. Where's the log? What's a "Blitz3D basic"?

Would that make sense so far?

Sorry, no. I really have no idea what program you are using nor what "point it at the right port" means?

When I tried pointing it to the machine I was working on, but with wide client running it did not work in that way. That struck me as odd, since I felt this might be the right way to go about it. I used a port monitor to see what ports were being used in each case, but could not see a method by which to use the wide client as a means of doing it

Doing what? This is getting thoroughly confusing. If you run WideServer in FS, just run Wideclient on the client PCs. You then run FSUIPC applications on the clients. Let WideFS deal with the Network stuff. What are you trying to do with it?

Some places I've seen it written (not by you Pete I hasten to add) that this linking business was required if you want to develop stuff for FS using FSUIPC.

What "linking business"? We seem to be talking different languages here. If you want to use WideFS please check the documentation. It is all explained there how to use it correctly.

It's intention was so that you could use libraries to call the functions in your software I think, and may have been language specific, but without saying so.

There is a library for FSUIPC, of course, it is part of the FSUIPC SDK. If you want to interface to FSUIPC you need the FSUIPC SDK. There are sections in the SDK for several languages, including Basic. Have you looked?

Please just download the SDK and check the documentation. It sounds like you are starting from completely the wrong end of things. Ignore WideFS, write to interface to FSUIPC. WideFS is just a way of interfacing to FSUIPC across a Network.

Regards,

Pete

[Rotodyne]

PD> FSUIPC doesn't have any such message.

I see the message in the title bar of FS when there is a

client connected.

Having rechecked, it does seem to be attributed to the

server, but then you knew that all along really. I'd like to

say thanks for saving me the time and trouble of re running

and rechecking all that. Now I have, what does that change,

beyond establishing that you know the software you wrote

better than I do? (which we both knew already, and I for one

would not have it any other way, since that's the basis I

was working on when I paid you for copies of these

things in the first place!)

PD> WideServer does.

I see. Thanks for the info.

PD> Where's the log?

In it's folder;

D:\Program Files\Microsoft Games\Flight Simulator 9\Modules

Would it help out if I post some or all of it next post?

PD> What's a "Blitz3D basic"?

Google is your friend: And so can I be, so here's a link to

save you the trouble, it is the top link you'll find of most

use.

http://www.google.co.uk/search?hl=en&q=gle+Search

Most users use it for arcade games, but it does have other

abilities like access to DirectX for 3D, which at the price

is not bad value. It is often reported to be pretty fast by

those in graphics programming circles. It's not as fast as

one can get, but then it also costs less in terms of cash

and learning curve, thus it is quite attractive for general

coding work where DirectX graphics content is required. Like

in this case for example. It's also attractive to learning

coders, like in this case also.

PD> Sorry, no.

OK, I'll keep trying to clarify the situation.

PD> I really have no idea what program you are using

As stated above, Blitz3d Basic, and the program is the one

I'm trying to develop.

PD> nor what "point it at the right port" means?

I was directing TCP data at the port number specified in the

config as being the right one for FSUIPC by default (8002),

moreover I was directing at that port on the FS machine

(let's say machine 1) and once I saw that got a response, at

the machine I was working from, since that was running wide

client (lets say machine 2). Sorry, I was perhaps a little

imaginative in my usage of the words, but I am confident you

will by now have the gist. Anyway it worked on the remote

machine (1), which was running FS and not on the local

one(2) where I had only the client part of your package

running.

PD> Doing what?

Connecting to FS to get at the variables, hopefully that was

going to be via your software.

PD> This is getting thoroughly confusing.

Agreed, but I plan to stay with it until it becomes clear.

PD> If you run WideServer in FS,

I do

PD> just run Wideclient on the client PCs.

I did.

PD> You then run FSUIPC applications on the clients.

Well after a fashion I did, but more correctly I set about

writing one, since that was the task in hand. I tried in the

127.0.0.1 addressing style and also directly at it's explicit IP;

No response.

PD> Let WideFS deal with the Network stuff.

The client appears not to want to play on the machine I am

developing from (2), it's more successful if I work on

machine two and send TCP stream data to the right port on

machine 1 - by stating the ip address and port (8002)for

that machine, and then following that with the data I want

to send to your software. ($02BC) I'd imagine that'd be a

fair opening gambit?

I do note that other software seems fine with the client on machine 2

and it must point to me not knowing what to write or maybe how to write it (given there is is no SDK for this particular language, that's

maybe to be expected)

PD> What are you trying to do with it?

I'm trying to read variable data from FS on machine 1 and

display it on machine two, graphically.

PD> What "linking business"?

It's referred to by one or two in some docs for writing

stuff for FSUIPC, it's apparently about linking a library

for use. Sometimes other words are used. I am not fluent in

the various languages concerned which there are examples

for, but link is quite a common term used. I can only

surmise that "include" might be another term used in the

same context, but I am not able to be certain, however it

seems to fit in the context most times.

PD> We seem to be talking different languages here.

Granted, We do.

PD> If you want to use WideFS please check the

PD> documentation. It is all explained there how to use it

PD> correctly.

Just to be certain I re-read the right one would you name it

specifically please? as there seems to be rather lot of them

included in the overall package. Many of them I can not make

head nor tail of (yet), and a few I can just about fathom

roughly where they are leading. I'm more than happy to

re-read them, but I'd like to make sure I'm following the

one you are specifically referring to first and foremost.

PD> There is a library for FSUIPC, of course, it is part of

PD> the FSUIPC SDK.

Ah, I wonder if this is what the others were talking about?

PD> If you want to interface to FSUIPC you need the FSUIPC

PD> SDK.

Indeed, that is why I downloaded it.

PD> There are sections in the SDK for several languages,

Quite so.

PD> including Basic.

UIPC_SDK VB .Net Shell Revision 2.004.zip and

UIPC_SDK_VisualBasic.zip are two names I recognise as

relating to basic. not sure about any others bing for basic

or not just for this moment, apart from csharp.

PD> Have you looked?

Yes.

PD> Please just download the SDK

Already have done.

PD> and check the documentation. It sounds like you are

PD> starting from completely the wrong end of things.

Whereas, odd to relate, I started by reading your docs.

PD> Ignore WideFS,

OK.

PD> write to interface to FSUIPC.

OK, but I'm constrained to using TCP streams directed at the

main machine(1) as a target as far as I can tell, since

that's the syntax for TCP in the environment I'm writing in.

So which machine do you suggest I target the TCP stream at?

I could stay with the remote (1) or try again for the local

(2) which appears not to respond? well, it certainly does

not seem to have done so far.

PD> WideFS is just a way of interfacing to FSUIPC across a

PD> Network.

I'm sure that's the intention and that most of the time that

is indeed exactly what happens, but my experience so far is

of another variety, in that it does not respond on streaming

to the local machine as far as I can tell. In fact my

software then says it failed, whereas if I go after the main

machine it reports that it succeeded, and wide server concurs

on that.

I wish I could work out how to get my code closer to what's

actually needed here.

I get the connected message (even in the logs), but I can't

so far get it to say disconnected by sending the code for

that in the same way. (which I'd imagine should happen from

what I've read so far)

About as much use as half a see-saw as it stands; needs

someone to work the other end for intended usage to be

worthwhile.

[Luke Kolin]

The client appears not to want to play on the machine I am developing from (2), it's more successful if I work on

machine two and send TCP stream data to the right port on

machine 1 - by stating the ip address and port (8002)for

that machine, and then following that with the data I want

to send to your software. ($02BC) I'd imagine that'd be a

fair opening gambit?

I think what Peter is attempting to state is that you should NOT attempt to talk to WideServer directly via a TCP/IP stream unless you want to reverse-engineer the whole protocol. You're far better off developing assuming you're on a single box, and then let WideClient/WideServer abstract away the network layer for you.

I maintain and extend software that uses WideServer; as far as I am concerned I'm just dealing with FSUIPC and FS on a local box and if there's a network between me and FS9 I am blissfully unaware and unconcerned.

Cheers!

Luke

[Pete Dowson]

Connecting to FS to get at the variables, hopefully that was

going to be via your software.

Okay. So FORGET WideFS for now. That is where you are totally confused. You do NOT interface to FS through WideFS but through the FSUIPC interface. For that you need the FSUIPC SDK. Do NOT mess about with ports and TCP/IP or anything like that. All that will be handled for you by WideFS WHEN AND ONLY WHEN YOU HAVE A PROGRAM INTERFACING TO FSUIPC!

it's more successful if I work on

machine two and send TCP stream data to the right port on

machine 1 - by stating the ip address and port (8002)for

that machine, and then following that with the data I want

to send to your software. ($02BC) I'd imagine that'd be a

fair opening gambit?

No, absolutely not. You will NEVER get that working. Go download the FSUIPC SDK. Forget WideFS. You obviously totally misunderstand the whole concept. WideFS just provides a Networked copy of the FSUIPC interface. It is that you need to deal with.

OK, but I'm constrained to using TCP streams directed at the

main machine(1) as a target as far as I can tell ...

Do not use TCP or anything to do with the Network. That is handled by WideFS. Write your program to talk to FSUIPC, following the examples provided in the SDK.

If you want to do your own Network linking program, that's fine, but it is absolutely nothing to do with either WideFS or FSUIPC. That's all your own affair. You'd have to do both client and server ends of your own link. That's not relevant to anything of mine.

PD> WideFS is just a way of interfacing to FSUIPC across a

PD> Network.

I'm sure that's the intention

It is NOT only "the intention". It is what is implemented, and it has been so since FS98 days. It is well established and heavily used. WideClient "pretends" to be FS running FSUIPC. Any program written to interface to FSUIPC will run okay on the FS PC without WideFS even installed, or on the Client via WideFS. The interface is reproduced exactly. That's all you need to use. No network stuff at all.

... my experience so far is

of another variety, in that it does not respond on streaming

to the local machine as far as I can tell.

Of course not. It responds only to the WideFS protocol, which is not published and which will not be. Please FORGET the Network, write to the FSUIPC interface only.

I'm sorry, but this is getting no where. If you insist in talking about TCP streaming and so on then you may as well continue talking to yourself. I cannot help you. You seem to be deliberately misinterpreting me. IGNORE NETWORKS, IGNORE WIDEFS, use the FSUIPC SDK and interface to FSUIPC, like hundreds of other programmers have done before very successfully.

Pete

[Rotodyne]

"You seem to be deliberately misinterpreting me"

Just ask yourself if anyone would actually have time to waste doing that. What possible motive could there be?

Preposterous concept.

[Pete Dowson]

"You seem to be deliberately misinterpreting me"

Just ask yourself if anyone would actually have time to waste doing that. What possible motive could there be?

Preposterous concept.

I fully agree, if you were doing so -- which I didn't say. But unfortunately that's the way it reads. Hence the word "seems". I have to somehow get folks to read what is written rather than what they think should be written.

How many ways can I emphasise "forget WidefS and the Network, interface to FSUIPC"? Maybe much bigger fonts in red?

Regards,

Pete

[BrunoBL]

I wish I could work out how to get my code closer to what's actually needed here.

Please allow me to post my view, as I also started out with many of your doubts. After a while I finally understood what was involved and went from there to writing my applications for FS via FSUIPC. It is really much simpler than initially it seems.

You need to write a program that goes along the following generic lines:

1. estabilish connection with FSUIPC (one line of code).

2. read any variables you wish from FS via the FSUIPC interface. (one line of code per variable).

3. Tell FSUIPC to process the read (one line of code).

4. close the connection with FSUIPC. (one line of code).

That's it.

Steps 1 and 4 are done only once, at the begining and end of program respectively.

If you need constant update of the values (likely), then do all the reading (step 2, above) inside a program loop. I do step 3 inside the loop, too.

How you go about to implement the above will obviously vary according to the programming language you use. I used Delphi, in which case you need to make available for the compiler a library of functions written for it, called "PFUSER.PAS". This library contains the actual code for functions you will be calling from within your code. It is available from the SDK, as is all the necessary information on how to use the FSUIPC interface.

Strictly speaking, the library isn't needed but by using it you bypass the need of a lot of low-level programming. Just call the library functions passing the right arguments and you're done.

If it is of any use, here are code fragments from my Delphi application. The application does all sorts of things, as varying wind noise intensity depending on indicated airspeed and lighting up the red/green landing gear status (locked/transit) anunciators on the instrument panel. So suppose you want to read IAS and the 3 landing gear leg positions. A program could look like this:

-----------------------------------------------------

{Do the following only once, at the begining of your program,}

{to estabilish communication with FSUIPC:}

FSUIPC_Open(SIM_ANY, dwResult);

{Then, begin a loop (this fragment would be inside a Delphi "timer" }

FSUIPC_Read($0BF4, 4, @gearLeft, dwResult); // left gear position

FSUIPC_Read($0BEC, 4, @gearNose, dwResult); // nose gear position

FSUIPC_Read($0BF0, 4, @gearRight, dwResult); // right gear position

FSUIPC_Read($02BC, 4, @IAS, dwResult); // IAS

FSUIPC_Process(dwResult); // Process the reads

{here you can use your variables (IAS, gearLeft, gearNose, }

{gearRight) as needed. Don't forget to convert to meaningful }

{quantities: knots for the IAS, etc. For instance, to convert }

{IAS to knots, do this: }

IASKnots := Round(IAS/128);

{end the loop here}

{Just before your program ends...}

FSUIPC_Close;

-----------------------------------------------------

Hope this sheds more light than shadow on the matter!

As Pete explanined, do not fiddle with TCP/IP, networking, ports or anything like that. Just talk to FSUIPC directly.

Do take a good look at the SDK. there are working code examples (for Delphi and other languages).

Good luck!

Best regards,

Bruno.

[Rotodyne]

Thank you Bruno, your post was indeed helpful. I was able to learn from it. You appear to understand, since you've clearly been where I am now. :wink: