kronzky

Seems that WinRar was the problem. If you open the zip file with *it*, it showed folders that had been deleted. These were not shown in WinZip, hence the confusion... Uploaded a new version now, without any deleted remnants.

That is just Firefox's way of temporarily renaming files if you open them directly (without saving them first). The listing I took the screenshot off comes from the file I opened from my download page (just to verify there's nothing weird in there).

I'm not sure which Intro and Sara folder you're referring to. There shouldn't be any in the zip file. This is all it should contain:

You could try setting the respawning timeout to a longer period (right now it's 3 seconds), to see the exploded tank. It's line 119 in functions.sqf ("%1 setTriggerTimeout[3,3,3,false]"). The options like bulletcam, starting/stopping targets, etc. are available from the radio menu. (There some documentation in the Notebook.) Targets are positioned in front of the player, so if you point him towards a mountain, or move him to the other side of the runway (either in the editor, or while the mission is running), you will then have the targets at whatever location he's looking at. - That's why it's called the "Moveable Target Range"... ;)

Since there's still quite a shortage of SP-Missions out there I figured I'd port my Urban Patrol Script over from VBS. (Finally something that's going the other way...) Details and downloads here: http://kronzky.info/ups It allows you to set up a quick mission in a couple of minutes, without having to worry about waypoints, scripts, or AI behaviour. All you need to do is place a marker over the area to be patrolled, put some OPFORs in the area, and have them call the patrol script. That's it... The script will take care of generating random movements, intelligent responses to enemy encounters, and notices when everybody's dead. It's a very easy and fun way to familiarize yourself with a new map, without having to spend hours making a mission that will only be predictable after a couple of runs. With this script every run will be totally random. And since you can set it up without even knowing the map too well, you will have a fairly realistic simulation of real-life scenarios, with unfamiliar environment and unpredictable enemy behavior. Yes, you won't be able to make a "deep", multi-subjective, and inter-dependent "save-the-world" mission with this, but for simulating normal day-to-day patrolling missions, and the unpredictability associated with it, it does the job quite nicely. Here's a rundown of the main features: Setup Options Patrol any "marker-designated" area with any unit or group, whether it's Infantry, Armored, Cars, Choppers, or even planes, using any side (east, west, resistance, civilians). Several independent marker areas (for different units) can be used on the same map. The start position of the units can be a random position anywhere in the active area - in that case some units may even end up on roofs. You can create a random number of "clones" of a unit/group you placed in the active area. [*]AI Behavior The AI will avoid "dangerous" areas, and react intelligently to attacks. If it sees a team-member being shot, or spots an enemy without themselves being detected, it will not continue on its regular path, but instead use a flanking approach to get to the shooter. The accuracy of the approach will depend on the "knowledge" the AI has about the shooter (i.e. whether the shooter was actually seen or only heard).(image) If AI units get stuck (mostly due to bad pathfinding) they will try to free themselves after a while. Units will make occasional stops of random lengths during their patrols. When independent AI groups meet each other they will share their knowledge about any enemies they might have spotted. By default units patrol in safe mode at limited speed, but they will switch to combat & full for a limited time when they encounter enemies. [*]"Intel" Options An automatic trigger is generated for each area to announce when that section has been cleared of enemies. (image) The units can be tracked via a dynamic marker on the map. (image) While the first versions of this script were not MP-compatible, by now it most definitely is! (So you can ignore the older posts regarding this issue.) Here's what it looks like after a car and an infantry unit have been patrolling for about 15 minutes: http://kronzky.info/ups/car_and_foot_patrol.gif (146 kB)

I may be missing something, but I don't quite see how Michael Jackson's death is in any way "related in some way [to ArmA], for example: military, politics, science and other military games"...

There is a dedicated page on creating an overview image on the Wiki: http://community.bistudio.com/wiki/Overview_Picture

The correct syntax is "lighton" & "lightoff", but that action only works persistently with empty vehicles. If the vehicle is AI controlled the command will cause the light to switch momentarily, but will be reset right away by the AI. To control the lights of AI-controlled vehicles, set their behavior to "combat" or "stealth" to turn it off. Any other behavior modes will cause them to drive with the lights on. Another situation is where the player is the driver of the vehicle. If you have the "Light On/Off" option in your action menu, then you can either (obviously) control it via the action menu, or via the action command. If you don't see the light action, then that means that some other (AI) unit is the commander of the vehicle (e.g. the gunner in an M2 HMMWV), who is then also charge of the driving/behavior mode, and therefore the light status. In that case you'd have to set the commander/gunner of the player-driven vehicle to mode "combat" or "stealth" in order for the light to be turned off.

If I remember correctly, the AI will only turn the lights on if they're in safe or careless mode.

You can do it anywhere you want. Just make sure that you give those created objects a name, so you can refer to it. If you just create a unit via "_unitType createUnit [_pos, _group]", you have no way to refer to that unit (and this is probably where your frustration comes from). To access it in scripts, triggers, etc., name it via the createUnit command's init field:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_unitType createUnit [_pos, _group, "myUnit=this"];This assigns the newly created unit to the variable "myUnit", which can then be used anywhere in the game, just as if it were created in the editor. You can also use a similar approach with the alternative createUnit command, which returns the created object (e.g. _unit = _group createUnit [blah,blah,blah]). As long as you stay in the same script you can use that returned _unit variable in other commands. If you need it outside of the script, either put it into a global variable, or assign it via <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">call compile "myUnit = _unit" The same principle applies to vehicles (just that none of the createVehicle commands have the option to specify an init string, so you have to use the second method of naming it (via "call compile").

You could give each unit a GetIn EventHandler, and if they get into an unauthorized position, kick them out via a GetOut action.

this in a trigger's activation line refers to the triggering unit. If you want to refer to the trigger itself, give it a name, and then use that in the getPos statement.

It sounds like a timing issue of ArmA (i.e. when it's done creating all units, vehicles, triggers, etc.), and then testing any trigger conditions against it (especially considering all the extra objects that have to be taken into consideration with the ACE mod). I'm not sure the addition of *anything* will fix this reliably, since the creation timing seems to be somewhat random. What you *could* do though is, make your KRON_Cleared_Sector_A1 trigger check for some other initialization variable as well (in addition to the UPS variable). So - Your sector done condition could look like this "KRON_Cleared_Sector_A1 && !isNil 'INIT_DONE'", and somewhere in your init scripts - at a point where you're absolutely sure all mission objects have been created - you'd set the INIT_DONE variable to some value. That way the trigger can only ever be true after this init value has been explicitly set by you

You might want to try emptying the listbox first, before you resize it, and then putting the pre-existing lines back into it again.

You can use variables and most scripting commands in the description.ext. Together with _EXEC, it gives you pretty good flexibility: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_EXEC(_str=localize "STR_LOCATION" + " | " + localize "STR_DAYTIME"); text = _EVAL(_str); (Of course, use double-underscores before EXEC & EVAL in your real code.)

You're probably looking for the createLocation command.

wrong forum

wrong forum

wrong forum

wrong forum

wrong forum

wrong forum

Having gamers comment on VBS is about as productive as having a bus driver comment on the latest Ferrari. He may rightly remark that it ONLY HAS TWO SEATS. And tight ones to boot! But he might be somehow missing the point...

This is so random - it's not even "offtopic". Moving to the "no topic" forum...

I haven't used the OFP version of UPS in a few years, so I'm just guessing now - but you could try setting the marker's position to negative values in the init file. The script will still work with that, I'm just not sure if the file is executed before you see the first briefing screen. e.g. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">"mark1" setMarkerPos [(getMarkerPos "mark1" select 0)*-1,(getMarkerPos "mark1" select 1)*-1]