Trigger external program from within OFP..?http://

[DBR_ONIX 0]

A typo a friend, DaveP lead to me thinking up this..

Well, lets start by copying this typo here..

it was..

Quote[/b] ]

STOLAction = this addaction ["STOL","stol.exe"]

_plane = _this select 0

_x = getvelocity _plane select 0

........

Okay, it was supposed to be .sqs, but would it work with a random file type?

I shoved a Visual basic program I made in the User/Username/Missions/Test.intro file, this addaction ["blah","script.exe"], previewed and hit enter..

Hmmm, not exactly usefull, but, what if you use an external program to monitor that file, and see when it's opened with Visual Basic? (Ye I keep bringing VB up, but most similar program langugaes will work too, it's just the one I know )

So, you have a "script" (Anything) that is.. erm.. Opened/Run (in a way), that you can call from anywhere a normal script can be called from, addaction, INIT script, weapon firing, addaction..

From past "Nah, can't be done" threads I've seen (Mainly on OFPEC), I can think of these ideas.. :

Combat Photographer

A weapon that every time you fire the camera (Basicly gun that fires bullets that don't do anything), it triggers the EXE, that takes a screenshot

My idea, the real intelligance photos, where a photo (screenshot) of enemy base is taken in quick cutscene, and put in mission PBO, where a projector screen uses the taken cutscene (always same name) as a surface texture

The problem was getting something to take the screenshot, now with this idea, it's possible..

Just to clear up, I know OFP doesn't run the script, it opens it, and you could monitor the file, and see when it's run with a VB/Delphi/etc program, take the screenie, shove it in mission folder (un-pbo it, shove in texture, re-pbo it)

It IS possible, I'm not sure of how you monitor a file being opened in VB, but a friend who knows should be online today, and I'll ask him

Anyone got ideas/comments/suggestions/random donation/coders?

Thanks for reading (unless you just skiped here, if so, shame on you!)

- Ben

[Edit : Stupid HTTP:// thing, shoo!]

[General Barron 0]

Hmm... interesting idea. Never thought about monitoring whether a script was accessed by OFP as means of 'communicating' with external programs.

One quick side note, scripts don't HAVE to be labelled with .sqs, so running a .exe, .txt, .xxx or any other file with the "exec" command is exactly like running a .sqs file. Most .exe files prolly aren't written in OFP script, or in ASCII format at all, which would explain the way your error looked.

As for your specific idea, (taking a picture, then inserting it in the mission): very creative, but I don't think it would work. OFP seems to read all it's .pbo files when you boot it up, and doesn't like it if you try to change things after startup. For example, you can't drop new addons into the addons folder after booting OFP; nor can you delete .pbo files once they are in use. So I doubt you could modify a mission file while it is in use. It might work, but I doubt it...

But I think this could be more useful in other ways. I'm thinking MP mainly, but it could be used to 'write' to any external script file. I'm thinking, to keep track of scores and any other stuff, by editing an external .sqs file. Of course, this is already possible with SoW, but who knows...

One problem though: is it even possible to detect if/when a file is accessed? My Java is pretty rusty, but I don't ever remember seeing a way to do that. If it is possible, then this might have lots of potential...

[pajama 0]

Yeah! Now you can hide viruses and trojans inside the .pbo!

j/k

[vektorboson 8]

As for your specific idea, (taking a picture, then inserting it in the mission): very creative, but I don't think it would work. OFP seems to read all it's .pbo files when you boot it up, and doesn't like it if you try to change things after startup. For example, you can't drop new addons into the addons folder after booting OFP; nor can you delete .pbo files once they are in use. So I doubt you could modify a mission file while it is in use. It might work, but I doubt it...

It would work. You can load images/textures with setObjectTexture and with ctrlText (set images in dialogs). Those images/textures can be placed somewhere in the OFP-directory-tree and are accessible through OFP; you can even update them while running OFP!

Quote[/b] ]

One problem though: is it even possible to detect if/when a file is accessed? My Java is pretty rusty, but I don't ever remember seeing a way to do that. If it is possible, then this might have lots of potential...

It should be possible through the WinAPI; the "File last read"-meta information should be updated when OFP accesses a script, thus you would just check if that date/time changed.

[LepparD 0]

My old squad and I was planning to make a "WAR map" over a whoile island cutted into zones. And whenever a 45 minute game was over, the zones would be saved as well as armour count etc. The game would restart, allowing new players into the allrdy fighting battlefield. We were pretty far in the project with web layouts etc. (Website, with image over war-map and the zones in correponding colors), with countdown for next player-entries.

But when bis released information about ofp2 and the ingame join, we dropped the production... Also since the ofp multiplayer scene isnt what it has been.

[[aps]gnat 28]

Nice idea too LeaparD .... shame its lost now and OFP2 is so far away

[DBR_ONIX 0]

Quote[/b] ]One quick side note, scripts don't HAVE to be labelled with .sqs, so running a .exe, .txt, .xxx or any other file with the "exec" command is exactly like running a .sqs file. Most .exe files prolly aren't written in OFP script, or in ASCII format at all, which would explain the way your error looked.

Yup, I wasn't sure whether OFP would like non.sqs files, but it reads them just like any .sqs file, the error resembles what happens if you open an EXE with notepad or the DOS-Edit thing, it was more you can access the OFP.exe file, and stuff that isn't in mission folder or PBO

I'm looking into the WindowsAPI stuff, to get the last read date of a file, and if it's within last second, for example, the script/file has been accessed (By OFP as a script). I should have something by this evening..

That WAR mission sounds impressive, shame you scraped it

- Ben

[Edit : Left quote in from the quote button]

[DBR_ONIX 0]

Nope, had look at WinAPI stuff.. ow

I'll keep trying, though

- Ben

[LepparD 0]

Well, since ofp2 is years from now... Ill look into it again...

Havent coded in ofp in a year though....

I was in charge for the mission scripting, and another member for the interaction with a program. I think his plan was to just start an .exe file up (i actually think it was a vb program), with -parametres.

For example: this addaction ['blah','script.exe -levie=east,1bmp,2t72,14infantry,3rpg" Monti="West,2m2a2,1jeepmgun"] etc etc.

Would some1 look into this?

This program, would then print out these values into a webpage accesseble on the net.

The hard work is to make it a persistent world. Which means first of all, make it alot harder to gain ground than fx CTI... So when captured a city, you automatically gain some AI defends in the town and around it, making a frontline with trenches etc. To take a town takes alot of time, but is very gaining when done - so you will have to work close together to conquer land. It will be very similar to CTI in some areas. The more land you have, will give you more money... But things cost alot more than what they do in CTI.

In short, you can say its a slow long-time based CTI, where you can go offline, and log on again after maybe a day.

[hardrock 1]

I don't think that this would work, since OFP doesn't simply 'call' the scripts, it parses them. Means OFP's engine reads them line for line and executes the actions written down in the script.

So OFP would open the .exe in your example, try to read the first line and parse it, at this point it would simply put out an error.

Try it though, but I don't think that any external files/programs/utilities are accessable from within the OFP scripting environment, which would be a lack of security too.

[DBR_ONIX 0]

Correct, flashpoint doesn't acctualy execute the files like running them from Explorer, it just reads them, which is where the VB checking last read time comes into things

I'm getting somewhere with the read last-access times, though

- Ben

Update :

I've got VB to display the times when the script (in OFP root folder) is accessed, but it's only updated when it is modified..Hmm, I'll try it with a PBO file.. Nope.. They dont seem to register as being accessed

I've also tried applying a texture with path ../texture.paa,but it never worked

I'll have to look into setobjecttexture

[Yssabem 0]

Keep trying man, good work.

[General Barron 0]

SWEET! It works!

I just ran the ofp with the ECP. If you haven't used it before, the ECP has a set of external scripts that are used to store user-defined settings. External, meaning they are not in any .pbo file.

So I ran the ECP, then looked at the 'properties' tab of the settings script. Guess what-- it changed! The "accessed" date changed from what it was before to 'today'. So, this could, in some way, work.

However, I doubt you could check when individual scripts within a .pbo file (mission or addon) were accessed. The whole .pbo is considered one file to windows, and when you load a mission/addon, I think it just loads the whole thing into memory and then doesn't touch it during play. I could be wrong though, I'd have to do more testing. But as long as it works via external scripts, then the darn thing works one way or another.

@vektorboson

Ah yes, I forgot about dialogs and the setobjectexture commands. I was only thinking about pictures in briefings, overviews and in cut resources, all of which need to be specified before the mission is loaded.

Btw vektorboson, I'm a big fan. Thanks for the tutorials, and the great scripts, all of which I've learned a lot from. Didn't think you were still around the OFP world. Cheers.

[General Barron 0]

Whoops, found the answer myself.

[vektorboson 8]

Thanks @General Barron!

--

PBOs are indeed opened once at startup and only writable when OFP is closed, thus cannot be changed while the game runs.

--

When I get home, I'm gonna try to write such a monitoring program myself; this could indeed open a hell lot of new applications, if this actually works.

Only limitation is, that OFP then can send only one "bit" (accessing one file).

[vektorboson 8]

Seems as if OFP doesn't update the file access time stamp of scripts it reads

@General

You probably checked the last access time stamp with right click/properties? Well, Microsoft's smart programmers thought that this is actually an access, thus making the right click/properties the last access

[kegetys 2]

A better way to do something like this would be to hook the CreateFile function from kernel32.dll in your program. That way you could pass whatever info you want from ofp in the file name to your program, and then return the handle of whatever file you want back to OFP, like a script created by the program. That way you should be able to pass data to your program from OFP and then back to OFP again...

[suma 8]

Seems as if OFP doesn't update the file access time stamp of scripts it reads

I think it does (actually this is something done by OS, which can be hardly prevented). However the file may be cached internally, meaning it can be accessed only for the first time you use it.

Quote[/b] ]Well, Microsoft's smart programmers thought that this is actually an access, thus making the right click/properties the last access

This shows how hard it can be to prevent OS from modifing access time.

Quote[/b] ]A better way to do something like this would be to hook the CreateFile function from kernel32.dll in your program. That way you could pass whatever info you want from ofp in the file name to your program, and then return the handle ...

This sounds viable to me - interesting idea. It could be quite difficult to implement it for some of us, but for someone who created DXDLL it should be a child's play.

[General Barron 0]

Quote[/b] ]You probably checked the last access time stamp with right click/properties? Well, Microsoft's smart programmers thought that this is actually an access, thus making the right click/properties the last access  

Doh! Well, actually I'll have to double check this, because I could have sworn that I opened the properties before running OFP, saw the "last accessed" as a few weeks ago; then ran OFP, and the "last accessed" changed to 'today'. Hmm... guess I'll have to double-check that.

Quote[/b] ]Only limitation is, that OFP then can send only one "bit" (accessing one file).

My idea is to have OFP pass data to this external 'reader' in binary. So you basically would have two scripts that OFP runs (1 and 0). OFP would then run these scripts one at a time in a sequence, and then the reader would take this sequence of bits and convert it into an appropriate data type (to be used by some other program).

In this way you could pass numbers (integer and decimal), booleans and strings (in the form of char arrays) out of OFP. The biggest limitation is the string limitation, since there is no way to break OFP strings into components.

Quote[/b] ]However the file may be cached internally, meaning it can be accessed only for the first time you use it.

I've found that when editing missions, for example, you can modify a script while the mission is running (in 'preview'); save the script; then execute it again within the mission (let's say thru Vektorboson's script console for example), and it will then use the changed script. That leads me to believe that scripts are loaded the moment the exec command is issued, and each time it is issued. Of course, I would hardly claim to know more about how the game works than its lead developer, but those are just my observations...

Quote[/b] ]A better way to do something like this would be to hook the CreateFile function from kernel32.dll in your program.

Could you elaborate on this a little please? I'm nowhere near the programmer that others here are (especially Suma, of course), so I'm not farmiliar with that function, or what you are trying to explain.

[gandalf the white 0]

A better way to do something like this would be to hook the CreateFile function from kernel32.dll in your program. That way you could pass whatever info you want from ofp in the file name to your program, and then return the handle of whatever file you want back to OFP, like a script created by the program. That way you should be able to pass data to your program from OFP and then back to OFP again...

"data" , could this data be text? or also images?

Even text should be able to prove a major breaktrough, dump all the information of units that have a name that contains "save_" , in a .txt file (wich is also read by OFP) and you could have saving / loading in multiplayer, right?

EDIT: wouln't the mission need to be unPBO's then? so windows can see it's multiple files?

[General Barron 0]

...and you could have saving / loading in multiplayer, right?

Well, you already have saving/loading in MP. It's called Sinews of War.

A shame it hasn't really taken off yet, although I can't say I've helped, since I've never used it before. Still learning MP scripting though, so I guess I have an excuse...

[stgn 39]

this all sounds very interesting, but except for a program that takes pictures of you getting shot at what could this be used to do.

STGN

[General Barron 0]

this all sounds very interesting, but except for a program that takes pictures of you getting shot at what could this be used to do.

STGN

Well, it could be used for tons of things. Someone just needs to come up with them :P.

However, a couple ideas I've come up with so far would be MP servers that automatically update their webpages with current rankings/scores; or an observer module of sorts that records the movements of units, to later be 'played back' in OFP or another program; or making the ECP's in-game settings dialog actually edit the external settings scripts (to save changes).

Do those 'force feedback' vests still exist? You know, you were supposed to strap them on, and then when you play your Genesis or whatever it would rumble and make you "feel" the game better. You might be able to get one of those to work whenever you are hit in OFP.

[HuNtA 0]

hmm.. lemme count

survaillence missions: take pictures of xyz and review at end of mission

video recording: make it load fraps when firing

and what we were gonna be using it for:

live video feed

and Gb, yeh, now U can get rumble chairs.. dunno about proging them though.. would be kinda hard

btw, Im DaveP/HuNtA, co-worker with ben on this project

[DBR_ONIX 0]

Lots.. If it can be made (form the posts so far it seems it can) your no longer limited to OFPs scripting stuff, you can, as pointed out, make something like a small Planetside, with website stats etc..

(Live) Intelligance photos of an enemy base

In helicopter monitor, where a picture is taken every second (I'm not sure how, very quick switchview? Probobaly not) and setobjecttexture it to the screen etc..

Hmmmmm... All this is about getting stuff out of OFP, how about a program that lets you chat to people in game, from an external program?

A chat program, that puts the messages in a script, like this :

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

?!newmessage:exit

(Script changes from down onwards)

external globalchat [message]

~1

external globalchat [message]

~1

newmessage=false

Just basic idea, but could be interesting

I'll try more writing this check file program tomorrow, need break from it

- Ben