wweyers

Thank you Pete for taking the time to respond! Best Regards Walter

Dear Pete, thank you so much for your input! But this confuses me. With ipc.writeStruct( ... , 0x0246, "1SW", minsdiff) you actually write the time zone offset (minsdiff) back? The corresponding SimConnect variable TIME ZONE OFFSET is documented to be not writeable, as well as offset 0x0246 as per your docs. Did your experiments prove that wrong? This might in fact do the trick, to force a particular time zone, even if it is a wrong one... Kind regards Walter

Dear Pete, this might not be the best forum for SimConnect questions, but this one might be an easy thing for you to get me some ideas on: SimConnect offers: CLOCK_SECONDS_ZERO CLOCK_HOURS_SET CLOCK_MINUTES_SET ZULU_HOURS_SET ZULU_MINUTES_SET ZULU_DAY_SET ZULU_YEAR_SET So, no way to set a local year and day here. To set a local date and time by setting the time part with the CLOCK_xx events and the date part with the ZULU_xx events might end up in a wrong resulting local date/time with an offset of +/- one hour in case the new date has a different daylight saving time and therefore a different timezone bias. Currently, I help myself in that I try to set the new time using the CLOCK_ and ZULU_ mix approach and afterwards I recheck the resulting local time against the wanted new local time. If they differ, I use the now updated "TIME ZONE OFFSET" variable I receive from SimConnect to update the zulu time, causing the sim to reload the scenery a second time, which is of course not nice. How are you dealing with this problem in your FSUIPC API? The whole problem seems to be around knowing the correct time zone bias for the current lat/lon and the desired date/time. I do not see how to get hold of this information other than asking some google web services and the like. Any ideas would be very much appreciated. Kind regards Walter

Dear Pete, thank you very much for your comprehensive reply! Regards Walter

Dear Pete, I'm quite an experienced system level programmer but almost new to remote controlling FSX. I successfully updated your API for current Delphi versions and use it with no problems. My first question is regarding the way requests are processed on the server side (FSX). If e.g. I do a write request on #0BB6 (Aileron Control Input) followed by an immediate read request within the same IPC call (SendMessageTimeout(...)), will the response for the value set during the write immediately be reflected on the read? Means, will the request be processed synchronously on the server side? Or is the request being processed asynchronously, such that the result will be reflected at some later read request? My second question is regarding timing. Doing the same reads, without any writes, within a loop, the time for processing the request (i.e. the SendMessageTimeout()) differs significantly in the range of some few milliseconds up to around 40ms (using precision timers), all measured against a more or less idling FSX and an average CPU load of less than 5%. How comes? Has it to do with FSX periodically generating frames? Based on these findings, what would be your recommended polling intervall? Thank you for reading, kind regards Walter Germany