Controlling +WEAPON.NOAUTOAIM

[Ed the Bat]

I understand that adding the +WEAPON.NOAUTOAIM flag to a weapon will force it to ignore any autoaim settings the player may have active. This is especially important for weapons with projectiles that are affected by gravity, which the autoaim will not properly compensate for, requiring manual adjustment by the player's aim.

My question is, can I control this flag on-the-fly? I have a weapon that will need this flag for its altfire to function correctly, but I would like its primary fire to honor autoaim. The flag applies to the entire weapon, and I can't control it with A_ChangeFlag because using commands like that in a weapon will control the flags on the player holding it, not on the weapon itself. This will create an error since +WEAPON.____ flags are exclusive to weapons, and unavailable to players.

I know it's an unusual situation to have two firing modes on one weapon so distinct from one another like this, but does anyone have any advice on how I might achieve my objective?

[XutaWoo]

My question is, can I control flags of weapons on-the-fly?

Here's the real question.

The answer is no, no you cannot. Inventory items, outside of their Spawn state mess with their owner's flags; their flags are set in stone.

[Ed the Bat]

Yeah, that's about what I was afraid of. I guess the inflexibility of a flag is the downside to it being so simple and easy to use.

[SFJake]

I do not understand this limitation.

You can change a monster's flag on the spot and it is INCREDIBLY useful.

This should be a suggestion. I can't imagine it being that complex an idea, unless there is some strange reasons that makes flags on weapons or items in particular so much more complicated to deal with than monsters.

[Ed the Bat]

As I understand it, weapons (and most inventory items, for that matter) require a lot of special considerations, especially considering how they co-operate with other actors, such as player characters. It can't really be so simple as you believe, or I honestly would have to imagine there'd already be methods to handle that kind of thing.

[Xaser]

I do not understand this limitation.

It's a limitation precisely for the same reasons you can't do many other "obvious" things: nobody has implemented it yet. The nature of how inventory items deal with things (namely, that their state functions treat the item's owner as the activator) means that this apparent "feature gap" is the result of someone not having introduced a function that does something different from the norm.

Even still, it may not be so simple anyhow, depending on how carved in stone the "inventory items' states treat owner as caller" behavior is. Keep in mind I haven't looked at this bit of code yet so I'm talking out of thin air, of course.

[XutaWoo]

I do not understand this limitation.

It's not so much a limitation as a possibly unintuitive feature and its side-effect.

Inventory items change the flags and properties of their owners. This is entirely intentional. It's just that +WEAPON.NOAUTOAIM is a weapon flag, which, well, means it's completely useless on a player.

[FDARI]

Well, I did make this "crutch" at some point: http://forum.zdoom.org/viewtopic.php?f=34&t=31590
It adresses the issue, and the solution may apply to weapons, but Graf would (somewhat understandably) rather have Doomscript.

What I hope is that Randy's bug hunt will lead to a new official version followed by a drive to complete the Doomscript branch. If he instead releases a new version and takes a break (which is still very nice of him) with no more clarity regarding Doomscript, I will once again really want this feature. Either in zdoom or in ToB.

This solution would be interchangeable with any other solution to the same problem.