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:

"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.

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.

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.

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)

Yes I downloaded the demo of that yesterday. I'll be honset, I think it could be better. I rate the galss panel stuff they do, but I'm not into flying liners and jet stuff. For GA, I suspect much, much better could and should be possible. For a more specific example; I'm not sure how one can make something blocky and fuzzy at the same time, but they found a way in some places, and it was not all that impressive, since that was a bit of information that was renedered useless as a result. The point of a panel being entirely to relay information in a clean and crisp manner. I'd settle or a panel that is not specific to one plane, but it must be at the very least convincing, surely? I've done panels and instruments that were clean, smooth moving and tidy in another sim, Sadly, due to rather too many other issues, that sim has no future as far as anyone can tell. So I'd like to bring that work to FS and expand on it if at all possible. Doing it via Pete's programs makes total sense to me. It's worth having as it'd then be a fair alternative to a simkits display. Obviously not quite as immersive, but as good as one could get short of being a physical dial if it is handled right in the first place. Previous versions have featured shadows, highlights, and reflections that actually change on the front glass. It's very natural feeling. Physical dials can't do that really, as they don't have access to the position of the sun or background to reflect, they must be quite sterile as a result. I liked using the more lively version, but it did not have all dial features working, I want to see the little wheels (odometers) running right too! ;O) It's getting very frustrating not being able to find a coder though. As FS users we could have it all, and we could have had it yesterday! The need is for a coder who knows and uses Pete's software and can use DirectX as that has the most hope of success. Does not have to be DX 9 particularly, but that would only help I'd guess. Oh well, back to the drainingboard. :roll:

Those reality XP gauges look like a good starting point for what I am trying to do. I can model in 3d and have been making gauges for flightsims of one sort or another for some years now, but I can't currently find a coder to work with who knows about ALL of this stuff. What I need to find is a coder who can understand how to load and use say DirextX models and link to FS via FSUIPC/WideFS. What I am mostly interested in doing is GA gauges running on a latop, and hooking into FS via Pete's progs to keep it all pretty simple. The ageing laptop can't cope with flightsim, but it could very probably do this really fine. If not, then why not on another machine? I'd really like to co-develop a new panel system, so others could even add new intruments as they discover they really can make good ones and it's not that hard to make them! It's potentially a huge niche waiting for the right program to allow it all. I wrote the author of My FS Panel, asking him if I could just send him a picture of the WIP 172 like panel I've been working on, but not even got a reply to say no! Anyone else fancy working on this?

Oh yes, thank you. I got that one and the FS-interogate in it does work fine, but I want to make a sort of "panel" for a more graphical output. I'm not a coder and I am looking for one of those. I am a model maker and have built about half of a plausible panel as such, with a fair number of instruments. I now need the help of a coder to actually interface this and one who know's a bit about 3d, enough to load and actuate a ready made DirectX model anyway! I am just doing the leg work so they know what SDKs to readup and to see if I can ease their path in doing that for them. If you are reading this and you might be the boy for the job, then do drop me a PM by all means. :lol: This one is different as it's built with regard to what is actually possible within a 3d model makers toolset, and a system has been developed which makes animating it pretty simple. Limited DirectX tests have been of a most encouraging nature. I'm calling this project, The Other Panel as a working title. You can e-mail me about it at "the_other_panel_@_googlemail_com" too if you'd like (underscores to dots).

I'm looking to use widefs to check into what various instruments should be displaying. I've not yet quite discovered the right documentation to read up about this. Are all instruments "numbers" available? If anyone can point me to which are the right docs for this task I'd really appreciate it. Thanks

I seem to be having a day of making mistakes, sorry I mentioned it. I shall not make that particular mistake again.

As I saw it (possibly I'm mistaken) it offers a larger display than some of the entry level personal GPS units, and it's got colour, which again is more than the smallest cheapest units. All this for often less cost than those units. Being as programmable as it is, I also felt it should offer more flexibility than those existing dedicated single use units. As for likely use, well what can linux do? It could be used for whatever FSUIPC can offer where a graphical output could be an advantage to the user. It might be that if it were stripped down it could offer use in home pits for all sorts of things. I guess all it would take is some imagination. The cost of GPS units seems to be held artificially high just now (certainly in the UK) This might be able to offer better value if the software were developed for it. The SDK and quite a lot of other items are part of the deal and are provided at no additional cost. Being open source this could be a fertile development platform. If it were only a games console then I would not, of course, have mentioned it. It was the potential flexibility which it offered that inspired.

I found this: http://www.gbax.com/ordergp2x.html mentioned while watching TWiT TV on the web today. (This Week in Tech) I note it's programable (open source too apparently), got Dual cpus, USB and not all that dear. Could this become an addon on for FSUIPC in the custom GPS/moving map for flightsim arena? I'm not a great coder so felt it best to ask in here. I'm sure someone will know more about whether or not this could be turned into a handy bit of kit.

Mostly it was a "leg pulling" type remark addressing something you said about surviving long enough to make updates and then whether you'd carry on with FS2006 or whatever it might be called anyway. It was in one of the "why pay for x" type monologues! :wink: (do people really need telling why? ) Anyhoo, keys for both products arrived bright and early this moring and it's all fine so far. Thanks once again for writing this seriously interesting & useful software. I'm sure I shall enjoy tinkering with it all. Just need to find a good replacement for FSNav now, not quite so happy that it can't be used easily on a laptop using wideFS. I'd rather find something that can use wideFS, as it's clearly a good way to go. Only got a 5Gb drive on the laptop. (XP Pro ate half of that 2004 would eat the othe r half, I'd like to use it for other things too!) I bought FSNav once before and lost the key to a HD crash, and a bit of naivity on my part (backed up wrong bit to cd! :roll: ). I'd more or less buy it again in a flash, but something is nagging at me and telling me to look for something more easily wideFS comapatible. I've Not found it yet! :? An open niche :?:

Been away from flightsim for an extended period (2-3 years) Bought Flightsim '04 last weekend, and already found your great work. Found I just had to order some of that - thanks for writing the good stuff! Looking forward to seeing if I can get inventive with it all. (it's where the fun is!) :wink: You are going on into 2006 with it all aren't you? (despite what you wrote about that) I've not just bought this for only 2 months have I? :P