Home   Help Search Login Register  

Author Topic: What OFP Does With Your Script File  (Read 4337 times)

0 Members and 1 Guest are viewing this topic.

Bluelikeu

  • Guest
Re:What OFP Does With Your Script File
« Reply #15 on: 15 Jul 2005, 18:50:20 »
Well, the point it to be able to edit/change/re-arrange the scripts while ofp is running not just add some extra commands like move my mouse here.

Offline Baddo

  • Former Staff
  • ****
  • Reservist Jaeger
Re:What OFP Does With Your Script File
« Reply #16 on: 15 Jul 2005, 19:43:57 »
#1

Does OFP Linux dedicated server work in combination with fwatch running in Wine? Are you sure about that?

#2

I am a bit confused of what you are trying to accomplish. If you are editing a mission then you are editing it. But wanting to "edit/change/re-arrange the scripts while ofp is running"... hmmm...

I can edit/change/re-arrange the scripts while OFP is running. I don't have a reason to rudely take control of a script file from OFP and alter it's contest 'on the fly' if that's what you are after here? Like OFP is in the middle of a script and you change the line X of that script and OFP would notice the change in that file without reloading it? Is that what you want?

Maybe it's just me, but I can't seem to get what is the thing you want to achieve in practice to benefit mission editing or playing somehow.

But anyways, keep trying.

:)

Bluelikeu

  • Guest
Re:What OFP Does With Your Script File
« Reply #17 on: 15 Jul 2005, 20:42:13 »
1. As you said before, fwatch does not work in linux. In order to it to have more compatibility you load the fwatch exe with wine. This may allow you to use fwatch while under linux. I believe that one goes into the kernel and goes to the directory of fwatch and then types:
winex fwatch.exe
this will increase the compatibility that linux has with fwatch, its quite simple.

Oh, and i believe that the latest version of Wine is called Winex, but i'm not sure.

2. Idea: change scripts while playing a mission. That is the main idea. But i want to make it a bit more grand, as in one creates their own schedule that edits the scripts. I not sure how to explain this....

Enter the name of a script:
carbomb.sqs
Enter the name of the script that you want it to be swapped with:
carbom.sqs  //With bigger explosion
Condition:
gametime == 100s

Why have both scripts taking up resources and doing the explosion, when you want it to have a bigger explosion "carbomb.sqs //with bigger explosion" It would get rid of the problem of having to synchronize the two scripts.

These wouldn't be the only options, but its just an example
« Last Edit: 15 Jul 2005, 20:43:52 by Bluelikeu »

DBR_ONIX

  • Guest
Re:What OFP Does With Your Script File
« Reply #18 on: 25 Jul 2005, 20:55:47 »
About.. a month ago? Maybe more, I had the same idea, to edit scripts via external program. Basicly what I did was use Visual BASIC to write two small programs, using WinSock.
When a message was sent from the client, it sent the data to the server program, which then created a script in the root of the flashpoint folder called ExternalChat.sqs or something.
Code: [Select]
?(1<= MessageRead):exit
player globalchat "#25/07/2005 20:17:59 : testing"
MessageRead=1
EXIT

Then the next ::
Code: [Select]
?(2<= MessageRead):exit
player globalchat "#25/07/2005 20:18:31 : testing again"
MessageRead=2
EXIT
etc

This was sort of usefull, the program (Same idea without a client, the "server" program gets info and creates the file) could get information from lots of places (Server computer, website database etc) and display this in game. The biggest problem was stoping it (OFP) showing the same message repeatedly, as there was no way of getting OFP to delete the file, thus the annoying ?(2<= MessageRead):exit stuff
(Program not released, as it's kinda fiddley to set up and of very limited use, but it's availbe if needed, email me if you want it :P
With FWATCH, you could create a file in FWATCH/mdb with the message, read this and display it in game, then delete the file with the delete command, so it's not read again, very easy/neat, I'll write this sometime :P)


This came from the idea that if I could take a screenshot, save it to the OFP folder and setobjecttexture it to something, so you could have real ingame intelligence,
but triggering the screenshot was impossible it seemed..
But... you can run a script from the OFP root, and a friend made a typo : [this] exec "script.exe" (was supposed to be script.sqs)

Hmm, could OFP trigger a program? Nope, got a weird error message (ASCII characters, with a |# unknowned character or something - OFP handles and script run as a text file).
So OFP can load a file from the OFP root, can a program watch this file and see if it's read.. Nope :(

Buut, I posted the idea on the BI forums (This thread, and after a few pages, kegetys suggested the idea that led of to FWATCH, which allowed OFP to create a file from a script, then in a program, check this exists, if so take a screenie, save it to OFP root, setobjecttexture it (thing setobjecttexture FORMAT ["../../%1.jpg",{fwatch code to read number from file}] -
The file was created by the VB program.. So if the file saved was 2.jpg, the number in that file was 2, i.e CurrentPhoto=2).
The setobjecttexture bit never really worked very well, it needed the mission to be reloaded, I never tried taking the screenshot in the intro video, but this could work, then you could pass the enemy position via an FWATCH file, so the random positions are the same in the main mission.

(Program can be downloaded here)

Changing the script works, I've not really tried with loops, but I'm almost certain OFP reads the script, and runs it, after it's finished, it'll forget the script. If it's run again, it'll read the file again, and run it.

A few interesting ideas I came up with while going though the above stuff (Quoted from OFPCamera readme)..
Quote
   *   Use a webcam, and similar idea to current program, to take picture of it, save it into root of OFP folder. Then setobjecttexture (Or possible using dialouges) somewhere. Pointless, but if the OFP server had a server program running, which recivied this image from each player, and sent it to others, it could have it's uses I suppose.
    * Sending stats to database via internet. Use FWATCH to create and write stats to a file, in the form
      player=dbr_onix
      rating=100
      misison=MyMission1
      Then to use a program to read of these stats, change the format to
      http://blah.com/handleStat.php?player=Ben&rating=100&mission=MyMission1
      And go to this URL. Then using PHP, enter these values into a database (Could be done in any server-side language, like Perl etc). You could then use this database to create stats for players etc. Or using dialouge ("Enter your squad name"-type thing), squad rankings on CTI servers, for example.
    * Use a program to write values to a file, then use FWATCH to read these values into OFP. Or (an idea that I made a while ago, VB->OFP) directly write a script, using varibles from inside the program. I wrote a VB program that recived a message using WinSock, which displayed the message in GlobalChat. A similar idea could be used to get these stats sent to the database back, and display them ingame (A ranking number beside player info on a dialouge, for example)
    * Use a similar idea, dynamicly create an image, download it to each client and use setobjecttexture, cutrsc, or similar.

Anyway, I think this is long enough... ::)
Hope this gives some people a few ideas, the program to send stats to a database, if secured by a password entered via a dialouge by an admin (so theres a final arugment on the URL, &password=whateveritis, and the script checks this on the server), so cheating potential is limited a lot, it could be cool. You could have a mission that reloads every 30mins, but people keep their weapons/ammo, health and position, and save the enemys position/health/ammo (unless their dead, a sort of body-delete script), same with vehicles, maybe create new vehicles for desroyed ones at a "repair center". This is possible via Sinews of War's concept, or FWATCH (I.e create a file for each player, a file for enemy units, enemy vehicles etc.
So ben.db :
Code: [Select]
health 0.4
wepons=m16
magazines=m16
mCount=2
pos=[2322,4342,4]
Then load the file FORMAT ["%1.db",name player])

Good luck to anyone who tries anything relating to this, it can (And probobaly will) open biig doors, and lead to big missions (Big missions can fit though small doors :P)
- Ben
Edit : WinSock, not FSock ::)
« Last Edit: 25 Jul 2005, 20:58:22 by DBR_ONIX »

Offline Chris Death

  • Former Staff
  • ****
  • Finally Death's gonna get ya
    • OFPEC
Re:What OFP Does With Your Script File
« Reply #19 on: 26 Jul 2005, 09:49:05 »
hmm - i was just flying over the posts here, but maybe this
info could be useful for you:

I once tried to implement an anti cheat system, server side controlled.

On the server there was an sqs file in mpmissions folder, which
contained some kind of anti cheat admin names.
Simply playernames to be compared from an array to the actual
participating players in the game to determine wether an admin
is present or not (to enable ACS for him or them).

OK, blablabla and so on....

Point is: it was an external script, not included to the pbo, and
it was only one the server. I could edit the script while the game
was running, and the effect of changes took place.

I just can't remember if it was: \..\mpmission\script.sqs
or \mpmissions\script.sqs - or something like this.

But you can use external open source scripts from pbo'ed missions - like addons to this, missions can do this.

~S~ CD
Dont argue with idiots....they will bring you down to their level and beat you there with experience.

How to use Waypoint type Scripted