JTD Building Search script

[TRexian 0]

No, unfortunately. :)

But... let me try to make a check and if that parameter is an object (like a building) I can getPos it and use that as the position. Come to think of it, that would make it more functional for triggers, right?

[gvse 10]

I've just tried and can confirm that it does not work indeed. The reason Im asking is because AI choose a different building from the one I really want them to search (a defecting VIP is hiding there)

[TRexian 0]

Can you post the line you used to call it? If you just want 1 team to search 1 specific building, I think we can get that done. :)

Edit:

If you know which building, for the initial position value, you can use (getPos _buildingID) where _buildingID is the building you want.

So, it might look something like:

searchFunc = [group (thislist select 0), 5, "NEAREST", (getPos buildingID)] execVM "JTD_buildingSearch.sqf";

Hope that makes sense... :)

Edited January 6, 2011 by TRexian

[madrussian 347]

1 - In terms of building position sequence, my ideal solution would be to work out a true ordering of them, in a pathfinding context, that would make sense. Something like, clear all the first level positions, then second, etc. In the absence of that, I'm afraid that any random ordering of the building positions would have the AI cross paths with each other too much. My first attempts had the AI bumping into each other and getting confused.

So I have always assumed that building positions are in no particular order to begin with? However what you are saying implies there is some implicit order of building positions?

I do wish there was a way to distinguish between indoor and outdoor building positions.

2 - I think that behavior can be achieved by integrating this with Tophe's building patrol script to get them to occupy the building. Then, to get them to leave, it would be a matter of having them rejoin the leader, then receiving their new waypoints. Since this script envisions having a 'wrapper' script (or some other mission structure), I can probably work up some way to do this - similar to the neighborhood search wrapper that I'm planning.

Well Tophe's has them moving around in the building. I was thinking of more along the lines of a group moving into individual positions and then staying in place. That would probably be useful, in terms of mixing things up.

I am interested to see your wrapper! If we had an occupy function though, we'd probably get a few more people creating different wrappers... I'd definitely give it a shot. :)

btw- Good to hear you were able to implement optional leader takeover!

Oh - does it matter to you if the leader actually leads the search, if he is going to take part in it? I think that would be a bad policy IRL, but, at the same time, if it is only 2 guys, I could also see a leader wanting to lead....

Yeah I can see that both ways. Probably doesn't matter much, but again, maybe shuffle the unit array before sending them in, for more variety?

[TRexian 0]

So I have always assumed that building positions are in no particular order to begin with? However what you are saying implies there is some implicit order of building positions?

I would say, generally, the building positions are in a rough order - position 1 is near an entrance, then they are placed so that each floor is one set, then the next floor up, etc. However, in some Takistan buildings the building positions on a roof are not necessarily the last ones.

So, sometimes the order makes sense, but other times it does not.

I do wish there was a way to distinguish between indoor and outdoor building positions.

Me too.

I also wish there was a way to set waypoints at house positions. Then, this would simply be a matter of creating a fireteam and giving them the waypoints.

I am interested to see your wrapper! If we had an occupy function though, we'd probably get a few more people creating different wrappers... I'd definitely give it a shot. :)

I can give it a shot.

Actually, for JTD_buildingOccupy, I would probably get the number of building positions, create a new group, then split the searcher group in a way that sends them into the building to occupy the building positions. Maybe a boolean after that to have them wander around? (Similar to Tophe's.)

btw- Good to hear you were able to implement optional leader takeover!

Untested, so no promises. ;)

Yeah I can see that both ways. Probably doesn't matter much, but again, maybe shuffle the unit array before sending them in, for more variety?

Hmmm... I kinda like that idea. :)

[kremator 1064]

TRexian this is great work mate ! Keep it up !

Sorry for being demanding about what this script could do, but like you, I too am working on a VTS port for Fallujah and having a gamemaster able to control all of these lovely functions is my overarching goal.

Having talented scripters like yourself makes this dream a reality .... hoorah !

[TRexian 0]

haha

No worries. I'm a big fan of the collaborative process. (I'm not really working on a VTS, just a mission.) I also like the challenge of doing things I haven't done before.

I just hope they work! :)

[gvse 10]

Can you post the line you used to call it? If you just want 1 team to search 1 specific building, I think we can get that done. :)

Edit:

If you know which building, for the initial position value, you can use (getPos _buildingID) where _buildingID is the building you want.

So, it might look something like:

searchFunc = [group (thislist select 0), 5, "NEAREST", (getPos buildingID)] execVM "JTD_buildingSearch.sqf";

Hope that makes sense... :)

Hey man,

This is the line I use now:

srch = [team1, 50, "NEAREST", (getPos_53912)] execVM "JTD_buildingSearch.sqf";

I need to test it more tomorrow but on first run they still do not seem to be entering the building I want them to. It's on a custom island, Thirsk, summer version. I'll post back tomorrow what I find out. (Hope the line I'm using is correctly phrased).Thank you for your feedback! :)

[TRexian 0]

Hmmm... never done it quite that way. What I suggest is, just for testing, is to put a marker on top the building you want to search, call it srchMarker. Then, the trigger line could be:

srch = [team1, 20, "NEAREST", (getMarkerPos "srchMarker")] execVM "JTD_buildingSearch.sqf";

That should get you close. If you find that it is using a different building, you could reduce the 20 to 10 or even 5, as long as it is very close to your intended building.

Let us know how it works!

[gvse 10]

Lol, you've never heard of it done this way probably because that is not the way to do that (told you I'm new to all this). Thanks for the hint, you are very helpful!

[TRexian 0]

haha

For full disclosure, I still feel very n00bish about alot of this stuff. It seems like every day I find something here that is better than what I can do. I'm always interested in learning how other people solve problems.

[TRexian 0]

Ok, got some testing done over the weekend.

New features seem to work.

- optional feature to include leader in the search

- optional feature to have the group 'occupy' the building, that is, the units will stay at the last building positions they were assigned to

- the array of searchers is shuffled, for some variety

Still haven't tested using an object as the initial position, but it should work.

Also, have a block-search script mostly working. Still need to error-test it and really make sure the buildings are searched sequentially.

Here's the array shuffle function - was kinda surprised I couldn't find one here or at OFPEC, but I didn't spend that much time looking. Receives an array, and returns it in a random order.

// JTD_arrayShuffle

private ["_array", "_count", "_arrayT", "_arrayN", "_c", "_r"];

_arrayT = _this select 0;
_count = count _array;
_arrayN = [];
_c = 0;
_r = 0;
while {(count _arrayT) > 0} do
{
_r = floor (random (count _arrayT));
_arrayN set [_c, (_arrayT select _r)];
_arrayT = _arrayT - (_arrayT select _r);
_c = _c + 1;
};

_arrayN

[kremator 1064]

Sounds good trexian! Looking forward to playing with the new version!

[madrussian 347]

Wow! Keep going TRexian! :)

Next request:

Optional parameter for a single group to storm (and/or occupy) multiple buildings.

OK, now I'm getting greedy. :D

But in reality that would add a ton of new dynamics and would probably make things that much more terrifying. Can you imagine a group of say 10 or 11, splitting up (without leaving the physical group) and storming 3 or 4 different buildings?

Might be worth the effort!

[TRexian 0]

haha

You know, I'd probably do a different kind of script for that - one that presumes at least 10 units.

With the right wrapper script and/or keeping track of groups in a global array, something like the multiple building storm/occupy is possible.

[TRexian 0]

First post updated with the new version of the script. Also, I have PM'd a few guys with a new alpha version of the test mission. If anyone else is interested, just post or PM me. :)

Edit:

It includes an implementation that searches the area around a specified position. That script is:

// JTD block search

private ["_groupSelect", "_posSelect", "_radSrch", "_houseArray", "_c", "_searchFunc", "_nameMarker", "_marker"];

diag_log "Block search started";

if (isNil "JTD_bldgSearchFunc") then
{
JTD_bldgSearchFunc = compile preprocessFileLineNumbers "JTD_buildingSearch.sqf";
};

// needs group, position and radius
_groupSelect = group (_this select 0);
_posStart = _this select 1;
_radSrch = _this select 2;
_houseArray = [];
_c = 0;
diag_log text format ["groupSelect: %1", _groupSelect];


while {alive (leader _groupSelect)} do
{
// building check
_houseArray = nearestObjects [_posStart, ["HOUSE"], _radSrch];

{
	_posSelect = getPos _x;
		diag_log text format ["selected position: %1", _posSelect];
	_searchFunc = [_groupSelect, 10, "NEAREST", _posSelect, true, false] execVM "JTD_buildingSearch.sqf";
	if (JTD_searchDebug) then
	{
		_c = _c + 1;
		_nameMarker = format ["srch_%1", str _c];
		_marker = createMarkerLocal [_nameMarker, [_posSelect select 0, _posSelect select 1]];
		_marker setMarkerShapeLocal "ICON";
		_marker setMarkerTypeLocal "dot";
		_marker setMarkerColor "ColorRed";
	};		
	waituntil {scriptDone _searchFunc};
} forEach _houseArray;
sleep (random 60) + 60;
};

Edit2:

I just found this at OFPEC, too, by haroon1992:

http://www.ofpec.com/forum/index.php?topic=35433.0

Looks like a promising house patrol script that is similar to mine. I would encourage people to give that a try, also. :) I looked at his script, and it uses a different implementation, and is quite a bit more detailed than mine. Might be good or bad, depending on what you want to accomplish. :)

Edited January 11, 2011 by TRexian

[DankTank 10]

Can I have a look at the updated version please? :P

I am not sure which to use the AHP or yours. I have only tested both using sample missions... I am aiming for completely random patrols utilizing ALL the buildings in zargabad and once they are engaged with the enemy(me) they will enter the surrounding buildings and storm a building if im hiding in it. With the AHP I dont see too much activity in terms of going in a building to chase after me. I also never seem to see them enter the mosque. So far I think yours works better in terms of them actually entering the buildings after me in zargabad. A few times I seen them in the distance up on roof and started shooting at me. Was very cool and the type of experience i am looking for. Using the ACM I can get a good random battle but they never enter any buildings so I am in need of somthing like this. Besides adding a few groups is it possible the units spawned from ACM run this script?

[TRexian 0]

DankTank -

Will send you a PM. :)

I think I know the kind of gameplay you want to achieve. You may want to try adding a 'fired' eventhandler to your unit, so that if you fire any weapon, it will trigger a script that will bring enemy squads toward your location. Or, have you looked at DAC3? It can produce patrols, which can then execute my script (or AHP probably).

I haven't done much with ACM, so I'm not sure how that would work.

PM heading your way. :)

[DankTank 10]

The 'fired' event handler combined with your building patrol is sort of my goal in my mission. random patrols that actually enter the buildings...which also converge on your location if your engaged etc. Im not sure but it seems they already communicate and do this when I use the SLX mod(minus enter buildings)??. I normally use ACE and I an starting to enjoy with SLX.

I am however using CO with no mods to test this first.

here is a sample of my mission to get a better idea of what im doing. Im also wanting to limit the SOM/missions to inside the same area I have the ACM limited to. The city of zargabad is the hotzone.

http://www.mediafire.com/?wb3xhzpzgt1wtas

Edited January 12, 2011 by DankTank

[DankTank 10]

_EHfirednear1 = this addEventHandler ["firednear", {_this exec "JTD_trigSearchInit.sqf"}]

Is this how I should go about the eventhandler? :D

***I think I see a problem already, im using exec instead of execVM for sqf Q.Q

Edited January 13, 2011 by DankTank

[TRexian 0]

Glad you're trying this! :)

Didn't have a chance to get to this last night.

Couple things - if you're using the trigSearchInit that was included with the mission, it will need some tweaking. :)

Here is how I would do it. You can put this in the init line of the player (warning - this is untested code):

// JTD trigger search from fired EH
// by TRexian

// executed by EH attached to player
// _srchEH = this addEventHandler ["fired", {_this execVM "JTD_searchFiredEH.sqf"};]

private ["_shooter", "_shooterPos", "_nearEnemy", "_group", "_searchFunc"];

if (isNil "JTD_bldgSearchFunc") then
{
JTD_bldgSearchFunc = compile preprocessFileLineNumbers "JTD_buildingSearch.sqf";
};

_shooter = _this select 0;
_shooterPos = getPos _shooter;
// may need a search for "MAN" type object instead
_nearEnemy = _shooter findNearestEnemy _shooterPos;	// should return null object if none

if (isNull _nearEnemy) exitWith {diag_log text "No enemies near."};

_group = group _nearEnemy;

_searchFunc = [_group, 50, "RANDOM", _shooterPos] call JTD_bldgSearchFunc;

First, it uses 'fired' instead of 'firedNear' so it only captures when the player fires. I've never used the findNearestEnemy, so I'm not completely sure how that will work.

Still trying to sort out some sort of documentation for you, too. :)

[DankTank 10]

Thanks for the new script. I tested it and I get no results. I added it to one of the opfor init lines and shot right next to them to see if they move... no dice.

[TRexian 0]

Yeah... that's what I get for posting without testing it. :)

Based on our discussions, and other feedback, I think I'm going to turn this into a 'suite' of scripts, and maybe create a module that would allow easy access to them. Included would be:

- an EH like you are interested in, that would call the nearest enemy to the location of the shot

- a block search that accepts an array of groups to search an array of buildings

- a block search that sends one group to an array of buildings

- a proximity script that, if an enemy group is near a player (configurable), there is a chance the group will search for the player

And whatever else I can come up with. :)

Right now, I'm re-working the test mission so that it is based on addactions to trigger the different behaviors, just so people can see what is supposed to happen.

[TRexian 0]

Ok, new version of the scripts and test mission available here:

http://www.mediafire.com/file/nrd8afg1kclrbzy/JTD_buildingSearchTest_0116.7z

(And soon on ArmAholic thanks to Foxhound.) :)

I've also updated the first post.

I'm not prepared to fully document the stuff, though, as the script suite isn't done yet - this is more like a demonstrator.

In the mission, now, there are 3 addactions:

- one group searches a block of buildings around a center point

- one group searches the player's last 5 positions

- different groups go to the player's last 5 positions and occupy those buildings

(I suggest not trying to have more than 1 going at any one time.) ;)

Also, there is a fired EH, which will draw the nearest opfor to search the building closest to the player.

A few enhancements:

- a server check

- a global array that tracks the groups that are searching

- a time check to end the search script after a defined amount of time

- some more robust error-catching

Thanks to the guys who have provided feedback! :)

[manzilla 1]

Thanks for the new version. I'm using this in some WIP missions. One question though. Is it possible to organize the files in to a folder structure? May like a JTD_Building folder. The only reason I ask is because it makes it much easier to keep my missions organized when making them. It's not a big deal but does keep things much cleaner.