[0.10.6] Gun Bonsai -- everything-compatible weapon upgrading

[SomethingWicked]

DoomThing445 wrote:
> I was thinking that maybe player upgrades could be separated from weapon
> upgrades, like being able to disable weapon upgrades altogether.
You could do that by commenting out the "#include" functions for each player upgrade in the zscript.txt file

l am not wholy sure if that'll just fuck up your mod or something, so make a backup

[Gourry]

I've noticed on mod with Project Brutality that combining a (high level also) chain lightning and swiftness makes the game lag a bit. It happens even when clearing the gore away. Haven't tried this issue with other game mods yet, but will report back.

Forgot to ask; does damage stack with bloodthirsty or no?

Edit: you can still get hurt by explosive death from enemy even under swiftness when walking through them.

[ToxicFrog]

DoomThing445 wrote:
> I was thinking that maybe player upgrades could be separated from weapon
> upgrades, like being able to disable weapon upgrades altogether.
You could do that by commenting out the "#include" functions for each player upgrade in the zscript.txt file

l am not wholy sure if that'll just fuck up your mod or something, so make a backup

The BONSAIRC lump is a better (and safer) way to turn off upgrades on an individual basis. Unfortunately it's not currently safe to disable all weapon upgrades, because if you do, the first time your weapon levels up it will generate an upgrade menu with 0 options and bad things will happen.

The easiest way to do this is probably to tidy up that code so that if there are no viable upgrades, it counts as a level up but does not open the menu or change any stats. That way if all the player upgrades are disabled you don't get a crash once you gain enough weapon levels, and if all weapon upgrades are disabled you can still gain weapon levels to unlock player upgrades. Then I can either add that as an option, or just ship two alternate BONSAIRCs that disable player upgrades or weapon upgrades.

I've noticed on mod with Project Brutality that combining a (high level also) chain lightning and swiftness makes the game lag a bit. It happens even when clearing the gore away. Haven't tried this issue with other game mods yet, but will report back.

Forgot to ask; does damage stack with bloodthirsty or no?

Edit: you can still get hurt by explosive death from enemy even under swiftness when walking through them.

- chain lightning uses a lot of particle effects and swiftness will keep them on screen for longer. There's an option in the bonsai settings screen to turn down particle effects, which may help.
- per-weapon damage bonus and Bloodthirsty per-player damage bonus stack multiplicatively.
- Swiftness just stops actors that aren't you, it doesn't make you invincible. You'll still take damage from explosions, walking into enemy projectiles, etc.

[Gourry]

Ok, I didn't know that. Thanks for letting me know.

[Linz]

Something odd I noticed playing this with Final Doomer: Enemies that drop ammo via Scavenge Lead don't show the proper pickup sprites, instead using vanilla Doom ones

[ToxicFrog]

Something odd I noticed playing this with Final Doomer: Enemies that drop ammo via Scavenge Lead don't show the proper pickup sprites, instead using vanilla Doom ones

I looked into this, and found a bunch of other, related bugs like SL never dropping ammo for the Final Doomer pistols.

Under the hood, there's some pretty gruesome stuff going on. The ammo actors each weapon is defined as using aren't the same as the ammo pickup actors you find in the world. Some of the weapon ammo actors don't have any sprites defined, which is why they don't drop at all. Others have sprites, but don't have the code used in the pickups to make sure they display the correct sprite for whatever character you're playing as. So it's dropping the correct ammo, but it looks wrong.

I could add a BONSAIRC rule to disable that upgrade when playing Final Doomer, but it does mostly work, and when it doesn't work it fails to work in a harmless way; it just looks wrong...

[DoomThing445]

Encountered a bug with Gearbox. If you have the weapon select active while freeze mode is on, upon swiftness' effect stopping while still in said menu it will unfreeze the world, and then exiting the menu will softlock the playthrough you were just having, forcing you to save load.

[ToxicFrog]

Encountered a bug with Gearbox. If you have the weapon select active while freeze mode is on, upon swiftness' effect stopping while still in said menu it will unfreeze the world, and then exiting the menu will softlock the playthrough you were just having, forcing you to save load.

Oh, I'm getting the weird bugs now. Sweet.

It looks like what happens is that, when you open the menu, Gearbox checks if the level is already frozen before freezing; then, when you close the menu, it returns the level to whatever frozenness state it had before you opened it. So the chain of events here:
- Swiftness freezes the level
- Gearbox remembers that the level is frozen, freezes it again, which is a no-op
- Swiftness timer is still running since it doesn't freeze with the rest of the level, and when it counts down to 0 the level unfreezes
- Gearbox then restores the level to its previous state of "frozen"
- RIP

The fix for this on my end is conceptually straightforward: don't tick Swiftness (or any other upgrades) while the player is frozen. Implementing this requires me to run around to all the stuff I have implemented as Powerups and fixing those, but it shouldn't be too hard. The surprising part is that apparently powerups keep ticking by default even when the player is frozen!

E: thinking about it, I think the actual fix is probably for Gearbox to change so that it stops the entire playsim when you open the wheel, the same way a menu does, but I don't know how viable that is and this should function as a workaround in the meantime.

[DoomThing445]

Encountered a bug with Gearbox. If you have the weapon select active while freeze mode is on, upon swiftness' effect stopping while still in said menu it will unfreeze the world, and then exiting the menu will softlock the playthrough you were just having, forcing you to save load.

Oh, I'm getting the weird bugs now. Sweet.

It looks like what happens is that, when you open the menu, Gearbox checks if the level is already frozen before freezing; then, when you close the menu, it returns the level to whatever frozenness state it had before you opened it. So the chain of events here:
- Swiftness freezes the level
- Gearbox remembers that the level is frozen, freezes it again, which is a no-op
- Swiftness timer is still running since it doesn't freeze with the rest of the level, and when it counts down to 0 the level unfreezes
- Gearbox then restores the level to its previous state of "frozen"
- RIP

The fix for this on my end is conceptually straightforward: don't tick Swiftness (or any other upgrades) while the player is frozen. Implementing this requires me to run around to all the stuff I have implemented as Powerups and fixing those, but it shouldn't be too hard. The surprising part is that apparently powerups keep ticking by default even when the player is frozen!

E: thinking about it, I think the actual fix is probably for Gearbox to change so that it stops the entire playsim when you open the wheel, the same way a menu does, but I don't know how viable that is and this should function as a workaround in the meantime.

I agree with Gearbox needing the playsim pause. This is because sometimes enemies from certain mods with Gearbox don't freeze, and the only surefire way to fix this would be with an actual freezing of the playsim.

Do you know any alternatives that actually freeze the playsim that I could use?

[UTNerd24]

This mod vaguely reminds me of an old mod called "Custom Gun" where mods could be applied to weapons. It feels like a proper sequel with the addition of player upgrades too. Might I suggest a vampric upgrade for weapons? Like, one hit = 1 hp. Not sure how you'd balance it in Rapid Fire weapons though. Looking forward to what the future holds for it!

[ToxicFrog]

There actually was an upgrade like that in early prototypes, but it turned out to be way overpowered no matter how I sliced it; it eventually got reworked into the Scavenge Blood player upgrade, which makes things a bit trickier by requiring you to actually run over and collect the health dropped by your kills.

I have occasionally toyed with the idea of adding more "supermastery" upgrades that are unlocked by completing multiple elemental trees, or "non-elemental" masteries that are unlocked by having a sufficiently high level weapon without ever taking an elemental upgrade; if I ever reintroduce per-weapon vampirism, it might make sense as one of those.

I agree with Gearbox needing the playsim pause. This is because sometimes enemies from certain mods with Gearbox don't freeze, and the only surefire way to fix this would be with an actual freezing of the playsim.

Do you know any alternatives that actually freeze the playsim that I could use?

Not off the top of my head. My half-baked-at-best idea is to do it the same way GB's level-up menu works -- have a custom menu class that overrides Init() to generate the menu contents on the fly. Then when you call Menu.SetMenu() to activate it, it generates the wheel on the fly based on the player's current inventory and, in singleplayer, stops the playsim.

The "generate the menu on the fly from a custom class" part is fairly straightforward, and Gun Bonsai does it in a few places (look in ca.ancilla.bonsai/menu/ for examples). The problems I foresee with this are:
- you'd need all custom menu drawing and input handling code. this probably already exists for the in-game wheel. Not sure how hard it would be to rework it as a custom menu renderer.
- since menu code runs outside the playsim, it would need to communicate back to it using netevents (the GB menus contain examples of this too) rather than just wiggling the playsim directly
- I don't know if the "pause the game when the menu opens" part is controllable, and I'm too tired right now to pry open gzdoom and find out. turns out this is controllable, set [fixed]menuactive = Menu.OnNoPause[/fixed] in your menu's Init().

There's probably an existing mod that demonstrates entirely-custom menus like this, but if so it's not ready to mind at the moment.

[Linz]

Are you gonna add even more upgrades in later updates out of curiousity?

[ToxicFrog]

Are you gonna add even more upgrades in later updates out of curiousity?

I'd like to, and I have a whole bunch of ideas for future upgrades in my notes, both my own and suggestions from people here and playtesters elsewhere.

The main obstacles are:
- they need to fit well with the rest of the mod;
- they need to be possible to implement—there are some cool ideas that I just can't make work without breaking compatibility with most mods, and GB's compatibility is one of its foundational design goals;
- and I need to have the time and energy to implement and test them.

A lot of cool ideas have foundered on the rocks of #2, and I've put them into the notebook in case someone, possibly future me, comes up with a way of implementing them. #3 is the biggest obstacle overall, though.

v0.11 is in the works, after taking a complete break from Doom for a while, but it's likely going to be a balance, bugfix, and internal cleanup change rather than adding new features; my big goal for it is to finally split the special Legendoom support into a separate mod, which should clean up the codebase some and open the doors to using the Legendoom power collection feature without GB.

[Netheritor]

I almost never play doom anymore. But may as well write something here, cause I like this mod.
First, and foremost; can you design incompatibility detector or something like that in the mod? Like... if the upgrade is somehow clash with some mods or doesn't found any string code, it will be given a warning symbol near the upgrade. Maybe it's more like, debug mode.

Now, upgrades idea; So, I'm a warframe player, may as well rip-off their upgrades.
1. Weapon swapping increase damage by x seconds. Players upgrade. The time is refreshed like power up.
2. Can you do spread shot? Like the one in skulltag? It's more like, add a copy of the weapon. Oh, it's also increase ammo usage.
3. Melee weapon shoot projectiles; Each hit has % to spawn short-range projectiles. Projectiles can pierce enemies, damage is up to you.
4. My previous upgrade idea; Killing enemies spawn a floating mine, mines will explode if detecting enemies within x radius or after x seconds. Damage is similar to killed enemies explode. Incompatible with each other.
5. Killing enemies give you protective shield, shield is surrounding your body (or just the front), you can shoot through the shield but enemies can't. Mechanics should be similar to revivication. So, enemy max health is your max shield; to gain another shield, you must deplete your shield first then kill another. Shield has damage reduction with each upgrade.
Note; Yeah, number 5 is tricky. Some gun may not shoot through the shield and instead just hitting the shield. My workaround is;
5.a. Don't give this upgrade to AoE weapon,
5.b. Give upgrade to hitscan or non AoE weapons OR if you can code something like fire rate detection (the gap between on button press and actual projectiles fired), higher number is no upgrade (it's usually charge weapon and mostly explosive), lower number means rapid-fire right?
5.c. The shield has 2 detection area, outer side and inner side. If inner side keeps getting hit, it will temporary disable the shield, until the weapons stop firing or fire button is released.
6. Later, it's already too long. My other idea is basically creating another (elemental) enhancement.

[mamaluigisbagel]

Been getting into and having fun with Raging Bull and noticed it seems to be another mod like Final Doomer Plus where HE Shots don't work. Just letting you know of the incompatibility.