topic disappearing

[pdpo]

Hi peter

I have posted two days ago a big post with some 2 improvement suggestions.

I have checked the day after if there was any answer, there wasnt

today I want to look again and the complete topic is gone. Any idea what is

happening here??

Greetz Peter

[JSkorna]

Your last post before this one is from March 22. Are you sure it was posted?

[Pete Dowson]

I have posted two days ago a big post with some 2 improvement suggestions.

I have checked the day after if there was any answer, there wasnt

today I want to look again and the complete topic is gone. Any idea what is

happening here??

Sorry, no. Where and when did you post it? I've not seen any such thing here in the Support Forum. How long ago was this? Oh, only two days you say? I've certainly not seen anything that hasn't been answered for two days. That tends to only happen when I go on holiday (as I do this Saturday, by the way).

If you posted in one of the Sub-Forums by mistake, other than the "User Contributions" subforum (and in relation to a contribution you were making for others to use), then it may have simply been tidied up as being not relevant, if it also looked old and not followed up.

If it is something you you want help with, or are asking about, please try posting here in the Support Forum. It must come here if you are looking for answers to questions as otherwise they might not even get noticed. The other sub-forums contain more permanent information and files rather than support questions.

I am out for a few hours this evening but will deal with anything here before I go to bed tonight.

Regards

Pete

[pdpo]

Well, I just repost what I posted before.

Maybe something went wrong with the post. I have been searching for it for while and cant seem to find it.

I was afraid the topic was deleted for some obscure reason.

Anyway, the following is the post again : (maybe a little shorter then the previous :

I have 2 things which would my life (cockpitbuilding life) a little easier.

As I cannot add features to fsuipc i need to rely on your kindness to add something.

I have 2 things that would be nice to have and they are related :

1) would it be possible to have an extra parameter in the RunReady line which specifies an

fsuipc offset, length and value. If that offset have the value as expected then the

runReady is executed otherwise it is skipped.

Use : I would like to use this feature so I tell fsuipc/widefs to start different programs

depending on the type of plane that is loaded in FS

2) a result of point 1 is that we would need much more entries for runready. Now we have only 9

but in order to build some sequences of programs which need to be loaded depending on an offset

we would need more then 9 but 64 (or 128)

Thanks a lot Peter to read this post, thanks a millon if you could implement this.

Greetings Peter Depoortere

Belgium

[Andydigital]

I remember reading a post with a request like this the other day so it definitely was here at some point, I seem to remember you saying you had a cockpit at home and you shared it with your children at times and that you wanted to make the process of loading different stand alone external exe gauges simpler and dependent on which aircraft you were loading up in FS.

[Pete Dowson]

1) would it be possible to have an extra parameter in the RunReady line which specifies an

fsuipc offset, length and value. If that offset have the value as expected then the

runReady is executed otherwise it is skipped.

Use : I would like to use this feature so I tell fsuipc/widefs to start different programs

depending on the type of plane that is loaded in FS

Why an offset? How would that get set? If you wanted Aircraft or Profile-dependent program loading, why not have it implemented in the same way of all the other Profile or Aircraft-specific facilities, like the Keys, Axes, Buttons,, JoystickCalibrations and Auto macro running facilities.

Possibly the best way for me to provide an equivalent facility would be to add program running facilities to the Lua ipc library, alongside the "ipc.runlua" and "ipc.macro" facilities already provided.

2) a result of point 1 is that we would need much more entries for runready. Now we have only 9

but in order to build some sequences of programs which need to be loaded depending on an offset

we would need more then 9 but 64 (or 128)

Again, I'd rather implement it in a more flexible way, such as additional Lua facilities. Wouldn't that meet the needs more flexibly? The conditions under which programs are run could be as simple or as complex as you liked, that way, and the Auto section method of running Lua programs in Profiles or Aircraft-Specific circumstances would be an easy way to relate them to aircraft being loaded.

The only thing i'm not clear about is terminating such programs. Is this also a requirement? Automatically or again by Lua library function? What happens if the Lua program is terminated -- should that terminate the programs it spawned, or not?

It needs some thought. I'm not really in favour of messing with the current [Programs] facilities -- they are unwieldy, not suitable for expansion, and certainly not as flexible as I like new facilities to be these days.

I'm on holiday from this coming Saturday for a week or os, so I can't really do anything till September now. But think about my suggestions and let me know. I will too. I'm sure something worthwhile could be done on those lines.

Regards

Pete

[pdpo]

@AndyDigital,

that was the post I was looking for... you see i had it posted but it disappeared for some reason....

Hi Pete,

well, I think you got the idea of what I like to acomplish. I have not worked with aircraft specifics in FSUIPC

as I use SIOC scripting to do all of my stuff and that script reads on an offset the tail number of the plane

and deducts a plane-numbers from it. That plane number is then used to let the script do different things.

You are better placed to know where in your code this could be added. Of course LUA might be ideally as this

poses a lot of flexibility.

Ideally programs spawned by a logic could be stopped when the logic returns false or when LUA stops.

In my case it would be nice to have programs started when an fsuipc offset (plane type) has a certain value

and to stop the programs when the offset changes and load another set.

Pete, enjoy your vacation.... dont think about this... this is an idea...for future improvements...

When september is there and you decide to work on fsuipc then you can think about this.

Greetings Peter Depoortere

Belgium

[Pete Dowson]

You are better placed to know where in your code this could be added. Of course LUA might be ideally as this

poses a lot of flexibility.

Yes, I think so. And it avoids messing in very old code and risk introducing new bugs. Lua is easily expandable by adding new library functions.

Ideally programs spawned by a logic could be stopped when the logic returns false or when LUA stops.

The Lua interpreter never "stops", only the individual threads. However, I can see the need for the facility to start a program running, via a simple Lua statement, without that Lua thread continuing to run. After all if it hasn't anything else to do there's no point in hanging around. So maybe there needs to be three library functions:

1. Start a program which runs independently of the thread

2. Start a program which is terminated (kindly or by process killing) when the thread terminastes (tidily or forcibly)

3. Kill a program tidily or by process killing

Of course 1 and 2 would probably be the same function with different options (much like the Run parameters in the [Programs] section).

You might also need auxiliary functions:

4. Test if a process was running

5. Bring a process Window to the foreground (gives it keyboard and mouse focus)

6. Put a process window to the background

7. Minimize, maximize, restore a process window.

In fact, overall it might be quite extensive, so I would probably collect all such functions into a separate new library. Have to think of a library name: maybe "run" or "ext" (for "external process functions").

BTW are you using FS9, or do you have a really very powerful PC, because the thought of having up to 64 or 128 processes running alongside FSX in the same PC is pretty horrible. What performance can you expect?

On the better side, having such facilities in a Lua library means I can easily add the same facilities to WideClient, so these things can all be done on networked PCs too (where, in my opinion, they all belong! ;-) ).

In my case it would be nice to have programs started when an fsuipc offset (plane type) has a certain value

and to stop the programs when the offset changes and load another set.

The [Auto] facilities in FSUIPC are explicitly designed to start and stop macros and Lua programs based on aircraft name -- or Profile name, which may be more convenient. This would be a far more efficient way of doing such things, though of course with Lua you could do it your way if you wished.

When september is there and you decide to work on fsuipc then you can think about this.

It is interesting in any case, and I'd enjoy implementing such a library. Remind me in September.

Regards

Pete

[pdpo]

Peter,

I am using FS2004 on a good computer but the facitilies I was trying to get should be available for connected PCs via wideclient.

All instruments are running on remote computers with their respective screens.

Thanks, I'll trigger you again in spetempber....enjoy the vacation....

Greetings Peter Depoortere

Belgium

[Pete Dowson]

I am using FS2004 on a good computer but the facitilies I was trying to get should be available for connected PCs via wideclient.

All instruments are running on remote computers with their respective screens.

Ah, just looking back it hadn't actually clicked in my head that you referred to "RunReady", a WideClient parameter. I was thinking of the Run parameters in the [Programs] section in FSUIPC's INI file! That makes a bit of a mockery of all my talk about Profiles and [Auto] sections. Sorry! I must have been confusing you a bit with all that! I think I started off wrong after your intro saying "as I cannot add features to fsuipc ...".

This actually makes it even more important to do it via the Lua system. I really wouldn't want to try doing it using extensions to the "RunReady" part!

Would you mind if I changed the title of this topic (if I can, that is)? It isn't really applicable to the true subject and I'd like to be able to find it more easily on my return.

Regards

Pete

[pdpo]

Hi Pete,

you were reading my mind just now, I was going to post : could you change the title as this one doesnt really show about

what it contains anymore.

Greetz Peter

[Ian P]

I might be able to if someone can suggest an appropriate title?

If not, I'll ask the Big Boss if he can.

Ian P.

Forum Admin

(P.S.: I have no idea what happened to the previous topic either, sorry!)

[pdpo]

Hi Peter,

I know it has been a long time since september ... did you give this already a thought?

Greetings Peter Depoortere

[Pete Dowson]

I know it has been a long time since september ... did you give this already a thought?

Do you mean the facilities to run programs, like the ones in the ext Lua library added back in September, soon after your request? Here's the entry in the current FSUIPC4 History file:

A new Lua library called ext is added (also in WideClient 6.899h) which loads, handles and closes external programs and, to some extent, program windows such any those undocked from FS. The latest Lua plug-ins package includes full documentation. The 'ext' library was then extended with shell, keys and message posting functions. This also applies to WideClient 6.899j.

The current versions of FSUIPC are 4.823 (with a minor 4.824 update available too), and 3.999g, with WideClient at 6.961. They all include these facilities among many others. See the Download Links subforum.

I think you perhaps need to scan the forum occasionally for updates? ;-)

Pete

[pdpo]

Hi Peter, indeed... it was a long time I did not look at the forum... havent noticed this...

will try out if this can help me....

greetings peter