Red on Avsim

[hm]

Hi Pete

Your announcement on AVSIM regarding FSUIPC :

... "allowing applications to select 'white on green' messages in FS..." and I thaught this was impossible? :lol: I hope we can do it via "button programming and conditions also :wink: ".

Best regards,

Hugo :wink:

[Pete Dowson]

Your announcement on AVSIM regarding FSUIPC :

Hmm. Me? Announce on AVSIM. I don't announce anywhere.

... "allowing applications to select 'white on green' messages in FS..."

Oh, a quote from the release notice for the version of AdvDisplay which has been on pre-release here for weeks?

and I thaught this was impossible?

Er ....why?

I hope we can do it via "button programming and conditions also

Sorry, I have no idea what you mean. The messages come from programs which send them to offsets in FSUIPC. There has been a "white messages" option in FSUIPC (see Technical page) for many releases. All that the addition in version 3.51 does is allow the application to operate that option via the offsets.

What are YOU thinking of?

Pete

[hm]

Pete,

AVSIM says on his home page:

Peter Dowson announces that AdvDisplay version 2.14 is now available. Pete notes, "This includes a minor change, but it is essential for compatibility with a new facility in FSUIPC 3.51 (soon to be released) allowing applications to select 'white on green' messages in FS."

Sorry, about the misunderstanding of the statement. I thaught about something with button programming like:

13=CU(F+0,13)0,6,(code for 'give message'), Gear is up

And if the condition is true the message "Gear is up" would appear on the screen. Well, I have to wait for it, the basic stone is allready there :wink:

Regards,

Hugo

[Pete Dowson]

Sorry, about the misunderstanding of the statement. I thaught about something with button programming like:

13=CU(F+0,13)0,6,(code for 'give message'), Gear is up

No. That would be a huge amount of work, and no one has ever remotely suggested anything like that. The message facility in FSUIPC is used via the offsets -- see 3380 and 32FA. You could write an application to do what you want. The facilities have been there since FS2000 days. They are used profusely by many programs.

Pete

[hm]

No. That would be a huge amount of work

Well, thats the thing I don't understand. If I take the same example:

13=CU(F+0,13)0,6,(code for'give message'),Gear is up

If I analyse it, I could write it like this, however, I am not really sure about the syntax right now :

13=CU(F+0,13)0,6,Cx01003380,x43

14=CU(F+0,13)0,6,Cx01003381,x65

15=CU(F+0,13)0,6,Cx01003382,x61

16=CU(F+0,13)0,6,Cx01003383,x72

17=CU(F+0,13)0,6,Cx01003384,x20

18=CU(F+0,13)0,6,Cx01003385,x69

19=CU(F+0,13)0,6,Cx01003386,x73

20=CU(F+0,13)0,6,Cx01003387,x20

21=CU(F+0,13)0,6,Cx01003388,x75

22=CU(F+0,13)0,6,Cx01003389,x70

23=CU(F+0,13)0,6,Cx0100338A,x00

24=CU(F+0,13)0,6,Cx020032FA,x0002

where x43,x65...x70,x00 are the codes for the null terminated string "Gear is up" and a selection of a 2 second display time or much shorter by a Dword settings:

13=CU(F+0,13)0,6,Cx03003380,x72616543 raeG

14=CU(F+0,13)0,6,Cx03003384,x20736920 si

15=CU(F+0,13)0,6,Cx03003388,x00007075 pu

16=CU(F+0,13)0,6,Cx020032FA,x0002

Seemes that feasible?

Hugo

[Pete Dowson]

Well, thats the thing I don't understand. If I take the same example

The work is mainly in the syntax analysis for the parameters and in restructuring the tables to allow variable length parameters. I certainly don't re-parse the INI file every time buttons are pressed, it is all fast table look-up. The problem with variable length stuff like strings is that I need to do one of:

1) allow for the maximum string as a parameter in all possible button positions (something like 2048 x 128 extra reserved bytes), or

2) have a fixed allocation area of n bytes (eg 1024) into which all strings are placed, and use pointers or indices to access them from the table. Once the space is used up, discard further messages (mark the lines as in error in the INI file), or

3) dynamicaly allocate strings from the heap as needed, but otherwise as (2). This is the easiest, but the one I like least. I deliberately keep heap usage as low as possible in all my FS modules because it can affect performance more than anything, especially when Windows has to tidy the heap to get the needed space.

All this would be easier too if it could be done once and for all when FSUIPC is first started, but unfortunately I discard part of the tables (that part assigned specific to the current aircraft), and re-parse the INI for a newly loaded aircraft. So some strings may stay, some may go. this makes alternative (2) look difficult unless I use two areas, one for global and one for aircraft-specific.

Admittedly, none of this is really complex programming, but in the context of already rather complex working code, I would rather re-write the relevant parts of it than try adding all this stuff into it. Things have grown over the years and have got messy. Each new addition makes it worse, and more likely to contain errors (as you can see by checking my "bugs fixed" in this area over than last many releases).

This is why I said it would be a lot of work. I didn't say complex or impossible, just a lot of work.

You can certainly do it the way you have illustrated. Do it that way for now, remind me to consider extending the syntax at another time, certainly not before February please, and after that it depends on what else may need to be done. As I said, until you mentioned it there has been absolutely no requests. If there had been it would have been on my list and may have got in before I froze FSUIPC for another few months.

Regards

Pete

[hm]

Hi Pete,

Thank you for having taken the time for this extensive explanaition.

I will write a small utility program that allows to expand my "own dummy instruction" in the FSUIPC.INI to a series of offset set instructions.

Best regards,

Hugo