UNN

You can't if your creating it yourself. You could always try and add the grenade launcher as another fixed, AI, manned turret. Although you will then have to try and hide the extra crew member yourself.

Lol Yeah, I spotted your posts in the new Antonov / Arma thread. Funny how things come around. I'm back doing a similar thing, only this time it's not with any specific addon. Anyway, hope thats help sort your problem.

Cheers BTW For anyone who does not want the init scripts running when a JIP joins, just add this at the top of init.sqf: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">If (!IsServer and (IsNull Player)) ExitWith {} At least this way we have the choice of executing init.sqf with a JIP. If your using CreateVehicle, then the object will always be local to the server until a player, or a member of the players group gets in as driver. Or in case of a infantry guy, it joins a players group or vehicle. As for which client called the CreateVehicle command, that would depend on how it was called. A trigger would be called by everyone, a user action or dialog would be called local by a specific client. If your thinking of cheat prevention, then no you can't tell who the cheat is. All you could do is identify an object that should not be in a mission and delete it.

If you called your captives CAP01,CAP02 e.t.c In the mission editor. Then your trigger would just need: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">pScript=[CAP01,CAP02,CAP03] ExecVM "SetUnitFree.sqs" SetUnitFree.sqs: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_Captives=_This; { If (Local _x) Then    {    _x EnableAI "Anim";    _x SetUnitPos "Up";    }; } ForEach _Captives;

Yeah, a trigger is fine as it calls the script on all clients and server. But as long as you make sure it's being called on the computer thats local to the unit, then you should be ok to. If the captives are AI, then you could run the script from the server only. One thing to watch out for though, is running the script from an objects init field in the mission editor. For example if you add this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">pScript=[This] ExecVM "SetUnitCaptive.sqs" Then you would need a small delay in your script. SetUnitCaptive.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; Sleep 1; If (Local _Unit) Then    {    _Unit SetUnitPos "Down";    Sleep 3;    _Unit DisableAI "Anim";    };

This works, it locks the animation in place: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">If (Local CIV01) Then     {     CIV01 SetUnitPos "Down";     Sleep 3;     CIV01 DisableAI "Anim";     }; To release the unit, call this. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">If (Local CIV01) Then     {     CIV01 EnableAI "Anim";     CIV01 SetUnitPos "Up";     };

I would certainly like to hear if the same thing happens on a proper remote server. For myself I tested all 23 variations on the init events and scripts for JIP. For all 23 of them, Player was returned as null. I'm not sure I understand what you mean. If the Player was known then the hint should not return a null object? But it does return null, at least in my tests. But if you notice, a processed init command gets executed quite early on in the JIP init sequence. At that early stage, Player appears to be unkown.

Well I just ran a check for the Player in my MP test mission. On a client starting a mission: Inits 0,1,3,18,19,21 returned the player as null. On a client starting as a JIP they all returned the Player as Null. You can do a simple test to confirm if this is the case. Run the following from a client that starts a mission. I used a Radio trigger and and a game logic with this line: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">GameLogic01 SetVehicleInit "Hint Format [""Player=%1"",Player]"; ProcessInitCommands If you quit out and JIP back into the mission. The Hint reports the Player as Null. Now I'm not running this on a proper (remote) dedicated server. Just Arma_server.exe being run on my client.

Yeah, that’s pretty much the way I've seen it work to. Until a player actually joins a game, they are considered to be part of and local to the Server. While it sorts out all the Groups and Sides e.t.c So far, launching the init events and scripts is essential for a JIP client. Again as far as my own experience goes, if I design my mission correctly I don't have to make any special consideration for JIP. JIP does have it's limits and restrictions, but once you understand them, they can be avoided. Not sure if anyone else is interested, but since JIP was introduced. The whole Mp initialise sequence appeared to get much more complicated. So I started making an attempt to map it across the Client, Server and JIP client. I came up with this: It's not as bad as it looks. The numbers across Vertical column represent the various different init events launched during startup: 0 - 5: Functions and scripts launched from an addons config Init event 6 - 11: Functions and scripts launched from Init.sqf 12 - 17: Functions and scripts launched from Init.sqs 18 - 23: Functions and scripts launched from the init field of an object placed in the mission editor. In each of the four stages I tested the same test script. The script performs six different tests, from launching a function through to launching a script that lanches another script via ProcessInitCommands. So for a config init event the numbers are: 0 : Call a function 1 : ExecVM a script 2 : Call a function to ProcessInit a function 3 : Call a script to ProcessInit a function 4 : Call a function to ProcessInit a script 5 : Call a script to ProcessInit a script The same six test are repeated for each of the four init stages. The horizontal axis is the sequence of events in chronological order. Not done as much testing as I would like, still need to map out the commands that work or don't work for each stage.

Yeah that was Aces, although you don't need to go to quite as far. Assigning the correct proxy is easy enough. Assuming you have a custom made model with enough proxies. But you don't appear to be able to add and remove weapons to and from, the additional turrets using scripts? Without that ability, you will have to hard code a weapon into the config.

Didn't BAS use Hidden selections with a pre-defined weapon in the p3d? Actually thinking about it, there is a new way. Given we have a few more new commands but it still won't account for proper animations. Edit: Well it depends on being able to add weapons to a specific turret, via scripts?

I doubt the script is flawed. Probably just my observation at that point in time. Hence the use of a ?

Sorry I missed that bit. But looks like the delay of 0.1 seconds in the loop, is enough to let the object drop. You should realy write your condition like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">while {!(IsNull emp_tar)} do { hint format[ "%1",emp_tar ]; sleep 0.001; _int_i = _int_i + 1 }; BTW I thought the While loop was no longer restricted to 10,000 cycles? Recently, I tried it as part of an init.sqf script, it still had the same limit.

Gnat is using part of a script I posted in a sample mission here http://www.flashpoint1985.com/cgi-bin....t=61522 Neither of us have ever said it was complicated or 100% new. Sometimes you have to be carefull not to react, to the reactions on the forum. Read what Gnat originaly said. Not everyone is familiar with scripting, so they may very well be gratefull, regardless of complexity. If someone writes somthing, that will be usefull to them? With the chopper transport, he is putting four new commands to good use, to solve a specific problem.

It should be: At least thats what it is in my wheeled3.pbo. It points to a picture used for the User Interface and is normaly defined in the config. Don't know where you got the "m1030\m1030" from?

Well not sure what scripts you are using, but this script works fine: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_Object=_This Select 0; _Pos=GetPos _Object; _Pos Set [2,5]; _T="LaserTargetW" CreateVehicle [0,0,0]; WaitUntil     {     Player SideChat Format ["Obj %1 %2",_T,Time];     _T SetPos _Pos;     False     }; This way you can keep the Laser Target going indefinetly.

You could always setpos it above ground in a loop. Looks like Laser Targets are subject to gravity.... Damn you Newton!

Take a look in the pbo's. You will find the scripts there. Apparently, early photos of the first Moon landing. Clearly show "Made by Atari" on the Moon rocks! Go figure...

Edit: Never mind...

Yeah, but that will probably have to be implemented as config based scripts. In OFP most addon makers were happy to script their own landing gears. But scripting dampers based on things like proximity to roadway LOD's e.t.c is no mean feat. I would be happy to disable dampers if it means they can operate from Aircraft Carriers. Are you taking into account, the height of the waves when positioning the object? I think setpos is still affected by tides e.t.c

There is the createTrigger command. Not used it yet, but I don't think there are any problems with it. Should make life a little easier in MP if you use a trigger.

Can't you just create a trigger using the Carriers config init event. Then just add and remove the action whenever a player enters or leaves the triggers radius? No intervention required by the Mission Editor then.

The way user actions interact with the interface has been modified in Arma. You have to be looking directly at the object for them to show up. Easy enough when your holding a rifle, just move the crosshair over the object. It helps reduce the amount of actions displayed when you have multiple actions. But as you pointed out, not so easy in an aircraft. It's a shame it's not an option. As there are a few other tricks that won't work now The only way round it AFAIK, is to attach the Action to the vehicle. Why not use a trigger and the AddAction command?

No Ammo boxes can't be loaded into vehicles as default. They are just a fixed proxy with a hidden selection, it's all config and p3d based. Also don't use cargo proxies as external objects if you can avoid it, they have to many issues. Especially with missiles. I would suggest you use standard proxies. But the Geometry LOD will not work that way, at least it didn't in OFP. Apparently the 50m size restriction is even more important now there is map streaming. So I doubt it will be lifted any time soon.

@plaintiff1 That’s pretty much where I stand on the subject to. I was just exploring the possibility that other things may be affecting the results Tj_au has observed. @Spokesperson In OFP I had Gravity equal to 9 to get the best results for my Mortar addon. But considering OFP\Arma's ballistics are a Black Box, and my scripts used a degree of fudging, I did not put to much emphasis on it. In the Olden Days, setting gravity to a small integer helped reduce the processing overheads. There is an entry in the config, sideAirFriction = 1; under class CfgAmmo. I've previously tried setting that to 0, to see if it had any effect. When I last tested it, it didn't. It may also be worth trying particles and class thing objects to. Particles offer a few more parameters to adjust. But seen as air resistance has such a massive effect on projectiles in Arma compared to gravity, that can been seen when the data is plotted. I think it's safe to say some sort of air resistance is modelled.