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

[Major Cooke]

What specific compatibility concerns do you have? How does the akimbo weapon system work in DE4D?

In particular, crashes and stuff happening since projectiles like the SSG meat hook must not be modified via any external sources. To make it easier, just about everything is going to inherit from several base classes: DE_Actor, DE_Weapon and a few others so identification is easy.

The way Bonsai works is, all the upgrades are non-actor classes; they're matched up with weapons by actor pointer and secondarily by actor type (so they can be reassigned to a new weapon of the same type if the old vanishes, e.g. if the player drops it), but don't directly modify the weapons at all. They're all carried around in a single inventory item (TFLV_PerPlayerStats) that also holds the ModifyDamage handlers and some other bookkeeping stuff. Effects trigger on damage dealt/received or on kill and are triggered by ModifyDamage or by WorldThingDamaged events captured by a StaticEventHandler.

The main issues I've seen with other mods that have upgrade systems is when the upgrade is a different actor type than the base item -- e.g. DRLA's assembles or Ashes Afterglow's upgraded weapons are different actors, so they lose all the upgrades the original had. But it sounds like that's not how DE4D handles things.

Yeah, those are good ways to handle that, and indeed, DE4D will avoid using inventory items where possible because I've learned that greatly increases the tick processing on player classes when compounded. On top of that, avoiding death exit resets with upgrades is my #1 concern, which I had to introduce a massive hack in D4D (it's predecessor) that has to give all the upgrade inventory items again, but with this new way, it won't be needed since it's all maintained by a static event handler.

All that said, I think your idea of having an lump that other mods can provide that carries compatibility information is a great one -- Bonsai doesn't currently support anything like that but it would be a good idea, both as a way for other mods to non-intrusively add compatibility tweaks and as a way for Bonsai itself to easily contain a list of such tweaks for other mods. I don't think that'll make it into 0.8.4, but it's on my TODO list now.

Off the top of my head, features it should probably have include:
- disable all upgrades for a given weapon
- disable specific upgrades for a given weapon
- treat a list of different weapons as equivalent
- force a weapon to be treated as melee/hitscan/projectile, bypassing the normal detection mechanism
- globally disable certain upgrades if a given mod is detected (e.g. Juggler is incompatible with Hellrider, so just turn it off entirely if Hellrider is loaded)

Come to think of it, having a special Service class so it can gather all the information on what to blacklist would be easier than making a parser by far. It was invented for that very reason after all.

So if you create a ServiceIterator that searches for, say... "BonsaiBlacklist" named services, you could then iterate GetString until it returns an empty string and save the results. Or split it based on specific characters in a string.

So all the modder would have to do is something like this:

Code: Select all

Class DE_BonsaiBlacklistService : Service
{
	override String GetString(String request, String stringArg, int index, double doubleArg, Object objectArg)
	{
		if (request ~== "Weapons")
		{
			Switch(index)
			{
				Default:	return "";
				Case 0:		return "DE_AkimboSystem";
				Case 1:		return "DE_LegendaryShotgun";
				Case 2:		return "DE_LegendarySSG";
			}
		}
		return "";		
	}
}

Or if, say for example, we want to simply blacklist any class inheriting from a specific one:

Code: Select all

Class DE_BonsaiBlacklistService : Service
{
	override String GetString(String request, String stringArg, int index, double doubleArg, Object objectArg)
	{
		if (request ~== "Weapons")
		{
			return "DE_WeaponBase|parent";
		}
	}
}

in which your service iterator detects for classes that inherit from DE_WeaponBase after parsing the parent "flag" there and proceeds to blacklist all of them automatically.

In fact, the upgrade system in DE4D is utilizing service classes to define new upgrades similar to the idea above, but adapted a bit to also using the LANGUAGE file for easy definition and creation of upgrades.

I'm also looking forward to playing DE4D! I didn't really like Doom Eternal but my complaints were mostly about the level design, not the gun mechanics.

And I look forward to letting folks try it when the time is ripe!

[ToxicFrog]

Services might be easier to implement, but I like the idea of just being able to supply a BONSAIRC lump. It's easier for non-modders to write one to make ad hoc tweaks, too. And I find writing simple recursive descent parsers relaxing. Services definitely solve some other problems that I've been using netevents to solve until now, though, so I'm going to keep that in my toolbox for later.

Regardless of which one I go with, I'll make sure to add documentation (might pull the modding docs out of the README and into a separate file, they're getting a bit large) and mention it in here when it becomes available.

It does occur to me that my design is probably not death-exit-friendly -- the event handler handles initializing and dispatching but the actual upgrade objects are stored inside the PerPlayerStats in the player's inventory, so if the inventory goes away so do all their upgrades. On the plus side, this means I need no extra work to support save/load; it'd be more complicated if the SEH were the source of truth.

So far... I have completed back to saturn X in ultra violence (no fast monsters and coop monsters). It was relatively easy. There definitely were dicey moments because of LegenDoom giving me an unnecessary surprises every now and then. I also completed all maps before the O of destruction. Even that has been quite easy. This mod IS compatible with Colourfull Hell but... It's not a good time and because LegenDoom and CH somehow collide (mostly LegenDoom cancelling CH). Well, you can't run both of them.

Really good mod but I kind of need to let people know that the melee upgrades can make the game... A BIT too easy. Dark Harvest combined with shock inscription, shield and little bit of damage. LET'S just say that it is QUITE op. Dark Harvest for now is able to buff your health and armor up to 999 which honestly is a bit ridiculous. I went to do some rocket jumping because of it.

Dark Harvest got toned down significantly in 0.8.3 for that reason, it now caps at 120 + 20 for each additional level and restores less per kill. Swiftness and Shield are both also due for nerfs as well. The balance in this is very much a work in progress (and not something I have a lot of practice with), so I appreciate the feedback -- and I'm glad you're enjoying it!

[stainedofmind]

While we're on the subject of balance, I think the Submunitions upgrade needs a bit of nerfing, as I find I can just fire off a shot in a crowded room and just sit back and let the cascade of bouncy boomers do all the work for me. Not sure if the answer is to have the submunitions have a shorter lifespan, or if it would be better not to have enemies killed by them to in turn spawn more submunitions. Other then that, so far in the small test run I gave of this, I'm really enjoying this and look forward to playing more of it!

[ToxicFrog]

0.8.4 released! It's all bugfixes and balancing. Dark Harvest and Scavenge Blood/Steel should now be working properly again, for real. Swiftness also got a lot of work; it's less powerful now, but gets more powerful as you take more levels (which it didn't, previously), and also the music and sound don't stop when it activates.

Download it here or in the OP.

---

- Balance: Swiftness now grants 35 tics (+7 per additional level) per kill
- Balance: Swiftness cap is now the same as the initial grant, and increases by 5 tics per kill during a swiftness combo
- Balance: Submunitions no longer trigger more Submunitions on kill
- Fix: music and sound effects no longer stop when Swiftness triggers
- Fix: crash when using `bonsai-debug,w-up` incorrectly
- Fix: crash when using Elemental Blast or Elemental Wave and the target vanishes unexpectedly
- Fix: HP/AC caps for Scavenge and Dark Harvest are now based on the player's max health FOR REAL THIS TIME

[Major Cooke]

Services might be easier to implement, but I like the idea of just being able to supply a BONSAIRC lump. It's easier for non-modders to write one to make ad hoc tweaks, too. And I find writing simple recursive descent parsers relaxing. Services definitely solve some other problems that I've been using netevents to solve until now, though, so I'm going to keep that in my toolbox for later.

Regardless of which one I go with, I'll make sure to add documentation (might pull the modding docs out of the README and into a separate file, they're getting a bit large) and mention it in here when it becomes available.

You could do both!
I personally cannot stand dealing with parsers, just too much work for too little gain, but it's your mod. I still recommend one for modders who prefer to use Service though.

It does occur to me that my design is probably not death-exit-friendly -- the event handler handles initializing and dispatching but the actual upgrade objects are stored inside the PerPlayerStats in the player's inventory, so if the inventory goes away so do all their upgrades. On the plus side, this means I need no extra work to support save/load; it'd be more complicated if the SEH were the source of truth.

With either a thinker that has the STAT_STATIC and containing the info needed to maintain it all, or with a static event handler (the former is better if you don't need all those event triggers, but the latter is quicker to retrieve if you need to constantly check stuff, I think), you can solve the problem that way.

And technically speaking, if you simply check to see if the save/load is happening when the world changes with e.IsSaveGame (I think), you simply do nothing because the one in the savegame overrides the current handlers. That's easy. And at the same time you have the power to check if entering a hub map you were already on too. Being able to keep upgrades I feel is more important because getting screwed over by a death exit is just ugh. Feels like a waste of time. You spend so much time building up only to be instantly torn down back to square one - even if you're advancing further in the levels, it sucks going back when upgrades are involved, because it ruins the rhythm you had going and you feel sluggish.

[ToxicFrog]

And technically speaking, if you simply check to see if the save/load is happening when the world changes with e.IsSaveGame (I think), you simply do nothing because the one in the savegame overrides the current handlers. That's easy. And at the same time you have the power to check if entering a hub map you were already on too. Being able to keep upgrades I feel is more important because getting screwed over by a death exit is just ugh. Feels like a waste of time. You spend so much time building up only to be instantly torn down back to square one - even if you're advancing further in the levels, it sucks going back when upgrades are involved, because it ruins the rhythm you had going and you feel sluggish.

The issue is that -- if the documentation is to be believed, which I realize is not always the case -- StaticEventHandlers persist across level changes but are not written to save files, so if I want the upgrades to be save/load friendly I need to make sure to stash a copy of them inside the player and keep that copy up to date, even if all the actual work happens inside the StaticEventHandler (and when a game is loaded, overwrite the copy in the StaticEventHandler with the copy in the player). That hasn't been a priority for me because death exits seem to be pretty rare -- I don't recall ever playing a megawad that uses them. I should probably implement this at some point, though.

[ArcCaster32]

okay have some patience with me here, I am a bit of a dunce in some things, especially more advanced ZDL Stuff or etc. How do I Check Filenames and etc?

[Major Cooke]

The issue is that -- if the documentation is to be believed, which I realize is not always the case -- StaticEventHandlers persist across level changes but are not written to save files, so if I want the upgrades to be save/load friendly I need to make sure to stash a copy of them inside the player and keep that copy up to date, even if all the actual work happens inside the StaticEventHandler (and when a game is loaded, overwrite the copy in the StaticEventHandler with the copy in the player). That hasn't been a priority for me because death exits seem to be pretty rare -- I don't recall ever playing a megawad that uses them. I should probably implement this at some point, though.

That's fair, though here's the basic idea on how to handle it - at least this is what I recall doing to a degree.

You could store the info in a regular event handler instead of the player. It'd be better that way because player morphing happens in some mods (i.e. AEoD's demon morph, D4D's demon runes, etc), not sure if that has any effect on your current system or not. I've encountered rare glitches where I wasn't able to unmorph because of reasons because something fudged with the pointer or whatever.

Plus you get some more code security with an event handler, no risks with inventory being wiped out by force if some GZDoom mods do that, trying to ignore the UNCLEARABLE flag.

Then, when moving to an intermission, simply ensuring that a static handler always has a pointer to the class object should suffice. When the next map loads, provided it's not a save game, it can point the newly created regular handler to it. Same thing with loading a hub map where a handler already exists, simply replace the pointer to it to be safe.

For starting a new game, thankfully we have NewGame() and the ability to check if we're opening a save game. In those instances, it would be the opposite way - the static handler fetches from the current event handler.

That should cover everything, I think.

[ArcCaster32]

okay have some patience with me here, I am a bit of a dunce in some things, especially more advanced ZDL Stuff or etc. How do I Check Filenames and etc?

Nevermind I figured it out, My apologies for the extra posts indestructible is now showing it's menu and is being loaded properly. I am good now, again my apologies for being a bug.

[ToxicFrog]

That's fair, though here's the basic idea on how to handle it - at least this is what I recall doing to a degree.

[a bunch of useful info elided]

Thanks, that's very helpful!

While we're on the subject of balance, I think the Submunitions upgrade needs a bit of nerfing, as I find I can just fire off a shot in a crowded room and just sit back and let the cascade of bouncy boomers do all the work for me. Not sure if the answer is to have the submunitions have a shorter lifespan, or if it would be better not to have enemies killed by them to in turn spawn more submunitions. Other then that, so far in the small test run I gave of this, I'm really enjoying this and look forward to playing more of it!

I forgot to mention this in the release post, but submunitions weren't actually meant to be able to trigger recursively and this is fixed in 0.8.4, which should hopefully tone them down to sensible levels without making them useless.

[DarkkOne]

So, I've noticed while playing DRLA that barrel damage from some of the barrels triggers the damage effects from my gun. I don't know if it's something you're aware of, or if it's fixable (wouldn't surprise me if it's not, and it's hardly a big deal), but just wanted it mentioned here.

[ToxicFrog]

So, I've noticed while playing DRLA that barrel damage from some of the barrels triggers the damage effects from my gun. I don't know if it's something you're aware of, or if it's fixable (wouldn't surprise me if it's not, and it's hardly a big deal), but just wanted it mentioned here.

That's intentional -- Doom keeps track of the ultimate originator of damage, so if you fire a rocket that explodes against a wall that detonates a nearby barrel that liquefies an imp, it knows to credit you with that batch of imp chutney, and this will also proc Gun Bonsai effects.

The rules for triggering effects based on other effects (e.g. you shoot an enemy which dies and releases submunitions which hit another enemy) are more complicated and have some weird edge cases in them that, fortunately, don't come up much.

[stainedofmind]

I forgot to mention this in the release post, but submunitions weren't actually meant to be able to trigger recursively and this is fixed in 0.8.4, which should hopefully tone them down to sensible levels without making them useless.

I did see that in the changlelog, and I'm happy to say that it does feel a lot better now! Still VERY useful, especially in tight quarters with a lot of enemies (and a shotgun/explosive type weapon), but its not an unstoppable death machine anymore.

Small upgrade suggestion, though I also know from experience how much of a pain this might be, but an idea could be ammo capacity upgrades.

[ToxicFrog]

Small upgrade suggestion, though I also know from experience how much of a pain this might be, but an idea could be ammo capacity upgrades.

That's actually in the roadmap, and I have a bunch of notes on how to implement it; the main implementation difficulty will be making it work in a way that doesn't break existing backpack behaviours.

The main design difficulty is choosing how exactly it works. I have a few ideas, but no good sense of which one is best, and might have to just prototype them all and play around with them. Open questions:
- player or weapon upgrade?
- immediate effect (e.g. works the same as a backpack, but stacks with backpacks and with itself) or ongoing effect (e.g. lets you gradually earn capacity upgrades)?
- if the latter, what triggers it? Level-ups? Kills? One idea I've been kicking around is a player upgrade where finding more ammo that you don't have room for increases your carrying capacity for that ammo, but that might be tricky to implement.

[mamaluigisbagel]

Just discovered that from what I can tell, this mod does not work with FreeDoom. The HUD will still appear, but the weapons will not gain xp for killing enemies.