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

Add more TF2 specific DMG_ definitions #756

Merged
merged 3 commits into from Jan 26, 2018

Conversation

@Pelipoika
Copy link
Contributor

Pelipoika commented Jan 25, 2018

No description provided.

@@ -74,6 +74,24 @@
#if !defined DMG_CRIT

This comment has been minimized.

Copy link
@asherkin

asherkin Jan 25, 2018

Member

You don’t want these inside this #if - you might want an #if for each one though (@psychonic?)

This comment has been minimized.

Copy link
@Pelipoika

Pelipoika Jan 25, 2018

Author Contributor

The DMG_ defines above are defined the same way

This comment has been minimized.

Copy link
@psychonic

psychonic Jan 25, 2018

Member

I agree with @asherkin

The ones above were done that way because there was a popular include at the time that had all of them in it copied from the SDK like ours were.

For the TF2 ones, it's very possible to run into plugins where users have manually defined one or more of these on their own due to us never having them. It doesn't hurt to guard them.

This comment has been minimized.

Copy link
@Pelipoika

Pelipoika Jan 25, 2018

Author Contributor

Done

@@ -76,6 +76,36 @@
#define DMG_CRIT DMG_ACID
#endif

#if !defined DMG_RADIUS_MAX
//No damage falloff

This comment has been minimized.

Copy link
@Headline

Headline Jan 26, 2018

Member

This is a nit, but by doing this we eat up lots of whitespace, perhaps we can move the comments inline?

#if !defined DMG_CRIT
	#define DMG_CRIT DMG_ACID /* TF2 crits and minicrits */
#endif

Perhaps even take away the whitespace between each #endif and #if, but I'm not sure if smdevs would like them slammed together that closely.
@asherkin ?

This comment has been minimized.

Copy link
@asherkin

asherkin Jan 26, 2018

Member

That's actually a good point - they need to be doccomments for the parser to pick them up correctly, and the sanest way to do that is inline using /**< comment here */ (the DMG_CRIT one should change as well).

I don't really care about the line count / whitespace.

@asherkin asherkin merged commit 8c61fdc into alliedmodders:master Jan 26, 2018
2 checks passed
2 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.