Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Various explosives enhancements #3151

Merged
merged 22 commits into from
Feb 4, 2016
Merged

Conversation

VKing6
Copy link
Member

@VKing6 VKing6 commented Jan 13, 2016

If I had known I'd be making this many changes to explosives, I would have made a single branch for it, I swear.

This PR currently does these things:

  • Adds the function fnc_connectExplosive to add an editor placed explosive to a player's detonator.
  • Adds editor placeable variants of SLAM (bottom attack) and IED (pressure plate)
  • Reduces small IED pressure plate trigger distance
  • Renames all of the custom classes to use the ACE_ prefix

Plus a bunch of other random stuff.

To possibly look at in the future:

  • Eden editor eventhandlers for connecting to players.

@VKing6 VKing6 added kind/enhancement Release Notes: **IMPROVED:** config labels Jan 13, 2016
@VKing6 VKing6 self-assigned this Jan 13, 2016
@VKing6 VKing6 added this to the 3.5.0 milestone Jan 13, 2016
@VKing6
Copy link
Member Author

VKing6 commented Jan 13, 2016

Current problems is that the zeus modules plain don't work. No idea why.
Also the editor placed bottom attack SLAM should ideally be lying down.

author = ECSTRING(common,aceteam);
ammo = "ACE_SLAMDirectionalMine_Magnetic_Ammo";
displayName = CSTRING(Module_SLAMBottomAttack_DisplayName);
// TODO: Find a way to place the mine laying down instead of standing up
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would need to be scripted, does extended eventhandlers work on this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't appear to, nor does the regular eventhandlers work as far as I can tell.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kymckay
Copy link
Member

kymckay commented Jan 13, 2016

Renames all of the custom classes to use the ACE_ prefix

If you're renaming classes it might be worth switching to using GVAR while it's still viable to change classnames without causing issues

@VKing6
Copy link
Member Author

VKing6 commented Jan 13, 2016

Do you mean for anything specific?
I didn't notice anything that wasn't inside a class ACE_ subclass that didn't use GVAR.

@kymckay
Copy link
Member

kymckay commented Jan 13, 2016

I meant like this.

I don't actually think it's a standard now that I've looked at some other stuff, but it's kind of nice since it makes the classnames self documenting

@nicolasbadano
Copy link
Contributor

I don't actually think it's a standard now that I've looked at some other stuff, but it's kind of nice since it makes the classnames self documenting

To be honest I prefer ACE_SLAMDirectionalMine_Timer_Ammo to ACE_Explosives_SLAMDirectionalMine_Timer_Ammo. Adding the module name to variables is meant mainly to avoid namespace collision, which is unlikely on class names.

@VKing6
Copy link
Member Author

VKing6 commented Jan 13, 2016

I don't mind changing the module name to GVAR(Module), but will that have consequences for missions where the module exists?

@jonpas
Copy link
Member

jonpas commented Jan 13, 2016

Yes it would be backwards incompatible.

@kymckay
Copy link
Member

kymckay commented Jan 13, 2016

Nah, don't worry about the naming convention, I was under the impression that was our standard.

Any classname that is renamed is backwards incompatible though.

@VKing6
Copy link
Member Author

VKing6 commented Jan 14, 2016

I didn't notice anything that wasn't inside a class ACE_ subclass that didn't use GVAR.

This was a dirty, dirty lie, and I've fixed all of them now.

Also added fnc_connectExplosive.

@VKing6 VKing6 added the kind/cleanup Release Notes: **CHANGED:** label Jan 14, 2016
GVAR(defuseObjectPosition[]) = {0, 0, 0.038};
soundActivation[] = {"", 0, 0, 0};
soundDeactivation[] = {"", 0, 0, 0};
};
//class ClaymoreDirectionalMine_Remote_Ammo_Scripted: ClaymoreDirectionalMine_Remote_Ammo;
class ClaymoreDirectionalMine_Remote_Ammo_Scripted: ClaymoreDirectionalMine_Remote_Ammo {
GVAR(magazine) = "ClaymoreDirectionalMine_Remote_Mag";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this necessary, won't it be inherited from the parent?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes, you're right. I added that because I thought there was something that didn't work properly. Turns out it was the wrong config in getConfig ... -.-

Not removing them as it can be useful to have a reminder that those classes exist.
@VKing6
Copy link
Member Author

VKing6 commented Jan 15, 2016

Confirmed that this also works for AI with the dead man's switch. Evil mission makers take note.

thojkooi added a commit that referenced this pull request Feb 4, 2016
@thojkooi thojkooi merged commit 8c9523e into master Feb 4, 2016
@thojkooi thojkooi deleted the explosives_cleanup_plus_minetriggers branch February 4, 2016 18:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/cleanup Release Notes: **CHANGED:** kind/enhancement Release Notes: **IMPROVED:**
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants