Spyder Addons

[spyderblack723 407]

Just check

heya, is it possible to set an init for  just the medics class?

 

I have setup a healbot that heals the team in combat and I would like the init to trigger when I recruit.

 

Thanks

In your init code, check if the type of spawned unit is of your preferred medic class and if so execute the script

[dogdoor 11]

Thanks for the quick reply Spyder.

 

at the moment I place:

dummy = [this, units (group this)] execVM "scripts\automedic.sqf";

 

in the AI init.

 

Not sure how to execute this via the recruitment option?

[spyderblack723 407]

Instead of this use _this, not sure if if I coded it to allow use of "this"

Basically just find the class name if the medic class that you commonly recruit, EDEN right-click context menu has an option copy unit class to clipboard.

Then just change your code to

If (typeOf _this == "medic class name in quotes here") then {

your medic code goes here;

};

If you need more help maybe I can do more once I'm back to my pc.

[dogdoor 11]

Thanks Spyder,

 

I am  not sure where to place the init code - normally I set this init on one of the ai in the team (non playable) however if this is called by the recruit script I am not sure how to apply it.

 

I do not want every ai medic to have this just the non playable ones in my team

[spyderblack723 407]

Thanks Spyder,

 

I am  not sure where to place the init code - normally I set this init on one of the ai in the team (non playable) however if this is called by the recruit script I am not sure how to apply it.

 

I do not want every ai medic to have this just the non playable ones in my team

 

You simply put it in the "Code" field of the recruitment module.

If (typeOf _this == "medic class name in quotes here") then {
    [_this, units (group _this)] execVM "scripts\automedic.sqf";
};

Of course you'll need to replace "medic class name in quotes here" with the classname of the medic that you commonly recruit. (Using the method in my last post to find the classname of the unit in the editor).

[dogdoor 11]

Legend!

 

Thanks, trying shortly.

 

And if I want to shortlist - other recruits I gather I just place the class names preferred in the whitelist list?

 

I am using UNSUNG and the UNSUNG_W (all west factions) is the only faction option that works - sub factions dont, so I plan to white list the units I want.

[dogdoor 11]

It worked!

 

This is excellent.

[spyderblack723 407]

Legend!

 

Thanks, trying shortly.

 

And if I want to shortlist - other recruits I gather I just place the class names preferred in the whitelist list?

 

I am using UNSUNG and the UNSUNG_W (all west factions) is the only faction option that works - sub factions dont, so I plan to white list the units I want.

 

Yep, and if you want to have several possible medic classes you can change your init code like so

 

if (typeOf _this in ["medicClass1","medicClass2","medicClass3"]) then {
    [_this, units (group _this)] execVM "scripts\automedic.sqf";
};

[spyderblack723 407]

Hey Spyder. I know you've ceased support for the mod, but I figured I'd just share for people using it that the Loadout Manager will not work for multiple items in the same mission anymore.

To repro: Sync a Loadout Manager module to an item in the editor. Place another Loadout Manager module down and sync it to another item. When you preview the mission, notice how the ability to access the manager only works on one item.

I used to be able to do this. Perhaps something has changed in your last update and I now can only use one module but should have it synced to multiple items instead?

Intentional?

I'll mess around and see if there's a way to have multiple loadout managers working again.

 

Figured this one out, you should be able to get around it by only using one module with multiple syncs. No promises, but I'm looking towards a possible recoding of the loadout module so it works without bugs like it did when first released.

[HeroesandvillainsOS 1504]

Ah I meant to report back on this!

Spyder, it works just fine when you place one module down and sync it to multiple objects. I really don't even know what gave me the original idea that 3 modules for 3 objects (etc) would be the best way to do it. :(

I mean, that's what I used to do and it used to work, but honestly, thinking about it now, it was a pretty dumb idea on my end.

I guess the only thing that's technically "different" now that I use one for multiple objects, is that only one object of the several synced objects gets the nifty OSD that says "Loadout Manager" when you walk close to and look at the item. In order to access that on the other objects, you need to pull up the mouse wheel options (only one will ever get the OSD).

But other than that, it works just like it always did except now I use less modules. I'm ok with that (it's much more efficient) but obviously I love the feature a lot and look forward to whatever improvements you plan on making.

[dingbat91 0]

Hey Spyder!

 

first thank you for these tools, makes it so much easier to add some basic things I enjoy to missions I want to play!

 

Secondly I was wondering if you (or anyone really) could help me with getting UAV Spawning to work. as to my knowledge it doesn't crew them, effectively making them null and void.

 

I've believe I've managed to get it so I can use unitIsUAV to check the summoned vehicle is actually a UAV, but attempting to use createVehicleCrew seems to throw an exception and I've no idea where to go from there...

[spyderblack723 407]

Hey Spyder!

 

first thank you for these tools, makes it so much easier to add some basic things I enjoy to missions I want to play!

 

Secondly I was wondering if you (or anyone really) could help me with getting UAV Spawning to work. as to my knowledge it doesn't crew them, effectively making them null and void.

 

I've believe I've managed to get it so I can use unitIsUAV to check the summoned vehicle is actually a UAV, but attempting to use createVehicleCrew seems to throw an exception and I've no idea where to go from there...

 

Thanks!

 

The following command might be useful to you

 

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

 

so possibly run

 

if (unitIsUAV _this) then {
    _success = player connectTerminalToUAV _this;
};

In the code field. Of course you'll need a UAV terminal in the assigned GPS slot of the unit you connect the UAV to.

[spyderblack723 407]

THIS IS NOT AN OFFICIAL RELEASE, PLEASE DON'T MIRROR

 

I've been rewriting the loadout manager over the past week. It seems to be very strong and bugfree (knock on wood) in SP. However, due to my internet situation I cannot test how it performs in MP. If anyone would like to help out and have an early look at the rewritten module, I would appreciate any feedback on how it performs and any bugs you might find, especially in MP.

 

Thanks!

 

https://www.dropbox.com/s/y5hsviv9ezhtcoi/SpyderAddons_TestVersion.zip?dl=0

 

Short explanation of a new feature - To create a server/mission side loadout or folder, simply select the preferred folder/loadout in the left list, click the export button, and then paste the code copied to your clipboard in your mission's init.sqf file.

[HeroesandvillainsOS 1504]

Nice UI! :) Me likey. It's also very snappy (the Virtual Arsenal opens almost the very second you click on the option). Optimization, baby!

 

I can't really test the server feature right now but I like the concept. Could you go into a bit more detail for the most practical way you'd invision mission makers using this? I'm assuming the server would run the script of available loadouts and clients wouldn't need the mod?

 

Any other features you'd like tested for either that module or any of the others?

[spyderblack723 407]

Nice UI! :) Me likey. It's also very snappy (the Virtual Arsenal opens almost the very second you click on the option). Optimization, baby!

 

I can't really test the server feature right now but I like the concept. Could you go into a bit more detail for the most practical way you'd invision mission makers using this? I'm assuming the server would run the script of available loadouts and clients wouldn't need the mod?

 

Any other features you'd like tested for either that module or any of the others?

 

That module is the only one that needs testing for now. Just use the module as you normally would and report any feedback or bugs. I'm thinking about giving some of the other modules the same treatment, but that's only an idea for now.

 

Server loadouts are simply loadouts that the mission maker would provide for the player's automatically. Clients would still need to run the mod.

You could maybe even provide server loadouts for the players to access and then shutoff the ability for players to create and save new loadouts (Would need to add that functionality).

Essentially this feature allows a mission maker to lessen the "setup" time and/or restrict players to certain loadouts while still allowing them to choose which they want to use.

 

(Your old loadouts should automatically be ported to the new data format upon the first time you open the menu, let me know if they do not).

 

Note: Menus can also be navigated in a more logical way (double click to open or load loadout, ..\ icon for easy access to parent folders)

[HeroesandvillainsOS 1504]

Awesome. :)

I also love the idea of where you're going with the script option for the loadout manager. In some of my releases, for instance, I've talked about transferring gear to AI and it's definitely easy for me to say when I've already spent time doing that on my own. Not so simple for a newcomer seeing as they'd have to make them from scratch. It would be a great benefit for players to have the mission maker make suggestions for them. Quicker into the action. That's a great idea!!!

Good job.

[Incontinentia 339]

Hi Spyder, just to let you know, the cfgPatches author change still causes errors when your modules are used in a mission (including latest versions). Think it's the cfgPatches files inside the module PBOs that's making Arma get all uppity. Will give the Loadout Manager a test soon! 

[HeroesandvillainsOS 1504]

Hi Spyder, just to let you know, the cfgPatches author change still causes errors when your modules are used in a mission (including latest versions). Think it's the cfgPatches files inside the module PBOs that's making Arma get all uppity. Will give the Loadout Manager a test soon!

What exactly are the kinds of problems you are seeing? Could you elaborate a bit please?

The only thing I've noticed is using the test version will delete your pre-saved loadouts if you revert back to the RC one. I'm actually ok with that but people should probably know in the event they don't want to lose them.

EDIT: Oh, I think you're talking about the author is not a value message. Yeah, that's caused by the civ interaction module. I just removed it from my missions but everything else seems fine.

[spyderblack723 407]

Hi Spyder, just to let you know, the cfgPatches author change still causes errors when your modules are used in a mission (including latest versions). Think it's the cfgPatches files inside the module PBOs that's making Arma get all uppity. Will give the Loadout Manager a test soon! 

 

It should just be the Civilian Interaction module, and that's only because the module is all broken and won't repack without becoming unusable. Every other module has been fixed.

[Incontinentia 339]

I hope you don't mind but I had a dig around and I'm not sure it has. In the ambience module you've got: 

class CfgPatches {
	class COMPONENT {
		units[] = {};
		weapons[] = {};
		requiredVersion = 1.60;
		requiredAddons[] = {"A3_Modules_F"};
		author = MOD_AUTHOR;
		authors[] = {"SpyderBlack723"};
	};
};

And should have: 

class CfgPatches {
	class COMPONENT {
		units[] = {};
		weapons[] = {};
		requiredVersion = 1.60;
		requiredAddons[] = {"A3_Modules_F"};
		author = MOD_AUTHOR;
		authors = "SpyderBlack723";
	};
};

This gets rid of the author/ errors in the editor I think. 

[spyderblack723 407]

I hope you don't mind but I had a dig around and I'm not sure it has. In the ambience module you've got: 

class CfgPatches {
	class COMPONENT {
		units[] = {};
		weapons[] = {};
		requiredVersion = 1.60;
		requiredAddons[] = {"A3_Modules_F"};
		author = MOD_AUTHOR;
		authors[] = {"SpyderBlack723"};
	};
};

And should have: 

class CfgPatches {
	class COMPONENT {
		units[] = {};
		weapons[] = {};
		requiredVersion = 1.60;
		requiredAddons[] = {"A3_Modules_F"};
		author = MOD_AUTHOR;
		authors = "SpyderBlack723";
	};
};

This gets rid of the author/ errors in the editor I think. 

 

That is how it is supposed to be. It was changed in (1.60?) so that authors is an array and author is a single string.

[BB_Frost 37]

Hey spyder - very cool set of addons. :)  The Loadout manager is especially spiffy for getting recruits equipped quickly.  Thanks for all this work and especially your work on ALiVE.

 

Regarding the vehicle spawner, anyone have any thoughts on how to avoid horrific explosions if the spawnpoint is currently occupied by the last vehicle spawned?

[tourist 617]

@hmarcbower: what's so difficult in simply driving away the previously spawned vehicle?  That works 10 out of 10 times for me... :D

[BB_Frost 37]

@hmarcbower: what's so difficult in simply driving away the previously spawned vehicle?  That works 10 out of 10 times for me... :D

 

That is also 100% successful for me :)  However, I was being clever and spawning the vehicle inside a closed hangar (thus it is out of sight when it appears), and this would likely get used in a MP environment (so perhaps the vehicle waiting on the spawn point isn't something the player using the spawner knows about).  

 

Best I've thought of so far is to open the pbo (for which I would seek permission) and add in an isFlatEmpty check and give the spawned unit a name (which incorporates the spawn marker name, perhaps, in the event of multiple spawn points / spawners).  Then I can create a trigger that moves an invisible, simulation disabled building over top of the spawn point when the vehicle spawns so that isFlatEmpty comes back false until the vehicle moves, when the trigger then moves the invisible building away (and relieves the unit of its name so it can be used by whatever next vehicle is spawned).

 

But that seems somehow inefficient, so I was hoping someone with a  better understanding of these things could help. :)

[spyderblack723 407]

Hey spyder - very cool set of addons. :)  The Loadout manager is especially spiffy for getting recruits equipped quickly.  Thanks for all this work and especially your work on ALiVE.

 

Regarding the vehicle spawner, anyone have any thoughts on how to avoid horrific explosions if the spawnpoint is currently occupied by the last vehicle spawned?

 

 

Hey spyder - very cool set of addons. :)  The Loadout manager is especially spiffy for getting recruits equipped quickly.  Thanks for all this work and especially your work on ALiVE.

 

Regarding the vehicle spawner, anyone have any thoughts on how to avoid horrific explosions if the spawnpoint is currently occupied by the last vehicle spawned?

 

 

That is also 100% successful for me :)  However, I was being clever and spawning the vehicle inside a closed hangar (thus it is out of sight when it appears), and this would likely get used in a MP environment (so perhaps the vehicle waiting on the spawn point isn't something the player using the spawner knows about).  

 

Best I've thought of so far is to open the pbo (for which I would seek permission) and add in an isFlatEmpty check and give the spawned unit a name (which incorporates the spawn marker name, perhaps, in the event of multiple spawn points / spawners).  Then I can create a trigger that moves an invisible, simulation disabled building over top of the spawn point when the vehicle spawns so that isFlatEmpty comes back false until the vehicle moves, when the trigger then moves the invisible building away (and relieves the unit of its name so it can be used by whatever next vehicle is spawned).

 

But that seems somehow inefficient, so I was hoping someone with a  better understanding of these things could help. :)

 

Thanks, glad you like the loadout manager. If you aren't using the test version already then you'll be happy to see a completely rewritten loadout manager for the next release.

 

Multiple spawnpoints is a good idea, never thought about that one. I think it would be pretty easy to implement as well. I can also try to implement a check that makes sure vehicles aren't spawned on existing vehicles. No promises on a quick release though, currently have my hands busy with other stuff.

 

Feel free to open the pbo  :)