UNN

That’s just standard parabola maths, you can get it easy enough of the net. It does not work with Arma, Arma takes into account drag, when plotting projectiles. The statement in the document about Arma's physics being wrong is a bit spurious. If you want to find out if Arma's physics are accurate, you need to use something more complex than that example. Alex should take the time to read through the forums. It’s been discussed numerous times.

Not really seen much in the way of scripting tutorials, along those lines. But I rekon it's a hard topic to tackle, as there are so many ways of doing the same thing and they all have thier own merrits. No worries

Definetly a bit of creating licensing going on there. The director should know his stuff, seen as his farther owned an aircraft factory, making parts for the Zero during WWII. So he is no stranger to high performance combat aircraft. The film is set in and around Italy. According to the wiki, Italy held the Air Speed record at the time, for sea planes. So you can kind of see where he got the design from.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">while{someThing} do{  _scriptHandler = [_dynamicVariable1, _someOtherThing] spawn compile preProcessFile "myScript.sqf"; }; Scripts staying in memory won't cause them to fail. The way your calling the above code, is not the best use of the spawn command. It should look more like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">MyScript=compile preProcessFile "myScript.sqf"; while {someThing} do     {     _scriptHandler = [_dynamicVariable1, _someOtherThing] spawn MyScript;     }; MyScript=nil; When you want to unload the script, set MyScript equal to nil. Thats what the Call command is for. Although you have to be carefull if you executing large scripts or ones that demand lots of CPU time.

After Suma posted the update this morning, I had to go back and try my test again. Second time around I did not get any change for either setting. Guess I should have done some more testing, as I could not recreate the results I had, first time around. The same settings are in the configs and you can find the parameters in the Arma exe. But from a scripting point of view, it does look as though it's disabled for now.

Cheers, but could you post a link to your forum?

Lol..that was quick. Funny thing though. The one consistent result I got when setting an enemy AI to 1 for all settings was. If you started firing in his general direction, he would turn around and start to crawl away. Set them to 0 and he would stay put. But I must admit, there was not much difference in his accuracy when returning fire, with either setting. Since Arma, you tend to see a few more posts from the BIS team in general.

With your system, how practicle would it be to store details on every active unit in a long running mission? Also what would be the basic hardware and software configuration. Could it be done with a single, standard server, outputting to a text file. Or do you need multiple servers and a database engine?

The commands setSkill and skill are both present from OFP V1.75. The setSkill array command was introduced in Arma V1.0 and appears to have nothing to do with the previous commands. Or at least it overrides setSkill and does not effect the value returned by skill. As far as I can tell setSkill array does appear to have some effect. But it's the other way round from what the wiki says. Setting everything to 0 appears to makes a more accurate and courageous soldier. But that was just a quick test.

Even before we got proper multiple airbases, I did a quick experiment to see how much fuel you would use flying from one small island airbase to the other and back again. It used about 1%. Kind of removes any sense of urgency. Unless you reduced the fuel capacity to 60 seconds of flying time

To be honest I don't know when it comes to playing sounds. I never did any MP stuff when I did my scripts back then. But if your assigning the events via a trigger then you can at least be sure the will play on all the clients, unless you tell it otherwise.

I'd be happy to include a guid in the stuff we plan to release. But that won't guarantee everyone (server, clients and addon makers) will use the method. So I would still want to make it as easy as possible for someone to identify which addons were mismatched, and locate the version used in the mission they were trying to connect to. It's safe to say the one thing everyone will use is their eyes. If a mission says you need xxx_yyyyyyV1_2. Then it's easy enough for someone to locate that version using a search engine, if the filenames match the message. OFPWatch let you select the server you wanted to play on and it downloads the addons used on that server. Regardless of the current version and without requiring any cooperation from the addon maker. But it still wasn't embraced by every server admin or player. Anything that helps coordinate addons and missions has to be a good thing, but without direct intervention from BIS. There will always be someone who slips through the net.

Something like this in the triggers activation: <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] ExecVM "MyHitScript.sqs"}]; _x AddEventHandler ["killed",{[_This Select 0] ExecVM "MyKilledScript.sqs"}]} ForEach (List MyTrigger) MyHitScript.sqs: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_Unit=_This Select 0; _ListOfSounds=["Sound01","Sound02","Sound03","Sound04","Sound05"]; _Sound=_ListOfSounds Select (floor (random (Count _ListOfSounds))); _Unit Say _Sound; Now things get a little more complicated, there are quite a few ways of detecting enemy units. You don't want the AI shouting like the little guy from Fantasy Island every 5 seconds. So you will have to make sure they only report new targets at reasonable intervals. Perhaps someone can point you to a similar script you can learn from. I did exactly what you want in OFP, but it's not the best example to learn from as it's a bit complicated. I tried to build a sentance based on the type of units, thier positions and heading relative to the reporting unit e.t.c In the mean time you could experiment with looping scripts and commands like: findNearestEnemy assignedTarget Also, while your adding your event handlers you could build some arrays of all the soldiers and vehicles present in the mission, on both sides. Then loop through the arrays checking knowsAbout Or try attaching enemy detected triggers to group leaders, and see what sort of results you get. Sorry I can't help more, like I said it's complicated and depends on what level of detail you want. But if you stick at it, and try experimenting with some simple scripts to get a feel for the commands. I'm sure you will find the experience rewarding, I know I did.

Well thats not exactly true is it. Lets face it, all he had to do was post one line: "Can I purchase the game over the counter in the NY area?" Two out of the four replies could be considered derogatry. Hardly think that counts as everyone? Although arguable, I would not consider either of them as being an over reaction, considering the tone of his original post. If you adopt an aggresive stance, expect an aggresive reply.

It's actualy quite small when your flying over it in a jet But thanks to the work Nutty is doing, it should be possible to extend the length of mission indefinetly, without running the server into the ground and loosing all your data. With a mamoth, none stop, gaming session

Well comming from the point of veiw of someone who only plays MP missions, the most important thing for me is. Will I be able to connect to the server and play the mission, if I download half a gig's worth of addons. I just want to play games online, I really don't care if it's the very latest version that comes with tartan seat covers or whatever. As long as I can connect to the server. Yeah, most of the time it's easy enough. Especially when missions are hosted alongside the required addons. But not everyone has the resources to do that. True, there some people who will throw a mission away simple because they have to download an addon. That leads to the numerous "Some many addons and not enough mission" threads we see on the forums. Whether that’s most people or not, I'm not qualified to say. There are already programs out there for OFP that tell you what addons are missing e.t.c Yet the same old discussions like this keep crawling into the forums. So they don't appear to offer the best solution? The worse case I can think of was a popular and large (700+ mb) Mod used in CTI's. I ended up having three different Mod folders each containing slightly different versions, but even then I still found other servers hosting different versions to the three I had on my HD. Simple because of the missions hosted on the server and the lack of proper version info. Lol…Oh well, that was a short lived initative. You never know, you might get lucky; perhaps someone else will come along and do all the work for you. If not, it certainly helped kill half an hour and padded the forums out bit

In some cases this is desirable, if the addon modifies or removes some functionality used in the mission. The CfgPatches class name is the name checked by the mission and reported to the user when missing, not the filename. If you made the addons filename and the CfgPatches name, the same. So they both include a version numbers. Then all someone has to do if told that MyAddonV1_2 is missing, is go search on the net for MyAddonV1_2.pbo. Unless the issue here is keeping all missions updated with the latest versions of an addon, rather than ensuring all players are using the same (mission compatible) version of an addon? If that’s the case you will need to inform the mission maker of what changes you have made so they can decide if they need to re-compile that mission. From experience the only problems I had when trying to locate an addon used by a specific mission. Was if the mission was an old mission and the older version of the addon was no longer available from the makers site, you could spend ages trying to track it down. Especially if they used a generic name in the cfgPatches section of a config. All you really need to solve the problem is proper naming conventions for the filename and cfgPatches name, along with someone who is willing to host links or copies of all versions of any addon, and ensure it comes up first in any Internet search engine.

How are you calling the script?

Since version 1.08 of Arma, you can now use this function to return all the Gunners in a vehicle: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[_Vehicle] Call {Private=["_Gunners"]; _Gunners=[]; {If (Count (AssignedVehicleRole _x)>1) Then {_Gunners=_Gunners+[_x]}} ForEach (Crew (_This Select 0)); _Gunners}

This script will give you a basic idea: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_Gun=_This Select 0; _Gun DoWatch (_Gun ModelToWorld [0,50,50]); WaitUntil     {     Sleep 10;     _Gun Fire ((Weapons _Gun) Select 0);     !((Alive _Gun) Or (SomeAmmo _Gun))     }; Adjust the sleep command according to the reload rate and the rate of fire you want.

I posted a comment in a single-issue rant thread. Never got round to creating a split screen video showing OFP compared to Arma. In a nutshell OFP = very smooth, ARMA = induced epileptic fit. I can only blame the decision on TrackIR? As no rational person would deem the latter to be better, without some external influence. If it wasn't for the fact that OFP did a better job, I would have probably put it down to an idiosyncrasy of the engine. As it stands now, you just have to alternate between keyboard and mouse while gritting your teeth

Yeah, to a certain degree. Here is a filtered list of just the populated areas. Unpbo sara.pbo to see what other types there are. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_Towns=[]; _TownTypes=["NameCityCapital","NameCity","NameVillage"]; _CfgTowns=(configFile >> "CfgWorlds" >> WorldName >> "Names"); For "_i" from 0 to ((Count _CfgTowns)-1) Do     {     _CfgPath=_CfgTowns Select _i;         If ((GetText (_CfgPath >> "type")) in _TownTypes) then         {         _Towns=_Towns+[[GetText (_CfgPath >> "name"),GetArray (_CfgPath >> "position")]];         };     }; Hint Format ["Towns %1",_Towns]; @The_Tarus Sorry I missed your previous post. The first bit: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_cfgPath = _cfgTowns Select _i; Just returns a pointer to the class name. After that you need to pull out the different properties associated with that class, like name and type e.t.c using: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">GetText (_CfgPath >> "type") There are types for "Hill" and "VegetationVineyard". The entries with empty names use type "ViewPoint". To add those to your array, just change the script to read: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_TownTypes=["NameCityCapital","NameCity","NameVillage","Hill"]; And: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_Towns=_Towns+[[GetText (_CfgPath >> "name"),GetArray (_CfgPath >> "position"),GetText (_CfgPath >> "type")]]; Once you have unpbo'ed the addon use unRap.exe to convert the config to a text file.

A moveable version would be nice, but given the limitation of the engine to only deal with objects up to and under 50m's, I'm not so sure? But I've not exhausted all the options just yet.

Yeah, it is a neat solution. Thanks to someone on the staff at BIS no doubt. Yes, they are direct, child, class names to cfgWorlds. You could do the same with class SecondryAirports or class clutter e.t.c I particularly like the ability to store the config paths as a variable. I ripped that out of missions.pbo. Which is straight from the horse’s mouth...so to speak Would be nice to see more examples of that ilk.

Yes, use the config commands. This will give you an array of all towns and their positions on the current map: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_Towns=[]; _CfgTowns=(configFile >> "CfgWorlds" >> WorldName >> "Names"); For "_i" from 0 to ((Count _CfgTowns)-1) Do     {     _CfgPath=_CfgTowns Select _i;     _Towns Set [_i,[GetText (_CfgPath >> "name"),GetArray (_CfgPath >> "position")]];     }; Hint Format ["Towns %1",_Towns]; From that you can either setup triggers using the CreateTrigger command or write a script to do a distance check.