N6722c

Ahyou are the "Geoff D" on the Beta group? Why aren't we discussing this there, then? Well, FSUIPC4 is of course always receiving changes in the Transponder code, so it can populate the Offsets and supply such values readily to its own clients. If you think that a simple TransmitClientEvent back to SimConnect, presumably of an XPNDR_SET control, might "fix" it, then I can add it in now for you to try (just in case, as it were). What would worry me, however, is the latency imposed by SimConnect's use of TCP/IP asynchronous stacks and the associated queues. Supposing someone is incrementing through valuesx, x+1, x+2etc. By the time FSUIPC received the x+1 value the actual transponder might be already on x+2, and if FSUIPC then transmits the x+1 back, by the time that arrives the correct value might be x+3. This would effectively end up in a never-ending loop with nothing actually getting done properly at all! The only possible way out of that I can think of is for FSUIPC not to send any changed value until it has remained unchanged for a period of time, perhaps as much as a second. There's still a possibility that this would conflict with another change though. I wouldn't agree to it unless the above worries are resolved. I may have to insert some test code, with an adjustable delay (milliseconds up to several seconds), and only set the code as permanent after thorough testing. Regards Pete Pete, For all practical purposes, a delay of up to 5-10 seconds before implementing the READ-WRITE would be fine. As far as the Pilot is concerned, the display changes as he INCs & DECs. As far as the controller is concerned, he is not aware of the exact time that the pilot changes the code, but provide he gets an update in 5-10 seconds, he is happy. This should avoid any race conditions that you are worried about. ie. Transponder has to be at the same value for 5 seconds bfore FSUIPC does a READ-WRITE, and then not do any more WRITES until the transponder has changed from the last value when it was WRITTEN, and has once agan been stable for 5 seconds. ACTUALLY: This is far more realistic that INSTANTLY changing the Transponder, as, in real life, a Controller will not see a Transponder update from the pilot until the Secondary Radar swept through the Pilots bearing, and received a response from the Radar's Transponder Interrigation. Typical SSR rotation speeds are 5-10 sec/rev. Should be fine -- and like most of your "fixes", maybe it could be something that the user can select, so, if for some unforseen reason it caused a problem with some other systems, the user has the option to turn it on or off. ( Default is OFF). I would be delighted to test any "test coded FSUIPC" and report back to you with the results both in FSX Multiplayer (where it is needed) as well as test for any undesirable effects in Free Flying, or when on Vatsim. Regards Geoff_D

I didn't even know the MP system was so pro-active. Do the MP packets contain everything about an aircraft? But if it changes on screen, and is recognised by everything else as being changed, and only the "MP system" is excepted, then surely it must be an MP issue? Well, I'm not sure what "events" these are. The Simconnect interface for this certainly works 100% -- including using the XPNDR_1_DEC/INC, 10, 100 and 1000 controls. They all change the actual transponder value and the changed Transponder code is sent to any Simconnect clients who've asked to receive such changes. .Well, yes, it is their code. And as it does only appear to affect the MP system it explains why I really have no idea. There's nothing in any of my explorations in this or previous versions of FS which overlaps with MP I'm afraid. Sorry. Only in areas I know, and I'm afraid MP is not one. There's nothing appearently wrong with the Transponder stuff in all the areas I deal with. What methods are you talking about for these "reads" and "writes"? SimConnect? You are talking a slightly different FS language to the one I know. Are you talking as a Gauge programmer? If you think there is a bug, have you sent it to FS? Try reporting it, in detail, via tell_fs@microsoft.com. Well, if this is simply a SimConnect "TransmitClientEvent", yes, it could be done. But I'd really very much prefer that it be fixed at source. After all, Microsoft are actively changing things at this moment. Do you want me to submit it to MS on your behalf? There's no way I can provide corroborating evidence as I've never used MP and don't realy want to start now. It would be better coming from you directly if possible. If you are quick it might even make it into the forthcoming SP1 update. Regards Pete Peter I will submit the problem as a bug once again on the CONNECT site. I do not hold out ANY hope for it making into SP1 - I am sure you appreciate why, but I will at least try once again. However, if after SP1 is released (and your corresponding work load reduces), maybe you would consider adding the required processing to FSUIPC to effectively make the Transponsers in question functional in MP, by the READ-WRITE process. Once again, it will be a case of Peter Dowson's FSUIPC correcting problems in MS code @!!@. As you are probably aware, there is a growing interest in using the FSX MP system, and , for example, FS-MP, as a fast growing FSX MP Community of over 1000 members, would dearly like to start using Transponder Codes in our sessions. Knowing that if MS does not fix the issue in SP1, then FSUIPC will provide a work around (hopefully in the non registered mode), would allow us to plan ahead, and use the Transponder as an integral part of our sessions. Geoff_D

My fault, I did not explain the problem clearly enough. Yes, we are talking about an effect seen in FSX Multiplayer, but I do not believe it is caused by anything in Multiplayer. (1) We are talking about what happens when the Transponder Gauge is updated, and if that update is recognised as an update, and sent through the FSX MP system. (I know no MP SDK etc etc... I don't believe it is a MP issue). The Transponder works fine if it is a type where a new Value is written to the Transponder. Writting a new value to the Transponder is recognised as an event, and the MP system does it job, and the value is sent out to the Controller. ( So the MP part is working OK). Where I believe the problem is in the INC & DEC functions of the Transponder, that while cosmetically changing the value on the display, does not cause a system event, that triggers the new Code to be sent into the MP system. If one writes a new code to the Transponder, that write function causes an update (event).... So, the question is, what is missing in the standard INC DEC Transponder code. Whatever that may be, I suspect only MS can fix that . (and INC DEC tranbsponder would have to be re-comopiled again etc etc) I thought that this may be a know issue, and if not, I was bringing it to this forums's attention in the hope that FSUIPC could, like it has done so many times in the past, produce a work around for MS's faulty programming. Maybe this is not the case, I don't know -- I am looking towards the experts here to maybe throw some light on what is really happening. What I do know is that FSX MP DOES (100% SURE), send the transponder code correctly if the Transponder is update by a "WRITE SQUAWK CODE to the Transponder", and does not if if it updated using the "INC DEC" functions, which seesm to imply, that there may be something defective or missing with those INC DEC functions. Futher, if the Current Transponder display was READ, and then WRITTEN Back to, the the code would trigger an update event (or whatever the process is), and the code would be sent into the MP system. So, some 3rd part program, that constantly READ, and then WROTE back to the Gauge the same value, would seem to FIX (work around) the problem. If this is the case, could this possibly be one additional function that FSUIPC could perform ? (rather than having to run yet another background program to perform this trivial work-around function).

Is there somthing know to be defective with the Microsodt Transponder INC & DEC code ? Not all transponders work in FSX Multiplayer, in that, some do not send updated Squawk codes (to a controller). The Transponders that do not work use INC/DEC to change their codes. Transponders that do work Enter Digits into the Transponder from a 0-7 set of buttons. All Transponsponders work if you use an addon method to write the whole Code to the Transponder. So FSX MULTIPLAYER is more than capable of sending codes from ALL transponders, provide the INC/DEC method is not used. Even defining keys with FSUIPC to INC & DEC the Transponder does not, as predicted from the above, cause the Codes to be sent. The conclusion is, that the INC DEC, while changing the Displayed new Squark Code, does not cause a triggering (event ?) to send the new code from the Pilot's plane through the MP system. -------------------- Assuming it is an INC/DEC problem, then also, maybe it is an INC DEC problem in FSX Shared Cockpit that causes COM1 radios to get out of sync with each other ?? They CAN be resynchronized with a hidden guage that constantly reads and writes back their values, implying that maybe it is a similar problem to the transponder. So, I guess my questions are mainly directed to Peter, the expert in these matters ... (1) Is this a know Problem ? (2) If so, is this something that MS should be able to fix (they have it working OK on COM2, Nav1, Nav2 etc) ? (3) If FSUIC aware of this as a problem ? (4) If this something that FSUIPC could be used to make a "work around", assuming MS will not fix the problem ? BRUTE FORCE solution is to put a hidden, dummy gauge in each plane (real pain), that does this READ/WRITE to these two Guages every second or so, to FORCE them to operate correctly -- but there has to be a BETTER way ??? Geoff_D

EXACTLY -- The Host cannot change the time of his own session, once it starts, even if he uses FSUIPC or SIMCONNECT to alter his Local or Zulu time while the sim is running in HOST mode. Those Changes just get overwritten by, what I am calling this 3rd SIM_CLOCK, which was initialized when the session started. ( Actually the host cannot change many aspects of his own session, that he would like to, time being just one of them. He can allow the players to change things, like aircarft, display settings, airport, (but not time!!) etc, which he cannot even allow himself to do !!! go figure) I would just be happy, as a host, to be able to change the time of day of MY MP session. Geoff_D Peter: I understand your confusion now.... you were missing the important, and not obvious fact, that even the HOST cannot change the time of his own session, once it starts, no matter what he tries to do to force a change of Local or Zulu time. !!! One would obviously, "assume" that he would be able to (sigh).

Sorry Peter, I was probably not precise enough with my descriptions. Here is how I "believe" it works, based on outside observation of FSX operating. (1) The Host starts a session, and sets where geographically he is in the world, say London Airport. (2) The Host sets the time that the Sim will start at, that time being the local time at London Airport. (3) The MP Sim starts, and the Host sends out this time to all players, telling them that the local time at London, that they are to use. (the players machine then calculate the corresponding time if they are anywhere else in the world, ie if in NY, they subtract 5 hours etc etc). So everyone is in a MP Sim, simulating a period of time (date, time) as defined by the Host for this particular simulation, and this 3rd Clock (SIM_TIME) starts ticking away on the Host machine. On a regular basis, the HOST tells the client what the correct time is at LONDON, and the clients remain "in sync" with the host. -------------------------------------- This "theory" is based on the following observations in FSX. (a) The Host can set any time they like for their given location when they start the session. (b) This time is seen by the Host and Clients when they look at CLOCKS within the session, so everone is synced to the corect SIM time, with corresponding Time Zone Offsets as appropriate. © If FSUIPC or SimConnect attempt to change the LOCAL TIME or ZULU Time on the HOST, it starts to react, and load the textures in for that time, and then, within a few secinds, reverts back to the previous SIM TIME, and loads in those appropropraite textures. ie The Local time , changed by FSUIPC, gets reset back to this previous running SIM time. (d) Individual payers cannot define their own local time, as they could in FS2004. Ideally, it would have been nice if the HOST had the option to enforce SIM time, or to allow players to set any time they wanted -- as was the case in FS2004. It is this SIM_TIME I am looking to change on the on the SERVER/HOST, so that it runs at a new SIM_TIME, and therefore also updates all the players with this new time. Does that make it clearer ?? Geoff PS: If anyone else knows better how this works, PLEASE correct me :) I am only Guessing, based on observation.

Peter Thanks for your very informative reply. It would seem that Multiplayer runs on a seperate time CLOCK, that is initially set to a given time when the HOST starts the session, and thereafter "Free runs". I have tried changing LOCAL or ZULU time using FSUIPC. The time starts to change, textures start to reload, and then it changes it mind, and reverts back to the old time SIM_CLOCK time. (Hint hint) Yes, I appreciate that one cannot change the time as a player, as your time is constantly being update by the host. I wish to change the HOST's time (as the host), so that both the HOST and all the Clients TIME is changed to the new time (Typically back to a early daylight time, wrt the HOST's time zone). So, what I was looing for was a FSUIPC offset, that would modify this internal SIM CLOCK time. I realize the trick is finding this "Ticking Clock", but since you found the LOCAL & ZULU clocks in earlier versions of FS, if anyone can, it would be you. While I agree that the ideal thing would be to request, and obtain a simconnect function to achieve this, I think we both know that hell will freeze over first :( Hacking packets, while possible, and a sure way to achieve the desired functionality, is far from ideal, as you can appreciate :) Yes, if one was able to Change (read/write) to this 3rd Clock, then every time it was changed by the HOST, it would cause both HOST & PLAYERS to reload textures etc. This is what is wanted, expected and totally reasonable. One would NOT want to change time every few minutes, just typically once every 12 hours at the most. Geoff_D

Peter, Is there any chance you could add a FSUIPC offset to set SIM TIME. ? ( for the HOST of a Multiplayer session, on their Hosting/Server machine) ie the "Time of day" that the simulator is running when in MP mode. This does not appear to be the same as LOCAL TIME or ZULU TIME, which both seem to get re-synced to some SIM TIME, when any attempt is made to change them when in Multiplayer Mode (using FSUIPC or Simconnect) Being able to READ "sim Time" would also be nice, but not so important as being able to SET the SIM TIME. This function, like many others, is not yet available in SimConnect, thus adding another reason why FSUIPC will never be replaced by SimConnect :) ( Multiplayer Hosts would fine it a great advantage to be able to change their sessions time while it is running, mainly to revert back to daylight, without having to throw everyone off their session to reset the time, which they are forced to do at the moment ) Regards Geoff (Registered FSUIPC user)

Peter, Is there any way FSUIPC could be made to change the TIME of DAY of a MP session, by forcing a change on the hosting machine. Using the current FSUIP to program keys to change either Zulu Hours or Local Time hours, does not result in a permanent change -- a few seconds later, the system returns back to the original time. There must be another clock there somewhere ?? Geoff