Spitfire

I've just finished a VTOL (Vertical Take-Off & Landing) script using the new setVelocity-command. It works via action menu, and it's pretty crude (still beta) but it works. I have tested it with SU-25 and it may or may not need tweaking to use with other planes (the Harrier-addon, for example). It features action commands for turning the nozzles, increasing and decreasing the vertical thrust and activating retro-thrust (needed so you can slow down more effectively when approaching the landing zone). It's a bit tricky but you can get quite adept with it by practising a little. At least with my system, the plane tends to bank very slightly to the left when hovering in slow speeds, and I believe this cannot be fixed until BIS supplies us with means to set pitch & bank of objects. Don't let the speed of the aircraft get below 3-5 km/h when you are landing, since it'll tip over very easily. So, right now it's VSTOL rather than true VTOL but it's good enough for now. Please, test it as you wish, make modifications and give me some feedback. It's not perfect and I'd like to know how to make it better. Right now, this is best I can come up with at this point. You can download a zip-file with the scripts and a sample mission from http://www.angelfire.com/weird2/spitfire/ofp.html edit: I just uploaded a new version of the script. It fixes the stalling of the plane near zero speeds. It's still crude but now it works a little better

... but still some questions without answers! Knowsabout, engage at will, hold fire, open fire and their effect to AI behaviour are probably the most controversial issues when it comes to mission makers' experiences about them. I decided to take the bull by the horns and do some experiments, in order to finally understand the AI. I did some research around it since I'd like to know how the AI will respond to different situations in different combat modes so I don't always have to do complex time-consuming scripting in order to make AI behave the way I want. Especially when deciding when to fire and when to hold fire the AI seems to be very complex and seems to use higher mathematics than any of the above. There are a couple of things I've found out for sure. Behaviour (safe, aware, combat etc) and unit skill level are both affecting AI's ability to determine the knowsabout-level at different ranges. And of course another factor is the stance of the target (prone, crouch, stand). So far so good. Another fact is that knowsabout of 1.5 is a magical treshold value when any AI with "safe" behaviour WILL ALWAYS draw his weapon (ie, change the behaviour to combat) when confronting the enemy. What happens after that, I don't know for sure. If the AI is allowed to open fire, he will do it immediately after knowsabout reaches 1.5 and the weapon is drawn. Even if the weapon is drawn already the AI will hold fire until the knowsabout rises to 1.5. Only the combat mode of "Never Fire", of course, causes the AI to... eh... never fire. . However, if the AI is ordered to Hold Fire, neither the knowsabout level nor the distance seem to bear no importance whatsoever. I've stared at the wrong end of an AK-47 at 10 m distance with enemy knowing everything about me (knowsabout=4) but still not firing, only pointing the gun at me. However, during the next experiment the same enemy with the very same behaviour opened fire at me when the knowsabout level was only 2.5 and the distance being more than 50 m. I found out that a combination of "Hold Fire" and "Engage at Will" results in drawing the weapon at knowsabout 1.5 but not firing until I pose a threat too big for the AI, whenever that might be. When only "Hold Fire" without "Engage at Will" is issued, the weapon is not drawn until the AI is ready to pull the trigger, so it may still be holstered even at 10m with a knowsabout level of 4. So, the only mystery about AI behaviour hides in the "Hold Fire" -command. What are the factors that the AI uses to determine when to break the command and change their GREEN combat mode to YELLOW? I guess BIS's input is needed again After reading all that I'm written above I really feel like I'm splitting hairs here . Knowing these things about AI behaviour has really bugged me for quite some time now but I hope all this aimless sleuthing I've done is of help for someone.

Your problem seems to be the LOD setting. At your current setting the building never shows the most detailed LOD, not even at close distances. Try setting your object LOD slider all the way to the right in the preferences.

Have you tried "helicopter"?

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (bn880 @ Feb. 28 2003,16:58)</td></tr><tr><td id="QUOTE">Anyway don't worry if you don't get errors.<span id='postcolor'> Hmm... I wonder how that sentence looks like taken out of the context. Sounds a bit like a slogan for Microsoft products Anyway, I tried using deleteVehicle on waypoints, too, and it never crashed.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (whisperFFW06 @ Feb. 28 2003,14:10)</td></tr><tr><td id="QUOTE">In the last official comref, you have a list of unit types at the end. I've read that you can test to which "meta-class" a unit/vehicle is (ie, Apache does inherit from class "air", class air is meta class for all flying vehicles).<span id='postcolor'> The first level of these "meta-classes" seem to work well with nearestObject. Plane, car, tank, APC and man seem to work OK. As far as I know, air and land do not work.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Badgerboy @ Feb. 20 2003,17:48)</td></tr><tr><td id="QUOTE">or perfectly compress the core from all directions at the same time. (Also very unlikely)<span id='postcolor'> I read somewhere that if the uranium/plutonium core mass is big enough, all it takes is a large caliber rifle round to start the reaction. EDIT: hmm.. or then again it might have been a Tom Clancy or Clive Cussler novel and therefore not that reliable scientific source

Currently US is the last nation in the world to have any right telling other nations to scrap their nuclear/weapons of mass destruction -programs! Not soon from now Arab countries will not be the only nations to despise USA.

More than zombies , I'd like to see an "Escape from New York" type of mission, zombies replaced by muggers & other criminals. But nevertheless, civilian missions with weapons being very scarce but having an option to buy them is generally a good idea. Actually I've had this eternally unfinished project quite similar to bn880's Working Mission where some of these things are actually implemented. The setup is an anarchic Nogovo, very dark and hostile environment. Earn money by taxi driving (not as safe as in bn880's mission ), stealing & selling cars or signing assassination contracts. Buy vehicles and weapons. Avoid competing henchmen and try to survive. It's not that far from being finished, but it will take some time to polish it up.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Smokey @ Feb. 19 2003,03:50)</td></tr><tr><td id="QUOTE">Hmm, how do you do quotes in quotes? " "man" countType [_x] " foreach etc...<span id='postcolor'> I'd suggest using different types of quotes to avoid confusion: { "man" countType [_x] } foreach etc... That should work for sure. EDIT: In case you're interested I recently made a dynamic AI bus driver & passenger script which creates that nice and lively atmosphere. Here is a sample mission of 4 AI buses and 42 passengers. Feel free to use it.

Why bother with knives when you can have.... THIS! Drill addon by Kegetys Â

But I believe it works with APC, TANK, CAR and MOTORCYCLE. Covering every land vehicle as such. But then again, using T80 and T72 will ensure that they'll be East only

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (InqWiper @ Feb. 17 2003,19:01)</td></tr><tr><td id="QUOTE">this addeventhandler ["Fired",{obj=_this select 4;if (obj=="Flare") then {hint "Flare fired!"}}]<span id='postcolor'> I believe "Flare" works for white flares only. If green, red or yellow flares are fired, you'll need to modify the line a bit: this addeventhandler ["Fired",{obj=_this select 4;if (obj=="Flare" || obj=="FlareGreen" || obj=="FlareRed" || obj=="FlareYellow") then {hint "Flare fired!"}}]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (bn880 @ Feb. 17 2003,20:07)</td></tr><tr><td id="QUOTE">Here comes the part where SpitFire has to write the entire script... Â Â sorry, I'm just in a funny mood. Â <span id='postcolor'> Not funny! I would've, but as I said, I don't have OFP installed on this computer to test it...

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (ofpchaos @ Jan. 30 2003,17:46)</td></tr><tr><td id="QUOTE">Is it in any way possible to force AI tanks to go in reverse for a longer period of time – e.g. for a change of position?<span id='postcolor'> Maybe by really stretching the limits of OFP... I'd start by doing a looping script of series of getDir's, getPos'es and doMove's so that the tank is given orders to move, say, 3 metres behind the tank a couple of times per second. If I'm not mistaken, if the distance to travel is short enough the AI will use reverse instead of trying to turn the tank first. Of course, if it's done this way, controlling the actual direction of movement would require a bit more advanced scripting if you wish the tank to turn while travelling backwards. Heck, I don't even know if this suggestion would work anyway!

I can see two choices: 1) Use fired-eventhandler and check the type of ammo and if the person who fired it belongs to the group. Both the ammo type and the person are carried as a parameter for the script. 2) Use the built-in feature: onFlare.sqs -script which will be executed every time a flare is launched. A clip from the official comref: onFlare.sqs - launched when illuminating shell is lit(since 1.45) Â Â - arguments: [[r, g, b], gunner] - r, g, b is light color

I don't have OFP handy at the moment, but I think that you can work it out by using countType. "Tank" countType list triggerOne I believe that you can use something generic like "Land" or even "Vehicle" instead of "Tank", but you'll have to try it out yourself. If not, make several commands for "Tank", "Car", "APC" and so forth. If there are vehicles of many sides inside the trigger area and you want only eastern units to count, you'll have to do a double check by defining the triggerOne as EAST and PRESENT and then eliminate all non-vehicles by using countType.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (iNeo @ Feb. 17 2003,15:23)</td></tr><tr><td id="QUOTE">Yeah, but I didn't reckon it was worthy a place in General, and even doubted posting it in Offtopic because the review is so lame, lol.<span id='postcolor'> Yes, maybe you're right. If this was a true review instead of whining of a 13-year-old kid maybe it should be in General

Well, some people just can't recognize a good game if it bit them in their a**es. Nah, seriously there is no game that everyone likes. Playing OFP just requires certain kind of character to enjoy. btw. this is related to OFP and shouldn't be in off-topic...

Make a search for ProSphere at http://ofp.info

I totally agree. OFP has already plenty of every other type of add-ons except buildings. Now that missions are becoming more and more dynamic, having a lot of non-mission related civilian activity all around, there is suddenly a need for a good collection of static civilian buildings. Military buildings, as well. Mehanic has already provided us with every imaginable (an unimaginable) civilian car, but now we need another Mehanic to do garages for all those cars

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (killagee @ Feb. 16 2003,07:38)</td></tr><tr><td id="QUOTE">Everytime I start a new game the sound preferences are reset to default. I always have to turn the radio down before each game.Anyone know how to save these settings? Cheers <span id='postcolor'> The settings are normally saved on exit. There's something wrong with your system. Either your \users\yourname\UserInfo.cfg file is set to read only, or your copy of Flashpoint silently crashes to desktop when you're trying to quit so it doesn't have enough time to save the settings. EDIT: if nothing works, try manually editing the corresponding values in UserInfo.cfg. The contents of the file are quite self-explanatory.

Hehe, you must've read my mind (or the other way round ). I recently had an idea doing a script just like that. The camera part is easy. Just put </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">this addEventHandler ["fired", {_this exec "fired.sqs"}];<span id='postcolor'> to the init field of the player. Then make a script called fired.sqs: </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">_ammoname = _this select 4; _bullet = nearestObject [getpos player,_ammoname]; _bullet switchCamera "internal"; setAccTime 0.2 #flying ~0.1 ?(alive _bullet) : goto "flying"; setAccTime 1 ~0.5 player switchCamera "internal"; exit;<span id='postcolor'> That script works with any fired object: bullet, LAW missile, grenade, whatever. The tricky part is to make steering the missile possible. AFAIK, it can only be done with ProSphere controller or another script using similar technique. However, I've ran into troubles implementing ProSphere to the script since camera switching is conflicting with the camera tricks ProSphere is using. I'm sure it can be worked out, though.

But the F-16 has a bubble canopy with an excellent visibility and a pressure sensitive stick! I'd choose the Viper over any other American fighter. Back to topic. That Su-47 sure looks nice but there are something wrong with the proportions, for sure. And ZLOY, the size of the first image exceeds 100k, compress it or put it behind a link before a mod does it for you (for how long can we hide our off-topic conversation in these seemingly on-topic posts? )

Your suggestion works only with 1 group, but counting units inside an area trigger works with as many units/groups as you wish. btw. Instead of making the second trigger, you can type the condition field directly to the condition field of the waypoint you wish the reinforcement unit to wait. That way the waypoint will be activated only when the condition (east countSide enemyArray)/(totalEnemies) < 0.2 is met