Ulitimate Traffic 2

[duckbilled 311]

I'm planning a new rig for FSX and I noticed that the new UT goes through simconnect rather than traffic bgls. Am I correct that I could load UT2 on a different computer and network it with my FSX computer. Purchasing UT2 will depend on what I can do with it and what the benefit will be. I have a similar question posted in their forum but I'm not getting any answers.What type of benefit do you think I will see considering the FSX rig still needs to render the ai. AI is big for me and I have almost 200 traffic bgls in FS9. I'd like to take some of the resources off of FSX by using simconnect but it would cost me more because I wouldn't be able to cannibalize my current rig to build the new one. If I'm not going to gain a lot, I'd rather put the money in to better hardwareAlso can you use three rigs together? Is there any benefit to doing so? In the end, the only external add ons I will have running will be ASA and traffic (if it works). Maybe a second rig is worth the money and trouble for ASA alone?Please forgive me if this is basic but I am new to multi computer systems.

[Guest AVN8tr]

Although SimConnect does run across the network it's not really meant for offloading work onto another PC. Mainly it's for getting what ever is going on with PC A and rendering an entirely different or even the same scene on PC B.

[Bob Scott 7,779]

Although SimConnect does run across the network it's not really meant for offloading work onto another PC. Mainly it's for getting what ever is going on with PC A and rendering an entirely different or even the same scene on PC B.

I completely disagree. SimConnect is a Microsoft-provided IPC mechanism intended to allow external add-on programs to communicate with FS internals, just as FSUIPC has done for a long time. In fact none of the specific examples listed by Microsoft in the SimConnect SDK reference involve "getting what ever is going on with PC A and rendering an entirely different or even the same scene on PC B." I suspect maybe you are confusing SimConnect with the old Netpipes architecture.Many people run ActiveSky Advanced, for example, on a second PC and have it inject WX via SimConnect over a LAN. It requires a Simconnect.cfg file be placed in the client (remote) PC's documents folder to tell SimConnect how to access FSX on the host PC via the LAN.As to UT II working that way, I don't know enough about the program to know if all of it's interactions with FSX is via SimConnect. My gut feel, from watching it work, is that in addition to its runtime interactions with FS via SimConnect, it also has to have access to a large number of FSX's data files, for example .bgl files (to find airport data) and aircraft files. You probably need to check with Flight1 or the UT II bubbas to know for sure...I have my doubts that it'll work LAN-distributed like you want.RegardsBob ScottColonel, USAF (ret)ATP IMEL Gulfstream II-III-IV-VColorado Springs, CO

[Guest AVN8tr]

Obviously you've never read the SimConnect API or it's supporting documents because you would realize that HALF of it is intended for Shared Cockpit along with the intent of having an extra rendering pipe on another machine. Ie PC A and PC B... the fact that you even bring the up that it won't work so why are you trying to correct anything? And have you actually used the SDK examples you refer too... they're all half baked and incorrect to begin with surprised you would even mention them as a "trusted source" on what the SDK can do or not do.

[beatle 0]

Shared Cockpit has nothing to do with SimConnect, Shared Cockpit is a feature of the Multiplayer system - some of the variables you can read/write via SimConnect will be sync'd via Shared Cockpit, but that's about the only connection.SimConnect is solely an IPC machanism. You can use it to read certain variables, write certain variables, receive events, send events, query weather, change weather, display scrolling text, display a selection dialog, load a flight/mission, extend the mission system with custom actions, etc.If you don't like the samples in the default SDK and you are using managed code, you can try out my replacement Managed SimConnect SDK, which has several C# sample programs (including Silverlight apps using the Virtual Earth CTP map control to plot your track on a map and a WinForm app that uses the Virtual Earth 3D control to display a "cockpit" view within VE3D). The SDK is available on my blog (http://beatlesblog.spaces.live.com) or on my Azure Cloud Site (http://beatlesblog.cloudapp.net), which has a few live sample apps also.Tim

[Guest AVN8tr]

Wouldn't using a separate core be the better trick here? Also correct me if I'm wrong but the last time there was a separate "multiplayer api/system" it got deprecated.. and even traces of it can't be found anywhere except on fileplanet. Now I suppose you can say what got deprecated was related to peer-to-peer and the network code in general from DirectX8, but Microsoft clearly states that the new preferred method is via SDK + Winsock2. It's obvious that half of that equation isn't part of the Aces FSX SDK and worse yet not even documented or a relevant example provided. So in that respect I would have to take back what I said about Shared Cockpit being a part of the API since there is no "automatic" approach. Also the fact that Multiplayer objects start off as AI objects now doesn't seem to suggest a true Multiplayer SDK :) Also what I don't like about the SDK examples is that they seem to be written in Office versus VS. There is no way in heck half those examples were actually ever compiled, tested, and then transferred to the API documentation. Even the most recent ESP docs on MSDN contain some serious typos that might frustrate the newbie that isn't confident in his/her C++ skills and worse of all waste time. Not to mention the serious typos found inside the library code itself which would drive anyone bonkers.No argument from me here, just semantics. And yes of course I checked out your new API and I would consider it much cleaner than the previous approach and the examples aren't "half baked" they are complete and obviously tested. Job well done.. also you state " Virtual Earth 3D control to display a "cockpit" view within VE3D" is this really where were headed? In a sense where FS users could use their own cockpits but enjoy the benefits of mass GIS licensing of "earth" by Microsoft.

[beatle 0]

Wouldn't using a separate core be the better trick here?

Depends on what you are trying to accomplish :-> You could want to run your SimConnect client on a networked second PC/laptop because you are running FSX fullscreen on the main computer and therefore wouldn't be able to see the SimConnect client's UI easily any other way. In the case of my VE3D WinForm sample app, since both VE3D and FSX are D3D based, running the SimConnect client on another computer allows both of them to have more resources to do what they do.

" Virtual Earth 3D control to display a "cockpit" view within VE3D" is this really where were headed?

No idea if this is where we are headed or not, I was just looking for an interesting sample WinForm app without doing much work :->, plus I've written VE3D based apps like this before and they were always a big hit at the conferences/conventions that ESP was shown at (IITSEC, etc).

Also correct me if I'm wrong but the last time there was a separate "multiplayer api/system" it got deprecated

Well, the zone got shut down (I think that's the system you are referring to, I wasn't on the team from FS7 to FS9, so don't recall exactly), so I guess that would deprecate the system :->. We didn't provide a MP SDK for FSX, but we also never promised one. Here's a little story: We originally planned to use an MS internal technology for the MP system, but it's schedule got pushed back and they weren't going to be live before FSX shipped, we couldn't use the zone anymore since that was shutdown, so we had to go with our fallback plan, which was to license the GameSpy SDK and use their servers for the matchmaking system (their SDK also had code already designed to handle NAT routers, etc; so we didn't have to write that ourselves). Because we used a 3rd party technology for the MP system, we weren't free to document it, and we fully expected to use something different for FS11 anyway.So, we wound up with a MP system that was less than we had hoped for, that we couldn't document, and involved servers we had no direct control over - such is life in the real world :->Tim

[Pete Dowson 558]

... such is life in the real world :->

Hi Tim,Have you received no PMs from me? I've written a couple of times over the last week or three, but never seem to get an answer. If you don't have the information, fair enough, but please do say so.Thanks,Pete Dowson