thobson

An Abrams as well!! Â I take it the choppers are now gone. Extract from the readme file:

There are indeed a number of wierd bugs still lurking in the system

Very well done! Stealing an ammo truck is not easy. As for your questions - you really don't want me to answer them do you?

Thanks, yes I saw. Â I really meant the first review of this mission. Â I released it over 3 months ago.No not a never ending discussion. Â I really don't care about the score. Â They are all subjective and anyway it is only one person's opinion. Â I enjoyed making the mission, I enjoy playing it and I am very happy that others enjoy playing it as well. Â That is all that matters to me.

Thanks. Â I did originally use a script that re-set the terrain grid automatically every few minutes. Â The problem is that if the player has it set differently then every time they restarted a saved game the accumulation of errors in the vertical positioning of objects would get even worse. Â I have seen trucks completely underground and buildings flying several feet above the ground as a result of this problem. The only reliable way I have found to avoid this problem (and believe me I tried long and hard) is if the player sets Terrain detail to Normal out side of the mission. Â Thanks anyway. And thank you for your congratulations.

Please remember though to set terrain detail to normal. Â The mission takes so long to play that small errors in the OFP engine can cumulate and move objects vertically by several feet if your terrain detail is set to any other setting.If you play like me, you will do a lot of sniping, a lot of crawling, a lot of silenced assassination and a lot of running away! Â But other people play it very differently. Not just the start I hope That is meant to be part of the experience. Â There are several ways to collect weapons, dead bodies is one way, but you might find these guys are pretty short on ammo themselves EDIT: Sudden Death - My first review - Thank you! Â I did not do multiple languages because it is very difficult to do the translations well - and there is just so much dialogue I could not face the task.

I use a combined head set and microphone from Game. Â Cost about Å30. Â That is the one with the larger ear pieces. Â I later spent 4 x that much on a Sennheiser combo but was very dissapointed with the sound from the mike. Indeed it is a shame ofpec is down. In the meantime you might also want to look at: http://andrew.nf/OFP/Sounds/index.htm

Getting them to eject is not sufficient. You also need to unassign them from the vehicle: _unit action ["eject",vehicle _unit] unAssignVehicle _unit

I copied and pasted the script from the post above and ran it from the activation field of a waypoint - and it worked perfectly. I would check UNN's suggestion. Do you have any characters after the exit?

I have had another look through the script and can't see a problem I will try and ruin it when I get home tonight

The ofpec site is currently down that is why the links are not working. To find the ID of an object, say a bush. Go into the Mission Editor. Over on the right hand side is a button called: Show IDs (or something like that). Press the button then zoom into the map and you will see a lot of numbers. These numbers are the object IDs. Find a bush or building that is to be the centre of the bombing area note down its number. You can then refer to that object using: object XXXX where XXXX is the number you found

There might be an error in the file. I suggest you start with a Briefing that works and then change it is small stages until you get what you want. You can get a working briefing by de-pboing an existing mission.

Create a civilian present trigger the covers the map. In the acitviation field put: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{{_x AddEventHandler [{killed}, {if ((side (_this select 1)) == resistance) then {Resistance_Killed_civ = true}}]} forEach (crew _x)} forEach thislist Create a second trigger that has the following condition field: Resistance_Killed_civ Don't forget to set Resistance_Killed_civ = false at the start of the mission, preferably in init.sqs  The reason for this is if later when you are making changes if you want something to happen if Resistance has not yet killed a civilian then you will want to use the condition: not Resistance_Killed_civ This will only be true if you have initialised Resistance_Killed_civ to false There might be more elegant ways but the above should work. Note:  The trigger will fire the first time a resistance unit kills a civilan.  If you want this to repeat then one quick way would be to set the trigger to be repeating and have another trigger with condition field: Resistance_Killed_civ a time delay of say 0.5 seconds and an activation field of: Resistance_Killed_civ = false The main trigger will then fire everytime a civilian is killed by a resistance unit - providing they are killed more than 0.5 seconds apart. EDIT: The above is all for SP. I leave it as an exercise to the reader to make the necessary changes for MP

A simple way is put them in the same group and put them into column formation. Anotehr way is to write a script that periodicaoly checks the location of the front vehicle and gives a doMove instruction to the other vehicle. It depends on what you want to do as to the best way to do it.

Well the script could be improved but it is not clear to me what is causing your error. When you say you call it with: [name, 15, .5, 15] exec "bombing.sqs" Is that exactly what you have in your mission? Â If so then I think the problem is in using name. name is an OFP command. Â Look here: http://www.ofpec.com/editors/comref.php?letter=N#name Give the object a different name - or select a bush, get its ID and call with: Â [object xxxx, 15, .5, 15] exec "bombing.sqs" where xxxx is the id of the bush You should note also that the code refers to a _marker. Â But you must not pass a marker name into the script because the script uses the getPos command and not the getMarkerPos command Note also that although the script refers to the radius of where the bombs will fall: 1. the script will not drop in a circle but in a square 2. the value set for radius is actually the length of the side of the square. Â So for example if radius is set to 15 (in your case) then the bombs will fall in a 15x15 square centred on the object you provide. Â From the name radius you might have expected the bombs to fall 15 meters either side of the object, in other words in a 30x30 square Have a look here for ways of selecting random locations of the map for things such as this: http://www.ofpec.com/editors/faq_view.php?id=409

On the setPos thing, bear in mind a few wrinkles: 1. objectname setPos getPos objectname Will cause many objects to move quite some distance laterally. Â Try it with a wire, it moves about half its own length sideways. Â This is a pain if you want to place one ammo crate on top of another you need to do something like: _xpos = getPos ammo1 select 0 _ypos = getPos ammo1 select 1 ammo1 setPos [_xpos,ypos,0] ammo2 setPos [_xpos,_ypos,z] Surprising though it may seem this does result in ammo1 moving sideways. 2. objectname setPos [x,y,z] will for most objects place them z meters above ground. Â But if the object is a trigger it will place it z meters above sealevel 3. x is the number of meters from the left hand side of the map and y is the number of meters from the bottom of the map. On the copper problem: Â Controlling choppers is like trying to train a cat. Â Not impossible, but it is easy to find better ways of spending your life.

In that case Sanctuary's solution should do it

If you want it to stay put in the air you could try: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#loop ~0.1 a10 setPos [getPos a10 select 0, a10 getPos select 1,200] if not okaytogo then {goto"loop"} where a10 is the name you gave to the plane and okaytogo is a global variable that you intialise as false but set to true when you want the plane to move. You might need to chose fixed X & Y coordinates to keep the plane stationary. I have not tested this with a plane but it works fine for a chopper.

What is lots of infantry? Â I built quite a large mission that has approx 300 west and 300 east soldiers, plus about 40 resistance and a similar number of civilians There are many many things I needed to take care of. Minimise the number of variable names otherwise you will suffer from the large save game bug. Have Terrain Detail set to normal otherwise objects you place on the map may move vertically over time (I am assuming it is a long mission as well as a big one). Â When I say move vertically I am talking about a lot. Â Enough for buildings to fly and trucks to become submerged Do not rely on buildingPos returning the same value after a save and restore as it did before saving Do not rely on the player getting the action to climb a ladder after a save and restore. Do not remove all the mags from a tank - unless you are happy for the player to be unable to rearm the thing in the mission The list is virtually endless. Â My advice is try things and when they don't work try a different way. In case you are interested in having a look here is a link: http://www.flashpoint1985.com/cgi-bin....t=48991

It is not possible to do this. Â What you could do is have the unit located on some offshore island and move it to where you want it to be when the trigger fires. Â An alternative is to create the unit where and when you need it. Â As Abs points out OFPEC is a good place to get a lot of help on all this.Check out setPos: http://www.ofpec.com/editors/comref.php?letter=S#setPos and createUnit: http://www.ofpec.com/editors/comref.php?letter=C#createUnit

I have used this to make people un killable <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{_x addEventHandler [{Hit}, {_this select 0 setDammage 0}]} forEach [array of units] {_x addEventHandler [{Dammaged}, {_this select 0 setDammage 0}]} forEach [array of units]

I have never tested that. Â I have in the past tried to delete units that were in vehicles (while alive) and some very strange things happened. Â Hence the need to move them out and unassign them and then delete them. Â My preference without testing it would be give the ofp engine all the help you can to get it right so I would still do the setpos.

If waypoints are too close together strange things can happen. I suggest: 1. Move the infantry getin wp tso it is not on top of the jeep 2. Move the next wp further away than it currently is 10m feels too close

Excellent

Quite right - I should read more slowly. I only hope I am better at my job than I am at some of this Why not then just kill the lot of them with a: {_x setDammage 1} forEach crew aircraftname Then if the player happens on the wreck there will be bodies realistically inside it.