UNN

You could write the same code like this, if you prefer to stick with the game time. I kept the sleep in, as it's not a good idea to run a while loop without some kind of pause: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_time = Time+10; while {Time < _time} do     {     hint "Working";     sleep 1;     hint "";     }

Lol...You think your frustrated. I had a years worth of OFP scripting, made redundant by Arma, almost overnight We are working on this side problem, so it's still up for debate. Hopefully we will come up with a sloution, one way or the other, soon.

Depends what your trying to do. A simple way is. Add this to your init: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">GAMEEND_UNITS=[MYUnit01,MYUnit02]; Then for the trigger condition: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">(Count (GAMEEND_UNITS-(Crew MyVehicle))==0)

I think this is intended, it worked the same way in OFP. I doesn’t disappear, your moved to a cargo proxy object. Your character remains at the location you entered the vehicle, until you get out. In OFP it was possible find the initial user action, floating in mid air.

@BraTTy Cheers, I'm sure some of what we have planned for Carriers will come in handy for your Pacific War stuff. It's that particular theatre, that inspired me in the first place. @TankbusterSPAFF For me, the point is to move resources from A to B. But it does play a major part in the look and feel, so it's not something I would want to willingly exclude. I could live with the odd person, who happens to be sat in a cargo position, seeing some graphical glitches while a  vehicle is being driven onboard. What I can't really live with, is the problem Rock highlighted with the Stryker. Graphics are one thing, but having some unsuspecting player wreck their mission, because one or two vehicles cause the transport to tip over and destroy half the units in the surrounding area... I do prefer easy solutions But I don't mind writing extra scripts to avoid problems. As long as those scripts don't hog any resources for extended periods of time. Some of the possible solutions are pretty drastic. Yeah, imagine how Arma decides which objects should be drawn behind which. When a player is sat in a cargo position, Arma makes the assumption that, everything contained in the cargo LOD is to be drawn last. Everything else outside the LOD is drawn first. A vehicle being driven into the cargo bay, is classed as being outside the vehicle. The engine only starts to draw it correctly, once our system loads the vehicle into a cargo position. After more testing, I’ve decided to not allow any vehicle to be loaded or unloaded, if infantry are sat in cargo positions. Your going to have to move your guys out, before you drive anything in or out of the cargo bay. So that avoids that problem and I'm sure the same restrictions hold true to real life to.

You can learn a lot in a year or so. Failure is the mother of success I think this is heading towards, fix the eye candy at all costs? We just have to come up with a way of crushing the toes, of anyone who wants to sit in on the loading of Land Rover

I think the method we have chosen offers the best all round flexibility. Each cargo and transporter has to be registered with the system, but that can be done by anyone. Any addon that’s already been created, or is going to be created, can be configured to work with the system. By either the original addon maker or a third party. Every thing can work on proxies and inheritance alone, so no need to package or modify someone else’s work. In most cases no need for other peoples objects in MLOD format e.t.c The only skills required will be, moving proxies around in O2, creating a pbo and using a text editor. In most cases you can just copy an existing configuration and do a quick search and replace for the model and class names. The MI26 was the only addon I ever saw using that method in OFP. But I didn't want to go down that route for a variety of reasons. It was limited to a single cargo object, would prevent a combination of cargo and infantry. Could in some cases, cause damage to both cargo and transporter. Would potentially cause major problems in MP. Gnats system has different requirements, so the two can't really be compared. Hard to say without all the Arma MLOD's. I suspect the Strykers mass is offset? Yeah, antennas are a problem. In the case of the humvee, seen as we have the MLOD version, I could create a proxy with the antenna in a stowed position. If someone was making a vehicle that has antennas, with our system in mind. Then it's better to assign thier textures as a hidden selection and reveal them via the configs init event. That way they would remain hidden as cargo. For the other scenarios you may have to put up with it. It's annoying, but there is only so much that can be done without the MLODS. Yeah, as Rock said. So far the only real issues are, how the cargo will appear during the load process and what vehicles work. As you saw with the Stryker, it's not really suitable for driving into that type of vehicle. In that respect, automatically loading cargo without driving into the back, would avoid both problems. We could make life easy for ourselves and just support our relativly small number of UK addons. But we want the system to be as flexible as possible, only that flexibility comes with some compromises.

It has been asked before :P But it's a good opportunity to pole people about a problem I mentioned earlier. Here's a couple of pictures I took of a 4x4 driven into the cargo bay: The pic on the left is the internal view from my player object, sat in a cargo position. The second is the command view from the same player object looking at the same vehicle. In the first pic, even though it draws the 4x4 at the correct scale, it's rendered as though it's outside of the aircraft There are some lengthy work a rounds we could do to avoid this, so the questions are: -Is it something you could put up with? -Is it something we should avoid by not allowing vehicles to be driven into the back, prior to loading? -Do we go for a simple solution that switched a players view to that of the aircraft, once the player enters a cargo position and only return the camera once the player disebarks. -Do we add possible overheads to the scripting, mp performance and object count. To avoid, what is essentially eye candy? Assuming there is not a p3d based fix we can apply. Ok, I admit, the last question is somewhat loaded So you might have guessed, I can live with either of the first three. Any other unit outside the aircraft, or any external view, will draw the 4x4 correctly. Once the 4x4 is loaded into the cargo position, it will be rendered correctly for all players. Edit: Sorry added one more option I thought of.

Yeah, it is a little confusing. I'm assuming he means that commands that try and reference undeclared variables will now return an error, rather than returning the the variable type the command expected. For example: _IsAlive=Alive NOSUCHOBJECT; Hint Format ["Is Alive %1",_IsAlive]; At the moment the above code would not return an error and the hint would display the value bool.

I'm sure that in OFP you could not delete a unit that's sat in a  gunner, cargo or driver position e.t.c. You had to move them out first, before deleteing?

That’s certainly a good way of exploiting some of the addons we have planned. The larger the maps the better IMHO. At least with plenty of water it keeps the object count and development time to a reasonable level for map makers. There's an already healthy, if small, group of addon makers working on naval vessels, aside from our own plans. We would certainly want to be able to use those, along with our stuff. After all, the Nimrod still features in our plans, not to mention some scripts I'm itching to write. For me the main casualty is playing Arma itself Some how I start going though a combination of guilt and motivation, to get on with our projects, every time I sit down to play Arma just for fun.

Also when said "terrorist" is funded by a "firendly" country.

Yeah, it's no good for a vehicles driver\pilot. You have to apply the multiplier in a loop. Otherwise it's like you said. You won't see any result. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">WaitUntil     {     _bomb setVelocity [(velocity _bomb select 0)*1.2,(velocity _bomb select 1)*1.2,(velocity _bomb select 2)*1.2];     (IsNull _bomb)     }; Just adjust the value 1.2 for each vector until you get the desired result. If you want to get the bomb to travel at a fixed speed or the bomb is created with CreateVehicle then you will have to use trigonometry.

To be on the safe side, you can do it this way. To ensure you get just the cargo for vehicles with multiple gunners: Create a function called SSD_CargoCrew.sqf for example: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">private ["_cargocrew","_Vehicle"]; _Vehicle=_This Select 0; _CargoCrew=[]; { If (((AssignedVehicleRole _x) Select 0)=="Cargo") Then     {     _CargoCrew=_CargoCrew+[_x];     }; } ForEach ((Crew _Vehicle)-(Driver _Vehicle)-(Commander _Vehicle)); _CargoCrew Load the function from your init.sqf or somewhere suitable with: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">SSD_CargoCrew=Compile PreProcessFile "SSD_CargoCrew.sqf" Then call it when required with: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_para_array=[_Vehicle] Call SSD_CargoCrew I currently have a team of legal experts compiling a water tight disclaimer But in the mean time: There may be typo's or syntax errors in the above code. But the principle works. I will not be held accountable for any aspects of your requirements, which you choose to keep hidden. The above code is just one example of how to achieve the requested results and is not supposed to be the eleventh Commandment. Other than that, I hope it helps

You might have more luck with the doWatch command? Only the problem is, once you issue it, you have to handle it for the entire mission. Also don't try and watch positions to close to the unit in question. Otherwise odd things may happen.

I suspect you will probably count yourself lucky, if you contemplate the choice of music I will come up with for such a hulk As Rock said. The best we can do, is promise steady progress. Lol...That will probably cover the testing of either one new script command or a new config/p3d featureÂ

Looking forward to delving into the code. Especially the dialog to world scripts. Hoping there is some way to add user defined functions and events to the menu options to?

It might be worth taking a look at the Editor Update V1.02 config by Lowfly. He does lot's of stuff with dialogs and addons

To add to that, at one point the expectations of AI fell far short of the reality. Which, as I am lead to believe. Created a so called Dark Age for artificial Intelligence?

Yeah, it's quite a dilema. If eveyone was true to thier professed convictions. The majority would be statisfied with the traditional hex based wargames or even play Tank Pong. Either one offers detail over graphics or fun over complexity. But let's face it, it's not unreasonable\inhuman to want to have it all. Just watching someone drive through the Arma islands is a joy in itself. Why deny yourself such a treat All we can strive for is that one day, we can have it all and then some.

I'll second that! The forums should be used to provide additional, self-contained and practical examples to compliment the official Wiki. That way, this site can be a valuable resource for future developers Â

Well mine was dripping with sarcasm

I don't think you can use the Switch statement that way. At least in Arma, other languages used to use: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">case [1,4]:.... Probably the best you can do is pre-compile some common code: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_14Code=Compile "Hint ""1 and 4 where called"""; _23Code=Compile "Hint ""2 and 3 where called"""; switch _mycounter do { Â Â Â Â case 1: {Call _14Code}; Â Â Â Â case 4: {Call _14Code}; Â Â Â Â case 2: {Call _23Code}; Â Â Â Â case 3: {Call _23Code}; }; ?

@Mike Hawk It's a little unfair to want to ban someone for using an entire thread to make an impossible and esoteric request. As compelling as your choice of font is, that kind of reaction does nothing to further yours or anyone else’s position in the human race.

The event handler version would look like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">aha1 AddEventhandler ["getin",{_This ExecVM "TeamCrew.sqf"}] TeamCrew.sqf: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_Vehicle=_This Select 0; _CrewPos=_This Select 1; _Unit=_This Select 2; If (Local _Unit) Then     {     If !((Name _Unit) in gol_Rf) Then         {         _Unit Action ["Eject",_Vehicle];         Hint "Only -{GOL}- can fly the Attack choppers";         };     }; Not sure who would disagree? Each person has there prefered method. But they both work, so there isn't much to argue over. Myself, I tend to go for event handlers over triggers, but thats probably down to my background. Although I'm begining to see some advatages in using triggers for MP. For example, the above event handler version will not support respawns on it's own. You are going to have to re-attach the handler yourself if the chopper is respawned. With triggers you don't have to worry about such things. Triggers do have the potential to take up more resources, but in this case, I doubt such a trigger will cause you any problems.