MM8BDM v5 - Altfires and Charge weapons

[CutmanMike]

A long time ago we had a discussion on this forum about a feature that someone (maybe me?) was considering adding to the game, but it got pruned so I'd like to have it once again.

Charge weapons in this game (Atomic Fire, Proto Buster, Laser Buster etc) can fire their regular shots by mashing the Fire button (mouse1 by default). This can be used strategically to whittle down opponents with low health or finish someone off after a charge shot as hit them. However, I don't know about you but absolutely hate mashing my mouse button. Setting up an additional button or alias for this is not very intuitive either.

Here is my suggestion to fix this. Adding Altfires to charge weapons. When used it will simply fire the non-charge version repeatedly while held down.

I know a lot of people are against this, but I'd like to list some reasons why I think it's about time we added this feature:

Comfort. - The big reason. Mashing the mouse button is NOT comfortable in any kind of video game (especially my vertical mouse). It's bad for your wrist. We aren't going to save lives or anything with MM8BDM but if we can make playing the game more comfortable for players at little cost, we should consider it.
We aren't ever going to use Altfire for anything else in the core game. - Fact. I considered it at the very start of MM8BDM but we're never going to use altfires. Modders can still use them for anything they wish. Right now it's an optional feature that isn't getting used.
Players can achieve the same effect through aliases. - You can easily set up an alias to have the fire button mashed for you. This is not intuitive for players who aren't aware of aliases or know how to set them up however. Having the option through a keybind in the options (and possibly explained in game at some point) would be nice.

We will even make it so non-charge weapons fire their regular shot when pressing altfire so the button isn't completely dead when switching weapons.

I would like the community's consent before adding this though, in case I'm not seeing an important reason not to do this. Let me know what you think.

[BiscuitSlash]

As much as I love the whole "No Altfires in the core game" thing, those uncharged shots on chargeable weapons really need some love! I haven't done it enough because button mashing with a mouse feels really off.

Vote_Up for this new feature.

[Laggy Blazko]

However, I don't know about you but absolutely hate mashing my mouse button.

lol ur a casul

Actually, I don't see why not adding something like this. As long as I can still smash my button if I want to. =P
Vote_Up

[JaxOf7]

Glad we're on the same page of rapid firing by holding a button and being willing to modify vanilla weapon code
But I'm guessing your current methodology is this, which would cause quite a bit of code bloat:

(click to show/hide)

Code: [Select]

Every weapon

actor RollingCutterWep : MegaBuster 10056
...
Weapon.AmmoUse 4
weapon.ammotype "RollingCutterAmmo"
...
Fire:

->

actor RollingCutterWep : MegaBuster 10056
...
Weapon.AmmoUse 4
weapon.ammotype "RollingCutterAmmo"
weapon.ammotype2 "RollingCutterAmmo"
Weapon.AmmoUse2 4
...
Altfire:
Fire:

So I am making an alternate suggestion: http://www.best-ever.org/download?file=anotherturbobuttontest.pk3 (only atomic fire works)
Have the jump cancel script that checks your controls check for altfire/userbutton press, and then give/take a turbo toggle based on that.
And then just modify charge weapons like so

(click to show/hide)

Code: [Select]

TNT1 A 0 A_Refire

->

TNT1 A 0 A_JumpIfInventory("TurboToggle",1,2)
TNT1 A 0 A_Refire
TNT1 A 0

A change that affects just charge weapon coding, AND mods that already use altfire for their weapons can have players use the userbutton to utilize turbo as well.

[CutmanMike]

But I'm guessing your current methodology is this, which would cause quite a bit of code bloat

I believe all the weapons currently inherit a base weapon? Something like this should work:

Code: [Select]

Altfire:
Fire:
...
without having to edit every single weapon.

[JaxOf7]

That actually just does the BaseWeapon's Altfire on inherited weapons.

(click to show/hide)

Code: [Select]

WeaponA
...
AltFire:
Fire:
A_Log("A")
...

WeaponB : WeaponA
...
Fire:
A_Log("B")
...

Altfire with WeaponB results in "A"


You can indeed do this though

(click to show/hide)

Code: [Select]

WeaponA
...
AltFire:
TNT1 A 1 A_Jump(256,"Fire")
wait
...

WeaponB : WeaponA
...
Fire:
A_Log("B")
...

Altfire with WeaponB results in "B"


But that is prone to desync online...
And doesn't change the fact that you have to define weapon.ammotype2 and Weapon.AmmoUse2 for each weapon if you want A_JumpIfNoAmmo and A_FireCustomMissile(,0,1 to work.

[Russel]

If one was willing to wait for version 3.0 to make this change, simply employing the following flags on the base weapon would suffice:

+WEAPON.ALT_USES_BOTH - Altfire now makes use of Ammo1 and the defined Ammo2 [if any]
+WEAPON.ALT_AMMO_OPTIONAL - Ammo is no longer required to enter the Altfire state.


I'm personally not fond of your method because it's roundabout and takes up the user1 button.

[JaxOf7]

If one was willing to wait for version 3.0 to make this change, simply employing the following flags on the base weapon would suffice:

+WEAPON.ALT_USES_BOTH - Altfire now makes use of Ammo1 and the defined Ammo2 [if any]
+WEAPON.ALT_AMMO_OPTIONAL - Ammo is no longer required to enter the Altfire state.

Tested, you are completely correct.

Baseweapon would just need this

(click to show/hide)

Code: [Select]

actor baseweapon
...
+WEAPON.ALT_USES_BOTH
+WEAPON.ALT_AMMO_OPTIONAL
...
AltFire:
TNT1 A 1 A_Jump(256,"Fire")
wait


As for the altfire jump desync, it seems 3.0 actually fixes that. (Though I just remembered that desync issue could be sidestepped in current version with an inventory jump like so)

(click to show/hide)

Code: [Select]

AltFire:
TNT1 A 1 A_JumpIfInventory("BusterAmmo",1,"Fire")
wait


Welp, I'm satisfied. Altfire = rapid sounds good to me.
I'll just keep that turbo toggle code around for mods that decide they want to have a +user1 toggle rapid fire for main/alt.

[Superjustinbros]

Up-voted.

[Hallan Parva]

We will even make it so non-charge weapons fire their regular shot when pressing altfire so the button isn't completely dead when switching weapons.

upvoted entirely because of this
consistency and clarity saves lives

+support

[fortegigasgospel]

But then custom weapons. Sure like all of them have to be updated anyway, how much more work will that mean for them?

[Russel]

That depends entirely on if this is placed into 5a or whatever version we release to patch this game up for Zandronum 3.0.

If it goes in for v5a, that's +2 lines of code for each weapon:

Code: [Select]

weapon.ammotype2 "ammo"
weapon.ammouse2 ammousewhere the string "ammo" and the integer ammouse vary from weapon to weapon.


However, if this change is applied whenever we patch for Zandronum 3.0, all the new code would be placed on the actor BaseWeapon, which would handle all the functionality for us. This means that the only thing the people making their custom weapons need to bother with is inheriting from BaseWeapon instead of MegaBuster.

[GameAndWatcher]

Although it's technically not a charge weapon, could you guys also apply this to the Treble Boost? I'm sure there are situations where you wouldn't want to use the "boost" immediately.

[Gumballtoid]

That's not a bad idea, actually. Using altfire would just fire a single shot and not trigger flight, as though you were out of ammo.

[Russel]

I'm down for putting this into play, but I'd prefer to wait until Zandronum 3.0 to put it in if only because it wouldn't require as much on the side of creation and maintenance of custom weapon sets.

If it's required, I'll do it. Though I would rather not because it would set a new standard for the weapon bases that would look redundant and be nullified in a few versions incoming... it'd be work for me and potentially others to put in that would just become obsolete as soon as Zandro updates.


I want to see this in action, but I also don't want to update 80-someodd text files again, especially in a manner that would just get undone for another version incoming.