Jebus - Just Editor Based Unit Spawning

[dreadpirate 173]

On ‎6‎/‎23‎/‎2017 at 0:58 PM, anfo said:

G'day Dread

 

I'm probably asking a bit too much here, but I have a CQB scenario which I would like to use Jebus to respawn live targets within. The area is just shoot house walls on a flat ground, however when the units respawn they "sometimes" spawn away from their wanted locations (outside facility). They are not grouped so formations are not affecting them, but they are spawning with disableai "move".

 

Is there anything that can be done to spawn exactly where they're required? Again, probably a big ask I know. As they say, don't ask, don't get! ;)

 

What you could do is something like:

0 = [this, "INIT=", "_proxyThis setPos [1000,2000,10], _proxyThis disableAI 'PATH' "] execVM "Jebus.sqf";

where [1000,2000,10] is copied over from the x, y and z coordinates in the editor.

 

Also, use disableAI 'PATH' rather than 'MOVE' because:

 

https://community.bistudio.com/wiki/disableAI

 

[anfo 118]

Thanks Dread, you've come through again

[thick1988 0]

Hey guys,

Just implemented this and it's working well. However, I keep getting an annoying popup message each time a group spawns in. The error is:

Error undefined variable in expression: jebus_fnc_enemyradius
File C:\Users\etc...\jebus.sqf, line 332

I've looked at line 332 in the file, and it is as so:
 

    while {[_tmpRespawnPos, _unitSide, _pauseRadius] call Jebus_fnc_enemyInRadius} do {
        if (_debug) then {systemChat "Enemies in pause radius. Waiting."};
        sleep 5;
    };

I'm not the best at scripting/coding, but I can't see any issues here. Similarly, looking at the function in the other file yields this:
 

Jebus_fnc_enemyInRadius =
{
    params [
        "_position"
        ,"_friendlySide"
        ,"_radius"
    ];
    
    private ["_returnValue"];

    _nearestEnemies = [];
    _nearestUnits = _position nearEntities [["Man","LandVehicle","Helicopter","Ship"], _radius];
    {
        if ( (side _x getFriend (_friendlySide)) < 0.6 && (side _x != CIVILIAN) ) then {
            _nearestEnemies = _nearestEnemies + [_x];
        }
    } forEach _nearestUnits;

    if (count _nearestEnemies > 0) then {
        _returnValue = true;
    } else {
        _returnValue = false;
    };

    _returnValue;
};

I haven't made any changes to the sqf files at all. It still spawns the units, but I'm getting this pop up each time. Anyone know why?

[dreadpirate 173]

@thick1988:

 

Do you have the following line in your init.sqf?

call compile preprocessFileLineNumbers "JebusInit.sqf";

Do you have JebusInit.sqf in your mission folder?

 

Those are the most likely causes for this error.

 

Hope this helps.....

[thick1988 0]

Hello dreadpirate,

Thank you for your response. I do have Jebusinit.sqf in my mission folder, but do not have the 'call compile' line in my init.sqf. I will be sure to add that, and then let you know what happens. Thanks!

[thick1988 0]

So, I actually did have that in my init.sqf. Also JebusInit.sqf is in my mission folder as well. However, and I realize my stupid mistake now, I had my init.sqf file saved as a txt but the file suffix was hidden. Thanks again for your prompt response!

[Cpt.Sloth 0]

Hey there, I´m using your script for a wave attack mission, but got a small problem.

Everything works for my infantery, that I init with this Line :

 

0 = [this, "DELAY=",[180,400],"DEBUG", "RESPAWNMARKERS=",["m1", "m2","m3", "m4","m5", "m6","m7", "m8","m9","m10"]]  execVM "Jebus.sqf";

But when I try the same with Vehicles, they always respawn at their editor location, not at the empty markers that I placed. This is the Init Line of the Group leading Vehicle:

0 = [this, "DELAY=",[5,15],"DEBUG", "RESPAWNMARKERS=",["m11"]]  execVM "Jebus.sqf";

Is random spawning not supported for vehicles or do I have to change something up to make it work with them?

[dreadpirate 173]

@Cpt.Sloth

 

People complained that multi-vehicle groups were a nightmare with JEBUS (collisions, running over infantry, etc.), so I made vehicles respawn at their editor positions only.

 

So, yes, currently RESPAWNMARKERS only works for infantry.

 

But, you're right, I should revisit this problem and find a way to spread out vehicle respawns so they can use RESPAWNMARKERS.....

[Rich_R 1087]

For whatever reason, the classic Murkspawn script is finally defunct truly making yours the easiest and lightest respawn script to use.

 

The various options certainly allow dynamic mission building and your ongoing support is greatly appreciated!

 

Thanks for this!

[anfo 118]

Hi Dread

 

Another curiosity for you

 

 

[anfo 118]

*This text just replaces a double post

[dreadpirate 173]

46 minutes ago, anfo said:

Hi Dread

 

Another curiosity for you

 

 

 

The frustrating part about this is that JEBUS already uses both setDir and setFormDir internally to try and get units facing where they should but to no avail.....

 

But, as usual, I have a sneaky workaround that has the desired effect:

 

1. Place a small object, like a can, in the direction you want the unit to face and give it a variable name (eg. can).
2. Go into Special States for the can, enable "Simple Object" and disable "Show Model" and "Enable Damage".
3. 0 = [this, "INIT=", "_proxyThis doWatch can"] execVM "Jebus.sqf";

Obviously this is a pain if you have tons of units but it works.

 

I also recall there being an Arma 2 script that made a unit scan a specified sector, say 45 to 135 degrees, I wonder if that still works in A3?

 

[anfo 118]

Do you have to prefix every different _proxyThis with it's own INIT=?

 

For instance:

0 = [this, "INIT=", "_proxyThis doWatch can", "INIT=", "_proxyThis setPos [X,Y,Z]"] execVM "Jebus.sqf"; 

And I think Guardpost is the script you might be thinking of from A2. I have used it in A3

 

Edit: Discovered the "INIT=" syntax, all good. doWatch also works well, thanks :)

[f2k sel 164]

You could move the dowatch to the jebus.sqf file and do away with the can.

 

//Spawn infantry //
    _tmpGroup = [_tmpRespawnPos, _unitSide, _infantryList] call BIS_fnc_spawnGroup;
    sleep 0.1;
    {      
          _x setdir _respawndir;
        _x dowatch  (_x modelToWorld [0,10,0]);
        _x setUnitLoadout (_infantryInventoryList select _forEachIndex);
        _x setSkill (_infantrySkillList select _forEachIndex);
        sleep 0.1;        
    } forEach (units _tmpGroup);
        (units _tmpGroup) joinSilent _newGroup;

It seems to work for me in simple test.

 

 

 

 

 

 

 

 

 

 

[dreadpirate 173]

41 minutes ago, f2k sel said:

You could move the dowatch to the jebus.sqf file and do away with the can.

 

//Spawn infantry //
    _tmpGroup = [_tmpRespawnPos, _unitSide, _infantryList] call BIS_fnc_spawnGroup;
    sleep 0.1;
    {      
          _x setdir _respawndir;
        _x dowatch  (_x modelToWorld [0,10,0]);
        _x setUnitLoadout (_infantryInventoryList select _forEachIndex);
        _x setSkill (_infantrySkillList select _forEachIndex);
        sleep 0.1;        
    } forEach (units _tmpGroup);
        (units _tmpGroup) joinSilent _newGroup;

It seems to work for me in simple test.

 

Interesting, but what happens to units that are supposed to head out on patrol? Will they continually turn to face that position?

[f2k sel 164]

Once they start moving it sees to default back to normal and looking North for the most part, it should be no different than using the can method at least.

If you need them to look a certain way at various waypoints then use setformdir in that waypoint.

 

 

 

 

[dreadpirate 173]

6 hours ago, f2k sel said:

Once they start moving it sees to default back to normal and looking North for the most part, it should be no different than using the can method at least.

If you need them to look a certain way at various waypoints then use setformdir in that waypoint.

I'll give it a try. Thanks for your input.

[anfo 118]

Hi Dread

 

Can I pick your brain again please mate?

Say recent enemy mortar fire have got all the AI in the immediate area spooked and unable or unwilling to follow waypoints etc. I was trying to introduce a "calm" spawned AI that would immediately be SAFE and would follow waypoints as set. It seems however that even after the mortars have fallen, the new spawned AI will "inherit" the mood of his fellow AI and be generally uncooperative and combat ready.

 

Any known way to overcome this?

[dreadpirate 173]

18 hours ago, anfo said:

Hi Dread

 

Can I pick your brain again please mate?

Say recent enemy mortar fire have got all the AI in the immediate area spooked and unable or unwilling to follow waypoints etc. I was trying to introduce a "calm" spawned AI that would immediately be SAFE and would follow waypoints as set. It seems however that even after the mortars have fallen, the new spawned AI will "inherit" the mood of his fellow AI and be generally uncooperative and combat ready.

 

Any known way to overcome this?

I've noticed this as well and it's strange because a group respawned by JEBUS is a completely new group and should have no prior knowledge. 

 

Are you running any AI scripts / mods? Maybe they are being alerted by other groups?

[anfo 118]

3 hours ago, dreadpirate said:

JEBUS is a completely new group and should have no prior knowledge.

 

Good information to know and I think yes, we're running VCOM so I guess I'll try it without that running. Thanks for the feedback :)

[anfo 118]

Hey Dread

 

If you were being paid for this I reckon I'm making you earn it! (and you're probably still not earning enough)

 

Another question or maybe a feasibility case. As you would imagine I try to limit FPS drops on the dedicated server wherever possible and it appears that spawning many enemy groups at once can contribute to performance loss.

 

Take for example I have 5 groups of enemies that are syncronised to one trigger. They all obviously spawn once the connected trigger fires and possibly impacts the server at that one moment. Of course I could put in 5 separate triggers with different countdowns, but I feel suddenly we have a messy editor situation with triggers lying on triggers.

 

What is the chance a new variable could be added called "START="? The objective of the the new start variable (or whatever it might end up being called), is to define the initial spawn delay of the unit or group. This is contrary to "DELAY="  which controls subsequent spawns if applicable to the unit. The hope is the load of spawning could be spread out with varying start values and hopefully reduce performance loss and help manage the editing process.

 

It's not the end of the world if this is an unreachable objective and I'm happy using (and continually learning) about Jebus and what it achieves for our clan games. 

 

Anfo

 

 

[dreadpirate 173]

On 22/07/2017 at 11:18 AM, anfo said:

Hey Dread

 

If you were being paid for this I reckon I'm making you earn it! (and you're probably still not earning enough)

 

Another question or maybe a feasibility case. As you would imagine I try to limit FPS drops on the dedicated server wherever possible and it appears that spawning many enemy groups at once can contribute to performance loss.

 

Take for example I have 5 groups of enemies that are syncronised to one trigger. They all obviously spawn once the connected trigger fires and possibly impacts the server at that one moment. Of course I could put in 5 separate triggers with different countdowns, but I feel suddenly we have a messy editor situation with triggers lying on triggers.

 

What is the chance a new variable could be added called "START="? The objective of the the new start variable (or whatever it might end up being called), is to define the initial spawn delay of the unit or group. This is contrary to "DELAY="  which controls subsequent spawns if applicable to the unit. The hope is the load of spawning could be spread out with varying start values and hopefully reduce performance loss and help manage the editing process.

 

It's not the end of the world if this is an unreachable objective and I'm happy using (and continually learning) about Jebus and what it achieves for our clan games. 

 

Anfo

 

 

Hi @anfo,

 

I will implement "START=" in the next version of JEBUS because I can see your point about server lag when multiple groups spawn at once.

 

I was hoping the next version would involve a comprehensive clean up of the code and implement some new features, but I may just make a quick release for now and work on more ambitious things when I have more time.

 

[anfo 118]

Hi Dread

 

What would you think if something in this code is preventing CACHE and REDUCE from working in MP?

waitUntil {!isNull player};
[] execVM "scripts\briefing.sqf";
[] execVM "scripts\aide_memoir.sqf";

In SP/Editor the AI will CACHE and/or REDUCE, but not in MP. All other parameters seem to work ok.

[dreadpirate 173]

On 16/08/2017 at 3:34 PM, anfo said:

Hi Dread

 

What would you think if something in this code is preventing CACHE and REDUCE from working in MP?

waitUntil {!isNull player};
[] execVM "scripts\briefing.sqf";
[] execVM "scripts\aide_memoir.sqf";

In SP/Editor the AI will CACHE and/or REDUCE, but not in MP. All other parameters seem to work ok.

 

Are we talking about a dedicated server here? Because "player" doesn't exist on a dedicated server, so that code will never execute.

 

I think something similar might be affecting CACHE and REDUCE. They both use the scripting command playableUnits. Maybe it doesn't work the same on dedicated as it does on a listen server (where I do all my testing)?

 

I might try switching it to allPlayers and see if it makes a difference

[anfo 118]

5 hours ago, dreadpirate said:

 

Are we talking about a dedicated server here?

 

Yes, I wasn't sure what else to use to allow JIP to see the briefing in map. When I remove that line, CACHE and REDUCE work.