Jump to content
dreadpirate

Jebus - Just Editor Based Unit Spawning

Recommended Posts

What I have been doing so far is running a gear script on the units after they spawn.

See "redressAFRArmy.sqf" in the example mission.

I've also used Jona's Easy Redress Functions successfully.

 

But I can see how dressing the units in the editor is more intuitive and convenient for people.

 

It'll be in the next version.....

 

(I can't guarantee when that will be, however.....)

Awesome thanks for the response mate. Love using this script do to its simplicity!

Share this post


Link to post
Share on other sites

Saving unit loadouts turned out to be much less difficult than I was anticipating (thanks to some built-in BIS functions).....

 

Version 1.35

  • Fixed caching with hideObjectGlobal and enableSimulationGlobal
  • Editor loadouts are saved and restored on respawn

Download

  • Like 1

Share this post


Link to post
Share on other sites

 

Saving unit loadouts turned out to be much less difficult than I was anticipating (thanks to some built-in BIS functions).....

 

Version 1.35

  • Fixed caching with hideObjectGlobal and enableSimulationGlobal
  • Editor loadouts are saved and restored on respawn

Download

 

 

 

Fantastic work mate greatly appreciated.

  • Like 1

Share this post


Link to post
Share on other sites

So does this work as a replacement for GAIA's own respawn system which has been broken for some time?

Share this post


Link to post
Share on other sites

So does this work as a replacement for GAIA's own respawn system which has been broken for some time?

Short answer? Yes.

 

I started making JEBUS because GAIA's respawn lacked the ability to run a custom init string on respawning units.

 

It has grown a bit since then.....

Share this post


Link to post
Share on other sites

@dreadpirate

 

Found a bug:

 

on line 348 it reads:

case "STRING";

it should read:

case "STRING": {_tmpZone = _gaiaZone;}

​otherwise, if you put a STRING in for _gaiaParameter, it will do nothing because _tmpZone was never set.

Share this post


Link to post
Share on other sites

Can I make suggestion?

 

What about before line 154,


// Make sure unit is a unit and not a group)
if (typeName _unit == "GROUP") then { _unit = leader _unit; };

I can't tell you how many times I put the init in a group, and then realize it later, and then have go through each group to determine which group I did it to. This is especially easy mistake in the Eden editor. Didn't have this much trouble in the old editor.

  • Like 1

Share this post


Link to post
Share on other sites

@dreadpirate

 

Question?

 

Why don't you implement a feature that pauses spawner if player is nearby? I see you have a function for it, but its not implemented. Was it too resource heavy too be implemented?

 

Suggestion:

 

At the moment, JEBUS does not support static weapons. It will try and respawn the unit and a new vehicle, but there is good chance that the old static vehicle is still intact.

 

I have modified JEBUS to support static weapons (vehicles). Instead of posting my code, I have PM you a link to my code changes.

Share this post


Link to post
Share on other sites

@dreadpirate

 

Question?

 

Why don't you implement a feature that pauses spawner if player is nearby? I see you have a function for it, but its not implemented. Was it too resource heavy too be implemented?

 

Suggestion:

 

At the moment, JEBUS does not support static weapons. It will try and respawn the unit and a new vehicle, but there is good chance that the old static vehicle is still intact.

 

I have modified JEBUS to support static weapons (vehicles). Instead of posting my code, I have PM you a link to my code changes.

 

The function for detecting if a player is nearby is only used by the caching system at present, but you are right, it is immersion breaking to have friendly units spawning right on top of you. I'll take your suggestion on board for the next release.

 

Admittedly, static weapons weren't really in my thinking when developing JEBUS. But what you could do is: Have an empty static weapon, create a gunner unit running JEBUS, give the gunner a GET IN NEAREST waypoint next to the static weapon.

 

I noticed a few spawning issues while testing JEBUS today, I'm hoping they can be fixed with just a few sleep commands.....

Share this post


Link to post
Share on other sites

@dreadpirate

 

Found a bug:

 

on line 348 it reads:

case "STRING";

it should read:

case "STRING": {_tmpZone = _gaiaZone;}

​otherwise, if you put a STRING in for _gaiaParameter, it will do nothing because _tmpZone was never set.

 

Actually, I can just delete that line and it will use the default, which is the same thing.

 

I must've read the switch documentation wrong.....

 

Can I make suggestion?

 

What about before line 154,


// Make sure unit is a unit and not a group)
if (typeName _unit == "GROUP") then { _unit = leader _unit; };

I can't tell you how many times I put the init in a group, and then realize it later, and then have go through each group to determine which group I did it to. This is especially easy mistake in the Eden editor. Didn't have this much trouble in the old editor.

 

Great suggestion, I've done the same thing myself a couple of times under Eden. Consider it done.....

Share this post


Link to post
Share on other sites
Admittedly, static weapons weren't really in my thinking when developing JEBUS. But what you could do is: Have an empty static weapon, create a gunner unit running JEBUS, give the gunner a GET IN NEAREST waypoint next to the static weapon.

 

 

Yeah, what you described works, but there are ups and downs to both methods. With my method, the vehicle is considered part of the unit therefore, if you kill the static gunner and the gun, they will respawn together. Think of a guard at a base. With the method you describe, if the static gun gets destroyed that poor gunner will have no gun  :( when he respawns. The downside with my method is that because the original unit gets deleted and a new one gets created in its place, there is chance it will not be placed down in the exact same spot. So if you put a dude with a static mg on a tower, well when he respawns there is a chance he might fall off  :o (although it hilarious because of the way Arma treats static gunners).

 

Yin and yang right? At least now, the script supports static weapons. Whether you want to use that functionality or not I guess depends on the mission makers circumstances. He can do it the way you described or maybe he wants the static weapon to respawn with the unit.

 

I noticed a few spawning issues while testing JEBUS today, I'm hoping they can be fixed with just a few sleep commands.....

 

 

I haven't noticed anything yet. Everything seems to be working okay on my machine. I am on the DEV branch though so that might make a difference.

Share this post


Link to post
Share on other sites

What I have been doing so far is running a gear script on the units after they spawn.

See "redressAFRArmy.sqf" in the example mission.

I've also used Jona's Easy Redress Functions successfully.

 

But I can see how dressing the units in the editor is more intuitive and convenient for people.

 

It'll be in the next version.....

 

(I can't guarantee when that will be, however.....)

 

Ohhh PLEASE PLEASE TRY to do this plese Heheeh its will be wondefull

 

Waiting for this hope u can do this.

 

Thanks for jebus is great

Share this post


Link to post
Share on other sites

Ohhh PLEASE PLEASE TRY to do this plese Heheeh its will be wondefull

 

Waiting for this hope u can do this.

 

Thanks for jebus is great

 

Already done! :-)

 

v1.35 saves the editor loadout and restores it on respawn.....

 

I'm just working on ironing out a few bugs before releasing 1.36

Share this post


Link to post
Share on other sites

Hi dreadpirate

 

Your reply to an earlier post of mine lead me to your script, namely because I was thrilled with your example mission demonstrating different options. Do you however have a solution to putting AI on different levels of a building and having them cache in their pre-placed positions?

Share this post


Link to post
Share on other sites

Hi dreadpirate

 

Your reply to an earlier post of mine lead me to your script, namely because I was thrilled with your example mission demonstrating different options. Do you however have a solution to putting AI on different levels of a building and having them cache in their pre-placed positions?

 

Negative. I've been using GAIA's FORTIFY option for creating CQB situations.

Share this post


Link to post
Share on other sites

Negative. I've been using GAIA's FORTIFY option for creating CQB situations.

 

Roger, thanks mate

Share this post


Link to post
Share on other sites

Hi dreadpirate

 

Can I get your advice from someone who only posseses a basic understanding of code in general

I'd like to spawn AI very simply, where we (Blufor) activate a trigger, the AI spawns and is killed never to return.

Is the application of the following code workable?

0 = [this, "LIVES=", [1,1]] execVM "Jebus.sqf";

I deduced by putting [1,1] I offer the AI only 1 life. Also is the "GAIA" folder used in the mission folder only when "GAIA_MOVE" or "GAIA_FOLLOW" or "GAIA_FORTIFY" codes are used?

Share this post


Link to post
Share on other sites

Hi dreadpirate

 

Can I get your advice from someone who only posseses a basic understanding of code in general

I'd like to spawn AI very simply, where we (Blufor) activate a trigger, the AI spawns and is killed never to return.

Is the application of the following code workable?

0 = [this, "LIVES=", [1,1]] execVM "Jebus.sqf";

I deduced by putting [1,1] I offer the AI only 1 life. Also is the "GAIA" folder used in the mission folder only when "GAIA_MOVE" or "GAIA_FOLLOW" or "GAIA_FORTIFY" codes are used?

 

"LIVES=" can be either an array as you have in your example or a number as in:​

0 = [this, "LIVES=", 1] execVM "Jebus.sqf";

Both will produce the same outcome, the group will spawn once when the trigger is activated and never respawn.

 

If you don't use any GAIA codes with JEBUS, you can safely delete the GAIA folder, but you will also need to remove the GAIA initialisations from the init.sqf file.

 

Everything from the line:

// Change the following numbers to your liking

to the end of the file.....

Share this post


Link to post
Share on other sites

Thanks DreadPirate for your reply

Share this post


Link to post
Share on other sites

Hi again

 

You can see I'm right into your script, but am observing something funky going on. I've placed down 1 x 8 man squad of RHS Russian troops and have

0 = [this, "LIVES=", 1] execVM "Jebus.sqf";

...in the group leaders init. Everything was fine early as the triggered fired, they spawned and I killed them. All good and I'm happy.

 

However... further into editing task, I come back to test the very same group, which will despawn on initialisation as designed, but then wouldn't spawn when the trigger fired. So I put down more four man squads to test along side using same init code and one of the following will occur:

  • 8 man squad won't spawn on trigger, but 4 man squad will
  • Three 4 man squads all linked to same trigger, using same code (maybe LIVES changed to 2). Result: 2 squads spawn, 1 doesn't.

Has this been observed? I must admit we are using mods, but I'm wondering why it would work initially then degrade to the point where it goes wonky?

 

Later edit: I now believe it is the RHS AFRF units I am using, and the fact that I'm still using a slightly older RHS.

Share this post


Link to post
Share on other sites

Hi again

 

You can see I'm right into your script, but am observing something funky going on. I've placed down 1 x 8 man squad of RHS Russian troops and have

0 = [this, "LIVES=", 1] execVM "Jebus.sqf";

...in the group leaders init. Everything was fine early as the triggered fired, they spawned and I killed them. All good and I'm happy.

 

However... further into editing task, I come back to test the very same group, which will despawn on initialisation as designed, but then wouldn't spawn when the trigger fired. So I put down more four man squads to test along side using same init code and one of the following will occur:

  • 8 man squad won't spawn on trigger, but 4 man squad will
  • Three 4 man squads all linked to same trigger, using same code (maybe LIVES changed to 2). Result: 2 squads spawn, 1 doesn't.

Has this been observed? I must admit we are using mods, but I'm wondering why it would work initially then degrade to the point where it goes wonky?

 

Later edit: I now believe it is the RHS AFRF units I am using, and the fact that I'm still using a slightly older RHS.

 

I can't see anything wrong with what you've done. Mod units shouldn't be a problem.

 

Try: 0 = [this, "LIVES=, 1, "DEBUG] execVM "Jebus.sqf";

 

and see what it says.....

Share this post


Link to post
Share on other sites

I can't see anything wrong with what you've done. Mod units shouldn't be a problem.

 

Try: 0 = [this, "LIVES=, 1, "DEBUG] execVM "Jebus.sqf";

 

and see what it says.....

 

Awesome Dread, will try

 

Later: "Enemy in pause radius, waiting."

I think I can work this one out! ;) So if I'm testing too close to where the enemy are meant to spawn, how far out should I (or a trigger) be?

 

Later again: All good, found the parameters in the Jebus.sqf file. Even several posts about it above as a suggestion :P. It's funny what you overlook until its relevant to you.

  • Like 1

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×