Spawn loot drops (placeholder)

[AcadiusLost]

found this in the wiki:

To disable the loot system, set the ACR_LOOT_DISABLE local integer variable on the creature to a value of 1. If you want to modify the amount of loot droped, set the ACR_LOOT_CR_MOD local float variable to the desired value. This alters the creature's CR for the purposes of calculating loot drops (whether it is positive or negative). Setting it to 1.0 would produce loot as if the creature had a CR of 1 higher than it does, and setting it to -1.0 would produce the opposite effect, loot as if the creature was 1 CR point lower.

But I also see this in standards:

The total drop value will be subject to an overall multiplier depending on creature type: 0, 1, 2.

The basic formula for calculating the value of the loot drop is:

CM * p ( ( n * CR ) - Eq )

CM - creature multiplier (0, 1, or 2)
p - random variable (0.01 - 1.00)
n - GP value
CR - challenge rating
Eq - dropped equipment value

It seems we've got a fundamental difference here- should the blueprint factor be additive/subtractive at the level of CR, or a bulk total multiplication? The former seems more nuanced and a finer level of control, but potentially also more arbitrary and less distinctive. (when a drop is doubled, it's going to tend to be noticeable- a CR+1.5 level drop isn't going to be, so much). I can implement either way (or both ways)- we just need to make a call on it.

The random value "p" in the equation above is also a matter of some debate in the thread- I've found a usable formula for generating a Normal distribution with a given mean and standard deviation from a flat random range, so I'll plug that into the code- but assuming we go with a mean of 1, how large a standard deviation are we looking for? 0.3, 0.5?

Finally, I don't see a resolution on a good value for "n"- which kind of serves as the "anchor" for the whole system. Alara suggests 5 as an opening bid, but that's about all I see on the matter. I can code around 5 .0 for now, and make it a named constant so we can tweak as we go if necessary.

Input? I can take and repost things from Standards Folks who may not have post access here via PM if that helps- but since I can't post over there, maybe we can hold the "implementation" part of that discussion over on this side of the fence.

Disclaimer: At this point, I'm going to have the function generate gp of the drop value- I think someone dubbed it the ATM-style rewards system. Later this number can be used to draw from loot tables and such, but for now we're going for a first-pass run to get something in place for early Beta.

[AcadiusLost]

Got this coded, though it will need testing. One point of uncertainty from my perspective is when we should be doing the subtraction of droppable wealth value- Rusty's version has it before randomization and before the multiplier factors in- which means droppable gear of any meaningful value will run the risk of pushing things into the negatives before we consider whether it's a loot-heavy sort of a mob or not. Intuitively, it seems to me this subtraction should be the final step, with a 0 being passed in place of a negative that could otherwise confuse things.

But, I'm interested to hear any arguments for why it's better nested down by the CR and anchor. Since there seemed to also be some debate as to whether we should even be performing the subtraction, it's just a comment in my code for now, "To be completed" once things are clarified.

[indio]

I'm ready to test when you want to get this started.

[Rusty]

So, hesistantly, I suggest we proceed along the lines of a CR:GP randomised lognormal deviating drop value, excluding all monster gear except ammunition...

We can't include total monster gear drops without wasting hours trying to balance stores and monster equipment or breaking the reward system.

[AcadiusLost]

Allright... so no need to work gear drop compensation into the formula just yet. Are all our ABR creature blueprints set to drop nothing, or is that something the builders themselves are going to have to handle?

Do we need to go so far as to destroy a spawn's kit when it dies? I could potentially write a function for this, but it might be extra processor cycles- a full mob inventory loop using GetDroppableFlag() to determine if anything needs to be destroyed.

I have to say, though- removing all gear drops from all spawns may have the unintended side effect of encouraging CvC- after all, a level one PC drops /all/ their gear (equipped or in inventory), plus whatever they had left of their 300 gp starting gold. That's a pretty stunning difference from a mob of similar CR. I suspect that's always going to be true, but I remain a fan of the "drops weapon but not armor", assuming it had a weapon. Ammunition to some extent as well, though not as important unless we bring back more realistic encumbrance for ammunition.

[ç i p h é r]

I'm with AL on the "drops weapons but not armor", but I don't want to beat a dead horse if this has already been discussed and debated ad nauseum.

[AcadiusLost]

Discussions aside- the question is, should we be making special arrangements ain the ACR code to "enforce" that no gear drops? Right now that is logistically in the hands of the builder (or ABR toolsetter, as the case may be), so there are likely to be differences here and there.

If so, would it be more efficient to re-set the droppable flags (on spawn, busy time), or destroy things with droppable set onDeath (in combat, also a busy time). Further, how can we exempt plot-related quest items from being so nuked? (or proper ACR "loot", once we have tables to generate it?)

[Rusty]

I assumed simply directing builders to have their mobs set to not drop gear was the simplest solution, tho' central enforcement is always a bonus.

[ç i p h é r]

We can skip any items marked as plot with GetPlotFlag().

Maybe we can destroy corpse inventories and spawn ACR loot in the OnOpen event of the mob corpse/container? That way, we don't expend any extra cycles if players are uninterested in mob dropped loot (typical of high levels wading through low CR mobs). And if the engine doesn't already do it, we can set a timer on these containers to destroy them (garbage collection script).

[AcadiusLost]

Currently, the "lootable corpses" are the default ones created by the engine- I don't believe they have an editable blueprint that we can hook with acf_pl_* files to get at the OnOpen event. I know in NWN1 we had some systems by which we could generate a stocked placeable corpse via scripting, but I'm not familiar with how the default behaviour was overridden.

If people are fine with leaving the "spawns should never drop any of their gear" situation to the builders to enforce, it's proably more efficient not to worry about having another level of script-enforcement added.

But back to the original questions:

What value is good for n? (Right now I have Alara's 5.0 "opening bid" in as a placeholder)

How do we want to handle Creature Type multipliers? (+/- CR, or 0,1,2 multipliers?) - Right now I've got handling for both in the code, but we need to have a guideline for builders, and two parallel systems for the same end is undesirable.

How do we want the randomizing distribution set, for mean and stdev? (Currently have mean = 1.0, standard deviation at 0.5, but this means CR1 creatures are usually going to be dropping at least 2-3 gold, more often 5 gp, and sometimes 7-8 gp- doesn't really fit the "0.01-1" range that Rusty had spoken of in the earlier posts. Perhaps a larger standard deviation? Though that cuts both ways, you'll see larger drops with equal frequency.)

If I can, I'll try to confirm that my code works tonight- but before we drop it into the ACR and release it, I'd like to get answers from the above that have standards/DMA approval.

[AcadiusLost]

Still looking for the answers to the above questions- but things are working right now. One quirk of the Normal Distribution, Mean=1, stdev=0.3, is that most everything will drop at least 1 gp (using the gold-only placeholder version). We may want to tweak the mean down and increase the standard deviation (or leave the mean, increase stdev, and decrease n).

Currently, this has CR 0.33 orcs dropping 0-3 GP (usually 1), and a CR 3.5 shaman dropping 10-17 gp or so.

[Veilan]

I'd prefer a subtracted constant to increasing the spread, with or without altering n, if the 1 gp minimum is deemed a problem. I haven't run any math on this yet, but a gut feeling tells me a slapped on "-CR" or the like might work out nicely. That constant could take the place of the -Eq if the formula is already in use like that.
I think we won't need the -Eq anymore, because I believe the broad consensus was to not drop equipment consistently, but only as occasional part of the GP value the mob would drop after the formula.
So the 10-17 gold shaman could occasionally drop his quarterstaff, but only 5-13 coins then.

[AcadiusLost]

With regards to the randomizing function, it's a matter of what we want from it. Should defeating a group of 10 orcs leave behind 10 "loot bags", each of which has 1-2 gold, or should just two or three of those have 3-6 gp? The latter is easier on server resources, less tedious for the players, and perhaps more believable IC (unless they're communist orcs?). The same problem will crop up at higher CR though, if all we do to address it is tune down one of the linear adjustments, and tune up the standard deviation.


What about the Creature Modifier for drop wealth (as defined on the blueprint?) Did we want to lock it in as a multiplier (0,1,2), or set it as a +/- CR float? I'll leave both in place, but wanted a call on which should be Standard Proceedure for builders, so there's not confusion on the matter.

[Veilan]

We were told we don't yet have a good way to create encounter based rewards, and decided to go for individual CR for now, and leave special rewards (like making it all the way through a dungeon) builder / DM responsibility.

However, I guess a rough heuristic could be to just boost average value per CR mob, and add, say, a 75% "swipe" condition - i.e. a 25% condition of spawning a drop in the first place. That way you could do something pretty close considering those 10 orcs, due to the virtue of stochastics, maintain the average wealth, just not the same per individual orc.

It's a good thought, I'd also prefer an approach towards that direction, if it doesn't add a notable strain or burden.