Remote Mines

[ILMTitan]

I believe you are referring to noAutoFire? Using that won't work, because it sets the unit to fire state 0 (hold fire).
Perhaps if I change it from bool to int, and have default 0 -> normal toggle, 1 -> hold fire (these two representing the original states), 2 -> return fire, 3 -> fire at will?

[NOiZE]

So i just need to add KamikazeFireControl=1; to my mine's FBI's and then ppl can choose between fireatwill and hold fire? or are more tags needed?

[Pxtl]

I believe you are referring to noAutoFire? Using that won't work, because it sets the unit to fire state 0 (hold fire).
Perhaps if I change it from bool to int, and have default 0 -> normal toggle, 1 -> hold fire (these two representing the original states), 2 -> return fire, 3 -> fire at will?

Oh. My bad.

So there isn't any tag to override the default fire-state for a unit that could be reapplied also provide the _only_ firestate where NoAutoFire is enabled? Or does "NoAutoFire" override this option? To me, it would make sense that it be two tags - one to control the ability of the user to change the fire-control, a second to set the default (and possibly _only_ fire-control option). But that would be slightly confusing, given the very specific name of the "NoAutoFire" tag.

Either way, any solution is better than no solution, so my nitpicking is pointless.

[KDR_11k]

There's standingFireOrders or something, two tags with one saying whether to show the switch and the other saying what it should default to (was used for things like having Berthas spawn on Hold Fire in OTA), no idea how much Spring uses those.

[Pxtl]

There's standingFireOrders or something, two tags with one saying whether to show the switch and the other saying what it should default to (was used for things like having Berthas spawn on Hold Fire in OTA), no idea how much Spring uses those.

Google shows standingFireOrders as a COB variable, but the Wiki says nothing about it in the FBI. If this doesn't exist, a StandingFireOrders tag (0=inherit from builder, 1-3=default) combined with a CanChangeFireOrders tag would provide a nice generalist-solution. Incorporating StandingFireOrders into NoAutoFire would be wierd, since the logic for StandingFireOrders would be "default 0, unless NoAutoFire is enabled, then default 1, but StandingFireOrders takes precedence over NoAutoFire". weird, like I said. Damnit, I need to set up VC++ on my machine so I can try this stuff myself - haven't coded C++ in half a decade, though.

On the other hand, 2 more tags might be more tag-soup than 1 more tag.

[ILMTitan]

I do believe that the two tags you describe would be more correct, and would allow noAutoFire to be deprecated (making it essentially 1 extra tag). I only have two minor concerns with it: 1. Mines would default back to having the fire state toggle 2. The way I think I would implement it would remove the ability of LUA to effectively change noAutoFire. I don't know if any existing scripts use noAutoFire.