st_dux

May I ask why this was changed? Interacting with map objects was useful: One way I used this feature was to attach waypoints to buildings that would run a script to automatically have the group with that waypoint occupy the building positions found at the attached building. Now this script requires that I have the building named; I cannot simply attach a waypoint to it in the editor. Of course, naming this building will be more difficult now, too, because object IDs are gone. Am I supposed to just use nearestObject on a game logic placed near the center of the building now and hope that nothing besides the building I want is closer? If I want to check if a bridge is destroyed now, for example, how would I go about finding the object to check?

First off, I apologize if this is in the wrong forum section, but I'm not sure where else to put it, and thus far, PMs to admins have failed me. Anyway, here's my issue: I've had an account on these forums for a relatively long time. My old account username was ST_Dux; if you search for posts by this user, a bunch of stuff will come up. The trouble is that I went inactive for a significant period of time, and when I came back, the login system on the forums was changed from a username/password paradigm to an email/password paradigm. This wouldn't ordinarily be a problem, but I don't actually remember what email address I used for that account; whatever it was, it is not my current email address. Unable to login, I created a new account instead, but ideally, I would like to recover my old account. If anyone can help me with this, I'd appreciate it.

Every .PAA file that I try to use in ArmA 3 is showing up with the wrong colors. Essentially, red and blue seem to get reversed. The images look fine in TexView but are consistently wrong in game. Why is this happening?

The "_" in this case should not be there. Also, "_myOldUnit" isn't defined anywhere in your script, so I am not surprised that it's coming up as undefined.

Do the paratroopers start inside the helicopter, or do they board it earlier in the mission? If they board it earlier in the mission, how does this take place (i.e., is it via a Get In waypoint, via scripting, etc.)? Have you tried using unassignVehicle before giving the eject action yet? This would need to be done for each unit in the group.

As far as I know, the low-level FSMs are not accessible to us. User-created FSMs for AI behavior have just as much (and just as little) precedence as scripted behavior; using the FSM format is more a matter of preference.

Wait, what?

And that is perfectly reasonable, particularly for larger functions that may be reused in several different scenarios or by several different scripters. That said, I don't think it's right to say that inline function code is less efficient because it is processed in exactly the same way.

OK, I kind of expected that. I disagree with the idea that this kind of function is somehow less efficient. The game processes this code in exactly the same way as it processes functions split into dedicated files. This isn't like C++ where making a function inline actually changes the way it is compiled. At the end of the day, it's all just interpreted SQF code anyway.

isNull only works if there is something that could be null. A variable that points to nothing at all is not null; it is undefined. To check if something is undefined, use isNil instead. if (isNil "task05") then {...} Alternatively, you could set up your task variables before actually creating all of your tasks; in this case, isNull could work. Some people will tell you that this is a better practice, although personally I don't think it makes any difference at all. Here's how you'd do that: task05 = taskNull; if (isNull task05) then {...};

Within the context of Arma scripting, what exactly would constitute an inline function?

The AAF have captured an important leader in the Altis resistance movement and are planning to execute him later today. Although the AAF are our allies, we cannot allow this execution to proceed; the potential intel that the resistance leader possesses is too great. You are to lead a small team of CSAT Special Forces soldiers on a daring dawn raid on the compound where the resistance leader is being held, capture him alive, and bring him back to headquarters for interrogation. This is a relatively simple but fairly challenging hostage rescue scenario that requires the player stealthily approach an enemy compound and then coordinate multiple elements in a fast-paced assault. One wrong move can result in the resistance leader being killed, which means mission failure. This scenario does not require any addons or mods to play. It was designed for 100% vanilla Arma 3. Workshop link: http://steamcommunity.com/sharedfiles/filedetails/?id=634796582 Armaholic link: Operation Bengal Toe This is the first mission I've published in years, although I've been editing Arma missions for about 15 years now, and I work with VBS3 professionally. I started scripting before the Biki existed, which now that I think about it, makes me feel pretty old. Enjoy the mission, and if you find any bugs, please report them here!

Thanks for checking out the mission, AZCoder. If you're getting a mission failed screen, then the resistance leader is indeed being killed; nothing else can cause mission failure in this scenario. My advice for avoiding this is to be more careful on approach to the compound: If you encounter a patrol, you must either eliminate it very quickly (not allowing for any return fire) or avoid it altogether. If the patrol has a chance to tell HQ that they are under fire, the resistance leader will be killed. During the actual assault, you have to be very aggressive: Moving too slowly will allow enemy soldiers at the compound to kill the resistance leader. It's not particularly easy, which is why you get a free autosave after successfully infiltrating. The mission is now up on Armaholic as well for those averse to Steam: Operation Bengal Toe

Have you tried using (vehicle _target) instead of just _target? It might be that you can't target an individual crew member of a vehicle.

That sounds like it might be a bug in Eden. Did you try the thisList option?

Sounds like this could be a bug. Have you tried syncing in the opposite direction (i.e., if you synced from module to trigger, try from trigger to module, and vice versa)?

The easiest thing to do would be to have all of your Independent soldiers join an OPFOR group.

To be honest, I don't use the modules myself, so I don't know off-hand. I would assume that a task notification would display by default whenever activating the task changed module, but I'd have to take a look at the function associated with it to find out for sure, and I don't have access to that right now. You can, of course, always create a task notification manually by tapping into the notification system directly: https://community.bistudio.com/wiki/Notification

Waypoints are for controlling the movement of groups. They are not tied to the task system in any way (although you could use the activation field of a waypoint to enact a task state change if you wanted). Based on your description, I assume you were using the task modules in the 2D editor. They are still there. You can find them under the modules/logic group (F5 shortcut) in the "Intel" category. These modules tie directly into the ArmA 3 Task Framework that davidoss linked above; activating them via module versus via script is merely a matter of preference.

How were you doing this with waypoints in the 2D editor? Tasks are completely separate from waypoints.

This is a classic problem that has existed in some form since OFP. The string version of a group will have a space in it, breaking everything, so you cannot "format it in" like you can with other data types. It sounds like you've already found a workaround for your particular problem, but for the benefit of others, a quick way to get around this is by using the group leader: format ["(group %1) call test;",leader _group] This still winds up using the group, but because you are formatting in an object (the group leader) rather than the group itself, it doesn't break.

You can pass arbitrary arguments via addAction. It is the parameter right after the path to the script (which, by the way, you can just use instead of running code that executes a script anyway). Just make the parameter equal to your money value, like this: [[_cash ,[("<t color=""#FF0000"">" + ("Collect Money") + "</t>"),"scripts\pickupcash.sqf",myValue,0,false,true, "",'']],"addAction",true,true,false] call BIS_fnc_MP; Note where I added "myValue" above. This is where you could put the value of the money dropped. Then, in your pickupcash.sqf: _money= _this select 1; _amount = _this select 3;

Thanks for the help, guys. I actually only needed pictures for a mission overview and briefing, and I hadn't edited in so long that I didn't realize that you can just use JPEGs now, which seem to work fine. I will keep this page bookmarked until I come across a situation where PAAs are necessary, though!

moveInCargo/Driver/Gunner/Commander will not work for a unit that is already inside of a vehicle. You will need to move them out of their current vehicle first. Using an "eject" action is usually fastest. myUnit action ["eject",vehicle myUnit]; waitUntil {vehicle myUnit == myUnit}; myUnit moveInCargo myBoat;

The group is already assigned to the _group1 variable. If you need this variable to be global so that it is usable in your next trigger, simply remove the underscore before "group1". Keep in mind, however, that if you run this spawn code more than once, only the last spawned group will be "group1".