Is it possible to make ofp access...

[Prospero 1]

Hi all,

Is it possible to get OFP to read in (at something like perhaps 50 Hz, or approximate frame-rate) a small amount of data (say, at least 512 bytes) generated from an external application? Either an external application running on the same PC, or a separate PC over a network?

Prospero

[BOPMatt 0]

Hmm, could you be a little more precise on that subject or at least the purpose?

LoadFile or PreprocessFile could of course be used to read data from somewhere on the same machine (absolute and relative pathnames will work for all file operations in OFP as far as I have tested ... I use that fact in order to store all my custom sounds and music tracks in one single directory) ... but that depends on what type of data you want to load?

Imho binary data won't work, but if you want to import some sort of dynamic variables etc. you could of course use the standard file-reading operations...

Waiting for more information...

[Prospero 1]

Ah I see your point, yes.

So, put this (simplified) case:

If one has an external application writing a file which we'll call changing.sqs to the relevant user mission folder, and let's say it does this every second or so. I could then simply [] exec "changing.sqs" every second or so in a script within that mission - and the latest version of changing.sqs would be executed each time?

The reason, by the way, is to get OFP to read in some state data being generated by a (fairly complex) flight-model software module. At the moment, without the ability to precompile OFP scripts, it needs to be executed outside OFP for speed reasons.

Prospero

[BOPMatt 0]

So if your application is writing some sort of script or a set of values (by assigning variables) I don't see a problem:

Let's say you want to make your missions always use weather and daytime-settings corresponding to your region and you have a script (or application) running that is able to extract that data from somewhere.

So you could periodically (say every minute) generate an ascii-file, e.g. "set_conditions.sqs", looking like this:

60 setOvercast 0.3

60 setRain 0.7

60 setFog 0.2

skipTime (19.2 - daytime)

Where 0.3,0.7 and 0.2 are the "real-world" values inserted by the application and 19.2 is the current time in hours (though that skipTime-call would make more sense if executed only once in "init.sqs").

Of course your application needs access to the same machine that is running OFP (well, network-drives/shares may work too ... haven't yet tested that) and you'll have to store that script "outside" the mission file itself so you could have a trigger with a timeout of 60 seconds and this in the init-field:

[] exec "../dynamic_scripts/set_conditions.sqs"

(as I mentioned before I use this method to store my custom .ogg-files in a dir called "SoundBank" so I can change them on the fly, reuse them and keep mission-pbos small and flexible)

exec, loadFile and preprocessFile will all work (regarding their special requirements) and always get the current (updated) file though imho preprocessFile was implemented to avoid permanent and recurring file access

[bn880 5]

I suggest you just run a small test on loadFile... make sure you get no file permission errors as the file is being read by ofp + external application and written to by external application.

Do something simple like hint or sidechat and just keep changing the message every time.

Too much theory and not enough experimentation here already. You have everything, try it.

[Guest]

I think that Suma mentioned that loadFile reads from disk each time.

[Prospero 1]

Thanks BOPMatt and all;)

Yup, it looks like it's time to try it. This may be naive but perhaps setting up a RAM disk to read from / write to might be a bit quicker. Anyway, I'll just have to see now, and hope that nothing nasty happens regarding the possibility of simultaneous access of the file. Yes, I know that's not the correct term, but this is new to me;)

Prospero

[Prospero 1]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (BOPMatt @ Oct. 30 2002,19:18)</td></tr><tr><td id="QUOTE">So if your application is writing some sort of script or a set of values (by assigning variables) I don't see a problem:

Let's say you want to make your missions always use weather and daytime-settings corresponding to your region and you have a script (or application) running that is able to extract that data from somewhere.

So you could periodically (say every minute) generate an ascii-file, e.g. "set_conditions.sqs", looking like this:

60 setOvercast 0.3

60 setRain 0.7

60 setFog 0.2

skipTime (19.2 - daytime)

Where 0.3,0.7 and 0.2 are the "real-world" values inserted by the application and 19.2 is the current time in hours (though that skipTime-call would make more sense if executed only once in "init.sqs").

Of course your application needs access to the same machine that is running OFP (well, network-drives/shares may work too ... haven't yet tested that) and you'll have to store that script "outside" the mission file itself so you could have a trigger with a timeout of 60 seconds and this in the init-field:

[] exec "../dynamic_scripts/set_conditions.sqs"

(as I mentioned before I use this method to store my custom .ogg-files in a dir called "SoundBank" so I can change them on the fly, reuse them and keep mission-pbos small and flexible)

exec, loadFile and preprocessFile will all work (regarding their special requirements) and always get the current (updated) file though imho preprocessFile was implemented to avoid permanent and recurring file access <span id='postcolor'>

BOPMatt,

I've set up a RAMdisk as s:

What would one specify in terms of the root pathname to get a file (let's call it input.sqs) to run from this drive? I've tried the following, but OFP says it can't find the file:

[] exec "s:\input.sqs"

Help much appreciated;)

Prospero

[BOPMatt 0]

Well, as I mentioned before I've yet only worked with relative pathnames (relative to the mission file so I'm referring to different directories when previewing in the editor and playing the final mission)...

For relative pathnames the simple slash "/" will work (though working on a win FS) instead of the backslash "\".

So e.g. "../../../../filename" will take you to your OFP-installation-dir when previewing from the editor but to will in my case lead me to the drive where ofp is installed. But I can't guarantee that absolute paths will work though I would try again using / instead of \