Caps not required. Words were meaningful on their own. Severe underestimation is not welcome.
I would be surprised if this feature were added. All weapon classes must be registered at load-time, in an array accessible by an ACS-function. The most convenient data to store in the array might be the NAME (zdoom-specific string with unique integer ID) as an integer. The ACS-function returns the name, and print/strparam with a feature that has been submitted for consideration (
viewtopic.php?f=34&t=30806) could be used to extract a string for ACS. For the string to have any utility it must be processed through the STRPARAM-function.
So -
New ACS function: int GameWeaponCount(): returns the number of weapon classes registered
New ACS function: int GameWeaponName(int index): returns the INT that can be evaluated to a weapon's classname
Submitted ACS extension: print/strparam(g:name_int): print name-int as string
Give random weapon:
GiveIventory( STRPARAM(g: GameWeaponName( random(0, GameWeaponCount()-1) ) ), 1);
Other concerns about the suggestion:
Why not extend it to all inventory objects? (Possibly accessing them through separate functions according to category)
You could have categories on base-classes: WeaponPickup (all inherited from weaon), HealthPickup (all inherited from health), AmmoPickup (all...), Pickup (any other pickup)
How to avoid giving things that should not be given?
The sigil in strife, and weapons used for non-military purposes, such as triggering or executing a cutscene / event. How not to hand them out? (More relevant notion of item that must not be given: A single class serving only as parent to 5 or 10 other classes, designed never to come into play itself).
Anything that would not be given by GIVE ALL (CCMD) should be filtered out of these arrays, as it is implied that randomly acquiring this is not good for gameplay.
Additionally, inventory might require an extra property or declaration element, to exclude it from the array.
If we choose only to support actors defined in decorate at this point, it is probably quite doable, and I have sometimes wanted something like this, as I tire easily of writing tables of weapon-names and finding them absent in other mods. However, when combining mods, you might in gameplay end up with only weapons from one of the mods, if they both replace the same spawning objects; but actor definitions from both mods will exist, meaning this feature will draw on definitions that do probably not suit the rest of the feature-set.