Units or groups appearing based on a trigger or script

[DuckHunter]

Is it possible, based on scritps or triggers, to make AI enemy units not appear on the map until a trigger is activated based on distance?  I feel this would allow for creation of larger missions by keeping these units inactive and not on the map until needed. That would significantly increase the frame rate of all players and give a more dynamic atmosphere to the battlefield.

Thanks,

DuckHunter Out

[UberKreb]

You could also use the createunit and createvehicle command to place more troops on the battlefield.  I would think by placing the needed units on the map would create even less lag, but when you start creating units, it might cause a bit of a slowdown.  

If you don't like that solution, put all unnecessary units/groups in a very distant place, and create a script or trigger that will setpos the group to their desired location when needed.

UberKreb

[Artak]

I'm working on a mission which has only about 30 units on the map and the rest (about 120) are created with a script.

By doing so I am able to lower the lag in the begining of the mission.

Here's a thread about it. http://www.ofpec.com/yabbse/index.php?board=6;action=display;threadid=7763

So.. the answer to your question is it possible, is yes, it is possible.

[Sui]

Yes, it's very possible...

Though you have to understand that a unit doesn't use much CPU time if it's off screen, so the extra bit of 'performance' you might get using a createunit system isn't huge.

Having said that, it's still an improvement. I regularly use createunit to make enemies in my missions...
I did make a mission where whole towns of enemies/civilians were spawned using triggers based on player distance.

The biggest problem I had was the fact that you often get a slight 'pause' when createunit is used, especially if you're creating a lot of units.
The way I generally get around this is to create the units when the screen is blacked out (ie. at the start or end of a cutscene). However this isn't possible if the player is running across the island...

Bottom line: it can be done, but it has it's own problems. The advantages are debateable, as it doesn't give you that much difference in terms of performance (unless you plan on having about 400 units in a mission or something insane like that ;D)

[DuckHunter]

Thanks for the replies,

Sui, You have peaked my curiosity on the spawning of troops based on distance, and would like to know how and where you entered the info to make it happen?

I guess giving the idea of the mission at hand would probably better allow anyone to assist me.

This is a multiplayer special operation mission that I want to place various enemy units at different locations accross the entire map.  For example, air force units at air bases, army units at army bases, hidden chemical storage facilities, hidden POW camps , multiple towns that are held by enemy forces, and possibly assassinations of high ranking key personnel.

The players of these missions will know NOTHING about enemy forces on the map. They will be given a mission in which they have to use UAV's to identify the target and situation and then come up with a plan to perform that mission based on the equipment they have.

I know that missions like this will take alot of time, but the guys I play with will usually spend weekends playing.  And like I stated before, I believe this will give us a dynamic feel of being in a war.

If it works or not, I will let everyone know

Thanks,

DuckHunter Out

[Sui]

Hey Duckhunter...

Here's some extracts from my "Secrets for Sale" mission, in which I used the technique.
I ended up scrapping the mission, as it was a flawed concept... but you live and learn

Here's the code I was using to spawn the groups at one particular base:

Code: [Select]

#base1
b1flag = "flagcarrier" createvehicle (getpos base1)
b1flag setflagtexture "rus_vlajka.pac"
b1lite = "UAZ" createvehicle [(getpos b1hpad select 0) - 43, (getpos b1hpad select 1) + 1, 0]
b1lite setdir 090
"SoldierEB" createunit [getpos b1lite, newgrp,"b1liteman = this"]
[b1liteman] join grpnull
b1liteman moveindriver b1lite
"SoldierEG" createunit [(getpos (leader b1patrol1)), b1patrol1,"",0.85,"CORPORAL"]
"SoldierEG" createunit [(getpos (leader b1patrol1)), b1patrol1,"",0.85,"CORPORAL"]
? stolen: "SoldierEMG" createunit [(getpos (leader b1patrol1)), b1patrol1,"",0.85,"CORPORAL"]
? stolen: "SoldierEB" createunit [(getpos (leader b1patrol1)), b1patrol1,"",0.85,"CORPORAL"]
? stolen: "SoldierELAW" createunit [(getpos (leader b1patrol1)), b1patrol1,"",0.85,"PRIVATE"]
? stolen: "SoldierEMG" createunit [(getpos (leader b1patrol1)), b1patrol1,"",0.85,"PRIVATE"]
? stolen: "SoldierEB" createunit [(getpos (leader b1patrol1)), b1patrol1,"",0.85,"PRIVATE"]
? stolen: "SoldierEMedic" createunit [(getpos (leader b1patrol1)), b1patrol1,"",0.85,"PRIVATE"]
"SoldierEG" createunit [(getpos (leader b1patrol2)), b1patrol2,"",0.85,"CORPORAL"]
"SoldierEG" createunit [(getpos (leader b1patrol2)), b1patrol2,"",0.85,"CORPORAL"]
? stolen: "SoldierEMG" createunit [(getpos (leader b1patrol2)), b1patrol2,"",0.85,"CORPORAL"]
? stolen: "SoldierEB" createunit [(getpos (leader b1patrol2)), b1patrol2,"",0.85,"CORPORAL"]
? stolen: "SoldierELAW" createunit [(getpos (leader b1patrol2)), b1patrol2,"",0.85,"PRIVATE"]
? stolen: "SoldierEMG" createunit [(getpos (leader b1patrol2)), b1patrol2,"",0.85,"PRIVATE"]
? stolen: "SoldierEB" createunit [(getpos (leader b1patrol2)), b1patrol2,"",0.85,"PRIVATE"]
? stolen: "SoldierEMedic" createunit [(getpos (leader b1patrol2)), b1patrol2,"",0.85,"PRIVATE"]
@ aP1 distance base1 > 400
_group = b1patrol1
#b1deloop
~0.01
? (east countside units _group > 0): deletevehicle (units _group select 1)
? (east countside units _group) > 1: goto "b1deloop"
? _group == b1patrol1: _group = b1patrol2; goto "b1deloop"
deletevehicle b1flag
? not (vehicle aP1 == b1lite): deletevehicle b1lite
? (vehicle aP1 == b1lite): b1lite = uazzy
deletevehicle b1liteman
exit

The leaders of the groups (in this case: b1patrol1) already existed with patrolling waypoints. The advantage to this being I don't have to move them with a script, and if the player goes to the base and kills the leader, the men won't spawn back again the next time the player visits that base.

Anyway, I had any number of these sort of excerts, which I activated using named triggers (in this case: base1).

As I said, it worked, but the benefits were marginal when compared to the disadvantages (the pause when creating untis).
Also, I have no guarantee that this will function as advertised in a multiplayer mission...

[deaddog]

One thing helps reduce the slight freezeup when using the createunit command to create several units.

Place a group with the editor containing several units.
in the leaders init field:  mygroup=group this;{deletevehicle _x} foreach units mygroup

This creates a group and then deletes all the members.  The groupname (mygroup) can be used with the createunit command and there should be no lag.  I believe because resources have already been allocated.

I've had success with this.  

[Sui]

This creates a group and then deletes all the members.  The groupname (mygroup) can be used with the createunit command and there should be no lag.  I believe because resources have already been allocated.

Good tip, but surely this would defeat the whole purpose of using createunit in the first place?

The idea is to save on resources until you need them, and by allocating them at the start they are still getting used

[deaddog]

That's a good point.  I suppose the only benefit from this would be that the OFP engine doesn't have to check to see if these units are within the view distance and, therefore, should they be drawn.

To be honest, I've never really seen any speed improvements using this technique (or deleting dead bodies).  I do this to hopefully improve lag on slower computers.  Not sure if it works in that regard.  

[macguba]

If you have a slow comp like mine then everything helps.   I wrote this somewhere else, but it seems relevant here.  Anybody got anything to add to this list?

macguba's quick guide to reducing lag[/color][/size]

The main causes of lag (in no particular order) are:-


Aircraft and choppers  -  These are the ultimate lag demons.     Do you really need them?   Do you really need that many?   If you do, can they land somewhere while they are not needed?

Ground vehicles  -  Particularly if they are of many different types, since OFP has to run the movement characteristics of every type of vehicle in the mission.   Reduce the number of types so that there is less going on in the background.   Do you really need both BMPs and BMP2s?   Or both T72s and T80s?    Similarly weapon types etc.

Groups  -  The fewer the groups, the less the lag.   Additional soldiers are not too bad for lag, so if needs be you can make existing groups bigger.

Waypoints  -  Use as few as you can

Triggers  -  If several events can be traced back to one root cause, use just one trigger and do everything else in a script

Scripts  -  Ususally a good thing, since they reduce the need for triggers.   However, there are two places to be careful:  using @condition and fast loops.   Triggers check themselves every 0.5 seconds.   Do you really need your loop to run faster than that?

Irrelevant units/vehicles  -  We all like a bit of eye candy, but think about what you are doing.   A few well placed vehicles can make a camp look a lot busier than a lot of badly placed ones.   Use static or empty objects rather than AI units.

Units close by  -  The further away a unit is from the player, the less lag it will cause.     In other words have your A10s circling a long way off.

Cloudlets/particles  -  Be they ordinary fires or helicopter dust scripts.

Island choice  -  Desert Island (small) good, Nogova (big) bad.

[DrStrangelove]

@macgumba: great list, i'll remember these points !  

@Sui: i see your last point, but IMO it's the internal AI routines that lags opf games. It's a difference if you place 10 or 200 soldiers on your map, even without waypoints - every active soldier uses a little piece of the big cake we call 'free runtime resources' of the cpu.

It's definitely better to have only , say, 40 active soldiers and create the rest of the 200 with scripts when special events occur. However, it's annoying to have a 1 second lag when a soldier is spawned, that's why it's better to load / delete the appropiate models at mission start.

[Sui]

You're right, AI routines do use a little bit of runtime, but a tiny miniscule amount (provided they are off screen and not engaging any enemy forces).

I think it would use up just as much resources deleting units at the start then creating them, as it would just having them there the whole time...
The resources are allocated anyway... remember OFP was not originally designed with the deletevehicle command implemented. They don't get erased from memory

So, if you want to have 400 units, then deletevehicle/createunit is going to make a difference. If you're going to have 40 - 100 units, then it's not

Wait... hang on... Oh, you reckon if you load the models it reduces the CPU slowdown? No. This doesn't work unfortunately... you'll still get a jump even if all the models previously exist.
Deaddog was talking about pre-assigning resources for all the units you're going to create, in an effort to reduce the jitters when you createunit them

[deaddog]

Let's all go out and buy a new 3Ghz computer with 2G of RAM and really fast SCSI drives.  

What lag?  ;D

[DrStrangelove]

@Sui: Yes, i was talkin about creatunit issues as well. Sorry if i confused you somehow... i'll try a short version:


- know what types of units you'll want to create with 'createunit' during your mission
- place them in the editor, so their resources are loaded at mapstart
- DON'T DELETE them with 'deletevehicle' - it appears the resources don't get loaded at mapstart then
- use a dummygroup to create new units into, then let them join their appropiate groups after "this join grpnull" etc


I think that sums it up

[EDIT]
Ok, i made a little test because i heard so many reports and rumors lately about performance issues with 'createvehicle' that i can't remember what is right and what is wrong.

(i already edited my above list of sentences)

Try out my little test mission. Make a DIR under your /opflashpoint/users/<your_name>/ called Spawntest.intro and put the mission.sqm into it.

It shows how to create units during the mission without any lag. There's 1 east Soldier at mapstart with 'grp1=this' in the init line to provide an existing group to create units into. Plus all resources for an east Soldier are loaded, so no createunit-lag. After creation, all east Soldiers join grpNull.
A trigger counts how many enemies exist near you. When 10 east units are spawned, another trigger forces the mission to end. By changing values of the count trigger you can spawn more until you hit the OpF engine unit limit.

After watching the mission 1 time you can change things to test my above list:


- change the outside Soldier to another type, say, an Officer. You'll see that the 1st created Soldier is causing a lag because the "SoldierEB" resources need to be loaded first.
- or change the init line of the outside Soldier to "grp1=group this; deletevehicle this". That way the soldier is deleted right after mapstart. AMAZINGLY the 1st created soldier will still cause a lag. That shows (IMHO) that the engine is smart enough to see that even though the soldier exists, the player will never see him because he's deleted intime.

Hope this helps. Comments / Suggestions / Enhancements welcome.  

[Sui]

Yeah... it'll work when creating only one or two units

Try it with 20 or 30.

You'll get a huge jump. It doesn't work when creating the sort of number of units you'd need to populate a town or a defensive line...

OFP still has to get all those new AI routines online, which causes a nasty CPU slowdown spike

I've even tried putting 1 second delays between creating each unit, and you simply get smaller pauses, about 1 second apart

There's no simple answer... createunit may increase performance in a particular situation.

But unless the unit is going to be onscreen or engaging an enemy unit(s), it isn't going to be pulling much more resources than if it wasn't there at all.
In fact, I'm betting it would pull about the same resources as that are allocated to it right at the start of the mission (hence the deletevehicle on mission start theory doesn't really work).

Anyway, I use it in my missions (as I generally hide the pause using a fadein/fadeout during a cutscene). However I have doubts as to it's true effectiveness...
I believe in some situations it does more harm than good.

[macguba]

I've been beta testing LCD's new mission Operation Noname.    There is a createvehicle lag spike .... but there is also a little bit of lag afterwards, whereas there wasn't before.   In other words the whole createvehicle thing was effective in making the early part of the mission playable for me.   Sui is right that the odd unit offscreen makes very little difference, but on very slow comps like mine (benchmark 756) it does add up.

The bottom line is that the most effective anti-lag weapon is really good unit placement ... that way you need fewer units, and fewer units means less lag.

[DrStrangelove]

Createunit is definitely good for:

- missions where the players mustn't find the enemy just by hopping into a chopper and boosting all over the island until they find some red spots on the radar. Good for stealthy vietcong missions.

- reacting to the amount of units the player(s) has/have in their groups. Not to mention, reacting on the type of weapons they have.

- random encounters all over the island. (random= type of units created and command)

All things i try to add into my mission.

[Dinger]

CreateUnit is good for scaring up troops, for dynamic missions and so on.
I am going to disagree about some of the lag causes; or rather about the priorities of them.
yeah, lots of stuff onscreen will slow things down noticeably.
But proximity and AI have a noticeable effect.

When I was making "Short Straight", I had some issues with FPS.  Well, okay, the point of the mission was the helo insertion at the beginning, so I was willing to sacrifice a bunch of FPS provided nobody got shot.  But afterwards, I did want to have some fighting without the frame rate chunder of a dozen helos and three platoons of infantry.

It turns out that even stuff that was out of sight but in the general area caused a severe amount of lag.  Rather than createunit, I used bulk setpos with a savegame to hide the frame rate hit.
So when the leader of the player's group gets a certain distance away from the LZ, a script runs that indexes the position of the two squads (4 groups) securing the LZ, and setposes them to an island far, far away.
I have a single NVA squad that represents a counterattacking platoon.  WHen it gets to a certain distance from the LZ, or when it's triggered, I setpos in the whole platoon, along with the LZ force (with another savegame to hide the freeze)
That way, I get a counterattack late in the mission, when attrition has (hopefully) reduced the number of running and fighting AI units to a more manageable level, and it happens at logical moments in the mission (moving away from the LZ, returning to the LZ).
Oh yeah, and the helos don't have to land -- if they hover way out at sea, they have a minimal effect on FR.  And, the way helos land, it's probably safer that way anyway