kronzky

If the action is available via the action menu (the one at the lower right), this utility might be able to help you pin down the exact syntax to do this via a script.

Well, anything that is posted there right now will be deleted anyway, once the forum is officially transferred. So it wouldn't make much sense to post anything there, that you care about. But I don't understand your note regarding spam threads in the search results. I've search there a lot for old stuff (since it's faster than the old forum), but I didn't see any spam. Could you post a complete search URL that would return those results? Thanks.

The class names for nearestObjects have to be enclosed in brackets:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_trk = nearestObjects [vehicle player, ["Truck5tRepair", "MH6"], 25];

I'm not sure if the color scheme is final, but if anybody wants to change it, to match their personal preference, here's how you can do it (that is, if you use Firefox). [*] Find your profile folder (this will be something like C:\Documents and Settings\[username]\Application Data\Mozilla\Firefox\Profiles\[someRandomCode].default). If there are several profile folder, add a new entry to your bookmarks, and then look where the newest version of places.sqlite ended up. [*] Go to the \chrome folder in there, and open (or create) the file userContent.css [*] Add the following lines: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">@-moz-document domain(forums.bistudio.com) { Â Â :link {color:#a21a21 !important} Â Â body, .thead {background:#666 !important; color:#fff !important; background-image:none !important} } Now you can play around with the color definitions, and make'em look any way you want. The color definitions that I entered above, just to make it a bit more readable, look like this: Â Â Â . Not perfect, but it's a start...)

Global variables definitely work between different dialogs, and would probably be the easiest way to achieve this.

I'm hosting it for snafu now. It's on a premium account, so no more download limits: http://rapidshare.com/files/166043483/vbs2_british.PDF

This is the place to put any non-ArmA screenshots or videos you've made or come across. It should be somewhat topical (i.e. related to games, military, computers, etc.), and of course fall within the normal board rules (images <100K, no gore, no flame-baiting, etc.), but other than that, feel free to post any cool or interesting media here that you think might be appreciated by other users.

There are LOTS of worthwhile organizations in the world - military and otherwise. If we would start a birthday thread on each one of them, every single year, we could dedicate a whole forum to that. But, feel free to post one on the 250th...

Your abstract example doesn't make much sense... "rofl" can either be true or false, but there wouldn't be a third alternative. (But I assume that that's just a matter of picking a bad example.) If I go by your description of the problem ("I want to check two values, if none of them is true, I want to do something else."), I would suggest something like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if ((a==1) && (b==2)) then { Â // do something } else { Â // do something else };

I normally don't post in offtopic, but this game has so blown me away, that I had to... I pretty much spent the whole weekend playing Far Cry non-stop, and I'm still looking forward to more. This is the first game in YEARS that has succeeded in really sucking me in! I already thought that I was just getting too jaded, having played too many (bad) games, but FC2 really put the fun back into gaming. The intro is probably the best since the on in the original Half-Life (by which they were probably heavily influenced): Having the driver speeding through the back roads, chatting with you incessantly, with hardly any attention paid to the road, already put a big grin on my face. And the absolutely gorgeous landscape, and the attention to detail (e.g. you grabbing the front seat when he has a near-collision), only got my hopes up even further. But - a lot of games have nice cut-scenes, but they are totally unrelated to the quality of the game itself, so I was still somewhat cautious. But FC2 was actually able to keep up that level of perfection all through the game (i.e. when you take out the map while driving, the avatar drives with just one hand, or when you use the computer at the gun shop, the transition from you sitting down in front of it, and having the game computer fill your whole screen is nearly flawless). They didn't seem to take any shortcuts in this game, but developed everything as well as they reasonably could (and that's a rare thing nowadays). Of course, the scenery is ABSOLUTELY BREATHTAKING, as well as believable (they even got the HDR right for once!), and further intensifies the correct atmosphere they're trying to bring across. And this is just the looks... As far as game-play is concerned, it too is right up there. While you don't have the same kind of freedom as in ArmA (the roads & rivers are still a kind of network of corridors, with hardly any cross-connections), you have enough alternatives, to be able to make your own decisions on how to proceed. The different weapon types and environmental features allow you a good deal of creativity when it comes to taking out those opponents (just can't beat burning down a whole town to take out those nasties!). And I don't know why people are complaining about the AI - I must say they're the best "free-range" AI I've ever seen (just don't make the mistake of comparing it to some scripted situation-specific AI behavior - these guys adapt to any environment, and even to changing situations). They do use cover effectively, they do flank you (and will show up behind you if you don't watch out), and they even have "patience", something I don't think I've EVER seen in AI: They may just stay at one spot, hidden, for a couple of minutes, making you wonder if they, right now, are sneaking up on you, or whether they're still at the last spot you saw them, making outsmarting them pretty tricky. (Normally, with a new game, I find a method of forcing the AI into their death within minutes. Here - not so much... They still keep me on my toes.) And, to continue with the game's level of perfection: I've played it now for 2 days straight. About 6-8 hours a day. And I've not come across a single bug!!! And this is a V1.0 game, with a brand-new engine! (Only once did an objective not complete correctly, but doing it over fixed that problem.) Not one glitch, no getting stuck anywhere (me or the AI), no crashes, alt-tabbing works fine, and not even any typos or discrepancies in the subtitles! UNBELIEVABLE!!! Yes, there are some issues that are not perfect, but very few that actually kill the fun, unless you're the type of person who looks for them: First on my list would be the driving. Racing a car down some jungle roads, with only the keyboard as input is not much fun (even though you do get used to it). The roadblocks (as have been mentioned multiple times before) do get tiresome after a while, and sort-of kill your chance of just doing some relaxing "sight-seeing". The damage system, of course, is totally unrealistic (I can put ten 50-cal bullets into a guy, and not only is he still alive, but still has perfect aim!) But then again, this is not supposed to be a military simulation, but a fun game, and since I can take the same kind of damage, it evens it out, and apart from the ridiculousness-factor of it, it's less of a bother than I thought it would be. So - in a word: I LOVED IT, and am looking forward to A LOT more time on it. After one weekend I'm about 20% through, so you definitely get your money's worth! Not one of those "6 hours, and you're done" games...

Good news for all you offline players! I have gotten the OK by KilJoy to convert his incredible mission for Single-Player mode. So, if you have a few weeks to spare, to try to tackle this monster mission, keep your eyes on this thread! I will try to stay as close to the original as possible, only making adjustments where they might be necessary for technical reasons, or to make up for the lack of other players. Here's a list of things different/new in the SP-version: [*]Instead of straightforward kill-counts the player's rating is used (which will give you different points depending on what it is that you killed, e.g. 1000pts for an officer, 200pts for a rifleman) [*]For every rank increase you can recruit 2 AI units (for a total of 12) [*]To make up for the lack of human medics, you can recruit a medic as you become Corporal (2nd rank) [*]To make up for the lack of human shuttle drivers/pilots, there will be a chopper shuttle available at all times, to take you back to the base [*]Abandoned vehicles will stay at their position indefinitely. Only unarmed, destroyed vehicles will respawn at their original location. [*]Empty enemy vehicles can be used independent of rank [*]If a player leaves a town and then returns, the town will only be re-populated to its previous level, not to the initial full-strength level [*]Town are considered cleared if there are less than 12 AI units left (8 for smaller towns) [*]Since it would be too easy to rack up points with side missions, each side mission can only be played once per cleared town [*]A reconnaissance plane will randomly patrol the current island and briefly reveal enemy position. The fewer enemy units there are in a town, to more often this plane will patrol that area (to help in finding the last survivors) [*]In Veteran mode you can save every 10 minutes. In Recruit mode you can save as often as you like. [*]Passcodes for ranks and cleared cities allow you immediately activate these objectives later on [*]You are able to skip some time in the barracks [*]The mission has been fully translated into German, French, Spanish, Polish & Russian Other than that, everything will stay the same. You have a ranking system which give you different capabilities depending on your level, destroyed vehicles will respawn at the base, killed AI-units can be recruited again at the base, enemy troop levels stay the same, etc., etc. Yes, it will be a killer of a mission, and probably take you a couple of weeks to finish, but that way ArmA will finally have the truly comprehensive and engaging campaign it deserves... If there are any other changes you think might be necessary for SP-mode, please post it here. Do *not* post any requests for any "improvements" over the original game though. As I said, I will try to stay as close as possible to the original, and will not make any significant changes unless they're warranted by the lack of human teammates. I will also need some beta testers within the next few days. Please, only apply if you really want to test, and will provide me with some feedback regarding bugs and gameplay issues. Do NOT apply if you just want to play this mission before anybody else... I am also planning to localize the whole mission. So if anybody would be interested in translating about 100 words and phrases, please PM me (I got the German one, but any other language would be welcome.) Thanks! ================================================ <span style='color:RED'><span style='font-size:11pt;line-height:100%'>UPDATE: OFFICIAL VERSION 1.0 RELEASED: </span></span> <span style='font-size:10pt;line-height:100%'>http://kronzky.info/missions/arma/evolutionsp/</span> ================================================

Oh sorry... I guess I should never assume that things work the same way in ArmA as they do in VBS (where I just had to do the same thing). So I'm afraid you're out of luck... Perhaps you can just place a movable gate on the opposite side of the existing one, and use that instead. Not pretty, but probably the best you can do.

Just move it out of the way via a setPos command (be aware though, that if you do this for a MP game, you have to execute the command on all machines). P.S. I have also recently updated my Vehicle Browser, so that it will also show you any possible user actions and their syntax for objects. This may also help you in finding out how to operate specific objects.

Or on the Wiki, with pictures! [*] Infantry [*] Vehicles

You should look into the actions TAKEMAGAZINE & TAKEWEAPON . I've had civilians pick up both successfully (this was in VBS, but I'm fairly optimistic that this will work in ArmA as well).

With isClass you can directly check whether a particular addon is present, by looking for one of the classes it is using.

I don't really know the name of this object, but I can give you a method to find out any class name of any object you're interested in: Create a trigger with the following settings: Repeatedly: true Condition: format["%1",loop]!="false" On Activation: player sidechat str(typeof nearestObject [getPos player,"Static"]); loop=false On Deactivation: loop=true This will constantly display the class name of the nearest object to you (which has to be of the class "Static"). You can pin down which objects should be detected by specifying a different class (just look up the cfgVehicle class tree on the Wiki, and you'll know what's available). Be aware though, that just because you know the class name, that doesn't mean you'll be able to place it in the editor (in case that's your ultimate goal). To do that you might need an editor expansion addon (just search the addon section for it - there are a couple).

Just the unit names, no quotation marks (e.g. [p1,p2,p3]). And, yes, the in test will work.

You can't actually compare arrays with the "==" operator, that's why that method doesn't work. And even if it did, it would probably also take into consideration the order of the list, and that would most likely never be the same. Let's assume our first list was copied into "listone" (e.g. <span style='color:blue'>listone =+ thislist</span>). Then we'd have to check for each unit in that list, whether it is also present in the list of the 2nd trigger: <span style='color:blue'>unittest=true; {if !(_x in listone) then {unittest=false}}forEach thislist; unittest</span> The thing is though, that this condition would be true right at the start of the mission (where both trigger areas are empty), so you'd have to add some more conditions, to eliminate that situation: <span style='color:blue'>unittest=((count listone!=0) && (count thislist==count listone)); {if !(_x in listone) then {unittest=false}}forEach thislist; unittest</span> Another tricky thing might be that the first trigger will never actually contain all units that are in there. If it's just a regular presence trigger, it will only fire once, when then first appropriate unit enters. But not again, when the rest of the team follows. So you will probably need a counter condition in that trigger as well (e.g. <span style='color:blue'>if (count thislist)==number_of_units_required</span>). Since all this is getting pretty complicated, I've posted a demo mission here...

Read up on the Wiki article on list, and that might answer your question. If you are assigning the "thislist" from a trigger to a variable via your method (mylist = thislist) that means "mylist" will only contain a pointer to the trigger list (i.e. you're not really copying the list content into your variable, but merely referencing it), which means as the trigger list is updated, so is your variable. So - unless you have two triggers overlapping, testing for presence in one trigger, plus presence in the second trigger list, will never return true. You probably want to copy the content of the first trigger list, so that is stays static, no matter what else happens to the trigger itself in the meantime. The syntax for that is mylist =+ thislist.

Get rid of the first condition (this &&) and you should be all set. After all, the condition "this" will only be true if the main condition of the trigger is fulfilled (e.g. BLUFOR present), which will never be true at the same time as the "isNull" condition. But are you sure you want to test for "isNull", and not for (!alive)? I'm not sure what your exact scenario is, but if you're looking for dead units, those aren't totally removed from the game right away (which would make isNull true). If I remember right, they will turn into null objects at some point, but you should probably do some further testing of that before you implement that condition.

The syntax looks fine. But there must be something else going on, that you're not telling us... I tried the same code you listed, and it worked as expected (demo mission). I also expanded the test script a bit, to check for different cars, and that worked fine as well: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_car = _this select 0; if (locked _car) then { Â Â hint "Locked"; } else { Â Â hint "Unlocked"; };

The easiest would probably be to put a trigger over that ammo box, and give it the following command in the On Activation line: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{_x setVehicleAmmo 1}forEach thislist This automatically re-supplies all the vehicle's magazines.

Dynamic patrols can achieved in two ways: Either you move the marker to a new position (via setMarkerPos), or you order the units to stop patrolling at the current location (via the KRON_UPS_side flag, as you did), and then you issue them a new patrol command. This has the same syntax as the initial UPS call, just with the new marker name in it: (e.g. nul=[unitname, "Bravo", etc...] execVM "ups.sqf") Just be aware that you can't call the script with "this" in the first parameter. That only works if you call it from a unit's unit line (in that case "this" refers to the unit). But if you call it from somewhere else you need to refer to the unit by its name. Hope this cleared up things a little bit. And definitely look closely into the dynamic patrolling demo! That has all the relevant features in it.

Well, you cannot actually pass the trigger object, since it's not really contained in your tName variable. That only contains *part* of the trigger's name, but not the trigger object itself. All you're really passing to the script would be the name of the trigger (or part of that name). But since you're familiar with the call compile concept it's fairly straightforward to then get the actual trigger *object* from that in your script. So, if you call your script like this:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">call compile format ["TRG%1 setTriggerStatements['this','nul=[""TRG%1""] execVM ""tst.sqf""', '']",tName]; and the script itself contains something like this:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_name = _this select 0; _trg = call compile format["%1",_name]; _pos = getPos _trg; player sidechat format["arg:%1, pos:%2",typename _trg,_pos]; you will end up with the trigger object in your script (as seen by reading its position). And, of course, ShinRaiden is right, in that you shouldn't really use "nil" to dump stuff into. It's not going to break anything per se, but if you should ever forget that you overwrote nil with your own value, and later use it to empty a variable, you might be in for a surprise. Actually, that behavior has recently changed, in that you can't overwrite commands anymore, but I'm not quite sure if this was only done in VBS, or in ArmA as well, so better play it safe... ;)