Allow finer-grained control over artillery shots via flares

[devshark]

After inquiring how to wrap up a mod feature i've been working on, it turns out it was currently impossible.

My use-case is to have the vanilla artillery-turret support all of my new artillery ammo types (currently 4) but also somehow having a finer-grained control over which one gets shot with a flare. so far, i've made new flares but then ran into the problem.

The modding problem is, vanilla artillery-turrets, use artillery-wagon's gun. it accepts only the "artillery_shell" ammo_category. the flares themselves apply to a whole ammo_category. so even when i change the ammos' category to my own, the vanilla turret cannot shoot them anymore.

my initial proposal would be one of these:
1) ammo_categories having a parent. e.g. all specialized ammo types are derived from artillery-shell so that the arty turret can shoot them. but they respond to their own flares.
2) turrets taking in a list/array of ammo_category they support
3) the "shot_type" parameter on the flare, similar to "shot_category" but checking for loaded ammo's entity name

I'm leaning towards #2, but any one of these would avoid the need to have to reimplement the whole artillery "stack" when making new artillery ammo "types".

Currently, the problem is - since a flare affects the whole "shot_category" meaning the whole "ammo_category", making new artillery ammos with categories different than "artillery-shell" makes them unshootable by the vanilla artillery-turret (which uses the artillery-wagon's gun) which accepts only "artillery-shell" ammo category.

Having it (the weapon) accept a list of supported ammo_category or supporting ammo_category parenting/inheritance would solve this problem.
e.g. making the turret accept a

Code: Select all

ammo_category = { "artillery-shell", "custom-artillery-shell" }

or something like this:

Code: Select all

{
    type = "ammo-category"
    name = "custom-artillery-shell"
    parent = "artillery-shell"
}

i hope you get the idea.

EDIT/UPDATE: for what it's worth, i offered to help implement this feature but was told by Scott it'd be best to post it here. if there are no "free hands" and this change is determined to be worth implementing, the offer to help roll it out still stands.

[Honktown]

Interestingly, ArtilleryRemoteCapsuleAction is not documented in the api, though it has an entry in the wiki.

I was going to say register to the event on_player_used_capsule and fire a filtered artillery with the proper ammo and in range, but the last bit is missing: there doesn't seem to be a way to force attack a position.

You could try https://lua-api.factorio.com/latest/Con ... ml#Command
defines.command.attack

May require making an invisible, nonmoving, unselectable unit that is peaceful and will die in 1 hit.

[devshark]

@Honktown, thanks for the suggestion, but that workaround is unacceptable. I need the vanilla artillery-turret to be able to accept (load) and fire different ammo categories, because the ammunitions themselves need to differ from the "artillery-shell" category to be able to respond to different flares (because flares affect the whole ammo-category)

As it is, implementing artillery ammos that shouldn't response to the defaul artillery-remote (their category being something other than "artillery-shell") requires the mod-maker to implement the whole artillery-stack just for it.

But, if this gets rejected, i'll come up with a workaround and your suggestion will certainly help in that case.

[Honktown]

@Honktown, thanks for the suggestion, but that workaround is unacceptable. I need the vanilla artillery-turret to be able to accept (load) and fire different ammo categories, because the ammunitions themselves need to differ from the "artillery-shell" category to be able to respond to different flares (because flares affect the whole ammo-category)

As it is, implementing artillery ammos that shouldn't response to the defaul artillery-remote (their category being something other than "artillery-shell") requires the mod-maker to implement the whole artillery-stack just for it.

But, if this gets rejected, i'll come up with a workaround and your suggestion will certainly help in that case.

There may have been a misunderstanding? I assumed you used the base turret, and it could have different ammos loaded. The default behavior can't be overridden I think (that they fire against anything in range), but their extra behavior certainly can be. The filter would select all artillery on the surface, and then check if the available ammo is loaded, not filter different kinds of artillery.

I was doing other things, and I found for a unit to receive a command, it (SHOULD?) be added to a group or be ai_controllable. ai_controllable is probably not good to enable for the player, so:

https://lua-api.factorio.com/latest/LuaUnitGroup.html

It's unclear whether an artillery can command attack an entity outside of the normal range; if it would use the max range. I may try messing with it, because my current mods have added another shell. Worst case I try changing the artillery range bonus, issuing the attack command, and setting the range bonus back in the same function. It could be a useful little library to implement: ammo-specific targeting remotes, which could even apply to other mods which have implemented automatic attackers. Add in a few useful extras like a "stand ground" or "patrol" remote and we have some more complex mechanics going.

[devshark]

There may have been a misunderstanding? I assumed you used the base turret, and it could have different ammos loaded.

Yes, they could be loaded as long as their ammo-category is "artillery-shell". as soon as that is changed to "custom-artillery-shell" so that they are no longer affected by the vanilla artillery remote, the ammo becomes unloadable and unshootable.

[devshark]

bumping for visibility.

[Bilka]

AttackParameters::ammo_categories was added for the next version, I believe that resolves this :)