Deocorate Value Extension

[Project Shadowcat]

This portion is already doable in ACS... [wiki]SetAmmoCapacity[/wiki]

A purely DECORATE way of doing this would be nice, though.

I won't disagree.

[Graf Zahl]

I do. DECORATE in its current state will not provide solutions for every eventuality - especially ones like this that may be used in one out of 1000 projects.

[Amuscaria]

I do. DECORATE in its current state will not provide solutions for every eventuality - especially ones like this that may be used in one out of 1000 projects.

That's because only 1/1000 projects are large scale.

[Graf Zahl]

Then these special projects can surely use ACS with DECORATE. Just adding bloat to the engine so that you can avoid a minor inconvenience is not a good design decision.

[CO2]

Alright, what we need is a way for this kind of thing to happen.

Dynamic ammo capacities - This is already supported via ACS, so that's ok.
Some sort of function like random() that you can specify a type and it returns the number of the item held, so that way with some simple math we could take that result, and generate a number that is lower the more of said item is held for things such as hitscan offsets, or whatnot. If we can get that then the rest of this should be settled, and if it's already in, I have to agree with Graf, acs combined with decorate can already do what you need.

[Gez]

I do. DECORATE in its current state will not provide solutions for every eventuality - especially ones like this that may be used in one out of 1000 projects.

I was thinking of a property for a (new) inventory subclass, not a codepointer.

[Graf Zahl]

That'd be even worse. I won't add new code for things that can already be done just so some people that refuse to make 'dirty hacks' that combine DECORATE with ACS. The real hack would be the addition of a redundant feature.

[Graf Zahl]

Once we got a proper scripting language this will come automatically. But with DECORATE as it is it won't happen. I might as well close this thread.