BOPMatt

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 \

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

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...

I guess you would have found this using the board's search-function but here you go: if you want to make a single unit eject: unitname action ["EJECT",vehiclename] ... of course that also works with foreach in order to make groups eject (though you would usally use a script instead to add a slight timeout for each ejection because ejection more than 1 person at once will look more than weird...).

... that is because a condition is a control statement resulting in a boolean value (true or false). So if you for example want to activate a trigger only if a certain condition (besides the one you selected from the pull-down-list for activation) is true e.g. the leader of you own group is still alive you could set condition to: alive (leader player)

@edc The SetPos-command does also work with triggers so you can let OFP perform a loop (depending on the timeout-interval you chose for the trigger I recommend you choose a shorter interval, half the time for example, for the move-loop) in which you just call: Triggername SetPos (GetPos player) ... of course that works for other units too. I've used this to make a certain enemy officer surrender if he any member of my team gets closer to him than 15m and all of his guards are dead or out of sight ...

Well, as you suggested one way would be to create a trigger that gets activated by "present east". Adjust the range according to your needs (i think 200m should do the job most of the time but 500 may be more accurate possibly degrading performance though) and set an apropriate interval. Move the trigger along with the player (accordingly the range will not be 100% accurate for all friendly units or every single member of the player's group) and evalutate the value of the knowsabout for each enemy unit listed in the trigger (retrieved via the list command). So if an enemy unit is listed in that trigger's list and is alive and knowsabout player reaches a certain level it is time to start your "countdown". Afterwards it is up to you to decide how to manage that countdown: The most accurate way would be to let each enemy unit who matches the pattern described above execute (or call) a script which will simply run a 15-second countdown, afterwards check if the unit is still alive and if so call for help ...

Although I can't really outline a possible solution I would at least like to add a theory about the difference that might cause the problem. As you might know, if more than one human player is present the variable (or better reference) "player" points to different characters on each client. So if the internal "unload transport" command maybe (I can't in any way verify that but to me this seems to be the most significant difference between the cases you described above) makes use of "player" then this might confuse the engine and mess up the correct execution of the given commands. When encountering such problems I would always give manual scripting a try: You could work with the DoMove, FlyInHeight, DoStop etc. commands (like Chronicles also suggested) and make the troops eject from the vehicle by using the groupname leave vehiclename command or the unitname action ["EJECT",vehiclename] command (issuing defined names to the choppers and infantery groups would be a good idea for accurate results ... or more disappointment ) ... if you want to make that script more dynamic and e.g. use only the group to eject as a parameter you could also use the vehicle unitname command in order to determine the vehicle the desired group is currently assigned to ... I hope this might help... P.S.: when using the eject-action don't forget to call unitname UnassignVehicle first or the chopper will try to pick the corresponding units up again immediately...

I have not checked this issue yet and are recalling this from my memory, so feel free to correct me Answer: A short "no" with a long "but"... As far as I know you can't assign music to a single player since they will always play on the global "channel". You see I used the word "channel" and that is where I think you could give it a try: Think about defining your music as radio chatter (well, as far as I know that also means "degrading" the sounds to lower samplerates and mono) so you can at least tighten the group of recipients to e.g. a vehicle or the player's group (i think on death the player will automatically be removed from its' previous group but I don't know if you can assign him to a "special" group [using the join-command] while he's waiting to respawn). Not quite as good as simply assigning a music track to a certain player but maybe a path to walk And btw, I think one of the things that make OFP that "interesting" is that almost everyday people come up with unorthodox ideas that even BIS did not think of when creating the scripting engine

About your problem concerning FlyInHeight: Keep in mind that choppers (since 1.85 all aircraft "know" that command) do not respond immediately to that command. They will change altitude when switching to the next waypoint (or when the next DoMove-Command is issued to them). Concerning the speed of the landing-maneuver: Maybe a different approach could be to use scripted waypoints instead of the editor's default ones (usually working with scripts will result in more accurate control about the chopper's movement & behaviour). When issuing the Land command to a chopper without any H (no matter if invisible or not) within the chopper's visual range the chopper will look for a convenient spot. This may take some time but even using a H will not always significantly change the speed of that maneuver since the chopper still has to find a save "path" to that spot. My advice would be to set up a row of waypoints (or gamelogic-units that can also be used at waypoints utilizing the DoMove-command) at the insertion zone and bring the chopper in almost manually by issuing different flyinheight-values. On touchdown you could lock the current WP until insertions are complete or set up a timeout for the corresponding waypoint. This should be faster but includes the risk of crashing the chopper into the ground or obstacles in its' way... Maybe you could also use the SetWPPos command to make the chopper execute lots of flyinheight commands in a row ... it's kinda hard to explain ... maybe I'll try to make up a short, comprehensive example later.

In order to illustrate the described problems I've just put a little example together: Example SQM-File Done with 1.85 Required AddOns: MH6v2 (Capt.Moore), EditorAddOn102 I suggest you preview the mission in the editor first before you take a closer look at the waypoints and the trigger. I can't even guarantee that it will work fine on other machines than mine (the behaviour of especially helicopters in OFP is really tricky sometimes) but eventually you should see the MH6 drop off a soldier on a roof-top-like spot. That was the good news... The major problem is that most vehicles will never reach the exact location of a waypoint. So the most important waypoint in this case is not the one next to the trigger but the one next in line. If you change that waypoint you will most probably end up with the MH6 crashing into one of the buildings, going way too fast at the desired drop-off point or never reaching it at all. Furthermore these waypoints only work with the MH6 since it is the only one small enough and with its' eject-coordinates on the right hand. Any Blackhawk or Huey for example will either crash or drop the soldier to his death. You see it is possible but not in any way comfortable to handle since any changes in the mission might force you to redo the whole procedure and require a lot of testing runs (as most things in ofp do ). The buildings with that flat roof-top from Resistance would be more easy to handle or at least would require less modifications if you for example decide to change the type of chopper but if I got you right that's not what you were after

A basic problem with your idea is the fact that (as far as I have experienced it) choppers in ofp have a very "far" prediction while moving making them change waypoints before they actually reach them (in order to make a smooth transition when going high speed  i think). So you will need lots of waypoints in order to A) make the chopper go slow enough and B) be able to somehow guarantee the insertion point A) is not really a problem: You can use a set of waypoints close together all set to "limited" and additionally define short (1s will do) timeouts to slow down the chopper (or lock the WP via script until insertions are complete) B) imho _is_ a problem: Since you will have to make the units who should be inserted eject from the chopper, you will have to make sure, the eject position for the desired chopper is above the spot you want to make the insertion and not the chopper itself (usually that would be close enough together but depending on the building below it might be too far already ). Short Version: Use a set of waypoints to slow down the chopper or lock the insertion point (WP). Then make your infantry eject from the chopper. The problem is precission ... depending on the insertion zone. IMHO that script will need a lot of testing and finetuning waypoints and timings and might in the end still be sort of instable...

Actually I was looking forward to some kind of Object Reference too ... because how should I know about valid parameters to functions like action or playMove (besides of reading those unofficial but actually close to the official reference)... Though I'm pleased at last because the official reference did reveal at least two important things: Additional modes to the helicopter command Land (I was desperately trying to find a sane way to let helicopters hover in low altitude or wait on the ground with running engines to pick up troops) and the switchCamera "Gunner"- command in order to include e.g. a sniper-view in a cutscene... so thanks again ... but don't let us down now and please expand this reference

I haven't had the chance to take a closer look yet but thank you anyways BI! I've been praying for the release of the reference ... no more try-and-error-parameter-evaluation and "there must be some kind of function to handle this"-thoughts

... well, I think I could do so But please add detailed information about what you want the movement to be/look like so we don't have to start this over and over again. So send the mission and required information and I'll see what I can do for you ... and when BTW: I pray for an OFFICIAL command reference... (Edited by BOPMatt at 9:15 pm on Oct. 25, 2001)