UNN

Cheers, I don't have access to my ARMA PC atm, so I can't post the test mission. But basicly, I put a manned (AI) URAL on the main airport and named it U01. Then placed eight Game Logics on the map, with this line in thier init fields: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">This MoveInCargo U01 The changes to the pbo were simple, I just added the following lines to the scripts called by the Init and SLX_Init_Other_All events. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Localize Format ["Init %1",Time]; <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Localize Format ["SLX_Init_Other_All %1",Time]; That should now write to Arma.rpt every time they are launched. Sorry I cant send you both the test mission and addon atm, if you don't mind waiting a few days? I will send them as soon as I get the chance.

Hi, I think I've hit an obscure problem with the Extended eventhandlers? From what I've seen so far, it's this line in init.sqf: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">// If it's a vehicle then start event handlers for the crew. if(!(_unit isKindOf "Man"))then I say I think it's that line, not had chance to narrow it down further. But it's possible to have objects as vehicle crew, that are not IskindOf "Man". Game Logics or any class (below Man) that can support simulation="Soldier". If I move 8 game logics into the back of a 5 ton truck, I get a drop of 20fps until they are moved out again. Remove the extended addon pbo, it then works ok. I added some debug info into the Init and SLX_Init_Other_All events, for the handlers config. It looks like both those events are called every 0.2 seconds, repeatedly, for every game logic that remains in a vehicles crew. Can someone confirm this? Cheers

Instead of a dialog, try calling something like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Localize Format ["Pos: %1 Vec: %2",getPos Player,VectorUp Player] That will write the values to Arma.rpt. From there you can cut and paste.

I don't have any choice. BinPBO crashes, as soon as I run it with binarize checked

It's difficult to comment, because I run both the server and client on one PC. So I can't run any tests with more than one client connected at any one time. Consequently, I can only guess at some of the possible problems. Also, I don't really understand what your doing in your mission. This array: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_array = [c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11,c12,c13,c14,c15,c16,c17,c18,c19,c20,c21,c22]; Does it just contain all playable units of side civilian? If it does, do you have a similar array for all units of side West, set to playable? I would have thought that running a respawn script from the killed event would work ok for the West player. But if any of the Civis respawn while you are playing a West unit. Then you would have to reassign the Arrest and Fine e.t.c actions to the new civ object, for the West players. Is that correct? I thought that any unit that JIP's, can be assumed to have no user actions assigned on it's client? Which units get duplicate user actions after JIP, in your mission?

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">The problem with actions.sqf above is that it doesn't detect if the unit already has the actions, so you'll end up with units who have duplicate actions, right? Is there any way to stop this, so that units that respawn get the actions again, but those who already have them don't? Just a thought, you have an array of all the playable objects? <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_array = [c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11,c12,c13,c14,c15,c16,c17,c18,c19,c20,c21,c22]; When a player first JIPs, the Player command returns Null. Can you check your array (C1 through to C22). To see if any are either Nil or ObjNull during JIP startup e.t.c If it is, then it might mean the players object has not been used before. If not, you could create a public array of all the players who start the mission, then check the JIP player to see if it's already in the array. If it isn't then you add the actions.

I don't think you can inherit skeleton classes the same way you can with vehicles e.t.c I've not looked into the method Synide posted, but it looks like a good way to work if you have lots of different pbo's sharing the same model.cfg. But again I don't think it works like the inheritance we know with cfgVehicles? @Synide, is that correct? Or will Binarize look to inherit any of the classes it finds in the cfg's, through steps 1 to 5? I just use #include files for all the common bone properties e.t.c.

I assumed it applied to dialogs and displays, because it appears to have nothing to do with what the Wiki says. Fortunately I also had the moving parameter setup in the dialogs I wanted to move, so I didn't give it a second thought.

I did some SAR scripts for OFP, with CSJ on his Hueys. Arma's new anim system means we don't have to worry so much about autohover e.t.c now. While we don't have the rope function of VBS, we can at least do a bit more than we could in OFP.

That would be: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">enableSimulation = 1; It works for any standard dialog that I’ve used. The Moving property Raedor mentioned looks like it’s the one. I just did a quick test. I had both MovingEnable set to true for my entire dialog and Moving set to true for my main background control. MovingEnable could be removed, set to true, or false, without affecting the dialogs movement.

Don't you just need to set <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">movingEnable=1; in your dialog class?

The short answer is, it will At least, after the Cargo system is released. Stuff like that, is it's real intention.

I just noticed this property in class Randomshape: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">models[] = {}; Dunno if it's another proxy or a p3d, that goes in the list. Or even if it works. But either way, let us know how you get on.

Yeah that looks ok, assuming your selections in O2 are named proxy.UKFFuel and so on. I haven't exhausted all the possible settings for proxies, so it might be worth experimenting with the different simulations to. In OFP, some buildings had entries in their configs with a list of alternate proxies to use. Mainly for random furniture, again not sure if they were actually used in the game, but they were there. I don't have the OFP configs now, so I can't check. But I can't find any references in Arma, so it may have been removed?

I don't think you have to inherit from any proxy, as long as the required properties are there. But class ProxyAmmoInTruck might be the best one to inherit from. Although simulation = "alwaysshow" is the important property. It might be worth looking into class RandomShape? Only I'm not sure if it just applies to buildings or even works in Arma. But it would be a nice way of randomising the vehicles, if it did.

You can get the dimensions using this method: Dialogs & wide screen monitors

Yeah, for things like damage and turrets. It was user defined anim sources I was thinking of there, although I guess there is no need for you to use them in this case. You should be able to trigger the hide animation with the damage animsource, without any scripting? But that’s assuming your not doing something extra in your script.

Ahh..so you had the solution to your problem at hand, all this time. Isn't that just the way with Arma There are so many possibilities. BTW, for future reference. Do Anims get transmitted to JIP clients?

Yep, the killed event is fired locally to the object. You can use the SetVehicleInit command. To execute it on all clients. You will need to modify killed.sqf, depending on how you want it to work for JIP. Looking at your code, you delete the turret at the end of the script. I take it you just want the texture hidden for anyone who joins a game in progress?

I know what you mean. I think it's changed a lot since OFP. Not had much experience with particles in Arma myself, so I was still thinking along the lines of the previous OFP examples, when I tried it. What happens if you DeleteVehicle the particle source? I can see where you were comming from. It's better to concentrate the end conditions for multiple scripts, into one line of code with the terminate command. But I guess it's just not practicle with particles.

Since we can now have addon based dialogs as well as mission based ones. There's a danger of IDD conflicts across different addons and missions? I figure something along the lines of, or derived from OFPEC tags. Would be the ideal solution? The quickest way I can think of, to tie into OFPEC. Would be to convert the tags into a numeric value, and use that value as a base for your dialog idd's. So in the case of RKSL, using the Arma ToArray command: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">hint format["%1",toArray("RKSL")] You would get: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[82,75,83,76] Which could be converted into 82758376000. Ok, seems a bit drastic, but it does work. Now we can reserve idd's from 82758376000 to 82758376999 for RKSL dialogs. I think a thousand dialogs are enough for anyone? Alternatively we could base it on our position in the OFPEC tag list. So if for example RKSL was the 59th tag listed. We would reserve idd's from 59000 to 59999. It doesn't really matter how you derive the idd's, as long as the chances of other people using the same one, is decreased.

Assuming they are not reindexed or reused. Then it will certainly do for now, if you add a couple of zeros to the number. I doubt we will ever see more than 99999 tags? The RKSL idd would then work out to be 99900 to 99999. i0n0s would be 156600 to 156699.

I just knocked up a simple test with two scripts running. They both terminated without any problems. <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; _Script1=_Unit ExecVM "Script1.sqs"; _Script2=_Unit ExecVM "Script2.sqs"; WaitUntil {!(Alive _Unit)}; Hint "Here"; Terminate _Script1; Terminate _Script2; Script1.sqs: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">WaitUntil { Player SideCHat Format ["Time %1 %2",_This,Time]; Sleep 1; False }; Script2.sqs: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">While {True} Do { Player SideCHat Format ["Time 2 %1 %2",_This,Time]; Sleep 1; }; Using either WaitUntil or While. But then there is no sensible reason why WaitUntil or While should work any different with the terminate command.

I think it's because your assigning Ammo and Fuel e.t.c <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">transportAmmo = 50000; transportRepair = 50000; transportFuel = 50000; Perhaps it's now treating your building like a giant ammo crate or truck?

No it's stll planned and is already implemented to a certain extent. You could just extract the scripts from the pbo. Only it probably won't be supported fully in the first beta release. So far the only issue is saving a game half way through the loading and unloading process. If thats easily solved, then the script version will follow soon after.