UPSMON - Urban Patrol Script Mon

[fencr0c 10]

Can also confirm UPSMON 5.0.8 R2 is working have tested with mission.

Are you using with script spawned units or those placed in the editor?

[manzilla 1]

Works for me too. Did you put the proper code in your mission init file?

[Antigoon 10]

Got a small problem with the script. When enemy is detected, I want a squad far from the area to get in a vehicle and move to the patrolarea and after getting out execute upsmon.

I encounter a few problems...

-I give the squad a get in wp and move them to the area, after get out wp, upsmon starts in last wp init and gives a first patrolwp....but the group does not move!!

-I simply give the group a wp closeby to a vehicle, synch it with trigger detected and execute upsmon in the wp init...the group enters a vehicle but ,this time, does not move to the area (As I thought upsmon makes them look for a vehicle if far away from their patrol area)

What is strange is, when in the first example, I add the fortify command, they execute it fine (target area is Zarg city), just not the regular default patrol (haven't tried it with other commands yet).

I suspect the answer to this ,is probably hidden in this thread somewhere, but 50 pages is a lot to sift through, and searching the thread hasn't gotten me anywhere....anyone know what my mistake or the problem is?

[demonized 20]

dont use the getin wp, place group next to vehicle, and activate upsmon on group by trigger, once upsmon starts group will enter vehicle by themselves if so and so distance in init_UPSMON is smaller than actual distance to patrol marker.

other way regardless of distance, in trigger have:

{
if ( (vehiclename emptyPositions "Driver") != 0 ) then {_x assignAsDriver vehiclename; _x moveInDriver vehiclename} else {
	if ( (vehiclename emptyPositions "Commander") != 0 ) then {_x assignAsCommander vehiclename; _x moveInCommander vehiclename} else {
		if ( (vehiclename emptyPositions "Gunner") != 0 ) then {_x assignAsGunner vehiclename; _x moveInGunner vehiclename} else {
			if ( (vehiclename emptyPositions "Cargo") != 0 ) then {_x assignAsCargo vehiclename; _x moveInCargo vehiclename};
		};
	};
};
} foreach units groupName;
nul=[(leader groupname),"town","move"] execVM "scripts\upsmon.sqf";

this will move all group members into vehicle in driver, commander, gunner cargo positions until there are no more positions available and then run upsmon on group.

Just copy the code and paste it into the trigger, it may look strange but works as i tested it before posting.

[Antigoon 10]

Thx, Demonized, that works!

[galzohar 31]

upsmon stopped working for me, i dont know why but the ai refuse to do anything anymore. they just stand still as they were put in the editor, the script doesnt do anything anymore.

not sure what happened :/

Most likely you broke your init.sqf script somehow so that UPSMON doesn't even initialize. To figure such things out, do:

Run the game with the -showScriptErrors parameter

Check out the RPT file for script errors.

[ckolonko 0]

Hi,

I love this script and now use it in all my missions. Is there any way to set up civilians to spot for enemy forces? This way if your unit enters an area and is spotted by a civilian dicker they can vector enemy forces to your position.

[Antigoon 10]

Is there any way to set up civilians to spot for enemy forces?

I had the same idea and I think you can do it by grouping the civilian you placed with an enemy (with probability set to 0) and then use one of the nowp parameters. But I haven't tried it out yet

[Lonestar 11]

Nice find Antigoon, it's worth a try.

[ckolonko 0]

I've tried it and cant get it to work. Its annoying me because I had it working in arma the other day but didnt save it.

[Rafalski 10]

try to not init upsmon to the enemy leader unit which 0 possibility. (init to any of civilians) NOTE: civilians in such group (leader is enemy) will be treated as enemy !

PS. basically in most cases doesn't matter in which unit is UPSMON inited, as the script itself looking for the leader, and gives order to the whole group.

but apart from above case with civilians, set always init in the leader

PS1: init only in one unit per group.,

Another solution:

make script which check if the civilian CIV1 knowsabout opfor > 1.49 and set some UPSMON reinforcement to the position of this opfor etc.

Edited March 24, 2011 by Rafalski

[Antigoon 10]

I just tried it and it works for me. UPSMON initializes and I get the detected message when he spots me, so I'm pretty sure he will communicate the position to the enemy. I did put the params in the civvie's init field ,like Rafalski said.

[ckolonko 0]

Yeah think Ive got it working too. However, its not the civilian that spots me. It says that squad 1 (the enemy squad) spots me. Is this because the civilian has passed on the message?

[Antigoon 10]

I tested it like this...

I put a civilian with

nul = [this,"testE","nowp3"] execVM "scripts\UPSMON.sqf";

in it's init, grouped to enemy with prob. 0.

And one enemy hidden in a house with

nul = [this,"testE","nowp"] execVM "scripts\UPSMON.sqf";

in the init.

As soon as the civ (instance 1) spots me, the enemy (instance 2) also detects me and immediately starts a flanking attack.

So, yes, the civilian has passed on the message for me.

[ckolonko 0]

Nice one! Thanks Antigoon.

[galzohar 31]

Suggestion: Make it possible to also init the script to the group rather than demand a unit in a group, which will save checking to make sure you're actually initializing the script with an existing and living unit that is still actually in the group.

[demonized 20]

Suggestion: Make it possible to also init the script to the group rather than demand a unit in a group, which will save checking to make sure you're actually initializing the script with an existing and living unit that is still actually in the group.

Yeah this is a important fix imo, before with UPS both leader or groupname could be used.

+1.

[Rafalski 10]

to speed up the work pls give me <code>.

( used to be: _unit = _this select 0; )

nul = [_GroupName or _unitname] execVM ".....

_param1 = _this select 0;

<code>

_unit = ...?

If I get it fast It will be added to the new !R3.

[demonized 20]

this worked for both:

1:    _null = [this] execVM "test.sqf"
2:    grp1 = group this; _null = [grp1] execVM "test.sqf"

_unit = _this select 0;
_unit = leader _unit;  // if this line was removed error was caused on grp1 try.
// _unit is still _unit as before, only it is picked out of a group if this is not used. both this and groupname now works.
{_x doMove (getPos player)} foreach units group _unit;

both times all units members moved towards me.

Edit1: tested on a vehicle as well, both ways works.

Edit2: this will not alter anything in the original script, it will only alter the start to accept a group or a single unit, in the end, _unit will remain _unit as it have always been, it just gets picked out of a group if group is used instead of this.

Edit3: also a final note, this works with both test 1 and 2 if initlines are put in any other unit than leader as well, _unit will after script starts always be leader of group, no matter who activated the script.

You only need to add this line after your original _unit = _this select 0;

_unit = leader _unit;

Edited March 25, 2011 by Demonized
added info

[galzohar 31]

Well AFAIK there is already a part inside UPSMON that chooses a new leader in case the current leader is invalid (or work with current leader if he is valid). Perhaps run that part of the code right at the start based on the group (or group of the unit if a unit is given), so the script doesn't break when you initialize it with a unit that stopped being a valid leader before the script initialized (aka died, deleted, removed from group).

[demonized 20]

@galzohar - yes but leader is choosen from group based on this(single unit) in the initial start in init line.

[Rafalski 10]

nul = [this] execVM "script.sqf";

You only need to add this line after your original _unit = _this select 0;

_unit = leader _unit;

I can not check it at the moment but got questions?

1. There is a group and the leader is set to 0 possibility

a) what is _unit if script is initialized in INIT of the leader.

b) what is _unit if script is initialized in INIT of not leader.

BTW: if this is a unitName -> _unit must be unitName, not the leader of the group. So in case there is problem with the leader, script can be initialized in other unit. (as one of above posts with "possibility 0")

Edited March 25, 2011 by Rafalski

[demonized 20]

nul = [this] execVM "script.sqf";

I can not check it at the moment but got questions?

1. There is a group and the leader is set to 0 possibility

a) what is _unit if script is initialized in INIT of the leader.

b) what is _unit if script is initialized in INIT of not leader.

BTW: if this is a unitName -> _unit must be unitName, not the leader of the group. So in case there is problem with the leader, script can be initialized in other unit. (as one of above posts with "possibility 0")

a: if script is put in leader init with no probability, both this and grp1 works.

b: _unit is always leader, with all name, grp1, this.

BTW: if this is a unitName -> _unit must be unitName, not the leader of the group. So in case there is problem with the leader, script can be initialized in other unit. (as one of above posts with "possibility 0")

does not matter, as this or grp1 returns leader, call him michael jackson and _unit still will be current leader in script.

A few quick name tests:

1: named tl test and used test instead of this, ofc it worked wherever it was started from.

2: same as above, but this time probability of presence 0, _unit was considered isNull, ofc, script not working.

3: used test instead of this from a trigger wich started 5 seconds after test was gunned down by his own group, _unit is isNull, not working.

4: used grp1 instead of this and killed leader, 5 seconds delay, and run script, working.

5: used grp1 instead of this and probability of leader 0, working.

did tests on unmodified upsmon 5-0-8 R2 same as above, if leader killed before script is started, it comes message that no alive units in group, same with probability of leader 0, both fails.

So there is no workaround at the present in R2 that deals with killed name or not present by probability slider.

this have always been like that afaik.

_unit = leader _unit;

Is the best alternative until something better is discovered, ill certainly use it as it can deal with dead units in initiation, wich current R2 cannot.

[Rafalski 10]

OK, I though you find the way, the script will work if you put it in the init of unit which got possibility of present 0 ? :) heheh

SO still to make every thing works if you init script in the unit always init in the unit with 100% present.

Group or Unit;

in R3 this feature is added !

Edited March 25, 2011 by Rafalski

[galzohar 31]

Of course init lines won't run when it's for a unit that doesn't exist, but sometimes you want to spawn the script from places other than units' init lines (great for such situations where every unit in the group has probability of presence less than 100%).

For example I should be able to do:

In init line of any unit in group: patrol1 = group this;

And then in init.sqf: if (!isNil "patrol1") then {[patrol1, "marker1"] execVM "scripts\UPSMON.sqf";};

Of course in this simple example this can be worked around (in fact, even in more complicated examples it can be worked around), but often being able to start the script in this fashion will make life easier.

After all I'm sure the script already saves the group in a variable somewhere, or else it wouldn't be able to select a new leader when the current one is non-functional. All that really needs changing is that if the parameter is a group rather than a unit, then the group will be set accordingly and then it will check for leader and assign one if needed.

Only reason I suggested it is because I thought it would be easy to implement while saving some effort when trying to make missions with randomized enemy groups.

Though to be honest recently I've mostly been spawning groups rather than deleting them randomly, which makes it easier to use the current form of the script. But randomly deleting stuff is easier when your scripting knowledge is not as great ;)