Config for new claymore mines

[Trexian]

As some may have noticed in various other threads, I am working on an update to Pingu's claymores.  His was a very effective implementation, but, for some insane reason, I think I can do it better.

Yeah, crazy, I know.

One issue I'm trying to overcome is the change from A1 to A2 with cfgAmmo and cfgWeapons and cfgMagazines all being separated out.

Ideally, I'd like to have the claymores simply as "mines" that are put, then have useractions kick in to allow the player to disarm/sight in/attach tripwire.  However, I've been unable to get the useractions to work.

I think I need a fired eventhandler, but am unsure whether to try to attach it to the base man, in which case every time he fires, it would be checked, or to attach it to the mine itself, so it is initiated when the mine is put.  However, I am unsure where to set up the eventhandler.  I can put the userActions for cfgVehicles for the editor placed version, but not for the player placed version.

Any assistance would be greatly appreciated.

[h-]

One way to overcome the player put mine problem could be:
Use the fired event (on the man obviously) to check whether the fired weapon was "put" and if it was do a nearestObject search for the claymore type and create for example a custom game logic (that has the useractions configged) on the position of the mine, or delete the mine and replace it with the editor placeable one.

The game logic idea would reguire some sort of "is claymore exploded/whatever" loop I guess..

[Trexian]

Ooooh - I *like* the idea of using the same editor placed one in an eh context.

Now, what is the effect of adding a fired eventhandler to the man class, and have the spawned script check if the weapon was the claymore?  I mean, does that delay anything.  I've been told that eh's have no CPU cycle overhead, but it is hard for me to really believe it.

[DMarkwick]

Can the fired event handler just be applied to whoever has a Claymore? In that case there'd be a minimum overhead.

And yeah - I have trouble believing about the EH zero overhead thing too I cannot help but imagine *all* the little EHs all adding up & befouling the engine

But, I guess it might be true. I mean, surely all the events are always being handled regardless? And that all you're doing is tagging on an extra conditional? In that case I would imagine that adding an EH to anything has no more overhead than adding a single "or" conditional to the end of all the others.

[h-]

I doubt it has any effect on performance, I mean that would basically render XEH useless if it had..

I haven't seen any pefromance issues with eventhandlers and I use them a lot, even with quite a lot of code directly in them in the config..

EDIT:
Besides, I would bet that if you'd see the actual engine code it is basically huge pile of eventhandlers itself..

[Trexian]

Hey - you have a quick example of a fired XEH?   Also, I saw an example of an XEH that allowed for respawn.  It referenced a respawnInit.sqf or somesuch, but I have no idea what might be in that script.

Or, since I'm attaching it to any man class, do I not need to worry about respawn?

[h-]

Sorry, I don't really have anything done with XEH since I haven't had any use for it myself yet..

But it shouldn't be too difficult, you need to put the Extended_Eventhandlers in the requiredAddons array

Code: [Select]

class CfgPatches
{
class BLAH_Blehbleh
     {
       units[] = {};
weapons[] = {};
requiredVersion = 1.0;
requiredAddons[] = {"Extended_EventHandlers"};
};

};
Then add, after the CfgPatches, something like:

Code: [Select]

class Extended_Fired_Eventhandlers
{
    class Man
    {
            fired = "_this execVM '\x\y\z\bleh.sqf'";
    };
};
Completely untested so don't know if that works..

I guess the respawn thing has something to do with the fact that when respawning into a new unit the init eventhandler is not run again so I guess that's important only if your init includes something that has to be run always when a unit "inits"..
I'm completely confused, and always have been by all the MP stuff, it's pure luck that I'm able to get anything to work in MP so can't really help on that front.  

[Trexian]

hehe

You and me both.

I absolutely appreciate your insight on this.  I decided to simplify much of what I was doing, and I realized that, as I tend to do sometimes, I was over-complicating things a bit.  I already had a user-action (from Pingu's implementation) for "place claymore" that spawned an object at the player's position.  It then ran the separate init from the editor placed one.  I realized that, functionally, that was what I needed for the "fired addaction."  Building on another piece of advice from you, I just spawn the same object, with the same init, as the editor-placed claymore.

Now, that presented a few other challenges, but I am slowly overcoming those, too.  (In the spirit of foreshadowing, I may be posting soon on some issues with vehicleVarName....)

Thanks, and I look forward to posting something here for betatesting, relatively soonishly.

[Trexian]

Got the prior stuff sorted, using basically a dummy array to make sure various other arrays use the same index for certain things.  (Yeah, I could probably use one master-array, but that seems like overkill.)

New issue - and apologies if I should start a new thread, but it still relates to the config.

I have the following addaction defined in the config:

Code: [Select]

class UserActions
{
class PlaceClaymore
{
displayName = "Place claymore";
onlyForPlayer = 1;
position = "this";
radius = 0.5;
condition = """ClaymorePrimary"" in (magazines player)";
statement = "[this] execVM ""\@JTD\addons\testing\JTD_placeClaymore.sqf"";";
//statement = "[this] execVM ""\JTD_mines\scripts\JTD_placeClaymore.sqf"";";
};
};

However, the really odd thing is that it only appears if I go prone.  Honestly, standing/kneeling the addaction doesn't show up - only if I lie down.

Any ideas?

Thanks,
T

[DeanosBeano]

 In arma2 Radius have become a little fickle , in some vehicles i cant get them to work until i give it 3.
  your lucky to get a  result with a radius of .05 to be honest.

  in anycase i would try 1 meter radius or even 2

 radius =1;  // increase to two then even 3 .

 and another tip incase you havent already come across this before , make sure the person activating the script is the person who has the action  attached , this can crash servers in mp if the effect of the script goes global in my experience.

 #  target: Object - the object which the action is assigned to
# caller: Object - the unit that activated the action

 so make sure the target and the caller are one and the same.

[Trexian]

Ah - excellent advice!

The MPness of this has yet to be tested, so I'm very glad for anything that averts tragedy!

Edit:

Just realized the _target/_caller check needs to happen AFTER the action is called.  Thanks.

[DeanosBeano]

 well to be honest in your case what i said may not be good advice .
 it all depends how your setting it all up .
 if the action is on the mine itself then what i said wont apply  but if your adding the action to a player that approaches a mine and then his team mate gets near him and activates the action added to the player ,its that what caused crashes in my case.

 confusing this BIS addon making thing huh .

on another note
 Have you thought about mine as class Thing

 this way you could put a geometry lod in there that isnt seen and checl either the pos of the mine or the direction , if it changes (due to collision) then boom !!.
 i gues one limitation would be IIRC geometry isnt  drawn if a player is not with 50M or so

 just an dea i htough of many times but no time to implement.
 

[Trexian]

Oooh... actually, that's a fascinating idea!  I need to change the class of it anyway (I'd borrowed "desk" from another project). 

On a related note, changing the radius to 1 requires the player to kneel, which is perfect!  Thanks for that.

Also, most of the addactions are attached to the mine itself.  But, there are some - like attaching a tripwire, sighting it in - which could cause issues if more than one person did it in MP.

In thinking about your idea, I think I may have already stumbled into it - or rather, Pingu did.  This isn't technically a weapon.  It isn't a "put" type mine, but an addaction for placing the claymore.  This does allow many more options in terms of the deployment - remote detonation or tripwire, etc.  Is that what you were thinking?

[DeanosBeano]

 I was thinking Tripwire in the main,
  you can model the geometry and even animate it like me and norrin do with the fast ropes, remembering that you dont have to have a little thin line as the geo you can have it .5 of a meter tall, this allows people who spot them to use the straddle over the wall anim to avoid the trip wire.
 There would be lots of ways to determine whether a person has tripped the wire i guess the best one will be the most MP friendly approach.

[Trexian]

Yeah, the tripwire is something that may require much work.  For the foreseeable future, there is no observable tripwire, just a trigger.  While somewhat unrealistic, I think it is an acceptable trade-off for the fact that if you happen to put the cursor over the claymore, you'll get the addactions for it.   Kinda a built-in mine detector.

Plus, I think the trigger will be most effective in MP environment.

[Trexian]

Need some help.

DMarkwick and I have been having significantly different experiences while trying to test the same package.  If at all possible, I'd like to get some input from others.

http://www.mediafire.com/file/yznq52qjymx/JTD_minesPreAlpha0225.7z

Please do not be surprised if it doesn't start, or if the mines don't explode.  Also, don't be surprised if they do.   I just need to sort out why he and I are having such different results.

This should include a test mission, other information in the readmes.

Thanks.

[DeanosBeano]

 i will give it a try mate,
 One question before i even open it, i dont suppose this relies on Extended eventhandlers does it ?
 If it does then  you may have different versions ?

[Trexian]

Hmmm... THAT, my friend is an interesting question.

I don't *think* it does, but I always *say* it does, just to get people used to it.

But, if it *does* and we have different versions, that could create all sorts of issues, right?

Here's the deal, though: I think we have a more fundamental issue.  It works fine on my machine, but he can't hardly get it going at all.  But, enough of it works - like the icons and models - that the configs are "there" but they can't find the right paths or something.

(Oh, and if you happen to open the configs - I apologize in advance.   They aren't pretty.)

[DeanosBeano]

 well i dont use the CBA , unfortunately  it recently became less of a
 Community Base Addon

and more of

 A Convoluted Effort   , if i may put it that way .
 anyway if its any use to ya i removed the dependency and i walked through the mine  i did it 3 times and reset the mission each time.

 1 i got explosion but it missed me
 2 i was killed outright
 3 i was maimed .

 very nice concept i like it.

[Trexian]

Whew.

So it works?

Anything in the rpt about looking for (and not finding) a \@JTD\addons\testing path?

WRT to the "miss" - if you run very near the front of the mine, you may be able to cross the trigger before the explosion.  Hopefully that was it, or I'll have to put in a special "TargetDeano" routine.

[DeanosBeano]

 yeah it works ,
 there are lots of reports  but only the expected ones because the mine.p3d is not binarised at errors , i suspect it will need a geometry lod when uo do binarise too .
 there are no bad paths though .
 
 

[Trexian]

Excellent.

And, we should compare notes someday on A Concerning Evolution of some projects.

Edit:
Hey Deano-

I noticed doing the mission, an rpt error of:

Addon jtd_mines (entry JTD_Claymore) not found in the list of active addons.
Addon jtd_mines (entry JTD_Claymore) not found in the list of active addons.

When... it clearly is.   I mean, it works and all!  Any idea what's causing that?

[Planck]

Probabaly needs a cfgPatches definition.


Planck

[DeanosBeano]

 hmm,
 many reasons for that but the main one is that you may have spawned a mine from a script and not placed one in the editor , thus when mission loads JTD_mies wont be in the list of active addons i guess.

 i didnt see it in my rpt i dont think but its been a while since i checked your mission.
apparently there is a new preload  activeaddons or something   but using this can override the active addons in the mission.sqm so its all a bit messy. 
 i am sure Kju has done something on this somewhere  maybe PM him or something.

 alternatively like Planck says you may have messed a Cfgpatches up somewhere.

   i presume JTD_Claymore  is a class of mine inside jtd_mines ?

 the only other reason for that is if   JTD_Claymore was a seperate addon and had   jtd_mines as a required addon .

 remember when Required addons is placed like so

 requiredAddons[] = {"CAData",

 its looking inside the cfg specificly for 

class CfgPatches
  {
 
    class CAData

 some people can make the mistake of  naming the pbo different and then placing required addon = name of pbo.

[Trexian]

Ah - I think the spawning thing is the right answer.

I have a cfgPatches section that references/establishes the JTD_Mines addon.  But, in the mission init, I spawn some mines, without having them editor placed.  Well, there are some editor placed, but with a modified probability of presence, so maybe that changes the dynamic.

Thanks guys!

BTW, will be posting the beta release soonishly.