Need help with the FS2004 weather interface

[mdomig]

Hello Pete

I'm playing around a little bit with FSUIPC and want to set the weather using the new FS2004 interface. However, I have troubles understanding the documentation and the general procedure to set weather.

Here is what I do, pseudocode:

Weather.SetAllToZero;

Weather.ICAO = 'GLOB';

Weather.Command = NW_DYNAMICS;

FSUIPC_Write(Weather, 0xC800);

Weather.Command = NW_CLEAR;

FSUIPC_Write(Weather, 0xC800);

FSUIPC_Process;

sleep(2000);

So far so good, the Weather is reset every time i do this. After that:

Weather.MakeItRain;

Weather.ICAO = 'GLOB';

Weather.Command = NW_SET_PENDING;

FSUIPC_Write(Weather, 0xC800);

FSUIPC_Process;

sleep(for_ages, see below);

Weather.Command = NW_ACTIVATE;

FSUIPC_Write(Weather, 0xc800);

FSUIPC_Process;

When executing my program step by step everything is just fine. I could manage to get it running after adding a ton of sleep()'s, without them I usually crash FSUIPC and FS. It definitely is a timing problem.

The documentation writes:

WAIT TILL THE TIMESTAMP HAS CHANGED before changing the C800-CBFF are and doing another NW_SET or SETEXACT!

I take it I have to wait for a new timestamp when using NW_SET_PENDING too.

But: Which Timestamp? I know there is a Timestamp in the Weather structure, but I don't know when or where to read it, and what to compare it to.

That timestamp-thingie seems to be a common concept in FSUPC, thus I feel a little stupid because I just don't get it.

Help me, please!

[Pete Dowson]

When executing my program step by step everything is just fine. I could manage to get it running after adding a ton of sleep()'s, without them I usually crash FSUIPC and FS. It definitely is a timing problem.

It crashes FS? There should be no way at all that is possible. Please give me more details.

The documentation writes:

WAIT TILL THE TIMESTAMP HAS CHANGED before changing the C800-CBFF are and doing another NW_SET or SETEXACT!

I take it I have to wait for a new timestamp when using NW_SET_PENDING too.

Yes. The "SET_PENDING" is a SET command. The reason you have to wait for confirmation is that the data you supplied, that which describes the weather, must remain intact until it is sent to and accepted by FS. If you don't wait for the confirmation and change anything (like the command) then the wrong things will happen.

I'm wondering, now, whether trying to ACTIVATE without first SETting anything upsets FS. If you leave the entire SET_PENDING part out does it crash?

But: Which Timestamp? I know there is a Timestamp in the Weather structure, but I don't know when or where to read it, and what to compare it to.

It says "WAIT TILL THE TIMESTAMP HAS CHANGED". So you compare it with itself, to see when it changes. You simply read it at the same time (i.e. in the same PROCESS) as the SET, then, after the process, loop (with small sleeps, or use a Windows TIMER so you can do other things) reading it again until it returns a different value, showing that the update has been accomplished. (For safety put a limit on how long you wait, to avoid hangs in case things go wrong).

That timestamp-thingie seems to be a common concept in FSUPC, thus I feel a little stupid because I just don't get it.

Yes, I've been using that system for years in various things, and this is the first question on it. But no question is stupid, it would be more stupid not to ask! :lol:

Regards,

Pete

[mdomig]

Hi Pete

Sorry. Late hours and too much coffee don't mix. For some reason, after setting the weather I have been reading the new timestamp from Area 0 (weather at aircraft) instead of Area 3 (weather writing). That and a wee little nasty compiler quirk was causing my problems.

After a few fixes it all works smoothly, now that I understand the way FSUIPC interacts with my program.

The crashes:

I've managed to crash FSUIPC, which isn't too hard. Just do a FSUIPC_Write, process() it and immediately after that a second FSUIPC_Write. The result is a log file getting bigger and bigger very fast, an inoperative Program <-> FSUIPC communication link and FS moving like slow molasses. After some time FS crashes on it's own, or, if it doesn't like to, after closing it. This is probably nothing new, after all this behaviour is described in the documentation. At least I remember having read something like that.

However, on two occasions I am unable to reproduce, FS crashed after it received weather information via FSUIPC and I opened the weather dialog in FS. Might have something to do with incorrect/impossible weather settings, but that's just a guess. I'll tell you if it happens again and I am able to reproduce it.

Thank you very much

Martin

[Pete Dowson]

I've managed to crash FSUIPC, which isn't too hard.

Actually, assuming you are using a recent version of FSUIPC, it should be extremely hard -- FSUIPC traps all errors and logs them, then continues. If you mean crashing FS, then yes that is extremely easy -- writing to some sensitive parts of FS can cause chaos.

Just do a FSUIPC_Write, process() it and immediately after that a second FSUIPC_Write. The result is a log file getting bigger and bigger very fast

All FSUIPC_Write calls do is add data to the data area, FSUIPC is not involved at all. The only time FSUIPC is involved is in the FSUIPC_Process call, where a SendMessageTimeout is used. Unless you have the timeout in that set too short, the FSUIPC_Process call won't return until the data it transferred has been dealt with in any case.

There are many programs which do Writes, Processes and Writes with no problems, so if you think you can reproduce a problem IN FSUIPC I'd like more details please. It sounds more like a problem being generated in your program. If you call FSUIPC in an extremely tight loop then naturally both your program AND FS/FSUIPC will be completely tied up and may appear hung.

This is probably nothing new, after all this behaviour is described in the documentation. At least I remember having read something like that.

Really? Where?

What language are you writing all this stuff in? Maybe here's a problem in the specific SDK code you are selecting. In the 4+ years of FSUIPC, using the exact same interface all this time, exactly the same as FS6IPC and FS5IPC before it (going back to FS95), I don't recall anyone with the sort of problems you are describing, unless it was an error in the program they are writing. Please supply more details so I can get to the bottom of this.

However, on two occasions I am unable to reproduce, FS crashed after it received weather information via FSUIPC and I opened the weather dialog in FS. Might have something to do with incorrect/impossible weather settings, but that's just a guess. I'll tell you if it happens again and I am able to reproduce it.

It is easy to crash FS's weather system by supplying bad data. Just providing cloud types that aren't supported will do that. In the FS98 and AWI interfaces I do check and correct the inputs provided, but in the case of the New Weather Interface I don't check anything -- FSUIPC is a direct conduit into the Weather DLL. I omitted the checking after discussion with the main Weather program authors. We thought more flexibility for possible experimentation would lead to better things, but that carries the risks of crashing FS as you have found.

Regards,

Pete

[CarloZzz]

Hello Pete,

I've experienced exactly the same problems as described here using the new weather interface for FS2004.

The last reply you've written here was a great help :

It is easy to crash FS's weather system by supplying bad data. Just providing cloud types that aren't supported will do that.

Before I was using the AWI for FS2002, and it didn't crash. But when I wanted to use the same code for FS2004, troubles started...

So I switched to the NWI, but with no validation for the cloud types implemented in my program. In the documentation I've found cloudType is an unsigned char values from 1 to 10. So I the program was able to send each value between 1 and 10. After some experiments, I've found only cloudTypeValues 1 (Cirrus), 8(Stratus), 9 (Cumulus) and 10 (Thunderstorms) are valid. Any other values (like 2,3,...) crash FS2004.

So my questions are :

If I use the AWI for those bad values, FSUIPC should validate and correct it, no?

Even with a new version of fsuipc and using fs2004?

And are there any more of these "bad values" for other weather data? Or is it documented somewhere?

Thanks in advance.

Greetings,

Carlos

[Pete Dowson]

Before I was using the AWI for FS2002, and it didn't crash. But when I wanted to use the same code for FS2004, troubles started...

The AWI didn't change from FS2002 to FS2004, but it is only capable of dealing with the global weather, which, in FS2004, is no use -- global weather doesn's stay global, it gets localised, and then you lose control unless you constantly restart by clearing all weather so it will install new global weather to all localised weather stations.

After some experiments, I've found only cloudTypeValues 1 (Cirrus), 8(Stratus), 9 (Cumulus) and 10 (Thunderstorms) are valid. Any other values (like 2,3,...) crash FS2004.

Yes, well. I never did those experiments. I suspect FS crashes because they made provision for extra cloud type graphics but never actually had time to implement them. I expect their use leads to pointers to graphics which aren't present.

In FS2002 and before, the unallocated numbers actually just gave one of the others, so they were never of any separate use in any case. There are actually several references to the implemented types, which I believe date back at least to FS95, certainly FS98. Here is just one relevant extract from the FSUIPC Programmer's Guide:

The cloud types used in FS98 still apply to FS2000/2002, although they all seem to be mapped by FS2000 to one of Cirrus (1), Stratus (8), Cumulus (9), or Thunderstorm (10).

If I use the AWI for those bad values, FSUIPC should validate and correct it, no? Even with a new version of fsuipc and using fs2004?

As far as I can check at present, FSUIPC has never imposed any restrictions on the cloud type setting. And until FS2004 it was never a problem -- bad values were defaulted to other meanings automatically, by FS. No one before has mentioned that bad values crash FS2004, but I suppose it doesn't surprise me. The complete weather system was discarded and written anew by different people for FS2004.

I'm not sure, really, how far FSUIPC should check data and try to prevent daft things from happening in FS. With most offsets and values there's really no way I can tell. Adding development time to test all possible values for all possible inputs is really not feasible, and in any case much of what has been added has been found by experimentation such as by using "incorrect" values, so I could, if I'm not careful, be restricting progress if I do such things.

And are there any more of these "bad values" for other weather data?

Sorry, I don't know.

Or is it documented somewhere?

No. You or I would have to experiment. This is how we learn things and develop new methods.

Regards,

Pete